Reply to bearophile,

>> Reply to mike,
>>
>>> Wouldn't it suffice to overload the new keyword?
>>> heap:
>>> delegate t = new { return 3; }
>>> stack:
>>> delegate t = { return 3; }
> Generally in D the default behavior must be the safer one, in this
> situation it means the heap version...

but "is heap allocation always safe?"

Mike schrieb:
> On Mon, 14 Jul 2008 04:39:58 +0200, davidl <davidl@126.com> wrote:
> 
>> it's better to introduce a new keyword, closure.
>>
>> there
>>
>> on heap:
>> closure t = {
>>    // my closure
>>    return 3;
>> }
>>
>> on stack:
>> delegate t = {
>>    retirm 3;
>> }
> 
> Wouldn't it suffice to overload the new keyword?
> 
> heap:
> 
> delegate t = new { return 3; }
> 
> stack:
> 
> delegate t = { return 3; }
> 
> That way it could work with delegate literals too:
> 
> int b = 3;
> foo(new { return b; });
> 
> -Mike
> 
> 

I think the problem here is, new says that it will force a heap allocation for its call. But the heap allocation shall not happen per delegate, it shall only happen once for the surrounding stack frame if it contains at least one heap allocated delegate.
hm, is it understandable what i mean by this ? :)

Reply to Frank,

> Mike schrieb:
> 
>> On Mon, 14 Jul 2008 04:39:58 +0200, davidl <davidl@126.com> wrote:
>> 
>>> it's better to introduce a new keyword, closure.
>>> 
>>> there
>>> 
>>> on heap:
>>> closure t = {
>>> // my closure
>>> return 3;
>>> }
>>> on stack:
>>> delegate t = {
>>> retirm 3;
>>> }
>> Wouldn't it suffice to overload the new keyword?
>> 
>> heap:
>> 
>> delegate t = new { return 3; }
>> 
>> stack:
>> 
>> delegate t = { return 3; }
>> 
>> That way it could work with delegate literals too:
>> 
>> int b = 3;
>> foo(new { return b; });
>> -Mike
>> 
> I think the problem here is, new says that it will force a heap
> allocation for its call. But the heap allocation shall not happen per
> delegate, it shall only happen once for the surrounding stack frame if
> it contains at least one heap allocated delegate.
> hm, is it understandable what i mean by this ? :)

Yes, I understand it. (FWIW)

Jarrett Billingsley wrote:
> "Koroskin Denis" <2korden@gmail.com> wrote in message news:op.ueaoscr8enyajd@proton.creatstudio.intranet...
>> Shouldn't it be heap-allocated by default? I prefer scope keywork reuse :)
> 
> You have a point there.  And I think you may have something with using 'scope' to indicate nested functions whose stack frames are not to be heap-allocated.  It goes along with scope classes nicely.  You wouldn't be able to return a scope delegate, and it makes sense -- "this delegate only works in this scope.  When the scope leaves, the delegate is no longer valid."
> 
> Adding "scope" also makes it possible for the compiler to check that you don't do stupid things statically, at least in many cases. 
> 
> 

I think Walter's solution ("using 'scope' to tag function parameters that do not escape") may be even better. It doesn't add new syntax to literals, is statically verifiable more "locally", and may have other uses other than for delegates.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros:
> I think Walter's solution ("using 'scope' to tag function parameters that do not escape") may be even better. It doesn't add new syntax to literals, is statically verifiable more "locally", and may have other uses other than for delegates.

So to pass a lambda without closure you have to write something like this?
foo(scope (int x){return x*x;});

Bye,
bearophile

== Quote from Bruno Medeiros (brunodomedeiros+spam@com.gmail)'s article
> Jarrett Billingsley wrote:
> > "Koroskin Denis" <2korden@gmail.com> wrote in message news:op.ueaoscr8enyajd@proton.creatstudio.intranet...
> >> Shouldn't it be heap-allocated by default? I prefer scope keywork reuse :)
> >
> > You have a point there.  And I think you may have something with using 'scope' to indicate nested functions whose stack frames are not to be heap-allocated.  It goes along with scope classes nicely.  You wouldn't be able to return a scope delegate, and it makes sense -- "this delegate only works in this scope.  When the scope leaves, the delegate is no longer valid."
> >
> > Adding "scope" also makes it possible for the compiler to check that you don't do stupid things statically, at least in many cases.
> >
> >
> I think Walter's solution ("using 'scope' to tag function parameters that do not escape") may be even better. It doesn't add new syntax to literals, is statically verifiable more "locally", and may have other uses other than for delegates.

