On 05/03/2014, at 11:48 AM, srean wrote:

> The issue here has nothing to do with the "kind" of closure.
> 
> It has to do with the scope over which the closure closes.
> 
> 
> That is indeed a goodway to put it. The Felix compiler may choose to close 
> over a scope that you did not have in mind, so ou are better of specifying it 
> carefully if your algorithm depends on it.

It doesn't "choose" a scope in this case, the scope of a loop is function scope.
It's a flat scope, the whole function is a single C++ object, the variables
are non-static member variables.

That's if the function is a closure, i.e. not inlined. When you inline
a function its variables become variables of the calling function.
Again, a flat scope. On the heap. An object. Felix doesn't use
automatic (stack) variables (except occasionally, transiently,
for temporaries it generates).

Even if you write a block:

        var x = 1
        begin var x = 2; .. blah x; end
        { var x = 2; blah x; };

so that the x's are different, the block will be inlined.
The inlining of anonymous blocks like this is forced.
The inlining just renames the inner x variables
and makes the variables of the parent. So dynamically,
its still a flat scope. Unless you do this:

        var closure = { .... };
        ,,,
        closure ();

which forces the block to become a separate C++ object on
the heap.

I have simplified a bit, but that's gist of it. The reason blocks
are force inlined is because of this kind of thing:

        if x do { ... return; }; done

The return returns from the block, not the containing function.
This is fine. The problem is that Felix compiler generates
"blocks" itself, and then a user "return" or "break" would not
work as expected, so the block it generates is force inlined
to get rid of the scope. (Rough approximation of reality, ok?)

This is also the reason for

        break label; // plain break is NOT allowed in Felix
        return from proc-name; // returns from specified procedure

so there's no doubt where you're returning from or going to.

in Felix, its hard to know if a function/procedure has a separate scope
or not .. and where it is. Felix can

        (a) inline it
        (b) use the machine stack for the scope as a C++ object
        (c) use the machine stack for the scope as a C function
        (d) use the heap

and the compiler choses whichever is most efficient and possible
without "breaking" the semantics. For example if you return a pointer
to a local variable that forces the heap model to be used.


> If you popularize the existence of noinline and the fact that it can change 
> the meaning of your program, it will probably be ok. But for sure it can 
> catch you by surprise.

Sure it can, and I don't really want to popularise it because, you and I both
agree, its really not very satisfactory.

However, you can program Felix, I claim, effectively. It has gotchas as do
most other systems. And as I do keep saying you can't learn what they
are or how often they occur, or what to look out for, without writing code.
Particularly as the semantics are not quite hard and fast, Felix being
experimental with few users. This situation will not change without
users.

Its the same for any language. Rust, for example, discovered their
type system was unsound. And they have a really ugly "mut" hack
for mutable data.

It actually took me a while to understand that in Rust when they say

        x = y

has MOVE semantics .. NOT copy semantics .. they were not in fact
changing anything from C, it has move semantics in C too!

Surprised? I was. But then they explained, it does a shallow copy.
Which C does too. And Felix (for Felix types). So if you think of
a string class:

        struct string { int length; char *data; };

you understand that copying one of these animals has move semantics.
Rust tries to enforce this (you're not allowed to refer to the RHS after
an assignment from memory).



--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org




------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to