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

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

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;
}

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.

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

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.

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

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.

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.

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