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.
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.
All we need with that is to ensure vals get lazily evaluated if they're
only used once. That gets rid of one use vals, and one use vars
which capture the state of another var that is never modified (but
may be used multiple times).
Felix already does something like this anyhow: it works hard to eliminate
vals by substitution (to save on local storage which costs a lot when
recursing).
It's not immediately clear this will carry through properly. The details
of what uses what are hard to discover due to nested functions,
pointers, etc etc.
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.
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 *).
This particular problem pervades ALL algol like languages including C,
C++ and others. The concept of a "variable" is in fact a bogus idea perverted
from mathematics (which is generally functional). In C this is manifest in
the concept of "lvalue" and in C++ as well (although some say "reference").
Ml/Ocaml doesn't have this problem, being an ISWIM language. A symbol
only has one meaning: pointers are pointers, its not context dependent.
you have to get and set storage explicitly. This delegates the question
to knowing the order of execution. (It's the same problem but it manifests
in a different way).
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
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
