www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Foreach Closures?

reply Kevin Cox <kevincox.ca gmail.com> writes:
I was wondering about the foreach statement and when you implement
opApply() for a class it is implemented using closures.  I was wondering if
this is just how it is expressed or if it is actually syntatic sugar.  The
reason I aski is because if you have a return statement inside a foreach it
returns from the outside function not the "closure".

I was just wondering if anyone could spill the implementation details.

Thanks,
Kevin
Apr 08 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 09-04-2012 01:26, Kevin Cox wrote:
 I was wondering about the foreach statement and when you implement
 opApply() for a class it is implemented using closures.  I was wondering
 if this is just how it is expressed or if it is actually syntatic
 sugar.  The reason I aski is because if you have a return statement
 inside a foreach it returns from the outside function not the "closure".

 I was just wondering if anyone could spill the implementation details.

 Thanks,
 Kevin
A lot of magic happens with opApply. Basically, when you exit a foreach block that's using opApply, DMD translates this into exiting the closure and *then* doing the actual operation (i.e. return from the outer function). So, they're not quite closures in the usual sense. -- - Alex
Apr 08 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/09/2012 01:26 AM, Kevin Cox wrote:
 I was wondering about the foreach statement and when you implement
 opApply() for a class it is implemented using closures.  I was wondering
 if this is just how it is expressed or if it is actually syntatic
 sugar.  The reason I aski is because if you have a return statement
 inside a foreach it returns from the outside function not the "closure".

 I was just wondering if anyone could spill the implementation details.

 Thanks,
 Kevin
