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
Wow, this is no small change .. this should've ben dmd 1.2 or something.
Now, there's already been alot of talk about what new doors this might
open, so I'm not gonna talk about that.
What concerns me is that this will make semantic analysis more difficult
to implement.
Just think about "build/bud" for example, now the author will have to
worry about things like:
mixin("import x.y.z");
or even worse:
mixin(templ1!(something, templ2!(somethingelse), "x.y"));
I don't see how it's possible to interpret that without implementing a
full compiler.
P.S. I know that for "build" all we need is a list of import files, and
dmd already has a switch to do that.

Hasan Aljudy wrote:
> I don't see how it's possible to interpret that without implementing a
> full compiler.
You're right, it isn't possible.
> P.S. I know that for "build" all we need is a list of import files, and
> dmd already has a switch to do that.
DMD will also output a list of files that are textually imported, so bud
can pick them up at least the second time around.

Hasan Aljudy escribió:
>
>
> 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
>
> Wow, this is no small change .. this should've ben dmd 1.2 or something.
>
> Now, there's already been alot of talk about what new doors this might
> open, so I'm not gonna talk about that.
>
> What concerns me is that this will make semantic analysis more difficult
> to implement.
>
> Just think about "build/bud" for example, now the author will have to
> worry about things like:
> mixin("import x.y.z");
>
> or even worse:
> mixin(templ1!(something, templ2!(somethingelse), "x.y"));
>
> I don't see how it's possible to interpret that without implementing a
> full compiler.
>
> P.S. I know that for "build" all we need is a list of import files, and
> dmd already has a switch to do that.
I also like the new features and think the same as you.
First, I don't know what is the real beneffit of this features. I mean,
I want to see a real world example using mixins before thinking they are
great (BTW, the first time I saw them PHP inmediately came into my
head... even more after the post about """ @msg """).
Second, this makes even harder to get good IDE support for D. You can
have syntax coloring, and that's it. Autocompletion is going to be a
very though part: the IDE must act as a compiler, as you say it, to
figure out what the program will look like so that it can know what are
the declarations available to the programmer.
Anyway, I'm still working on Descent, and when I get to that part (which
I plan to implement because it's all there, in DMD... I guess?), I'll
tell you. :-)

BCS wrote:
> 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.
I suspect that generating debug info will require the mixed-in code to
be expanded in place with the proper #line directives, etc, in the
object file.
>> 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.
Yup. I think for a standalone code generator, it would probably be
better to generate the output file completely through pragma(msg) so as
to omit the template code used for processing the mixins. For example,
I figure it shouldn't be terribly difficult to do D codegen from a UML
file in template code, etc.
Sean

Ary Manzana wrote:
> Second, this makes even harder to get good IDE support for D. You can
> have syntax coloring, and that's it. Autocompletion is going to be a
> very though part: the IDE must act as a compiler, as you say it, to
> figure out what the program will look like so that it can know what are
> the declarations available to the programmer.
True, but on the other hand, specifically not supporting it in the IDE
may act as a needed brake on evil uses of it.

Walter Bright escribió:
> Ary Manzana wrote:
>> Second, this makes even harder to get good IDE support for D. You can
>> have syntax coloring, and that's it. Autocompletion is going to be a
>> very though part: the IDE must act as a compiler, as you say it, to
>> figure out what the program will look like so that it can know what
>> are the declarations available to the programmer.
>
> True, but on the other hand, specifically not supporting it in the IDE
> may act as a needed brake on evil uses of it.
I didn't say an IDE won't support it, I said it'll be very hard to get
there :-)
But... I'm wondering which are the evil uses of it. For me it's now
almost impossible not to program with an IDE (big projects, I mean). At
least in Java. Maybe compile time stuff will make it such that an IDE
won't be needed anymore. But it's very hard for me to see that happening.

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
I am not a D programmer (yet) only observing what is happening.
I compare the new "code generation at compile-time" stuff in D with
Forth. Forth also has a built-in interpreter & compiler which extends
the language and can also execute macros at compile-time through
EVALUATE. Of course Forth is much more low-level than D. But IMO the new
mixins are not a "radical programming paradigm change".
Perhaps I just did misunderstand something?
Andreas

Ary Manzana wrote:
> Walter Bright escribió:
>> Ary Manzana wrote:
>>> Second, this makes even harder to get good IDE support for D. You can
>>> have syntax coloring, and that's it. Autocompletion is going to be a
>>> very though part: the IDE must act as a compiler, as you say it, to
>>> figure out what the program will look like so that it can know what
>>> are the declarations available to the programmer.
>>
>> True, but on the other hand, specifically not supporting it in the IDE
>> may act as a needed brake on evil uses of it.
>
> I didn't say an IDE won't support it, I said it'll be very hard to get
> there :-)
>
> But... I'm wondering which are the evil uses of it. For me it's now
> almost impossible not to program with an IDE (big projects, I mean). At
> least in Java. Maybe compile time stuff will make it such that an IDE
> won't be needed anymore. But it's very hard for me to see that happening.
Oddly, I've found myself moving away from IDEs over the years, perhaps
partially because the editors I like to use aren't IDEs. About the only
time I use an IDE any more is for debugging... coding happens elsewhere.
Sean