On 03/03/2014, at 12:45 PM, srean wrote:
>
> For instance closures behave like lexical closures sometimes. The problem is
> that _sometimes_
No they behave like lexical closures all the time because that's what they are.
When you use a var, it is supposed to force immediate evaluation.
Whether it is inline:
var x = 1;
var y = x ;
++x;
// y is 1
or in a function:
fun f (var x:int) => x;
var a = 1;
var y = f a;
++a;
// y is 1
if you use a closure:
fun f(x:int) () => x;
var a = 1;
var g = f a;
++a;
var y = g ();
// y is 1
the evaluation is immediate even if you use a val or no binder:
at the moment closures are C++ classes with ordinary C++ non-static
member functions so they use the same evaluation strategy as C++.
That may change in the future, but not for an explicit var parameter.
If the behaviour is different, its a bug.
If you find a bug, post an example case please.
There may well be bugs, not only in the actual code
but also in the intended semantics.
The problems usually occur when you use a variable in the
body of a closure. That's a reference to the value stored in the
variable at the point in time it is elaborated (executed). This is
true in all programming languages I know of (which actually
support closures).
When you use a val, including in a function and including
when you use one by default, it may or may not be replaced
by its initialiser. Typically it will be replaced if it is used once
and maybe twice but if it's three times it will act like a var
and use eager evaluation.
When a function with a var parameter is inlined,
the body of the inlined code starts off with an assignment
of the argument to the parameter.
So vars give you eager evaluation .. but clearly only as eager
as the initialising assignment. If that assignment is delayed,
the value stored in the var will be whatever would be calculated
by the initialiser at the time of the assignment.
A var is the same as an lvalue in C, reference in C++,
or pointer dereference.
if you are not happy with using vars exclusively, including
explicitly in functions and procedure parameters, you need to find
another language. The default is deliberately chosen to favour
performance.
>
> So "Post valid Felix program snippet that compiles but does not
> have the expected semantics."
>
> is pretty useless advice.
I cannot help unless you have a specific problem.
--
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
