www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.031 and 2.015 releases

reply Walter Bright <newshound1 digitalmars.com> writes:
Some new stuff to make writing templates easier.

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.031.zip

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.015.zip
Jun 18 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright wrote:
 Some new stuff to make writing templates easier.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

Awesome; thanks! Out of curiosity, why doesn't return type deduction work for all functions (is this panned?). It seems to be possible to do: auto foo()() { return 10; } but not: auto foo() { return 10; } Allowing the latter would open up return type deduction for class member functions.
Jun 18 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Fraser wrote:
 Out of curiosity, why doesn't return type deduction work for all 
 functions (is this panned?). It seems to be possible to do:
 
 auto foo()()
 {
     return 10;
 }
 
 but not:
 
 auto foo()
 {
     return 10;
 }

Good question! Because deducing the return type requires semantic analysis, and for functions that introduces the old forward reference chicken-and-egg problem. This doesn't happen with function templates, because semantic analysis of them doesn't happen until later.
Jun 18 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g3ba3r$ppu$1 digitalmars.com...

 Good question!

 Because deducing the return type requires semantic analysis, and for 
 functions that introduces the old forward reference chicken-and-egg 
 problem. This doesn't happen with function templates, because semantic 
 analysis of them doesn't happen until later.

And what exactly is the problem? It's "too hard" to implement, or? I thought D was supposed to drop forward reference restrictions. Furthermore, the compiler already has support for deducing return types for delegate and function literals. Why can't the same mechanism be used for declarations?
Jun 18 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g3ba3r$ppu$1 digitalmars.com...
 
 Good question!

 Because deducing the return type requires semantic analysis, and for 
 functions that introduces the old forward reference chicken-and-egg 
 problem. This doesn't happen with function templates, because semantic 
 analysis of them doesn't happen until later.

And what exactly is the problem? It's "too hard" to implement, or? I thought D was supposed to drop forward reference restrictions. Furthermore, the compiler already has support for deducing return types for delegate and function literals.

Because the context in which they appear, statements, do not allow forward references.
 Why can't the same mechanism be used for 
 declarations? 

Jun 18 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g3bf7i$17br$1 digitalmars.com...

 Because the context in which they appear, statements, do not allow forward 
 references.

You haven't yet answered the more important question: what exactly is the problem with forward references? Is it too hard to implement, or is there something much deeper? Again, I thought D wasn't supposed to have such silliness.
Jun 18 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 You haven't yet answered the more important question: what exactly is the 
 problem with forward references?  Is it too hard to implement, or is there 
 something much deeper?  Again, I thought D wasn't supposed to have such 
 silliness. 

It's hard to implement, and in some cases (circular references) impossible.
Jun 18 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g3bkl5$1jbp$1 digitalmars.com...

 It's hard to implement, and in some cases (circular references) 
 impossible.

In the case of circular references, yes, it is impossible, in which case there's nothing you can do but issue an error. But you didn't sign up to be a compiler writer because it was easy, did you? And if something like this _is_ too much work for one man -- why not put the DMDFE source on dsource and start accepting help on things like this?
Jun 18 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 But you didn't sign up to be a compiler writer because it was easy, did you? 

If this was the last issue left, then I'd work on it. But there are other, far more important, things to be working on.
 And if something like this _is_ too much work for one man -- why not put the 
 DMDFE source on dsource and start accepting help on things like this? 

Reorganizing the internals of the compiler is not just accepting a patch. I've incorporated many user patches to dmd. The source doesn't need to be on dsource for that. It's not like there's a shortage of things users can work on to improve D. Frank Benoit, for example, tells me there's a huge need for help with dwt, and dwt can turn out to be a big factor in making D a success. GDC has fallen behind and could use some TLC. Writing articles, books, papers, and tutorials for D will help a lot.
Jun 18 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g3bqmi$2117$1 digitalmars.com...
 Jarrett Billingsley wrote:
 But you didn't sign up to be a compiler writer because it was easy, did 
 you?

If this was the last issue left, then I'd work on it. But there are other, far more important, things to be working on.

You always discount forward reference bugs as less important than other things. What other things *are* there that are so much more important? New features in D2? New features in D2 don't help me much when I run into the umpteenth forward reference bug in D1 that's completely un-workaround-able. New features in D2 don't help me when I have to cram every line of my library into a single module because DMD can't figure out what to do with an enum nested in a struct in another module. Or when DMD can't figure out how to instantiate a template declared later in the file. Or any of the other twenty-three unresolved forward reference issues in Bugzilla, including two regressions: http://tinyurl.com/3vg6jy
 And if something like this _is_ too much work for one man -- why not put 
 the DMDFE source on dsource and start accepting help on things like this?

Reorganizing the internals of the compiler is not just accepting a patch. I've incorporated many user patches to dmd. The source doesn't need to be on dsource for that.

I'm not suggesting patches. I'm suggesting that you not be the *only* person working on DMDFE. I'm also suggesting that if the internals need to be reorganized to implement forward reference resolution -- so be it. Maybe the compiler needs to be rewritten. It's been in development an awfully long time and D has changed considerably since development started. The semantic analysis that used to cut it when it wasn't much more complex than Java might not be working for us anymore.
Jun 18 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:

 I'm not suggesting patches.  I'm suggesting that you not be the *only* 
 person working on DMDFE.  

Anyone else see those "code swarm" videos which visualize the contributors to various open source projects? Take Python for instance: http://www.vimeo.com/1093745 For the first 10 years it's all Guido plus 2 or 3 others, but after 2000 the action really heats up. All those names swarming around are folks in the svn _checkin_ history. People who had commit access. Not just patch submitters. Good language designer? -- some people argue about that, but you have admit Guido van Rossum has definitely been a very good manager for Python. --bb
Jun 18 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:
 For the first 10 years it's all Guido plus 2 or 3 others, but after 2000 
 the action really heats up.

