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?

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?
>
>

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.

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.");

"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.

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.
>
>

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