Community

Pragma wrote:
> The import expression thing has me scratching my head though: what path
> does DMD use to determine where to find the imported file? (it's not
> clear in the documentation)
It just looks in the default directory. I know this is inadequate for a
long term solution, but I wanted to see what people thought of it before
spending a lot of effort on the details.

Walter Bright wrote:
> Kevin Bealer wrote:
>> You fixed all the bugs I've added in recent memory. Plus, if I
>> understand correctly, the implications of some of these features is
>> staggering...
>>
>> It looks like one could write a few hundred line module that can pull
>> in and do compile-time interpreting of a language of the complexity of
>> say, Scheme. And the code in the module could be both readable and
>> straightforward... And the results would be absorbed into the calling
>> code as normal optimizable statements...
>
> The irony is that it only took 3 hours to implement, which shows the
> power of having the lexing, parsing, and semantic passes be logically
> distinct.
>
> The idea is to enable the creation of DSLs (Domain Specific Languages)
> that don't have the crippling problem C++ expression templates have -
> that of being stuck with C++ operators and precedence.
>
> To make this work, however, one must be able to manipulate strings at
> compile time. I've made a start on a library to do this,
> std.metastrings, based on earlier work by Don Clugston and Eric Anderton.
You know the next step, right? A template version of htod!
include!("gl.h");
:D
L.

Lars Ivar Igesund wrote:
> Walter Bright wrote:
>
>
>>Fixes many bugs, some serious.
>>
>>Some new goodies.
>>
>>http://www.digitalmars.com/d/changelog.html
>>
>>http://ftp.digitalmars.com/dmd.1.005.zip
>
>
> Sounds like some nice new features, but even though the compiler seems to
> know that these new features are D 2.0, the spec don't show it. I'd suggest
> to branch the specification now, after all 1.0 shouldn't see any new
> feature changes. Without this, there is no point in the 1.0 marker
> whatsoever.
>
I also second that, branch the spec or annotate it *Vary* well. Either
way, the change log should say v2.0 as well

BCS kirjoitti:
> Without the gratuitous stuff that has to be the cleanest quine outside
> of bash (in bash an empty file prints nothing)
>
> import std.stdio;
> void main(){writef(import(__FILE__));}
And if the strings don't mess up with printf, it can be made even shorter:
void main(){printf(import(__FILE__));}

Walter Bright wrote:
>
> To make this work, however, one must be able to manipulate strings at
> compile time. I've made a start on a library to do this,
> std.metastrings, based on earlier work by Don Clugston and Eric Anderton.
>
> This is just the start of what's going to happen with D 2.0.
it needs some string manipulation stuff. I'd be more than happy to let
you put the string templates from dparse in. It has template to:
Discard leading white space
return a slice up to the first white space char
return a slice starting with the first white space char
Return a slice up-to but not including the first instance of t.
Return a slice starting after the first instance of t and containing the
rest of the string.
discard [ ]* then return [a-zA-Z_][a-zA-Z0-9_]*
non-string type template
return tuple with string broken up by d
return tuple with string broken up by white space
tuple cdr (think lisp)
check if anything in tuple begins with a given prefix
source at:
http://www.dsource.org/projects/scrapple/browser/trunk/dparser/dparse.d

Lionello Lunesu wrote:
> You know the next step, right? A template version of htod!
>
> include!("gl.h");
I did shy away from the "execute this shell command and insert its
output into a string literal" because that would turn a D compiler into
a huge security risk.

Walter Bright wrote:
> BLS wrote:
>> I guess here is a need for further explaination.
>>
>> Either I am an complete idiot (not completely unrealistic) and
>> missunderstood something, or a new, quit radical, programming
>> paradigmn change is on it s way. I mean it is difficult to realize
>> the implications.
>
> I think you're right. The only thing that makes me uneasy is the
> "preprocessor abuse" that comes up in C++. We should be careful in how
> we use this, lest the cuticle side of the thumb take over.
The most obvious danger is simply being able to eyeball what the source
code for a module actually is, but that's been an issue for any
sufficiently complex template code anyway. What I like about this
feature is that it improves upon the power of macros but does so without
providing a method for changing the meaning of existing symbols (the
"#define if while" problem). It also requires almost no new language
features, so it shouldn't have a tremendous learning curve. Finally,
since all this works via strings, it should be easy to determine what's
actually going on simply by tossing in a few pragma(msg) statements. If
there were a way to emit the "expanded" source we could even use this as
a "standalone" code generation tool of sorts. Nice work!
Sean

BLS wrote:
> I guess here is a need for further explaination.
>
> Either I am an complete idiot (not completely unrealistic) and
> missunderstood something, or a new, quit radical, programming paradigmn
> change is on it s way. I mean it is difficult to realize the implications.
> Bjoern
>
>
This could do thing like this:
BuildBarserFromFileSpec!("foo.bnf")
that would import "foo.bnf", parser a BNF grammar, and build a parser
from it. It even avoids the need to use functions for callbacks.
p.s.
I'm going to have to try and re-implement dparse using this.
Darn you Walter!!! I don't have time for this (cool stuff)!!! <G>