It corresponds to about Python 1.5.x, probably V. 1.5 has stopped being a toy language and started to be something you can work with, you can download a fixed version of it still, some people today write Python that is compatible with that version interpreter still: http://www.python.org/download/releases/1.5/ Even a blind like me can see that if D wants a chance of success, its development must become more open. Bye, bearophile
Jun 19 2008
prev sibling parent reply Georg Wrede <georg nospam.org> writes:
Jarrett Billingsley wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g3bqmi$2117$1 digitalmars.com...
Jarrett Billingsley wrote:
And if something like this _is_ too much work for one man -- why not put 
the DMDFE source on dsource and start accepting help on things like this?

Reorganizing the internals of the compiler is not just accepting a patch. I've incorporated many user patches to dmd. The source doesn't need to be on dsource for that.

I'm not suggesting patches. I'm suggesting that you not be the *only* person working on DMDFE. I'm also suggesting that if the internals need to be reorganized to implement forward reference resolution -- so be it. Maybe the compiler needs to be rewritten. It's been in development an awfully long time and D has changed considerably since development started. The semantic analysis that used to cut it when it wasn't much more complex than Java might not be working for us anymore.

We've had this discussion in the past, and Walter has said it's OK for anybody to make changes to the FE, that's why it's open source. That means that you /already/ can put it on dsource and have people send you patches. You can then automatically (say once a day or week) have the thing compiled, regression test suite run, and have the binary put on download. Once a particular patch has been used by enough people, it becomes easier to suggest Walter incorporate it in Phobos.
Jun 19 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Georg,


 We've had this discussion in the past, and Walter has said it's OK for
 anybody to make changes to the FE, that's why it's open source.
 
 That means that you /already/ can put it on dsource and have people
 send you patches. You can then automatically (say once a day or week)
 have the thing compiled, regression test suite run, and have the
 binary put on download.
 
 Once a particular patch has been used by enough people, it becomes
 easier to suggest Walter incorporate it in Phobos.
 

one problem, to really make that work you need the backend Walter uses.
Jun 19 2008
parent reply Georg Wrede <georg nospam.org> writes:
BCS wrote:
 Reply to Georg,
 
 We've had this discussion in the past, and Walter has said it's OK for
 anybody to make changes to the FE, that's why it's open source.

 That means that you /already/ can put it on dsource and have people
 send you patches. You can then automatically (say once a day or week)
 have the thing compiled, regression test suite run, and have the
 binary put on download.

 Once a particular patch has been used by enough people, it becomes
 easier to suggest Walter incorporate it in Phobos.

one problem, to really make that work you need the backend Walter uses.

Do the Tango guys have such a backend?? Hmmm. It sounds like it would be in Walter's (and therefore all of us) interest to device a way for us to use the Alt-FE as a drop-in. That way Walter could avoid bureaucracy involved in screening, selecting and trying out all the submissions. He'd now simply be sent the patches that in actual reality have proved themselves worthy, by not crashing and by giving the community a positive experience. Probably there'd be a few tens of users who regularly use the bleeding-edge-Phobos, and their experiences would then decide what gets suggested for the "real" Phobos. (This is not to say Walter is obliged to accept all of them, merely that he'd avoid most of the bureaucracy, most of the time.)
Jun 19 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Georg Wrede" <georg nospam.org> wrote in message 
news:485AFE87.3050902 nospam.org...

 Do the Tango guys have such a backend??

No, they just have permission to redistribute the DMD binary. Walter is the only one who has access to the backend.
Jun 19 2008
parent reply Georg Wrede <georg nospam.org> writes:
Jarrett Billingsley wrote:
 "Georg Wrede" <georg nospam.org> wrote in message 
 news:485AFE87.3050902 nospam.org...
 
Do the Tango guys have such a backend??

No, they just have permission to redistribute the DMD binary. Walter is the only one who has access to the backend.

I wasn't talking about back end sources.
Jun 20 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Georg Wrede" <georg nospam.org> wrote in message 
news:485B64BC.9010707 nospam.org...
 Jarrett Billingsley wrote:
 "Georg Wrede" <georg nospam.org> wrote in message 
 news:485AFE87.3050902 nospam.org...

Do the Tango guys have such a backend??

No, they just have permission to redistribute the DMD binary. Walter is the only one who has access to the backend.

I wasn't talking about back end sources.

Well that's the only form it exists in ;)
Jun 20 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Koroskin Denis" <2korden gmail.com> wrote in message 
news:op.uc1rl8s1enyajd proton.creatstudio.intranet...
 What about putting *compiled* (not the sources) backend (as a lib) to a 
 public as well, so that people could build a DMD themselves? This would be 
 a *huge* step forward. People would be able make some play with it, fix 
 some bug, run tests and propose the patch to Walter.

 Does putting backend in a compiled form to digitalmars.com/dsource involve 
 any copyright infringements?

People have been asking for this for ages. I get the impression Walter either doesn't see the value in it or doesn't have the time to do it.
Jun 20 2008
parent BCS <ao pathlink.com> writes:
Reply to Jarrett,

 "Koroskin Denis" <2korden gmail.com> wrote in message
 news:op.uc1rl8s1enyajd proton.creatstudio.intranet...
 
 What about putting *compiled* (not the sources) backend (as a lib) to
 a public as well, so that people could build a DMD themselves? This
 would be a *huge* step forward. People would be able make some play
 with it, fix some bug, run tests and propose the patch to Walter.
 
 Does putting backend in a compiled form to digitalmars.com/dsource
 involve any copyright infringements?
 

Walter either doesn't see the value in it or doesn't have the time to do it.

IIRC there is something about the back end being sold as a lib that might hook in with the 3dr party thing to make for a whole mess of stuff. I wonder what it would cost to buy any third party interests so that it could be redistributed?
Jun 20 2008
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Georg Wrede wrote:

 Jarrett Billingsley wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 news:g3bqmi$2117$1 digitalmars.com...
Jarrett Billingsley wrote:
And if something like this _is_ too much work for one man -- why not put
the DMDFE source on dsource and start accepting help on things like
this?

Reorganizing the internals of the compiler is not just accepting a patch. I've incorporated many user patches to dmd. The source doesn't need to be on dsource for that.

I'm not suggesting patches. I'm suggesting that you not be the *only* person working on DMDFE. I'm also suggesting that if the internals need to be reorganized to implement forward reference resolution -- so be it. Maybe the compiler needs to be rewritten. It's been in development an awfully long time and D has changed considerably since development started. The semantic analysis that used to cut it when it wasn't much more complex than Java might not be working for us anymore.

