On Sun, Aug 19, 2012 at 12:37 AM, john skaller <
skal...@users.sourceforge.net> wrote:
> Dobes solution to (one of the) problems with closure capture might work.
>
> Given this:
>
> var x = 1;
> val y = x + 1;
> ++x;
> println$ y;
>
> the problem is y (by specificaton) could be either 1 or 2, depending on
> whether y
> is eagerly evaluated (treated like a variable) or lazily evaluated
> (replace by initialiser).
>
> In a simple case like this the problem goes away if you do this:
>
> var x = 1;
> var x' = x;
> val y = x' + 1;
> ++x;
> println$ y;
>
> The "one use" variable x' captures the value of x at the point of the
> definition
> of y, so the value will be the same whether eagerly or lazily evaluated.
> We use a var for x' not a val, to ensure the sloppy semantics are firmed up
> rather than propagated.
>
> The obvious problem with this "solution" is that extra variables get
> created
> even when not required. If x is never modified there's no point capturing
> its current value in x'.
>
> This problem can be "fixed" by another transformation: if a variable is
> never
> modified, it might as well be a val. We count assignments of taking the
> address as modifications.
>
There's a kind of program transformation called "static single assignment"
(SSA) that views each assignment to a local variable (var) as a new name.
Writing a value to a memory slot (on the stack or the heap) is a separate
step from assigning a value to a "variable".
http://en.wikipedia.org/wiki/Static_single_assignment_form
Using this representation can make it very easy to implement vars and vals
and separate their storage to (maybe aliased) memory from their computation
and use.
For closures I think there has to be memory reads and writes going on, but
you would have to ensure that the memory location was created before it was
bound into the closure. So this can help with the "used before
initialized" problem as well because you will see that the memory location
being bound into a closure was created (assigned) after the closure itself
was being created.
The other nice thing about SSA form is that it kind of translates an
imperative program into a functional one, where the monad "memory" can be
programmatically added to the function/procedure calls that need it. Since
Felix can do whole-program optimization (unlike C++, Java, et al that
support dynamic linking and loading) it can correctly scope that monad down
so that, for example, only the types actually written by a procedure will
be prevented from "moving past" a call to that procedure. It can also use
inlining to allow better mobility for expression evaluation. That is to
say, you can use a different monad for every type and for I/O.
For calls out to C code you might have to block all "movement past" these c
bindings but eventually you could let the programmer to try to specify what
types of memory slots might be affected by such a call and thus re-mobilize
the evaluation of things.
Basically you could define "var" and its uses as the transformation:
var foo = 123; // val foo@1 = 123; val foo@mem = new foo@1;
val bar = foo + 1; // lazy eval
println $ foo; // println $ foo@1 ; val foo@2 = *foo@mem;
foo = 7; // val foo@3 = 7; *foo@mem = foo@3;
println $ foo; // println $ foo@2
println $ bar; // println $ foo@1
Technically this isn't true if the var's initialiser (the sole assignment)
> itself
> contains variables. If we convert to val, we forfeit the required eager
> evaluation.
> Except .. we just fixed that problem, so we might be able to "recurse" a
> solution.
>
With SSA, a var can be split into a series of vals and a "write to memory
slot" or "read from memory slot" operation.
The memory related operations have to be serialized which forces the var to
be calculated eagerly so its value is then written to "memory" exactly at
the moment of assignment (although escape analysis can allow one to
eliminate some memory reads/writes and keep things in "val" format).
"Reading from memory" is done when you access a var that may have been
written to via a pointer. In this model all calculations (whether put in a
val or var) may be deferred if analysis shows that it is safe to do so.
It's probably worth remembering that the C++ compiler will already be doing
all this work already, so maybe it's not worth the trouble in the Felix
compiler. Just dump as many useless variables as you like and let MSVC/GCC
eliminate them!
It's also unclear if the "solution" is correct. As mentioned before,
> a "val" is basically a pointer. You have to write
>
> &x
>
> to gets it real value (the pointer), if you write plain
>
> x
>
> it is effectively the automagical deref of the pointer.
>
It isn't possible to decide if the solution is correct until you've defined
what would be correct.
My definition is that a val must always evaluate to the same value,
regardless of where it is used. It is not a function.
> In this interpretation, you may well expect the current value
> stored, rather than the one at the time of definition,
> you'd be certain to expect that if you used an actual pointer
> (the deref is lazy .. its not done until you actually write the *).
>
Well ... in that case you're still in an operational model where a "val" is
using the state of the machine at the time the compiler deems appropriate.
The problem here is that this operational model is going to cause bugs in
people's programs due the surprise factor. It's a booby trap. If people
want to just "let the compiler decide" it should be an opt-in process
rather than opt-out.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
