On Fri, 15 Oct 2010 21:34:39 +0400, Walter Bright <newshound2@digitalmars.com> wrote:

> Max Samukha wrote:
>> On 10/15/2010 12:32 PM, Walter Bright wrote:
>>>
>>> The example relies on taking the address of a ref in a safe function. To
>>> close this hole, it appears that should be disallowed.
>>  And disallowing it makes references not so useful.
>
> I don't see why. They're useful enough.
>
>
>> What I like about Go's solution is that it is consistent with closures. When a group of locals escape with a closure (that is when the address of the local function using that group is taken) they are copied to heap. When a local escape by ref (that is when the address of the local is taken), it is also copied to heap.
>
> I understand how it works. There is a downside to it, though. In D2, closures get copied to the GC heap if there is a possibility of an escaping reference. A lot of people complain about this being unexpected hidden overhead.
>
> The trouble with "copy any ref'd local to the heap" automatically happening is the biggest advantage of passing by ref (efficiency) is automatically lost. Even if it does not escape, it is copied to the heap anyway, as you point out below.
>
>
>> What I don't like about Go's closures/addresses-to-locals and D's delegates is that stuff is heap-allocated implicitly and by default. Go has even gone (sorry) as far as allocating copies *every* time the address of a local is taken.
>
> Exactly. (Though D won't do the copy if it can prove that the delegate does not escape.)
>
>
>> That reminds me of the argument about "new" being necessary for classes because it makes the heap allocation explicit. It is difficult to say good-bye to "new" but at the same time we are somehow happy with implicitly allocated closures.
>
> I think that implicitly allocated closures are a lot less common than passing a local by reference.

IIRC there was some keyword (is that static?) that forces a closure NOT to allocate on heap.

I think I'll add an optional parameter that lists all the heap-allocated closures to ddmd (similar to how -vtls works).

== Quote from Denis Koroskin (2korden@gmail.com)'s article
> IIRC there was some keyword (is that static?) that forces a closure NOT to
> allocate on heap.

You're thinking of scope, and it works but it's a huge hack.  When &someNestedFunction is evaluated in the context of a function call and the parameter is scope, there is no heap allocation.  I've been meaning to dump a function into std.typecons, called noHeap or something, that just takes a scope delegate and returns it, as a way to bypass heap allocations for other cases of taking the address of a nested function.

In general, I think this is a decent strategy:  The implicit default behavior should be safe, easy to understand and easy to use even if it hurts performance. Optimizations should be carried out by the compiler when it can prove they won't affect code semantics or by the programmer when he/she can prove they're necessary.  I wouldn't mind having &someLocal heap allocate like closures do (and be allowed in SafeD), as long as there's an easy way to explicitly prevent this. For example, we could use the scope trick like with closures, and have a scopedAddress function in std.typecons that lets you unsafely take the address of a stack variable.

> I think I'll add an optional parameter that lists all the heap-allocated closures to ddmd (similar to how -vtls works).

Vote++.  This would be useful after you've identified some code as the bottleneck, to figure out why it's so much slower than it should be.

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:i97utq$d7e$1@digitalmars.com...
> Found through Reddit, talk slides by Rob Pike, "The Expressiveness of Go": http://go.googlecode.com/hg/doc/ExpressivenessOfGo.pdf
>
> http://www.reddit.com/r/programming/comments/dr6r4/talk_by_rob_pike_the_expressiveness_of_go_pdf/
>
> This time I think I have understood most of the contents of the slides :-)
>
>
> Few interesting quotations:
>
> From Page 18:
>
> There are pointers but no pointer arithmetic
>  - pointers are important to performance, pointer arithmetic not.
>  - although it's OK to point inside a struct.
>    - important to control layout of memory, avoid allocation
> Increment/decrement (p++) are statements, not expressions.
>  - no confusion about order of evaluation
> Addresses last as long as they are needed.
>  - take the address of a local variable, the implementation
>    guarantees the memory survives while it's referenced.
> No implicit numerical conversions (float to int, etc.).
>  - C's "usual arithmetic conversions" are a minefield.
>
>
> From page 19 and 20:
>
> Constants are "ideal numbers": no size or sign, hence no L or U or UL endings.
>
> Arithmetic with constants is high precision.  Only when assigned to a variable are they rounded or truncated to fit.
>
> A typed element in the expression sets the true type of the constant.
>
>
> From page 40:
>
> Goroutines have "segmented stacks":
>   go f()
> starts f() executing concurrently on a new (small) stack.
> Stack grows and shrinks as needed.
> No programmer concern about stack size.
> No possibility for stack overflow.
> A couple of instructions of overhead on each function call, a
> huge improvement in simplicity and expressiveness.
>
>
> From page 46:
>
> The surprises you discover will be pleasant ones.
>

