February 06, 2007
> 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 second that.
February 06, 2007
Walter Bright schrieb:

> The idea is to enable the creation of DSLs (Domain Specific Languages)

Kevin Bealer schrieb :
> 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.

to figure it out / This means /

procedure foo( num1, num2 )
  return aValue

or

PROCEDURE fo
  IN PARAMETERS num1, num2
  OUT PARAMETERS aValue


Is this something I can establish in D since 1.005 ?
?
Bjoern


Kevin Bealer schrieb:
> 
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.
> 
> This is just the start of what's going to happen with D 2.0.

For those who haven't seen it, Walter updated http://www.digitalmars.com/d/mixin.html with a simple example of what you can do with the mixin string mojo.

Phobos also has new documentation for metastrings:
http://www.digitalmars.com/d/phobos/std_metastrings.html

It looks like this feature is calling out for some sort of new 'here document' syntax, so that the code in strings can look and read more like code.

It certainly seems to solve the long standing 'can't generate identifiers at compile time' feature request.  And then some. :-)

It'll be very exciting to see what people come up with!

--bb
February 06, 2007
Nice!

That new mixin stuff will be great for that stacktrace I'm planning to do for months now ... gotta try that out asap :)

-Mike

Am 06.02.2007, 05:54 Uhr, schrieb Walter Bright <newshound@digitalmars.com>:

> Fixes many bugs, some serious.
>
> Some new goodies.
>
> http://www.digitalmars.com/d/changelog.html
>
> http://ftp.digitalmars.com/dmd.1.005.zip



-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
February 06, 2007
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


BLS schrieb:
> Walter Bright schrieb:
> 
>  > The idea is to enable the creation of DSLs (Domain Specific Languages)
> 
> Kevin Bealer schrieb :
>  > 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.
> 
> to figure it out / This means /
> 
> procedure foo( num1, num2 )
>   return aValue
> 
> or
> 
> PROCEDURE fo
>   IN PARAMETERS num1, num2
>   OUT PARAMETERS aValue
> 
> 
> Is this something I can establish in D since 1.005 ?
> ?
> Bjoern
> 
> 
> Kevin Bealer schrieb:
> 
>>
February 06, 2007
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

"The AssignExpression must evaluate at compile time to a constant string. The text contents of the string must be compilable as a valid StatementList, and is compiled as such.:"

Arbitrary code generation?!  This ought to make for some really slick compile-time code generators - say goodbye to delegate calling overhead and static variable bloat.

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)

Awesome update Walter - thanks again. :)

-- 
- EricAnderton at yahoo
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.

It's funny you should say that.  I was kidding with Kris in IRC last week about how you could just slap a copy of DMDScript in the compiler and let us talk to it directly from within templates.  While this isn't letting us muck about with the AST, to create specalized grammars, this is certainly a more elegant solution.

... and it doesn't even require a separate syntax.

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


-- 
- EricAnderton at yahoo
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

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.

-- 
- EricAnderton at yahoo
February 06, 2007
Pragma wrote:
> Walter Bright wrote:
>> 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.
> 
> It's funny you should say that.  I was kidding with Kris in IRC last week about how you could just slap a copy of DMDScript in the compiler and let us talk to it directly from within templates.  While this isn't letting us muck about with the AST, to create specalized grammars, this is certainly a more elegant solution.
> 
> ... and it doesn't even require a separate syntax.

Andrei and I toyed with that exact idea for a while. It got shot down after it became clear that since DMDScript has a "same-only-different" syntax from D, it would be terribly confusing.
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.

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.