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 import stuff has been part of C for a long time (in the form of #include), however I've never seen it used.  Maybe with string operations it will be useful, but otherwise I don't see the point.

=Joel

Sean Kelly wrote:
> 
> 
> 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.  

How are #line directives handled? is their any way to tell the debugger to look at another file:

mixin(MixInThisFile("foo"));

// results in this

// stuff
#line foo, 127
// stuff from foo:127

#line ... // revert back to original file:line

Then, in the debugger, it would start stepping you through foo in the correct place.

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

Put in a pragma msg in place of the mixin and you get the code.

maybe a mixin(string, filename) form would be nice. It would dump to given file as well as generate code.

> 
> 
> Sean

janderson 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
> 
> 
> The import stuff has been part of C for a long time (in the form of #include), however I've never seen it used.  Maybe with string operations it will be useful, but otherwise I don't see the point.
> 
> =Joel

not quite, I don't think this works in c

char string[] = "#import<bigstring.txt>"

sting gets the value of "#import<bigstring.txt>", not the contents of "bigstring.txt"

Sean Kelly wrote:
> If there were a way to emit the "expanded" source we could even use this as a "standalone" code generation tool of sorts.

Now there's something that's missing.  At least with C compilers, they can usually be asked to spit out what things look like after the pre-processor is done with it.  Getting the same kind of results from DMD, after all templates are evaluated would be great for diagnostics and debugging.

-- 
- EricAnderton at yahoo

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

BCS: I may be tempted to Enki-ize your work once you're done with that. I think a compile-time rendition is due. ;)

-- 
- EricAnderton at yahoo

Pragma wrote:
> BCS wrote:
>> p.s.
>> I'm going to have to try and re-implement dparse using this.
>>
> 
> BCS: I may be tempted to Enki-ize your work once you're done with that. I think a compile-time rendition is due. ;)
> 

Done? What is that? I haven't heard the term before. <g>

BLS wrote:
> 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


I think you answered your own question. :)

Take the compile-time regexp lib that Don and I wrote a while back.  Technically, Regular-expressions are a DSL of sorts.  This feature just makes the implementation of stuff like that easier.  The end result will still be D code.

auto widget = CreateNewWidget!("Some DSL Code");

I was confused too, since the wording could be interpreted as allowing you to just code in some other language, wherever you want.  This is not the case.  Ultimately, any DSL implemented in this fashion is going to have to operate on static strings.

> 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

I've thought about that too- much like BCS's work.  The only thing keeping me from doing this *was* that the code generated would be largely inferior to that created by an external program.  Thanks to the new syntax of mixin(), this is no longer the case.

-- 
- EricAnderton at yahoo

BCS wrote:
> Pragma wrote:
>> BCS wrote:
>>> p.s.
>>> I'm going to have to try and re-implement dparse using this.
>>>
>>
>> BCS: I may be tempted to Enki-ize your work once you're done with that. I think a compile-time rendition is due. ;)
>>
> 
> Done? What is that? I haven't heard the term before. <g>

BCS, you're not working at 3D-realms by any chance, are you? <eg>

-- 
- EricAnderton at yahoo

janderson wrote:
> The import stuff has been part of C for a long time (in the form of #include), however I've never seen it used.  Maybe with string operations it will be useful, but otherwise I don't see the point.

The fundamental difference is that #include inserts *program text*, while import inserts the contents as a *string literal*.

Some things that you can do with import that you cannot do with #include:

1) You can have tech writers write "help text" files, which can then be imported by the programmers as string literals. This means the tech writers do not have to be concerned in the slightest with string syntax.

2) It's an easy way to bind binary data into a program. For example, let's say one wants to embed an icon (.ico) file into your program binary. In C, one would have to write:

	static unsigned char icon[] = { 0x00, 0x10, 0x53, 0x29, ... };

meaning one must translate the binary data in foo.ico to the hex notation.

In D, one can write:

	static ubyte[] icon = cast(ubyte[])import("foo.ico");

Updated DMD to 1.005 from 1.0 today and now I get this error:

' C:\dmd\src\ext\derelict\sdl\ttf.d(79): struct derelict.sdl.ttf._TTF_Font unknown
'  size
' C:\dmd\src\ext\derelict\sdl\ttf.d(79): struct derelict.sdl.ttf._TTF_Font no size
'  yet for forward reference

Does anybody know how to fix that? I've already searched the NG, the derelict forum, upgraded to the latest trunk ... nothing helped so far.

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