I just hope they get serious enough about functional programming to gain some monads to go along with their "goroutines".

On 10/15/10 16:25 CDT, Nick Sabalausky wrote:
> I just hope they get serious enough about functional programming to gain
> some monads to go along with their "goroutines".

They should call them "gonads".

Andrei

On 10/15/10 17:34 CDT, Andrei Alexandrescu wrote:
> On 10/15/10 16:25 CDT, Nick Sabalausky wrote:
>> I just hope they get serious enough about functional programming to gain
>> some monads to go along with their "goroutines".
>
> They should call them "gonads".
>
> Andrei

Wait, that was your actual joke. Sighhhh...

Andrei

Andrei Alexandrescu wrote:
> On 10/15/10 17:34 CDT, Andrei Alexandrescu wrote:
>> On 10/15/10 16:25 CDT, Nick Sabalausky wrote:
>>> I just hope they get serious enough about functional programming to gain
>>> some monads to go along with their "goroutines".
>>
>> They should call them "gonads".
>>
>> Andrei
> 
> Wait, that was your actual joke. Sighhhh...

I see we should invite JokeExplainer to the forums!

On 16/10/2010 9:34 AM, Andrei Alexandrescu wrote:
> On 10/15/10 17:34 CDT, Andrei Alexandrescu wrote:
>> On 10/15/10 16:25 CDT, Nick Sabalausky wrote:
>>> I just hope they get serious enough about functional programming to gain
>>> some monads to go along with their "goroutines".
>>
>> They should call them "gonads".
>>
>> Andrei
>
> Wait, that was your actual joke. Sighhhh...
>
> Andrei

Coincidentally, the official mailing list for Go PL
is known as go-nuts!  :-)

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:i9akvf$1jlq$3@digitalmars.com...
> On 10/15/10 17:34 CDT, Andrei Alexandrescu wrote:
>> On 10/15/10 16:25 CDT, Nick Sabalausky wrote:
>>> I just hope they get serious enough about functional programming to gain some monads to go along with their "goroutines".
>>
>> They should call them "gonads".
>>
>> Andrei
>
> Wait, that was your actual joke. Sighhhh...
>

Well it was a bit opaque. I was actually wondering if anyone would make the connection at all. :)

Not sure about their rationale, but here is a Visual C++ team blog entry about it:

http://blogs.msdn.com/b/vcblog/archive/2007/10/18/new-intrinsic-support-in-visual-studio-2008.aspx


"Walter Bright" <newshound2@digitalmars.com> wrote in message news:i9a2t3$26pm$1@digitalmars.com...
> Paulo Pinto wrote:
>> Still most modern languages are moving away from inline assembly.
>
> It's a pain to write an inline assembler and figure out how to integrate it in with the rest of the compiler. I can see why compiler writers don't want to do it, and look for reasons not to.
>
> Most modern languages do not even generate code - they target the JVM or CLI.
>
>
>> Even Microsoft has dropped inline assembly support for the 64bit version
>> of Visual C++, pointing
>> developers to MASM.
>
> I'd be curious as to their rationale.
>
>
>> People will always complain no matter what. Just use the official assembler for the target platform.
>
> Microsoft MASM has about 30 different incarnations, all accepting different syntax.
>
> It's a *constant* source of grief for customer support.
>
>
>> Personally the last time I used inline assembly I was still target
>> MS-DOS, long time ago and actually
>> it is one of the features I don't like in D.
>
> I'd be forced to write a standalone assembler if D didn't have inline assembler.
>
> In any case, inline assembler in D is a substantial productivity booster for me for anything that needs assembler. The inline assembler is also quite ignorable, if you don't like it.

Paulo Pinto wrote:
> Not sure about their rationale, but here is a Visual C++ team blog entry about it:
> 
> http://blogs.msdn.com/b/vcblog/archive/2007/10/18/new-intrinsic-support-in-visual-studio-2008.aspx

Thanks for the link. The user comments on it are less than kind about VC++ dropping inline asm.