February 06, 2007
Reply to Ary,

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

Cool thought:

build a compiler / IDE where the would front end short of code-gen is ued to read in code and the editor actually edits the parsed code tree. Say goodbye to syntax errors, maybe even semantic ones as well because you can't edit code to something that isn't correct... Er, maybe that wouldn't be such a good idea. Anyway, what is on the screen is actually a rendering of the parsed stuff. Talk about fast compile times:

codetree.CodeGen(); // no parsing etc.

Also the same functions that do name scopeing can do auto-compleat (or the other way around). 


February 06, 2007
Pragma 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
> 
> 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.
> 

Combine that with the ever increasing power of Tuples, some of the slowly improving type info, and compile-time string manipulation.... and you've got programs that write programs for writing programs that generate the original program automatically.  o_O

I like it.  Might even scrap some old code in favor of it.

-- Chris Nicholson-Sauls
February 06, 2007
Pragma wrote:
> 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");

You just showed something that I've been pondering attempting with this.  Namely a GUI library that builds all forms/controls/etc from some sort of markup (probably modified XML or JSON), either at runtime /or/ compile-time.

-- Chris Nicholson-Sauls
February 06, 2007
Thanks! That worked :)

Am 06.02.2007, 19:28 Uhr, schrieb Thomas Brix Larsen <brix@brix-verden.dk>:

> mike wrote:
>
>> 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
>>
>
> It should read: struct _TTF_Font {}
> http://dsource.org/projects/derelict/browser/trunk/DerelictSDLttf/derelict/sdl/ttf.d
>
> - Brix
>



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

When you inherit code or start to code on an existing project, the ability to 'ctrl+click' to jump to that variables definition is a huge time saver, otherwise you have to grep through tons of files , and in large libraries the classes may be nested very deep, you might have to ctrl+click 5 times before you get to what you're looking for.

I've actually gone the opposite way, drifting towards IDE's over time, even though for 'one-moduler's it remains <insert favorite editor here>.

I am really looking forward to descent, I hope you can devote enough time to Ary.


Charlie
February 06, 2007
On Tue, 06 Feb 2007 11:55:18 -0800, Walter Bright wrote:

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

Thanks Walter! :-(

Bud is no longer a useful tool because it can no longer do what it was trying to do - namely find out which files needed recompiling and get only that done. Because in order to do that now, it first has to recursively compile each command line file and imported file using the -c -v switches to get a list of the potential files needing to be checked for recompilation. But seeing I've just compiled them to get this list, there is not much point now in /recompiling/ them. Also, mixin-imported files are not necessarily modules but must be treated as code fragments, so they can't be compiled to see if they in-turn effectively import other files!

My work here is (un)done.

It seems that DMD now needs to be enhanced to do what Rebuild and Bud were trying to do.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
7/02/2007 10:18:52 AM
February 06, 2007
Reply to Derek,

> Thanks Walter! :-(
> 
> Bud is no longer a useful tool because it can no longer do what it was
> trying to do - namely find out which files needed recompiling and get
> only that done. Because in order to do that now, it first has to
> recursively compile each command line file and imported file using the
> -c -v switches to get a list of the potential files needing to be
> checked for recompilation. But seeing I've just compiled them to get
> this list, there is not much point now in /recompiling/ them. Also,
> mixin-imported files are not necessarily modules but must be treated
> as code fragments, so they can't be compiled to see if they in-turn
> effectively import other files!
> 
> My work here is (un)done.
> 
> It seems that DMD now needs to be enhanced to do what Rebuild and Bud
> were trying to do.
> 

If bud keep around meta data about what happened last time (building N required A, B, C) then if none of those changed, the set of files that can be used can't change. Having that kind of tree would let you do a minimal rebuild even with the new import stuff.

Once you go that direction (DMD would have to report the files used) why not have DMD report the public interface of each module? that would let bud notice when a change in a module doesn't demands a rebuild of the modules that import it. Some of this might be possible by watching for actual changes in .di file, not just checking modification dates.


February 07, 2007
Derek Parnell wrote:
> On Tue, 06 Feb 2007 11:55:18 -0800, Walter Bright wrote:
> 
>> 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.
> 
> Thanks Walter! :-(
> 
> Bud is no longer a useful tool because it can no longer do what it was
> trying to do - namely find out which files needed recompiling and get only
> that done. Because in order to do that now, it first has to recursively
> compile each command line file and imported file using the -c -v switches
> to get a list of the potential files needing to be checked for
> recompilation. But seeing I've just compiled them to get this list, there
> is not much point now in /recompiling/ them. Also, mixin-imported files are
> not necessarily modules but must be treated as code fragments, so they
> can't be compiled to see if they in-turn effectively import other files!
> 
> My work here is (un)done.
> 
> It seems that DMD now needs to be enhanced to do what Rebuild and Bud were
> trying to do. 
> 

Perhaps it would be feasible to turn bud (and perhaps rebuild) into Makefile generators.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org
February 07, 2007
Derek Parnell wrote:
> Bud is no longer a useful tool because it can no longer do what it was
> trying to do - namely find out which files needed recompiling and get only
> that done. Because in order to do that now, it first has to recursively
> compile each command line file and imported file using the -c -v switches
> to get a list of the potential files needing to be checked for
> recompilation. But seeing I've just compiled them to get this list, there
> is not much point now in /recompiling/ them. Also, mixin-imported files are
> not necessarily modules but must be treated as code fragments, so they
> can't be compiled to see if they in-turn effectively import other files!
> 
> My work here is (un)done.
> 
> It seems that DMD now needs to be enhanced to do what Rebuild and Bud were
> trying to do. 

The compiler cannot tell what file it'll need to textually import without compiling either, so cannot do a 'make' on textual imports.

No tool is perfect; I recommend just ignoring the problem with textual imports. Such shouldn't be used outside of specialized modules.
February 07, 2007
Ary Manzana wrote:
> Walter Bright escribió:
>> True, but on the other hand, specifically not supporting it in the IDE may act as a needed brake on evil uses of it.
> But... I'm wondering which are the evil uses of it.

From my point of view, evil uses of it are things like version control:

	mixin(import("versions.txt"));

where versions.txt contains:

	version = FOO;
	version = BAR;

etc., or other uses that subvert the right way to do things. One should think long and hard about using textual import to import D code.

What it's for is to:

1) import data for a string constant
2) import code that's in DSL (Domain Specific Language), not D, form.