Tagging the stuff that doesn't escape isn't backwards-compatible with D 1.0, where non-escaping is the default.  Not that we don't already have some pointless portability issues from D 1.0 to D 2.0, but I'd think it would be desirable to not add more.


Sean

bearophile wrote:
> Bruno Medeiros:
>> I think Walter's solution ("using 'scope' to tag function parameters that do not escape") may be even better. It doesn't add new syntax to literals, is statically verifiable more "locally", and may have other uses other than for delegates.
> 
> So to pass a lambda without closure you have to write something like this?
> foo(scope (int x){return x*x;});
> 
> Bye,
> bearophile

I said parameters, not arguments. You'd declared the function like this:

  void foo(scope int delegate(int) dg) {

the function call would remain the same:

  foo((int x){return x*x;});

Seems a better solution, at least at first sight, haven't though much about it.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Sean Kelly wrote:
> == Quote from Bruno Medeiros (brunodomedeiros+spam@com.gmail)'s article
>> Jarrett Billingsley wrote:
>>> "Koroskin Denis" <2korden@gmail.com> wrote in message
>>> news:op.ueaoscr8enyajd@proton.creatstudio.intranet...
>>>> Shouldn't it be heap-allocated by default? I prefer scope keywork reuse :)
>>> You have a point there.  And I think you may have something with using
>>> 'scope' to indicate nested functions whose stack frames are not to be
>>> heap-allocated.  It goes along with scope classes nicely.  You wouldn't be
>>> able to return a scope delegate, and it makes sense -- "this delegate only
>>> works in this scope.  When the scope leaves, the delegate is no longer
>>> valid."
>>>
>>> Adding "scope" also makes it possible for the compiler to check that you
>>> don't do stupid things statically, at least in many cases.
>>>
>>>
>> I think Walter's solution ("using 'scope' to tag function parameters
>> that do not escape") may be even better. It doesn't add new syntax to
>> literals, is statically verifiable more "locally", and may have other
>> uses other than for delegates.
> 
> Tagging the stuff that doesn't escape isn't backwards-compatible with
> D 1.0, where non-escaping is the default.  Not that we don't already
> have some pointless portability issues from D 1.0 to D 2.0, but I'd
> think it would be desirable to not add more.
> 
> 
> Sean

D 2.0 vs 1.0 is not like Java 1.5 vs Java 1.4, or C# 2 vs. C# 3.
D is still very "experimental" and very under development, and, for better or worse, that makes the differences between D 2.0 and 1.0 many, profound, and ever-increasing. The "worse" part is that it makes it very hard to maintain compatibility, perhaps even unpractical at all?

I wish there wasn't a need or desire to maintain 1.0 compatibility, and people would move to 2.0. The sole key to this being Tango of course. I understand you have good motives for not moving to 2.0 yet, but I hope those can solved quite sooner rather later. The D community has allways been divided in two camps, but never has the "rift" been so wide and hurtful as now. :/



-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

"Bruno Medeiros" wrote
> I wish there wasn't a need or desire to maintain 1.0 compatibility, and people would move to 2.0. The sole key to this being Tango of course. I understand you have good motives for not moving to 2.0 yet, but I hope those can solved quite sooner rather later. The D community has allways been divided in two camps, but never has the "rift" been so wide and hurtful as now. :/

We have tried.  D2 has too many blocker bugs for Tango to work properly, otherwise, there would be a D2 port.

But even if this did happen, there is no way that Tango would move to an as-yet-unreleased compiler and abandon efforts on D1.  And most likely, D1 Tango would continue to exist because some people simply don't like const.

I plan to move to D2 as soon as Tango can build with it.

-Steve

On Thu, Jul 31, 2008 at 8:01 AM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> "Bruno Medeiros" wrote
>> I wish there wasn't a need or desire to maintain 1.0 compatibility, and people would move to 2.0. The sole key to this being Tango of course. I understand you have good motives for not moving to 2.0 yet, but I hope those can solved quite sooner rather later. The D community has allways been divided in two camps, but never has the "rift" been so wide and hurtful as now. :/
>
> We have tried.  D2 has too many blocker bugs for Tango to work properly, otherwise, there would be a D2 port.
>
> But even if this did happen, there is no way that Tango would move to an as-yet-unreleased compiler and abandon efforts on D1.  And most likely, D1 Tango would continue to exist because some people simply don't like const.
>
> I plan to move to D2 as soon as Tango can build with it.

Is there a list of these Tango blocker bugs somewhere?

Perhaps the list should be put into bugzilla as a meta-bug that references all the relevant issues in bugzilla.  I have to believe that if Walter had a clear idea of what the bugs blocking Tango were, that he would prioritize them and wipe them out within a release or two.

--bb