Re: Foreach Closures?
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
Re: Foreach Closures?
* Jacob Carlborg d...@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
Re: Foreach Closures?
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
Re: Foreach Closures?
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
Re: Foreach Closures?
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
Re: Foreach Closures?
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?
Re: Foreach Closures?
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
Re: Foreach Closures?
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
Re: Foreach Closures?
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.
Re: Foreach Closures?
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
Re: Foreach Closures?
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
Re: Foreach Closures?
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
Re: Foreach Closures?
On 4/9/12, Kevin Cox kevincox...@gmail.com wrote:
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 don't like this subtle thing. For example let's say a newbie were to
implement a function called isDirEmpty. The first hint is to try to
walk the directory iteratively and return as soon as there's a match,
e.g.:
bool isEmptyDir(string path)
{
foreach (_; dirEntries(path, SpanMode.shallow))
return false;
return true;
}
isEmptyDir never returns false. All that false statement does is break
out of the foreach loop.
Of course the right way to implement this is:
bool isEmptyDir(string path)
{
return dirEntries(path, SpanMode.shallow).empty;
}
But still, the first version is extremely subtle. The semantics of
that code completely change based on whether dirEntries is an array, a
range, or an opApply.
Re: Foreach Closures?
On 10.04.2012 13:33, Andrej Mitrovic wrote:
On 4/9/12, Kevin Coxkevincox...@gmail.com wrote:
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 don't like this subtle thing. For example let's say a newbie were to
implement a function called isDirEmpty. The first hint is to try to
walk the directory iteratively and return as soon as there's a match,
e.g.:
bool isEmptyDir(string path)
{
foreach (_; dirEntries(path, SpanMode.shallow))
return false;
return true;
}
isEmptyDir never returns false. All that false statement does is break
out of the foreach loop.
Wake up! dirEntries produce a lazy _range_ and it's not opApply
closures. And you were the one to come up with this cool
parallel(dirEntries(...)) thing back when it was introduced.
Anyway that return false would have been translated to some
black-magic jump.
Of course the right way to implement this is:
bool isEmptyDir(string path)
{
return dirEntries(path, SpanMode.shallow).empty;
}
But still, the first version is extremely subtle. The semantics of
that code completely change based on whether dirEntries is an array, a
range, or an opApply.
array vs range is the same here. opApply is the weirdo.
--
Dmitry Olshansky
Re: Foreach Closures?
On 4/10/12, Dmitry Olshansky dmitry.o...@gmail.com wrote:
Wake up! dirEntries produce a lazy _range_ and it's not opApply
Sorry? Change DirIterator in std.file to this:
http://pastebin.com/DHvXuFeH
test.d:
import std.file;
bool isEmptyDir(string path)
{
foreach (string name; dirEntries(path, SpanMode.shallow))
return false;
return true;
}
void main()
{
isEmptyDir(.);
}
$ rdmd test.d
we're in oppapply
Re: Foreach Closures?
On 04/10/2012 12:06 PM, Andrej Mitrovic wrote:
On 4/10/12, Dmitry Olshanskydmitry.o...@gmail.com wrote:
Wake up! dirEntries produce a lazy _range_ and it's not opApply
Sorry? Change DirIterator in std.file to this:
http://pastebin.com/DHvXuFeH
You are doing it wrong.
Use:
if(auto r=dg(s)) return r;
instead.
test.d:
import std.file;
bool isEmptyDir(string path)
{
foreach (string name; dirEntries(path, SpanMode.shallow))
return false;
return true;
}
void main()
{
isEmptyDir(.);
}
$ rdmd test.d
we're in oppapply
Re: Foreach Closures?
On 04/10/2012 11:33 AM, Andrej Mitrovic wrote:
On 4/9/12, Kevin Coxkevincox...@gmail.com wrote:
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 don't like this subtle thing. For example let's say a newbie were to
implement a function called isDirEmpty. The first hint is to try to
walk the directory iteratively and return as soon as there's a match,
e.g.:
bool isEmptyDir(string path)
{
foreach (_; dirEntries(path, SpanMode.shallow))
return false;
return true;
}
isEmptyDir never returns false.
Yes it does.
All that false statement does is break
out of the foreach loop.
??? No, it returns false from isEmptyDir, unless the opApply
implementation abuses operator overloading.
Re: Foreach Closures?
On 04/10/2012 12:50 PM, Timon Gehr wrote: On 04/10/2012 12:47 PM, Timon Gehr wrote: On 04/10/2012 12:06 PM, Andrej Mitrovic wrote: On 4/10/12, Dmitry Olshanskydmitry.o...@gmail.com wrote: Wake up! dirEntries produce a lazy _range_ and it's not opApply Sorry? Change DirIterator in std.file to this: http://pastebin.com/DHvXuFeH You are doing it wrong. Use: if(auto r=dg(s)) return r; instead. WTF??! It is actually wrong in Phobos. Bug! http://d.puremagic.com/issues/show_bug.cgi?id=7884
Re: Foreach Closures?
On 04/10/2012 12:47 PM, Timon Gehr wrote: On 04/10/2012 12:06 PM, Andrej Mitrovic wrote: On 4/10/12, Dmitry Olshanskydmitry.o...@gmail.com wrote: Wake up! dirEntries produce a lazy _range_ and it's not opApply Sorry? Change DirIterator in std.file to this: http://pastebin.com/DHvXuFeH You are doing it wrong. Use: if(auto r=dg(s)) return r; instead. WTF??! It is actually wrong in Phobos. Bug!
Re: Foreach Closures?
On 10.04.2012 14:06, Andrej Mitrovic wrote:
On 4/10/12, Dmitry Olshanskydmitry.o...@gmail.com wrote:
Wake up! dirEntries produce a lazy _range_ and it's not opApply
Sorry? Change DirIterator in std.file to this:
http://pastebin.com/DHvXuFeH
Yeah recent change allowed to use straight alias this in DirEntry struct
thus there is no need for separate opApply now.
test.d:
import std.file;
bool isEmptyDir(string path)
{
foreach (string name; dirEntries(path, SpanMode.shallow))
return false;
return true;
}
void main()
{
isEmptyDir(.);
}
$ rdmd test.d
we're in oppapply
--
Dmitry Olshansky
Re: Foreach Closures?
On 10.04.2012 14:50, Timon Gehr wrote: On 04/10/2012 12:47 PM, Timon Gehr wrote: On 04/10/2012 12:06 PM, Andrej Mitrovic wrote: On 4/10/12, Dmitry Olshanskydmitry.o...@gmail.com wrote: Wake up! dirEntries produce a lazy _range_ and it's not opApply Sorry? Change DirIterator in std.file to this: http://pastebin.com/DHvXuFeH You are doing it wrong. Use: if(auto r=dg(s)) return r; instead. WTF??! It is actually wrong in Phobos. Bug! Is it still opApply in Phobos? I mean I did the pull that removed it. -- Dmitry Olshansky
Re: Foreach Closures?
On 04/10/2012 12:54 PM, Dmitry Olshansky wrote: On 10.04.2012 14:50, Timon Gehr wrote: On 04/10/2012 12:47 PM, Timon Gehr wrote: On 04/10/2012 12:06 PM, Andrej Mitrovic wrote: On 4/10/12, Dmitry Olshanskydmitry.o...@gmail.com wrote: Wake up! dirEntries produce a lazy _range_ and it's not opApply Sorry? Change DirIterator in std.file to this: http://pastebin.com/DHvXuFeH You are doing it wrong. Use: if(auto r=dg(s)) return r; instead. WTF??! It is actually wrong in Phobos. Bug! Is it still opApply in Phobos? I mean I did the pull that removed it. Yes, it is fixed in git head. Sorry for the noise.
Re: Foreach Closures?
On 4/10/12, Timon Gehr timon.g...@gmx.ch wrote: Yes, it is fixed in git head. Sorry for the noise. Sorry for my noise too, I didn't know it was fixed in git head. :)
Re: Foreach Closures?
Am Tue, 10 Apr 2012 08:46:05 +0200 schrieb Jacob Carlborg d...@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
Re: Foreach Closures?
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
Re: Foreach Closures?
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.
Re: Foreach Closures?
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
Re: Foreach Closures?
On Apr 9, 2012 5:59 AM, Ary Manzana a...@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.
Re: Foreach Closures?
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 a...@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=oAhrFQVnsrYhttp://www.youtube.com/watch?v=oAhrFQVnsrY
Re: Foreach Closures?
On Apr 9, 2012 9:19 AM, Manu turkey...@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 a...@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.
Re: Foreach Closures?
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 a...@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=oAhrFQVnsrYhttp://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.
Re: Foreach Closures?
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
Re: Foreach Closures?
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.digitalmar...@puremagic.com#post-jlutfe:24jal:241:40digitalmars.com -- /Jacob Carlborg
Re: Foreach Closures?
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.
Re: Foreach Closures?
On 4/9/12 9:35 PM, Kevin Cox wrote: On Apr 9, 2012 9:19 AM, Manu turkey...@gmail.com mailto:turkey...@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 a...@esperanto.org.ar mailto:a...@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 relly old D version.
Re: Foreach Closures?
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
Re: Foreach Closures?
On Apr 9, 2012 10:29 PM, Andrei Alexandrescu seewebsiteforem...@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.
Re: Foreach Closures?
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.
Re: Foreach Closures?
On Mon, Apr 9, 2012 at 8:21 PM, Ary Manzana a...@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.
Re: Foreach Closures?
On 4/10/12 10:47 AM, Brad Anderson wrote: On Mon, Apr 9, 2012 at 8:21 PM, Ary Manzana a...@esperanto.org.ar mailto:a...@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!
Re: Foreach Closures?
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?
Foreach Closures?
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
Re: Foreach Closures?
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
Re: Foreach Closures?
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;
}
Re: Foreach Closures?
On Apr 8, 2012 7:49 PM, Timon Gehr timon.g...@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.