We've had this discussion in the past, and Walter has said it's OK for anybody to make changes to the FE, that's why it's open source. That means that you /already/ can put it on dsource and have people send you patches. You can then automatically (say once a day or week) have the thing compiled, regression test suite run, and have the binary put on download.

The frontend is already on dsource (dmdfe), and is used by various projects (rebuild, etc). -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jun 20 2008
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Georg Wrede wrote:

 Jarrett Billingsley wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 news:g3bqmi$2117$1 digitalmars.com...
Jarrett Billingsley wrote:
And if something like this _is_ too much work for one man -- why not put
the DMDFE source on dsource and start accepting help on things like
this?

Reorganizing the internals of the compiler is not just accepting a patch. I've incorporated many user patches to dmd. The source doesn't need to be on dsource for that.

I'm not suggesting patches. I'm suggesting that you not be the *only* person working on DMDFE. I'm also suggesting that if the internals need to be reorganized to implement forward reference resolution -- so be it. Maybe the compiler needs to be rewritten. It's been in development an awfully long time and D has changed considerably since development started. The semantic analysis that used to cut it when it wasn't much more complex than Java might not be working for us anymore.

We've had this discussion in the past, and Walter has said it's OK for anybody to make changes to the FE, that's why it's open source. That means that you /already/ can put it on dsource and have people send you patches. You can then automatically (say once a day or week) have the thing compiled, regression test suite run, and have the binary put on download. Once a particular patch has been used by enough people, it becomes easier to suggest Walter incorporate it in Phobos.

FE is not the same as Phobos (or runtime), although there clearly are parts of the FE requiring things to be in the runtime. The runtime parts required by the FE isn't very exciting though, and probably not where it is easy to find much to patch. The only time Phobos would be relevant in this context, would be if a new patch to the FE _also_ required a change/addition on the runtime. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jun 20 2008
prev sibling next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Fri, 20 Jun 2008 16:00:39 +0400, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:

 "Georg Wrede" <georg nospam.org> wrote in message
 news:485B64BC.9010707 nospam.org...
 Jarrett Billingsley wrote:
 "Georg Wrede" <georg nospam.org> wrote in message
 news:485AFE87.3050902 nospam.org...

 Do the Tango guys have such a backend??

No, they just have permission to redistribute the DMD binary. Walter is the only one who has access to the backend.

I wasn't talking about back end sources.

Well that's the only form it exists in ;)

What about putting *compiled* (not the sources) backend (as a lib) to a public as well, so that people could build a DMD themselves? This would be a *huge* step forward. People would be able make some play with it, fix some bug, run tests and propose the patch to Walter. Does putting backend in a compiled form to digitalmars.com/dsource involve any copyright infringements?
Jun 20 2008
prev sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Fri, 20 Jun 2008 18:17:18 +0400, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:

 "Koroskin Denis" <2korden gmail.com> wrote in message
 news:op.uc1rl8s1enyajd proton.creatstudio.intranet...
 What about putting *compiled* (not the sources) backend (as a lib) to a
 public as well, so that people could build a DMD themselves? This would  
 be
 a *huge* step forward. People would be able make some play with it, fix
 some bug, run tests and propose the patch to Walter.

 Does putting backend in a compiled form to digitalmars.com/dsource  
 involve
 any copyright infringements?

People have been asking for this for ages. I get the impression Walter either doesn't see the value in it or doesn't have the time to do it.

IIRC, he once stated that there are parts of source code that he can't disclose (written by thirdparty, I assume), but he said nothing about compiled form redistribution restrictions.
Jun 20 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 GDC has fallen behind and could use some TLC.

I hope I'm not stepping on any toes by saying this, but GDC seems like a sinking ship to me. Almost all of the issues we have with Tango concern GDC codegen or install problems. At this point I'm very much hoping that LLVMDC or the other D compiler project (dyld?) can supplant GDC. In fact, I think the LLVMDC folks have been asking for help to get some issues sorted out? Sean
Jun 19 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Sean Kelly" <sean invisibleduck.org> wrote in message 
news:g3dtv7$1g0q$1 digitalmars.com...
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 GDC has fallen behind and could use some TLC.

I hope I'm not stepping on any toes by saying this, but GDC seems like a sinking ship to me. Almost all of the issues we have with Tango concern GDC codegen or install problems. At this point I'm very much hoping that LLVMDC or the other D compiler project (dyld?) can supplant GDC. In fact, I think the LLVMDC folks have been asking for help to get some issues sorted out?

I like what LLVMDC is doing but I don't think using the DMDFE in *yet another* compiler is the best idea. It's time that D had a bootstrapped compiler and that the DMDFE had some competition. As for "dyld" I think you're thinking of Dil. I was trying to help with Dil but with all the other projects and real-life responsibilities, I just don't have the time.
Jun 19 2008
next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Jarrett Billingsley wrote:
 "Sean Kelly" <sean invisibleduck.org> wrote in message 
 news:g3dtv7$1g0q$1 digitalmars.com...
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 GDC has fallen behind and could use some TLC.

seems like a sinking ship to me. Almost all of the issues we have with Tango concern GDC codegen or install problems. At this point I'm very much hoping that LLVMDC or the other D compiler project (dyld?) can supplant GDC. In fact, I think the LLVMDC folks have been asking for help to get some issues sorted out?

I like what LLVMDC is doing but I don't think using the DMDFE in *yet another* compiler is the best idea. It's time that D had a bootstrapped compiler and that the DMDFE had some competition. As for "dyld" I think you're thinking of Dil. I was trying to help with Dil but with all the other projects and real-life responsibilities, I just don't have the time.

