February 28, 2005
Another thing, the socket documentation is still the old one; it doesn't include the new stuff.
February 28, 2005
Vathix says...
>
>Another thing, the socket documentation is still the old one; it doesn't include the new stuff.

ok, we definitely need a new version. ;-)

So, question, does this mean that I don't have to,

dmd source.d ws2_32.lib

anymore?


February 28, 2005
In article <cvvu8r$h9u$1@digitaldaemon.com>, jicman says...
>
>Vathix says...
>>
>>Another thing, the socket documentation is still the old one; it doesn't include the new stuff.
>
>ok, we definitely need a new version. ;-)

I think your right.

If I may make a suggestion to the powers controlling the 0.114 distros. of D (zip's, rpms, ebuilds, etc.)..

Pull the 0.114 download links and just replace them with 0.115 once the content is available (take 0.114 out of circulation to avoid the inevitable bug feedback on this stuff).

- Dave

>
>So, question, does this mean that I don't have to,
>
>dmd source.d ws2_32.lib
>
>anymore?
>
>


February 28, 2005
On Mon, 28 Feb 2005 20:17:31 +0000 (UTC), jicman <jicman_member@pathlink.com> wrote:

> Vathix says...
>>
>> Another thing, the socket documentation is still the old one; it doesn't
>> include the new stuff.
>
> ok, we definitely need a new version. ;-)
>
> So, question, does this mean that I don't have to,
>
> dmd source.d ws2_32.lib
>
> anymore?
>

You will still have to do that.
February 28, 2005
Walter wrote:
> Lots of new string and regexp stuff:
> 
> http://www.digitalmars.com/d/changelog.html
> 
> A number of people have proposed having regular expression literals of the
> form:
> 
>     /regexp/
> 
> The advantages are it is visually distinct and it can be overloaded
> separately from strings. There are two problems with it:

Thanks for trying!!!!!!!!     A proposal below here.

> The first is distinguishing a regexp literal from a divide / or /= token.
> Languages that do support /regexp/ do it with a hack where the syntax parser
> tells the lexer "I'm expecting an operator" or "I'm expecting a term". In
> other words, the distinction between lexer and syntax analysis is lost.
> 
> The second is that D has 3 character types already. Adding in a /regexp/
> literal implies adding in 3 more types. Then you're obliged to create more
> overloads, more conversions, more rules. Not worth it.

Suppose we want to get rid of these two problems.

We'd have to conjure up a way to avoid having the lexer identify a regexp. Then we'd have to avoid needing 3 more types.

While a nice concept, the Unquoted Regular Expression is undeniably hard on the lexer. Regexps like

/ 2*3 /
/2 + 3 /

etc. are admittedly labourious. (While I (currently) think they are not ambiguous, especially if we restrict regexps to be contained within a single line, I understand that this would be too much work for D 1.0.)

As to the type thing, you're right, that would be way too much code writing and maintenance.

So, I outlined a solution. (Mind you, I haven't investigated it thoroughly, so it's just a suggestion.)


Instead of a special quoting mechanism ( /bla/ ) to differentiate between regexps and strings, we could use the context instead. In other words, whenever an anonymous function is expected, and a string is found, then the string would be considered a regular expression.

Thus, if bar is a string type variable, then

bar = "foo";

would be an assignment of string. And if bar is a type that "can contain a function", then

bar = "foo";

would be an assignment of an anonymous function.

If we do it like this, then there would be no syntactical difference between literals in source code and arbitrary regexps encountered at runtime. Any time you assign a string to a function variable, it would be considered a regexp -- and therefore compiled (if source then compiled into the binary, if runtime then jit-style compiled) before assignment.

This would obviate the need for the 3 new types. And it would let us use the regexps as earlier proposed. Examples:


found = "lskdjflskj" (theText);
ok = "lkajsdlkjaksdf" (aDataLine, i, theDollars);
ok = aStringVar (inputLine, pos, outArray);

enum {entireMatch, firstNam, lastNam}
if ( "lkjslkjlskjdlksjdf" (currentLine, where, S) )
{
    victim = S[lastNam] ~ " ," ~ S[firstNam];
}
// (entireMatch was missing in earlier examples.
//  Sub expressions start from S[1], like $1, etc.)

if( "^.*--" (inputline, i) &&
    " *XXX" (inputline, i) &&
    "[0-9]" (inputline, i) )
       showMessage("Line conforms to spec.");

if( findProlog (inFile, j) &&
    findNugget (inFile, j) &&
    findEpilog (inFile, j) )
       showMessage ("File is Well Formed.");
March 01, 2005
"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4223AC98.5070507@nospam.org...
> So, I outlined a solution. (Mind you, I haven't investigated it thoroughly, so it's just a suggestion.)

Hmm. If I could generalize, then any string immediately followed by parentheses would be considered a regular expression, and then the special semantics? That might actually work, but such things often have unintended consequences. Have to think about it.


March 01, 2005
Clearly, I've botched folding in your update. I'll try and get it all fixed tonight.


March 01, 2005
Nifty idea there, Georg!

-JJR
March 01, 2005
Why not just prefix the regexp with a keyword?

char[][] matches = regexp/match/(<string>);

That seems quite readable, it has the regexp-as-anon-func syntax, and it is trivial to detect in the lexical phase.

Walter wrote:
> Lots of new string and regexp stuff:
> 
> http://www.digitalmars.com/d/changelog.html
> 
> A number of people have proposed having regular expression literals of the
> form:
> 
>     /regexp/
> 
> The advantages are it is visually distinct and it can be overloaded
> separately from strings. There are two problems with it:
> 
> The first is distinguishing a regexp literal from a divide / or /= token.
> Languages that do support /regexp/ do it with a hack where the syntax parser
> tells the lexer "I'm expecting an operator" or "I'm expecting a term". In
> other words, the distinction between lexer and syntax analysis is lost.
> 
> The second is that D has 3 character types already. Adding in a /regexp/
> literal implies adding in 3 more types. Then you're obliged to create more
> overloads, more conversions, more rules. Not worth it.
> 
> 
March 01, 2005
DMDScript has been broken: "Error: circular initialization dependency with module value". I think it's caused between dmdscript.value (obviously) and dmdscript.protoerror (the only other static constructor is in dmdscript.lexer). The dependency seems to be: value -> dobject -> protoerror -> value. I only tested it on Windows.

OT: DMDScript source
Walter, don't you think the imports in DMDScript should all be private? Could you change that, please?

_______________________
Carlos Santander Bernal