View mode: basic / threaded / horizontal-split · Log in · Help
February 28, 2005
Re: DMD 0.114 release
Another thing, the socket documentation is still the old one; it doesn't  
include the new stuff.
February 28, 2005
Re: DMD 0.114 release
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
Re: DMD 0.114 release
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
Re: DMD 0.114 release
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
Re: DMD 0.114 release
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
Re: DMD 0.114 release
"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
Re: DMD 0.114 release
Clearly, I've botched folding in your update. I'll try and get it all fixed
tonight.
March 01, 2005
Re: DMD 0.114 release
Nifty idea there, Georg!

-JJR
March 01, 2005
Re: DMD 0.114 release
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 broken (was Re: DMD 0.114 release)
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
1 2 3 4 5
Top | Discussion index | About this forum | D home