We could certainly use some help over at LLVMDC :) The project has come pretty far in the last months, with beginning inline asm support, dstress regressions testing and generally a lot of bugfixes. However there's still a few things to do before we're there. Mainly exception handling and some codegen issues. Exception handling is a tricky issue. The LLVM support is there, but it needs someone to look at it, willing to submit patches to the LLVM developers so we can get the exception tables we need (and want)! Regarding code generation, for the most part, it's complete. However there are some subtle problems that I have yet to track down. The most critical one being a crash on GC collection. I've been spend the last weeks on improving symbolic debugging information to make these issues easier to track down. Any help in this regard would be extremely appreciated. So far my debugging sessions have been mostly fruitless in locating the true trouble spots :/ As to having a D compiler in D, I would love that. If there had been a usable D frontend in D when I started considering LLVMDC I would have used that for sure. However my knowledge on compilers etc was basically non-existing back then, and I was mostly interested in the code generation part. I can say that I've wished I wasn't coding in C++ and DMDFE sources _many_ times during this project... Oh well, just thought I'd chime in here since LLVMDC could definitely use some more testers/developers :) Tomas http://www.dsource.org/projects/llvmdc
Jun 19 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Tomas Lindquist Olsen Wrote:

 Jarrett Billingsley wrote:
 "Sean Kelly" <sean invisibleduck.org> wrote in message 
 news:g3dtv7$1g0q$1 digitalmars.com...
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 GDC has fallen behind and could use some TLC.

seems like a sinking ship to me. Almost all of the issues we have with Tango concern GDC codegen or install problems. At this point I'm very much hoping that LLVMDC or the other D compiler project (dyld?) can supplant GDC. In fact, I think the LLVMDC folks have been asking for help to get some issues sorted out?

I like what LLVMDC is doing but I don't think using the DMDFE in *yet another* compiler is the best idea. It's time that D had a bootstrapped compiler and that the DMDFE had some competition. As for "dyld" I think you're thinking of Dil. I was trying to help with Dil but with all the other projects and real-life responsibilities, I just don't have the time.

We could certainly use some help over at LLVMDC :) The project has come pretty far in the last months, with beginning inline asm support, dstress regressions testing and generally a lot of bugfixes. However there's still a few things to do before we're there. Mainly exception handling and some codegen issues. Exception handling is a tricky issue. The LLVM support is there, but it needs someone to look at it, willing to submit patches to the LLVM developers so we can get the exception tables we need (and want)! Regarding code generation, for the most part, it's complete. However there are some subtle problems that I have yet to track down. The most critical one being a crash on GC collection. I've been spend the last weeks on improving symbolic debugging information to make these issues easier to track down. Any help in this regard would be extremely appreciated. So far my debugging sessions have been mostly fruitless in locating the true trouble spots :/ As to having a D compiler in D, I would love that. If there had been a usable D frontend in D when I started considering LLVMDC I would have used that for sure. However my knowledge on compilers etc was basically non-existing back then, and I was mostly interested in the code generation part. I can say that I've wished I wasn't coding in C++ and DMDFE sources _many_ times during this project... Oh well, just thought I'd chime in here since LLVMDC could definitely use some more testers/developers :) Tomas http://www.dsource.org/projects/llvmdc

How pluggable is LLVMDC? For example, if it uses the visitor pattern & just public interfaces,it might be possible to replace the DMD classes with wrappers around classes generated from another front-end (maybe even a D one with a C go-between... sounds complex, but I might be willing to do that part).
Jun 19 2008
parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Robert Fraser wrote:
 How pluggable is LLVMDC? For example, if it uses the visitor pattern &
 just public interfaces,it might be possible to replace the DMD classes 
 with wrappers around classes generated from another front-end 
 (maybe even a D one with a C go-between... sounds complex, but I 
 might be willing to do that part).

LLVMDC is unfortunately not pluggable at all. Also DMDFE has some pretty weird AST constructs, and the codegen code is very much tied to the specific ASTs (and the info they hold) that DMDFE produces.
Jun 20 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Tomas Lindquist Olsen:
 As to having a D compiler in D, I would love that.

I think eventually creating such compiler can be an interesting thing to do. But what D are you talking about? D 1.x? D 2.x? Or a possible cross between the two? Bye, bearophile
Jun 19 2008
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Jarrett,

 "Sean Kelly" <sean invisibleduck.org> wrote in message
 news:g3dtv7$1g0q$1 digitalmars.com...
 
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 
 GDC has fallen behind and could use some TLC.
 

like a sinking ship to me. Almost all of the issues we have with Tango concern GDC codegen or install problems. At this point I'm very much hoping that LLVMDC or the other D compiler project (dyld?) can supplant GDC. In fact, I think the LLVMDC folks have been asking for help to get some issues sorted out?

another* compiler is the best idea. It's time that D had a bootstrapped compiler and that the DMDFE had some competition.

That is actually the motivating factor behind dparse. I'm writing it as the parser generator for a D front end in D. At this point I have a lexer (that is almost correct) and a framework for extracting the d grammar from the doc files as well as dparse (which is currently getting a major overhaul and soaking up most of my free time)
Jun 19 2008
prev sibling parent reply Sascha Katzner <sorry.no spam.invalid> writes:
Jarrett Billingsley wrote:
 It's time that D had a bootstrapped compiler and that the DMDFE had
 some competition.

I would love this too. A bootstrapped compiler is like the ultimate statement from a developer that he thinks his product is mature enough that even he himself uses it. I think when D has achieved this goal, it is finally adult. :) LLAP, Sascha
Jun 19 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sascha Katzner wrote:
 I would love this too. A bootstrapped compiler is like the ultimate 
 statement from a developer that he thinks his product is mature enough 
 that even he himself uses it. I think when D has achieved this goal, it 
 is finally adult. :)

The problem with a D compiler in D is that nearly every compiler back end is in C or C++, and having the D front end in C++ makes it easier to connect to existing back ends. Many, many times, however, I wished it was in D just because it would make coding it easier.
Jun 19 2008
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 19 de junio a las 12:08 me escribiste:
 Sascha Katzner wrote:
I would love this too. A bootstrapped compiler is like the ultimate statement 
from a developer that he thinks his product is mature enough that even he 
himself uses it. I think when D has achieved this goal, it is finally adult. :)

The problem with a D compiler in D is that nearly every compiler back end is in C or C++, and having the D front end in C++ makes it easier to connect to existing back ends. Many, many times, however, I wished it was in D just because it would make coding it easier.

