February 06, 2007
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.
February 06, 2007
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.
February 06, 2007
Kirk McDonald 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
> 
> 
> Mwahaha! This program, when run, prints out a copy of its own source. It also has some completely gratuitous new-style mixins.
> 
> // file test.d
> mixin(`import std.stdio : writefln;`);
> 
> mixin(`void main() {
>     mixin("writefln(import(\"test.d\"));");
> }`);
>


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__));}
February 06, 2007
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
February 06, 2007
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__));}
February 06, 2007
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
February 06, 2007
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.
February 06, 2007
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
February 06, 2007
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>
February 06, 2007
Pragma schrieb:
> 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
> 
> 
> Just try to wrap your head around this: http://www.digitalmars.com/d/mixin.html
> 
> template GenStruct(char[] Name, char[] M1)
> {
>     const char[] GenStruct = "struct " ~ Name ~ "{ int " ~ M1 ~ "; }";
> }
> 
> mixin(GenStruct!("Foo", "bar"));
> 
> //which generates:
> 
> struct Foo { int bar; }
> 
> In short this means that we can have *100%* arbitrary code generation at compile time, w/o need of a new grammar to support the capability.
> 

Hi Eric,
I am able to read and understand the code. (not nessesarily the far reaching implications)
But the generated code is still D. So what does it mean :
Walter Bright schrieb:
> The idea is to enable the creation of DSLs (Domain Specific Languages)
How ?
Bjoern
Post scriptum
I can imagine the following scenario : D Compiler is calling a Translator, a modified Enki f.i. to translate a Domain Specific Language into D ... strange