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