I don't think I have to tell *you* this, but since D is link compatible with C, I don't think that's a real issue... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- 41% of all people take people with curly hair less seriously
Jun 19 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Leandro Lucarella" <llucax gmail.com> wrote in message 
news:20080619210932.GE17841 burns.springfield.home...

 I don't think I have to tell *you* this, but since D is link compatible
 with C, I don't think that's a real issue...

It's not the linking that's the trouble, it's the fact that you'd need a D compiler to compile this new D compiler. And most platforms don't have one by default yet. That's not to say that GDC couldn't be used to build said compiler. It'd just complicate the build process. I wonder what other not-so-prevalent languages have bootstrapped compilers, and what their installation procedures entail? Would it be automatable enough to be able to, say, put it in a .deb/.rpm?
Jun 19 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Jarrett Billingsley (kb3ctd2 yahoo.com)'s article
 "Leandro Lucarella" <llucax gmail.com> wrote in message
 news:20080619210932.GE17841 burns.springfield.home...
 I don't think I have to tell *you* this, but since D is link compatible
 with C, I don't think that's a real issue...

compiler to compile this new D compiler. And most platforms don't have one by default yet.

If only we had a C-front D compiler... Sean
Jun 19 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Sean Kelly" <sean invisibleduck.org> wrote in message 
news:g3ejkj$67p$1 digitalmars.com...

 If only we had a C-front D compiler...

You mean TDC? ;) Course it's also based on DMDFE.
Jun 19 2008
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Jarrett Billingsley wrote:

 "Sean Kelly" <sean invisibleduck.org> wrote in message
 news:g3ejkj$67p$1 digitalmars.com...
 
 If only we had a C-front D compiler...

You mean TDC? ;) Course it's also based on DMDFE.

LLVMDC can do this. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jun 19 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Walter Bright, el 19 de junio a las 12:08 me escribiste:
 Many, many times, however, I wished it was in D just because it would make 
 coding it easier.

I don't think I have to tell *you* this, but since D is link compatible with C, I don't think that's a real issue...

It is, for a couple reasons: o Some back ends (like mine) is in C++, not C. o If you're porting D to a platform that has no existing D compiler on it, you're in for some significant problems.
Jun 19 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Charles Hixson:
 A D compiler option to emit C code?  (Or C++ code?)  It wouldn't need to 
 be as efficient as D-to-executable in order to be portable.
 
 (Yes, it would probably be a huge undertaking.  But it's an option for 
 portability that would allow D to be written in D.  I believe this kind 
 of bootstrapping was first used by Algol.)

Written in Python maybe :-) High level languages may be acceptable to write first gen compilers. (ShedSkin is written in Python and it works well enough, so it's possible). Bye, bearophile
Jun 19 2008
prev sibling next sibling parent reply Georg Wrede <georg nospam.org> writes:
Charles Hixson wrote:
 A D compiler option to emit C code?  (Or C++ code?)  It wouldn't need to 
 be as efficient as D-to-executable in order to be portable.

There's no reason this code would be any less efficient than the ASM the D compiler has to generate anyway. After all, the "C language" is actually not a language, it is more like a CPU independent symbolic assembly language. (At least in the K&R days it was.) While technologically an interesting option, I'd think that in a political way this would be unwise. Not to mention the credibility of D.
 (Yes, it would probably be a huge undertaking.  But it's an option for 
 portability that would allow D to be written in D.  I believe this kind 
 of bootstrapping was first used by Algol.)

/Technologically/, that is, in programming practice, it would be a huge success. Such a compiler could then immediately be used in an immense variety of domains. And additionally, many companies would then hand-tweak the C code in subtle but important ways, to really achieve astounding performance and suitability for possibly quite exotic needs. It could also give D access to both smaller and larger CPUs than today.
Jun 19 2008
parent BLS <nanali nospam-wanadoo.fr> writes:
Georg Wrede schrieb:
 Charles Hixson wrote:
 A D compiler option to emit C code?  (Or C++ code?)  It wouldn't need 
 to be as efficient as D-to-executable in order to be portable.

There's no reason this code would be any less efficient than the ASM the D compiler has to generate anyway. After all, the "C language" is actually not a language, it is more like a CPU independent symbolic assembly language. (At least in the K&R days it was.) While technologically an interesting option, I'd think that in a political way this would be unwise. Not to mention the credibility of D.

Most Eiffel compilers are using C as intermediate language. b
Jun 20 2008
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 19 de junio a las 14:52 me escribiste:
 Leandro Lucarella wrote:
Walter Bright, el 19 de junio a las 12:08 me escribiste:
Many, many times, however, I wished it was in D just because it would make 
coding it easier.

with C, I don't think that's a real issue...

It is, for a couple reasons: o Some back ends (like mine) is in C++, not C.

But you can access C from C++!
 o  If you're porting D to a platform that has no existing D compiler on it,
 you're in for some significant problems.

Yes, that's true, but that can be solved making a D compiler that can emits C code instead of asm/binary (just to boostrap in new platforms that have a C compiler). I think LVMM can do that, right? -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Y tuve amores, que fue uno sólo El que me dejó de a pie y me enseñó todo...
Jun 20 2008
prev sibling parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Walter Bright wrote:
 Sascha Katzner wrote:
 I would love this too. A bootstrapped compiler is like the ultimate 
 statement from a developer that he thinks his product is mature enough 
 that even he himself uses it. I think when D has achieved this goal, 
 it is finally adult. :)

The problem with a D compiler in D is that nearly every compiler back end is in C or C++, and having the D front end in C++ makes it easier to connect to existing back ends.

For people interested in this, I also host a binding+wrapper of the LLVM C interface in the LLVMDC svn repository :) http://dsource.org/projects/llvmdc/browser/binding/llvm
 
 Many, many times, however, I wished it was in D just because it would 
 make coding it easier.

Jun 20 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 GDC has fallen behind and could use some TLC.

I hope I'm not stepping on any toes by saying this, but GDC seems like a sinking ship to me. Almost all of the issues we have with Tango concern GDC codegen or install problems. At this point I'm very much hoping that LLVMDC or the other D compiler project (dyld?) can supplant GDC. In fact, I think the LLVMDC folks have been asking for help to get some issues sorted out?