Since opApply has to hand through the return code if it is non-zero, I assume that DMD simply generates a custom exit code for each possible way the foreach body can be exit from. eg: start: foreach(x; foo){ if(x==1) break; else if(x==2) return 10; else if(x==3) goto start; else if(x==4) continue; ... } ==> int __result; start: switch(foo.opApply((x){ if(x==1) return 1; else if(x==2){__result = 10; return 2;} else if(x==3) return 3; else if(x==4) return 0; ... }){ case 0, 1: break; case 2: return __result; case 3: goto start; }
Apr 08 2012
parent Kevin Cox <kevincox.ca gmail.com> writes:
On Apr 8, 2012 7:49 PM, "Timon Gehr" <timon.gehr gmx.ch> wrote:
 On 04/09/2012 01:26 AM, Kevin Cox wrote:
 I was wondering about the foreach statement and when you implement
 opApply() for a class it is implemented using closures.  I was wondering
 if this is just how it is expressed or if it is actually syntatic
 sugar.  The reason I aski is because if you have a return statement
 inside a foreach it returns from the outside function not the "closure".

 I was just wondering if anyone could spill the implementation details.

 Thanks,
 Kevin
Since opApply has to hand through the return code if it is non-zero, I
assume that DMD simply generates a custom exit code for each possible way the foreach body can be exit from.
 eg:

 start:
 foreach(x; foo){
    if(x==1) break;
    else if(x==2) return 10;
    else if(x==3) goto start;
    else if(x==4) continue;
    ...
 }

 ==>

 int __result;
 start:
 switch(foo.opApply((x){
    if(x==1) return 1;
    else if(x==2){__result = 10; return 2;}
    else if(x==3) return 3;
    else if(x==4) return 0;
    ...
 }){
    case 0, 1: break;
    case 2: return __result;
    case 3: goto start;
 }
Cool, so it basically translates break and continue to returns and returns to black magic. Cool.
Apr 08 2012
prev sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 4/9/12 7:26 AM, Kevin Cox wrote:
 I was wondering about the foreach statement and when you implement
 opApply() for a class it is implemented using closures.  I was wondering
 if this is just how it is expressed or if it is actually syntatic
 sugar.  The reason I aski is because if you have a return statement
 inside a foreach it returns from the outside function not the "closure".

 I was just wondering if anyone could spill the implementation details.

 Thanks,
 Kevin
In this video you can see what foreach with opApply gets translated to (at about minute 1): http://www.youtube.com/watch?v=oAhrFQVnsrY
Apr 09 2012
next sibling parent Kevin Cox <kevincox.ca gmail.com> writes:
On Apr 9, 2012 5:59 AM, "Ary Manzana" <ary esperanto.org.ar> wrote:

 In this video you can see what foreach with opApply gets translated to
(at about minute 1):
 http://www.youtube.com/watch?v=oAhrFQVnsrY
Thanks, that's perfect. I'm definitely going to try out decent.
Apr 09 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
OMG, DO WANT! :P
Who wrote this? I wonder if they'd be interested in adapting it to VisualD
+ MonoDevelop?

On 9 April 2012 12:56, Ary Manzana <ary esperanto.org.ar> wrote:

 On 4/9/12 7:26 AM, Kevin Cox wrote:

 I was wondering about the foreach statement and when you implement
 opApply() for a class it is implemented using closures.  I was wondering
 if this is just how it is expressed or if it is actually syntatic
 sugar.  The reason I aski is because if you have a return statement
 inside a foreach it returns from the outside function not the "closure".

 I was just wondering if anyone could spill the implementation details.

 Thanks,
 Kevin
In this video you can see what foreach with opApply gets translated to (at about minute 1): http://www.youtube.com/watch?**v=oAhrFQVnsrY<http://www.youtube.com/watch?v=oAhrFQVnsrY>
Apr 09 2012
next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Monday, 9 April 2012 at 13:19:32 UTC, Manu wrote:
 OMG, DO WANT! :P
 Who wrote this? I wonder if they'd be interested in adapting it 
 to VisualD
 + MonoDevelop?

 On 9 April 2012 12:56, Ary Manzana <ary esperanto.org.ar> wrote:

 On 4/9/12 7:26 AM, Kevin Cox wrote:

 I was wondering about the foreach statement and when you 
 implement
 opApply() for a class it is implemented using closures.  I 
 was wondering
 if this is just how it is expressed or if it is actually 
 syntatic
 sugar.  The reason I aski is because if you have a return 
 statement
 inside a foreach it returns from the outside function not the 
 "closure".

 I was just wondering if anyone could spill the implementation 
 details.

 Thanks,
 Kevin
In this video you can see what foreach with opApply gets translated to (at about minute 1): http://www.youtube.com/watch?**v=oAhrFQVnsrY<http://www.youtube.com/watch?v=oAhrFQVnsrY>
That was Descent, a plugin for Eclipse. They did it by porting DMD, with changes, to Java. A horribly painful task I'd imagine. I wonder if it'd be easier by just creating bindings for DMD for the language of choice. That being said, if MonoDevelop's parser gets to the point where it can evaluate this stuff well, I think that'd work just as nicely. You won't quite be able to see the actual compiler's representation of it, but you'd be able to expand mixins and such. Note that Descent hasn't been updated in almost a year now unfortunately.
Apr 09 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-09 15:44, Kapps wrote:

 That was Descent, a plugin for Eclipse. They did it by porting
 DMD, with changes, to Java. A horribly painful task I'd imagine.
 I wonder if it'd be easier by just creating bindings for DMD for
 the language of choice.
That would be horribly painful as well. Since DMD is not made to be used as a library. It really does not fit.
 That being said, if MonoDevelop's parser gets to the point where
 it can evaluate this stuff well, I think that'd work just as
 nicely. You won't quite be able to see the actual compiler's
 representation of it, but you'd be able to expand mixins and such.
The MonoDevelop parser will have the same problem as the one for Descent. Either it's a port of DMD and needs to play catch up all the time. Or it's a completely new parser that will, most likely, not have the same behavior as the compiler. A new parser would also need to play catch up with DMD. See my other reply: http://forum.dlang.org/thread/mailman.1506.1333927673.4860.digitalmars-d puremagic.com#post-jlutfe:24jal:241:40digitalmars.com -- /Jacob Carlborg
Apr 09 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-09 15:19, Manu wrote:
 OMG, DO WANT! :P
 Who wrote this? I wonder if they'd be interested in adapting it to
 VisualD + MonoDevelop?
That would be Ary Manzana. I think one of the reasons why he stopped working on this was that he ported the DMD frontend to Java and it's just a pain to stay updated with DMD. This comes back to us again, again and again. We _badly need_ a compiler that is usable as a library. Preferably with a stable API which it possible to create bindings for other languages. For that compiler to be stay up to date it needs to be the reference implementation, i.e. the one that Walter works on. Also Walter won't just drop DMD and replace it with something else or start a major refactoring process on the existing code base. BTW, Descent has a compile time debugger as well, if I recall correctly. -- /Jacob Carlborg
Apr 09 2012
parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 4/9/12 10:58 PM, Jacob Carlborg wrote:
 On 2012-04-09 15:19, Manu wrote:
 OMG, DO WANT! :P
 Who wrote this? I wonder if they'd be interested in adapting it to
 VisualD + MonoDevelop?
That would be Ary Manzana. I think one of the reasons why he stopped working on this was that he ported the DMD frontend to Java and it's just a pain to stay updated with DMD.
Yes, it was a pain. I can't understand how I did it. Aaaah... the times when one was young. :-P Robert Fraser also helped a lot with porting, doing some refactorings and many other cool stuff. I don't remember seeing a message of him in this newsgroup for a long time now...
 This comes back to us again, again and again. We _badly need_ a compiler
 that is usable as a library. Preferably with a stable API which it
 possible to create bindings for other languages. For that compiler to be
 stay up to date it needs to be the reference implementation, i.e. the
 one that Walter works on.

 Also Walter won't just drop DMD and replace it with something else or
 start a major refactoring process on the existing code base.
Yes, D definitely needs that. The Eclipse plugin could just use bindings to the D compiler API with JNI. In fact, I think Walter and company should stop working on the current DMD codebase and start all over again. The code, as I see it, is a big mess. Now that the spec is more or less "clear" and not many new features are added, I think this is the time to do it. Actually, nobody has to wait Walter. The community could just start writing a D compiler in D, host it in github and work with pull requests... something like what Rubinius has done with Ruby. Though you might think it'll be harder to catch up with language changes, if the code has a better design I think introducing new changes should be much easier than in DMD's current codebase.
 BTW, Descent has a compile time debugger as well, if I recall correctly.
Yeah, I'm not sure how well that works.
Apr 09 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/9/12 9:21 PM, Ary Manzana wrote:
 Yes, D definitely needs that. The Eclipse plugin could just use bindings
 to the D compiler API with JNI.
Would the JSON compiler output help? Andrei
Apr 09 2012
next sibling parent Kevin Cox <kevincox.ca gmail.com> writes:
On Apr 9, 2012 10:29 PM, "Andrei Alexandrescu" <
SeeWebsiteForEmail erdani.org> wrote:
 On 4/9/12 9:21 PM, Ary Manzana wrote:
 Yes, D definitely needs that. The Eclipse plugin could just use bindings
 to the D compiler API with JNI.
Would the JSON compiler output help? Andrei
It would cover the basics but as soon as you want to something more than slightly advanced you are up a creek.
Apr 09 2012
prev sibling next sibling parent Ary Manzana <ary esperanto.org.ar> writes:
On 4/10/12 10:24 AM, Andrei Alexandrescu wrote:
 On 4/9/12 9:21 PM, Ary Manzana wrote:
 Yes, D definitely needs that. The Eclipse plugin could just use bindings
 to the D compiler API with JNI.
Would the JSON compiler output help? Andrei
Not sure. At least in Descent you could hover over an "auto" keyword and know the inferred type, even inside function bodies. I don't think te JSON compiler output gives you any information about function bodies... right?
Apr 09 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-10 04:24, Andrei Alexandrescu wrote:
 On 4/9/12 9:21 PM, Ary Manzana wrote:
 Yes, D definitely needs that. The Eclipse plugin could just use bindings
 to the D compiler API with JNI.
Would the JSON compiler output help? Andrei
No, it's no way near sufficient for what Descent can do and what's expected from an IDE these days, think JDT for Eclipse. Descent can handle: * Syntax highlighting * Semantic highlighting * Show lex, parse and semantic errors * Compile time debugging * Compile time view * Formatting * Show the actual type of an inferred or aliased type * Smart autocompletion * Many other things as well Note that in addition to (most of) the above, JDT can handle a lot more. The compiler is the only tool that can properly handle this. It's also the only sane approach, to have the compiler usable as a library. Just take a look how it used to be (and in some cases are) in the C/C++ world before Clang and LLVM came a long: * You have the compiler * An IDE with a "parser/compiler" * The debugger with an (expression) "compiler" All these "compilers" are different and need to stay in synch. That's not how you do good software development. You build a compiler library that can be used in all the above tools. BTW, it's only the real compiler that can handle everything properly. -- /Jacob Carlborg
Apr 09 2012
next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 10 Apr 2012 08:46:05 +0200
schrieb Jacob Carlborg <doob me.com>:

 Descent can handle:
 
 * Syntax highlighting
 * Semantic highlighting
 * Show lex, parse and semantic errors
 * Compile time debugging
 * Compile time view
 * Formatting
 * Show the actual type of an inferred or aliased type
 * Smart autocompletion
 * Many other things as well
 
 Note that in addition to (most of) the above, JDT can handle a lot more. 
 The compiler is the only tool that can properly handle this. It's also 
 the only sane approach, to have the compiler usable as a library.
 
 Just take a look how it used to be (and in some cases are) in the C/C++ 
 world before Clang and LLVM came a long:
 
 * You have the compiler
 * An IDE with a "parser/compiler"
 * The debugger with an (expression) "compiler"
 
 All these "compilers" are different and need to stay in synch. That's 
 not how you do good software development. You build a compiler library 
 that can be used in all the above tools. BTW, it's only the real 
 compiler that can handle everything properly.
I think you are right. So clearly to make bindings possible this library would export a set of C functions. (I should think of export(C) as the "least common denominator" here.) DMD is no where close to look like a library and IDEs/debuggers need a different set of features. I think we can start a new thread to discuss this and maybe a Wiki page to collect ideas and brainstorm, unless there are better tools for that available. It would be nice if the developers of DDT, Descent, Mono-D and VisualD could share their insights there to get the requirements straight. -- Marco
Apr 10 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-10 19:49, Marco Leise wrote:

 I think you are right. So clearly to make bindings possible this library would
export a set of C functions. (I should think of export(C) as the "least common
denominator" here.) DMD is no where close to look like a library and
IDEs/debuggers need a different set of features. I think we can start a new
thread to discuss this and maybe a Wiki page to collect ideas and brainstorm,
unless there are better tools for that available. It would be nice if the
developers of DDT, Descent, Mono-D and VisualD could share their insights there
to get the requirements straight.
Sounds like a good idea. -- /Jacob Carlborg
Apr 10 2012
prev sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 4/10/12 2:46 PM, Jacob Carlborg wrote:
 On 2012-04-10 04:24, Andrei Alexandrescu wrote:
 On 4/9/12 9:21 PM, Ary Manzana wrote:
 Yes, D definitely needs that. The Eclipse plugin could just use bindings
 to the D compiler API with JNI.
Would the JSON compiler output help? Andrei
No, it's no way near sufficient for what Descent can do and what's expected from an IDE these days, think JDT for Eclipse. Descent can handle: * Syntax highlighting * Semantic highlighting * Show lex, parse and semantic errors * Compile time debugging * Compile time view * Formatting * Show the actual type of an inferred or aliased type * Smart autocompletion * Many other things as well Note that in addition to (most of) the above, JDT can handle a lot more. The compiler is the only tool that can properly handle this. It's also the only sane approach, to have the compiler usable as a library. Just take a look how it used to be (and in some cases are) in the C/C++ world before Clang and LLVM came a long: * You have the compiler * An IDE with a "parser/compiler" * The debugger with an (expression) "compiler" All these "compilers" are different and need to stay in synch. That's not how you do good software development. You build a compiler library that can be used in all the above tools. BTW, it's only the real compiler that can handle everything properly.
Yes. In fact, JDT has a built-in Java compiler in their implementation. Maybe it was easier to do it for them because the Java spec is easier and doesn't fluctuate that much as the D spec. And JDT used that compiler all over the place for getting all those IDE features.
Apr 10 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-11 04:50, Ary Manzana wrote:

 Yes. In fact, JDT has a built-in Java compiler in their implementation.
 Maybe it was easier to do it for them because the Java spec is easier
 and doesn't fluctuate that much as the D spec. And JDT used that
 compiler all over the place for getting all those IDE features.
Exactly. Java hasn't changed much in the last 10 years (ok, just now it starts to changed again). JDT also contains a full compiler, not just the frontend, so it can compile all code. This would be nice to have for D as well but I think the frontend is the most important part. -- /Jacob Carlborg
Apr 11 2012
parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 4/11/12 4:27 PM, Jacob Carlborg wrote:
 On 2012-04-11 04:50, Ary Manzana wrote:

 Yes. In fact, JDT has a built-in Java compiler in their implementation.
 Maybe it was easier to do it for them because the Java spec is easier
 and doesn't fluctuate that much as the D spec. And JDT used that
 compiler all over the place for getting all those IDE features.
Exactly. Java hasn't changed much in the last 10 years (ok, just now it starts to changed again). JDT also contains a full compiler, not just the frontend, so it can compile all code. This would be nice to have for D as well but I think the frontend is the most important part.
Yes. I'm still thinking how could it be done but I have no idea at all how to do it. I can't figure out what that API would look like. I like the idea of a new thread for this discussion. Eventually me or someone else should start it. :-P
Apr 11 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-12 03:12, Ary Manzana wrote:

 Yes. I'm still thinking how could it be done but I have no idea at all
 how to do it. I can't figure out what that API would look like.
Yeah, designing API's are hard. I'm starting to think that a completely new compiler (or frontend) built for this from the start might be the best idea anyway. Then we don't care too much about keeping up and just let it take the time it takes. There are still a big amount of that D is very stable and pretty straight forward. We don't need to _start_ with a compile time debugger or mixin evaluations :)
 I like the idea of a new thread for this discussion. Eventually me or
 someone else should start it. :-P
I think so too. You know, no one is stopping you :) -- /Jacob Carlborg
Apr 11 2012
prev sibling parent reply "Matt Peterson" <ricochet1k gmail.com> writes:
On Tuesday, 10 April 2012 at 02:24:31 UTC, Andrei Alexandrescu 
wrote:
 Would the JSON compiler output help?
I made a pull request a while ago that gives a lot more JSON output (https://github.com/D-Programming-Language/dmd/pull/813). I'm willing to try to improve it to better meet the needs of an IDE, if anyone has any suggestions.
Apr 11 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-12 03:31, Matt Peterson wrote:
 On Tuesday, 10 April 2012 at 02:24:31 UTC, Andrei Alexandrescu wrote:
 Would the JSON compiler output help?
I made a pull request a while ago that gives a lot more JSON output (https://github.com/D-Programming-Language/dmd/pull/813). I'm willing to try to improve it to better meet the needs of an IDE, if anyone has any suggestions.
I'm pretty sure that the JSON output can _never_ be enough for what we want to do. -- /Jacob Carlborg
Apr 11 2012
parent reply "Matt Peterson" <ricochet1k gmail.com> writes:
On Thursday, 12 April 2012 at 06:46:53 UTC, Jacob Carlborg wrote:
 I'm pretty sure that the JSON output can _never_ be enough for 
 what we want to do.
I agree with that, nothing will quite be the same as a full compiler-as-a-library (CAAL?). But in the meantime, there is a working compiler now, and isn't it better to get some kind of IDE-like functionality sooner rather than waiting for a long time with nothing?
Apr 12 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-13 06:50, Matt Peterson wrote:
 On Thursday, 12 April 2012 at 06:46:53 UTC, Jacob Carlborg wrote:
 I'm pretty sure that the JSON output can _never_ be enough for what we
 want to do.
I agree with that, nothing will quite be the same as a full compiler-as-a-library (CAAL?). But in the meantime, there is a working compiler now, and isn't it better to get some kind of IDE-like functionality sooner rather than waiting for a long time with nothing?
When you say "there is a working compiler now", which on is you referring to. DMD, LDC, GDC, SDC or any other? As far as I know neither DMD, LDC or GDC is usable as a library. I have no experience of SDC and don't know in what state it is. But I guess we would have to do some investigation and figure out what the best to do this would be. BTW, there are already IDE's with some kind of frontends available. MonoD, VisualD, Descent (now old) and possibly others. -- /Jacob Carlborg
Apr 12 2012
parent reply James Miller <james aatch.net> writes:
* Jacob Carlborg <doob me.com> [2012-04-13 08:40:39 +0200]:
 On 2012-04-13 06:50, Matt Peterson wrote:
I agree with that, nothing will quite be the same as a full
compiler-as-a-library (CAAL?). But in the meantime, there is a working
compiler now, and isn't it better to get some kind of IDE-like
functionality sooner rather than waiting for a long time with nothing?
When you say "there is a working compiler now", which on is you referring to. DMD, LDC, GDC, SDC or any other? As far as I know neither DMD, LDC or GDC is usable as a library. I have no experience of SDC and don't know in what state it is. But I guess we would have to do some investigation and figure out what the best to do this would be. BTW, there are already IDE's with some kind of frontends available. MonoD, VisualD, Descent (now old) and possibly others.
I think he means that while there isn't a suitable "CaaL", there are working compilers that can be improved to supply enough information to atleast start on IDE integration, even if it isn't as robust or efficient as an actual library.
From what I can tell, LDC would probably be the best for the kind of
code analysis an IDE would need, since it is has an LLVM backend. SDC would be good too, but SDC is probably the best one to try to move towards adding this functionality. -- James Miller
Apr 13 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-13 11:28, James Miller wrote:

 I think he means that while there isn't a suitable "CaaL", there are
 working compilers that can be improved to supply enough information to
 atleast start on IDE integration, even if it isn't as robust or
 efficient as an actual library.

 From what I can tell, LDC would probably be the best for the kind of
code analysis an IDE would need, since it is has an LLVM backend. SDC would be good too, but SDC is probably the best one to try to move towards adding this functionality. -- James Miller
I don't know if it would be much difference between LDC, GDC and DMD since they all use the same frontend. And it's the frontend that is the most important part, not the backend. -- /Jacob Carlborg
Apr 13 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Apr 10, 2012 at 10:21:04AM +0800, Ary Manzana wrote:
[...]
 Actually, nobody has to wait Walter. The community could just start
 writing a D compiler in D, host it in github and work with pull
 requests... something like what Rubinius has done with Ruby.
 
 Though you might think it'll be harder to catch up with language
 changes, if the code has a better design I think introducing new
 changes should be much easier than in DMD's current codebase.
[...] I've thought about this too. But the question is whether or not this will dilute the already small number of D compiler contributors to the point that it harms D more than helps it. T -- Fact is stranger than fiction.
Apr 09 2012
prev sibling next sibling parent reply Brad Anderson <eco gnuk.net> writes:
On Mon, Apr 9, 2012 at 8:21 PM, Ary Manzana <ary esperanto.org.ar> wrote:

 On 4/9/12 10:58 PM, Jacob Carlborg wrote:

 On 2012-04-09 15:19, Manu wrote:

 OMG, DO WANT! :P
 Who wrote this? I wonder if they'd be interested in adapting it to
 VisualD + MonoDevelop?
That would be Ary Manzana. I think one of the reasons why he stopped working on this was that he ported the DMD frontend to Java and it's just a pain to stay updated with DMD.
Yes, it was a pain. I can't understand how I did it. Aaaah... the times when one was young. :-P Robert Fraser also helped a lot with porting, doing some refactorings and many other cool stuff. I don't remember seeing a message of him in this newsgroup for a long time now... This comes back to us again, again and again. We _badly need_ a compiler
 that is usable as a library. Preferably with a stable API which it
 possible to create bindings for other languages. For that compiler to be
 stay up to date it needs to be the reference implementation, i.e. the
 one that Walter works on.

 Also Walter won't just drop DMD and replace it with something else or
 start a major refactoring process on the existing code base.
Yes, D definitely needs that. The Eclipse plugin could just use bindings to the D compiler API with JNI. In fact, I think Walter and company should stop working on the current DMD codebase and start all over again. The code, as I see it, is a big mess. Now that the spec is more or less "clear" and not many new features are added, I think this is the time to do it. Actually, nobody has to wait Walter. The community could just start writing a D compiler in D, host it in github and work with pull requests... something like what Rubinius has done with Ruby.
It's already been started. SDC: https://github.com/bhelyer/SDC Regards, Brad Anderson
 Though you might think it'll be harder to catch up with language changes,
 if the code has a better design I think introducing new changes should be
 much easier than in DMD's current codebase.


  BTW, Descent has a compile time debugger as well, if I recall correctly.

 Yeah, I'm not sure how well that works.
Apr 09 2012
next sibling parent Ary Manzana <ary esperanto.org.ar> writes:
On 4/10/12 10:47 AM, Brad Anderson wrote:
 On Mon, Apr 9, 2012 at 8:21 PM, Ary Manzana <ary esperanto.org.ar
 <mailto:ary esperanto.org.ar>> wrote:

     On 4/9/12 10:58 PM, Jacob Carlborg wrote:

         On 2012-04-09 15:19, Manu wrote:

             OMG, DO WANT! :P
             Who wrote this? I wonder if they'd be interested in adapting
             it to
             VisualD + MonoDevelop?


         That would be Ary Manzana. I think one of the reasons why he stopped
         working on this was that he ported the DMD frontend to Java and it's
         just a pain to stay updated with DMD.


     Yes, it was a pain. I can't understand how I did it. Aaaah... the
     times when one was young. :-P

     Robert Fraser also helped a lot with porting, doing some
     refactorings and many other cool stuff. I don't remember seeing a
     message of him in this newsgroup for a long time now...


         This comes back to us again, again and again. We _badly need_ a
         compiler
         that is usable as a library. Preferably with a stable API which it
         possible to create bindings for other languages. For that
         compiler to be
         stay up to date it needs to be the reference implementation,
         i.e. the
         one that Walter works on.

         Also Walter won't just drop DMD and replace it with something
         else or
         start a major refactoring process on the existing code base.


     Yes, D definitely needs that. The Eclipse plugin could just use
     bindings to the D compiler API with JNI.

     In fact, I think Walter and company should stop working on the
     current DMD codebase and start all over again. The code, as I see
     it, is a big mess. Now that the spec is more or less "clear" and not
     many new features are added, I think this is the time to do it.

     Actually, nobody has to wait Walter. The community could just start
     writing a D compiler in D, host it in github and work with pull
     requests... something like what Rubinius has done with Ruby.


 It's already been started.  SDC: https://github.com/bhelyer/SDC

 Regards,
 Brad Anderson
Awesome!
Apr 09 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-10 04:47, Brad Anderson wrote:

 It's already been started.  SDC: https://github.com/bhelyer/SDC
But has it been built to be usable as a library? -- /Jacob Carlborg
Apr 09 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-10 04:21, Ary Manzana wrote:

 In fact, I think Walter and company should stop working on the current
 DMD codebase and start all over again. The code, as I see it, is a big
 mess. Now that the spec is more or less "clear" and not many new
 features are added, I think this is the time to do it.
I think so as well.
 Actually, nobody has to wait Walter. The community could just start
 writing a D compiler in D, host it in github and work with pull
 requests... something like what Rubinius has done with Ruby.

 Though you might think it'll be harder to catch up with language
 changes, if the code has a better design I think introducing new changes
 should be much easier than in DMD's current codebase.
Yeah, it will be easier to add changes if the compiler has a better design, but you still need to catch up with the reference implementation. -- /Jacob Carlborg
Apr 09 2012
prev sibling parent reply Kevin Cox <kevincox.ca gmail.com> writes:
On Apr 9, 2012 9:19 AM, "Manu" <turkeyman gmail.com> wrote:
 OMG, DO WANT! :P
 Who wrote this? I wonder if they'd be interested in adapting it to
VisualD + MonoDevelop?
 On 9 April 2012 12:56, Ary Manzana <ary esperanto.org.ar> wrote:
 On 4/9/12 7:26 AM, Kevin Cox wrote:
 I was wondering about the foreach statement and when you implement
 opApply() for a class it is implemented using closures.  I was wondering
 if this is just how it is expressed or if it is actually syntatic
 sugar.  The reason I aski is because if you have a return statement
 inside a foreach it returns from the outside function not the "closure".

 I was just wondering if anyone could spill the implementation details.

 Thanks,
 Kevin
In this video you can see what foreach with opApply gets translated to
(at about minute 1):
 http://www.youtube.com/watch?v=oAhrFQVnsrY
Unfortunately I can't get it working. Ill have to keep fiddling.
Apr 09 2012
parent Ary Manzana <ary esperanto.org.ar> writes:
On 4/9/12 9:35 PM, Kevin Cox wrote:
 On Apr 9, 2012 9:19 AM, "Manu" <turkeyman gmail.com
 <mailto:turkeyman gmail.com>> wrote:
  >
  > OMG, DO WANT! :P
  > Who wrote this? I wonder if they'd be interested in adapting it to
 VisualD + MonoDevelop?
  >
  >
  > On 9 April 2012 12:56, Ary Manzana <ary esperanto.org.ar
 <mailto:ary esperanto.org.ar>> wrote:
  >>
  >> On 4/9/12 7:26 AM, Kevin Cox wrote:
  >>>
  >>> I was wondering about the foreach statement and when you implement
  >>> opApply() for a class it is implemented using closures.  I was
 wondering
  >>> if this is just how it is expressed or if it is actually syntatic
  >>> sugar.  The reason I aski is because if you have a return statement
  >>> inside a foreach it returns from the outside function not the
 "closure".
  >>>
  >>> I was just wondering if anyone could spill the implementation details.
  >>>
  >>> Thanks,
  >>> Kevin
  >>
  >>
  >> In this video you can see what foreach with opApply gets translated
 to (at about minute 1):
  >>
  >> http://www.youtube.com/watch?v=oAhrFQVnsrY
  >

 Unfortunately I can't get it working.  Ill have to keep fiddling.
Note that, as many already said, it hasn't been updated for a long time now, and things won't change. So only use it if coding for a reaaaally old D version.
Apr 09 2012