I've tried as much as possible to keep improvements to DMD in the front end code, rather than tweaking the back end. This is to make folding the changes in to other D compiler implementations easier. That said, I am here to help with any questions about how things work in order to help those connecting the front end to other back ends, and I am also willing to do what I can to fold changes into the front end that will make future updates easier.
Jun 19 2008
prev sibling parent Russell Lewis <webmaster villagersonline.com> writes:
Jarrett Billingsley wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g3bkl5$1jbp$1 digitalmars.com...
 
 It's hard to implement, and in some cases (circular references) 
 impossible.

In the case of circular references, yes, it is impossible, in which case there's nothing you can do but issue an error. But you didn't sign up to be a compiler writer because it was easy, did you? And if something like this _is_ too much work for one man -- why not put the DMDFE source on dsource and start accepting help on things like this?

While I'm a fan of the idea that someday we could contribute to D more directly, remember that one of the (original) ideas of D was that it was supposed to be easy to write a standards-compliant compiler. I still think that that's a good goal. Here's another chance to advocate for my "D simplifier." Let's have an open-source tool which does all of the hard stuff (like forward referencing and filling in "auto"). Its output would be a simplified dialect of D, which would be easy to compile. :) Russ
Jun 18 2008
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
On Thu, 19 Jun 2008 14:52:45 -0700, Walter Bright wrote:

 Leandro Lucarella wrote:
 Walter Bright, el 19 de junio a las 12:08 me escribiste:
 Many, many times, however, I wished it was in D just because it would
 make coding it easier.

I don't think I have to tell *you* this, but since D is link compatible with C, I don't think that's a real issue...

It is, for a couple reasons: o Some back ends (like mine) is in C++, not C. o If you're porting D to a platform that has no existing D compiler on it, you're in for some significant problems.

A D compiler option to emit C code? (Or C++ code?) It wouldn't need to be as efficient as D-to-executable in order to be portable. (Yes, it would probably be a huge undertaking. But it's an option for portability that would allow D to be written in D. I believe this kind of bootstrapping was first used by Algol.)
Jun 19 2008
prev sibling parent janderson <askme me.com> writes:
Robert Fraser wrote:
 Walter Bright wrote:
 Some new stuff to make writing templates easier.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

Awesome; thanks! Out of curiosity, why doesn't return type deduction work for all functions (is this panned?). It seems to be possible to do: auto foo()() { return 10; } but not: auto foo() { return 10; } Allowing the latter would open up return type deduction for class member functions.

Makes sense to me, although the second version would have to be made into a template. Why? Because what type is 10? Is it a int? a uint? etc... If it was automatically made into a template I'd be cool with that. -Joel
Jun 18 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g3agsn$1o76$2 digitalmars.com...
 Some new stuff to make writing templates easier.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

Bug 617 fixed? YES. Bug 1559/2140 fixed? YES. Bug 1675 -- wait, how did you fix that one? Also like the template alias arguments taking literals and template constraints on the D2 side. Will the template alias parameter extension eventually extend to being able to alias expressions in general?
Jun 18 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:g3b6db$fu3$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g3agsn$1o76$2 digitalmars.com...
 Some new stuff to make writing templates easier.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

Bug 617 fixed? YES. Bug 1559/2140 fixed? YES. Bug 1675 -- wait, how did you fix that one? Also like the template alias arguments taking literals and template constraints on the D2 side. Will the template alias parameter extension eventually extend to being able to alias expressions in general?

Crap, tried compiling something and got this: Assertion failure: 'global.errors' on line 272 in file 'statement.c' Turns out it's stuff like this: if(foo) mixin(SomeTemplate!("blah")); That fails. If the mixin is outside of a control statement, or if (here's the really weird one) you put braces on the body: if(foo) { mixin(SomeTemplate!("blah")); } It works. Short and sweet testcase: const b = "writefln(`hey`);"; if(true) mixin(b); // FAILCOPTER But put {} around mixin(b) and it works.
Jun 18 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 Crap, tried compiling something and got this:
 
 Assertion failure: 'global.errors' on line 272 in file 'statement.c'

Sorry 'bout that. Fix will go out in next update.
Jun 19 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:g3b6db$fu3$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g3agsn$1o76$2 digitalmars.com...
 Some new stuff to make writing templates easier.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

Bug 617 fixed? YES.

617 doesn't seem to work. The example in bugzilla doesn't, anyway.
Jun 18 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 617 doesn't seem to work.  The example in bugzilla doesn't, anyway. 

The example works if size_t is replaced with uint. Arggh. I'll do a better fix next update.
Jun 19 2008
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:g3b6db$fu3$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g3agsn$1o76$2 digitalmars.com...
 Some new stuff to make writing templates easier.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip


Bug 2111 fixed? YES. I'm kind of shocked, though, given your less-than-enthusiastic support for backporting it to D1 back when 2.011 came out.
Jun 18 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 Bug 1675 -- wait, how did you fix that one?

Too long identifiers get turned into an md5 hash (a suggestion made many times here). It's ugly, and the names are not demanglable, but it works.
 Also like the template alias arguments taking literals and template 
 constraints on the D2 side.

Andrei's ideas.
 Will the template alias parameter extension 
 eventually extend to being able to alias expressions in general? 

No, because they have to be evaluatable at compile time.
Jun 18 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g3baci$qou$1 digitalmars.com...
 Jarrett Billingsley wrote:
 Bug 1675 -- wait, how did you fix that one?

Too long identifiers get turned into an md5 hash (a suggestion made many times here). It's ugly, and the names are not demanglable, but it works.

Joy upon joys. This means Pyd and my binding library will now work correctly in DMDWin.
 Will the template alias parameter extension eventually extend to being 
 able to alias expressions in general?

No, because they have to be evaluatable at compile time.

And...? alias 5 x; // ok int foo() { return 10; } alias foo() y; // ok alias some.expression z; // error, can't evaluate at compile time. I see no issue. The same restriction applies to const variable initializers. (Or enum variables as they're so called in D2. Lol, what a dumb name.)
Jun 18 2008
prev sibling next sibling parent Don <nospam nospam.com.au> writes:
Walter Bright wrote:
 Some new stuff to make writing templates easier.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

Fantastic! Error #1947 seems to be fixed as well. (Except for an unrelated trivial error reported in a comment, which I've moved to a new issue (#2153) so that #1947 can be closed).
Jun 18 2008
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Walter,

 Some new stuff to make writing templates easier.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

what is the solution on 2144? ('==' vs. 'is') Change the spec or change the way things work?
Jun 18 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 what is the solution on 2144? ('==' vs. 'is')
 
 Change the spec or change the way things work?

spec
Jun 18 2008
parent BCS <ao pathlink.com> writes:
Reply to Walter,

 BCS wrote:
 
 what is the solution on 2144? ('==' vs. 'is')
 
 Change the spec or change the way things work?
 


:)
Jun 18 2008
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Walter,

 Some new stuff to make writing templates easier.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

template alias args using local names. Sweet! The docs mention this but don't have an example. ---- auto return type: Will this work? class A {} class B {} auto Fn()(bool a) { if(false) return new Object(); if(a) return new A(); else return new B(); } ---- Template Constraints! (/me drooling) ---- Issue 2112: the type of undefined variable incorrectly assumed to be int What was this ix here? did a real error type get implmeneted or was it just this bug getting fixed?
Jun 18 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 Issue 2112: the type of undefined variable incorrectly assumed to be int
 What was this ix here? did a real error type get implmeneted or was it 
 just this bug getting fixed?

just a bug
Jun 18 2008
parent BCS <ao pathlink.com> writes:
Reply to Walter,

 BCS wrote:
 
 Issue 2112: the type of undefined variable incorrectly assumed to be
 int What was this ix here? did a real error type get implmeneted or
 was it just this bug getting fixed?
 


:(
Jun 18 2008
prev sibling next sibling parent reply aarti_pl <aarti interia.pl> writes:
Walter Bright pisze:
 Some new stuff to make writing templates easier.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

Out of curiosity... Why have you implemented template constraints syntax using additional pair of parenthesis? Some time ago I proposed syntax to extend templates matching. It is in enhancement: http://d.puremagic.com/issues/show_bug.cgi?id=1827 Was it difficult to implement? Or you didn't want to break current syntax? IMHO proposed syntax is much better: - shorter: U: U[N], uint N against U N : U[N=uint] - natural order of declaration / definition. See above: in my proposition N is declared before using it. - extensible: if implemented for every case I proposed we would have already possibility to check sth. like this in templates: void foo(T : class)() {} - applicable for not only templates, but also is(), alias and static if/static assert. I can not stop thinking that you try to get a lot with just a minimal effort. But maybe low hanging fruits for D are already in basket? Could you please give some feedback, so I would feel a bit better with current syntax :-) Best Regards Marcin Kuszczak
Jun 18 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
aarti_pl wrote:
 Walter Bright pisze:
 Some new stuff to make writing templates easier.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

Out of curiosity... Why have you implemented template constraints syntax using additional pair of parenthesis?

Because when we tried to stuff everything into the parameter list, it got kinda visually incomprehensible when the constraints got beyond the trivial.
Jun 18 2008
parent reply aarti_pl <aarti interia.pl> writes:
Walter Bright pisze:
 aarti_pl wrote:
 Walter Bright pisze:
 Some new stuff to make writing templates easier.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

Out of curiosity... Why have you implemented template constraints syntax using additional pair of parenthesis?

Because when we tried to stuff everything into the parameter list, it got kinda visually incomprehensible when the constraints got beyond the trivial.

Well, it might be a bit less readable in specific (complicated) cases, but in general it should be more readable, because it groups same functionality - type matching - in the same place. It's generally good thing. Let's compare: void foo(T if isString!(T))() {} vs.: void foo(T)() if(isString!(T)) {} is really second version more readable? or: void foo(N : N=int if N & 1)() {} or alternatively in shorter form e.g. : void foo(int N if N & 1)() {} vs.: void foo(int N)() if (N & 1) {} [I prefer first version of syntax, which although longer, would be exactly same for every case, so it is much easier to learn. Currently there is a lot of special cases e.g. for is().] But even if second version is visually better, I can not understand how strictly aesthetic argument can outweigh arguments about consistency in language - same syntax for a few language constructs is IMHO strong argument, much stronger than visual appearance. It is much easier to learn such a language, because you can just apply same pattern for few different, but similar cases. And also arguments from my first posts (e.g. natural order of symbols declaration) are still valid... But anyway thanks - this is rationale although I don't agree fully :-) BR Marcin Kuszczak
Jun 18 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
aarti_pl wrote:
 But anyway thanks - this is rationale although I don't agree fully :-)

It's too much to ask for everyone to agree, the more important thing is if the job is getting done.
Jun 19 2008
prev sibling next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Walter Bright schrieb:
 Some new stuff to make writing templates easier.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

What effect has -fPIC to code? When do i use -fPIC? What is a situation, where the version D_PIC is useful in the source code?
Jun 18 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to Frank,

 Walter Bright schrieb:
 
 Some new stuff to make writing templates easier.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

When do i use -fPIC? What is a situation, where the version D_PIC is useful in the source code?

I trust /someone/ will find a use. <g>
Jun 18 2008
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Frank Benoit wrote:
 What effect has -fPIC to code?
 When do i use -fPIC?

It makes the generated code position-independent.
 What is a situation, where the version D_PIC is useful in the source code?

Some inline ASM operation that doesn't work with position-independent code...?
Jun 18 2008
prev sibling next sibling parent reply Don <nospam nospam.com.au> writes:
Frank Benoit wrote:
 Walter Bright schrieb:
 Some new stuff to make writing templates easier.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

What effect has -fPIC to code? When do i use -fPIC? What is a situation, where the version D_PIC is useful in the source code?

It was requested by me. When fPIC is enabled, if you are writing inline asm, you can't access any global values (including constants). So you need to do some slow, ugly workarounds. It's a big problem for SSE code which doesn't have any immediate instructions. You can't even load the value 1 into a register!
Jun 19 2008
parent Frank Benoit <keinfarbton googlemail.com> writes:
Don schrieb:
 It was requested by me. When fPIC is enabled, if you are writing inline 
 asm, you can't access any global values (including constants). So you 
 need to do some slow, ugly workarounds. It's a big problem for SSE code 
  which doesn't have any immediate instructions. You can't even load the 
 value 1 into a register!
 

Oh, i see. thanks
Jun 19 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Frank Benoit wrote:
 What effect has -fPIC to code?
 When do i use -fPIC?
 What is a situation, where the version D_PIC is useful in the source code?

Don answered this, but I wish to add that -fPIC has the same effect that -fPIC has for gcc on linux.
Jun 19 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright wrote:

 Some new stuff to make writing templates easier.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

Why is "alias" required when specifying a template parameter? It seems like the most accepting and general case. Why wouldn't it be the default?
Jun 18 2008
next sibling parent Russell Lewis <webmaster villagersonline.com> writes:
Jason House wrote:
 Walter Bright wrote:
 
 Some new stuff to make writing templates easier.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

Why is "alias" required when specifying a template parameter? It seems like the most accepting and general case. Why wouldn't it be the default?

The default is to interpret it as a type. I have argued that actually we need a "type" keyword (or something like it) to declare that a template parameter is a type. IMHO, a parameter without a limiter should accept *any* type of valid parameter: type, alias, or value.
Jun 18 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Jason House wrote:
 Walter Bright wrote:
 
 Some new stuff to make writing templates easier.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

Why is "alias" required when specifying a template parameter? It seems like the most accepting and general case. Why wouldn't it be the default?

Really? I have never had a use for an alias parameter (although I guess most types could work as alias parameters) except using an un-speced trick with regards to their name mangling. They seem way to permissive.
Jun 18 2008
parent reply Russell Lewis <webmaster villagersonline.com> writes:
Robert Fraser wrote:
 Jason House wrote:
 Walter Bright wrote:

 Some new stuff to make writing templates easier.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

Why is "alias" required when specifying a template parameter? It seems like the most accepting and general case. Why wouldn't it be the default?

Really? I have never had a use for an alias parameter (although I guess most types could work as alias parameters) except using an un-speced trick with regards to their name mangling. They seem way to permissive.

One great example of alias parameters is when you want to pass another template name as a parameter. You can build a foreach() template, operating over a Tuple, which passes each element in the Tuple into some other template.
Jun 19 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Russell Lewis Wrote:

 Robert Fraser wrote:
 Jason House wrote:
 Walter Bright wrote:

 Some new stuff to make writing templates easier.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

Why is "alias" required when specifying a template parameter? It seems like the most accepting and general case. Why wouldn't it be the default?

Really? I have never had a use for an alias parameter (although I guess most types could work as alias parameters) except using an un-speced trick with regards to their name mangling. They seem way to permissive.

One great example of alias parameters is when you want to pass another template name as a parameter. You can build a foreach() template, operating over a Tuple, which passes each element in the Tuple into some other template.

I'm not saying they're not useful ;-P. I'm just saying that they're used rarely enough that making them the default is not a good idea.
Jun 19 2008
prev sibling next sibling parent Max Samukha <samukha voliacable.com.removethis> writes:
On Wed, 18 Jun 2008 01:27:03 -0700, Walter Bright
<newshound1 digitalmars.com> wrote:

Some new stuff to make writing templates easier.

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.031.zip

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.015.zip

Nice release. Thanks!
Jun 19 2008
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Nice work.  #617 in particular is very welcome.  As a general comment for future
releases, is there any chance that a short description could be added to tickets
when they are closed describing the resolution?  It would save a lot of
questions
when releases occur.


Sean
Jun 19 2008
prev sibling next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Walter Bright schrieb:
 Some new stuff to make writing templates easier.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

what are difference between Template Constraints and static asserts?
Jun 19 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to dennis,

 Walter Bright schrieb:
 
 Some new stuff to make writing templates easier.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.015.zip

and static asserts?

if a static assert fail, the compiler just quits. If a template constraints is not satisfied, the template is considered to not match and other matches are attempted.
Jun 19 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
dennis luehring Wrote:
 what are difference between Template Constraints
 and static asserts?

Besides speed of implementation, I don't think there's much of a difference while SFINAE is in place. I'd love to see SFINAE removed and start relying on the power of D's template matching. I know SFINAE is a staple of C++, but I don't think it's really needed in D. I submitted a request in D's issue tracker, but there has been no response from anyone that'd strongly influence D's design.
Jun 19 2008
parent BCS <ao pathlink.com> writes:
Reply to Jason,

 dennis luehring Wrote:
 
 what are difference between Template Constraints
 and static asserts?

difference while SFINAE is in place. I'd love to see SFINAE removed and start relying on the power of D's template matching. I know SFINAE is a staple of C++, but I don't think it's really needed in D. I submitted a request in D's issue tracker, but there has been no response from anyone that'd strongly influence D's design.

I don't think SFINAE is effected by static assert. I think the assert is always used and always aborts the compile on failure. (Correct me if I'm wrong)
Jun 19 2008
prev sibling next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:
 Some new stuff to make writing templates easier.

Most appreciated! Perhaps I'm a little late... (I blame it all on the univ exams!) but thanks a lot :D This release is likely to make my life a lot easier :) -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Jun 26 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Tom S wrote:
 Most appreciated! Perhaps I'm a little late... (I blame it all on the 
 univ exams!) but thanks a lot :D This release is likely to make my life 
 a lot easier :)

You're welcome!
Jun 26 2008
prev sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g3agsn$1o76$2 digitalmars.com...
 Some new stuff to make writing templates easier.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip

<snip> Bugzilla 2118: Inconsistent use of string vs invariant(char[]) in doc Bugzilla 2132: CTFE: can't evaluate ~= at compile time, D2 only. These seem to be D 2-specific issues - so what are they doing in the 1.031 changelog? Stewart. -- My e-mail address is valid but not my primary mailbox. Please keep replies on the 'group where everybody may benefit.
Jun 26 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Stewart Gordon wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g3agsn$1o76$2 digitalmars.com...
 Some new stuff to make writing templates easier.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.031.zip

<snip> Bugzilla 2118: Inconsistent use of string vs invariant(char[]) in doc Bugzilla 2132: CTFE: can't evaluate ~= at compile time, D2 only. These seem to be D 2-specific issues - so what are they doing in the 1.031 changelog?

There were related effects for D1.
Jun 26 2008