See this:
var x = 1;
val y = x;
++x;
println$ x,y;
//////////
~/felix>flx --test=build/release xy
(2, 1)
///////////
Do you know what it "works"? Because the compiler already
takes into account the fact that moving an evaluation past a modification
to a variable it depends on could lead to an unexpected value.
The compiler is already doing what you want in this case.
Normally it would lazily evaluate y. Note, this is implementation
dependent: the compiler isn't required to do that at the moment
with the "specified" semantics.
The problem I originally pointed out is that the analysis does
not work when closures are involved.
The analysis only applies to straight line code.
The analyser makes the "conservative" assumption if a label
is hit, and does eager evaluation and doesn't look any further:
a performance hit, in favour of the expected behaviour.
So: I'm well aware of the issue. I don't know how to solve it.**
But it isn't a bug, because lazy evaluation is allowed for vals.
It may be that there's a better break down of "variable kinds"
than var/val (and perhaps fun). That's what I was looking at
with "const". It may be the names "var" and "val" are not the best,
or that the default shouldn't be "val", but that's not a semantic
issue but a psychology one (the default is chosen because
performance in the usual case is better).
** The reason this is very hard is that inlining *by definition
of the word inlining" means substitution. You replace a call
with the body of the function being called. You replace
a parameter with its argument.
Rather than force parameters to become variable which are
initialised, I define the semantics to allow the substitution
of val parameters by arguments. Without this, a heap of
optimisations are lost. The cost is code bloat, which is why
the inliner counts uses and does eager evaluation if there
are enough.
In a functional programming language, lazy evaluation is
generally better semantically. Haskell uses that. It then
uses "strictness" analysis to prove when it is safe to use
eager evaluation. A function is "strict" if it terminates
normally (for all arguments). Strict functions return the same
value no matter whether lazily or eagerly evaluated.
The problems start to occur when you try to work around
the failure of Haskell to do a good enough analysis
to support the performance imperative languages get out
of data structures like arrays (which are ridiculously slow
in Haskell because they're immutable and have to be copied
on every modification).
One way to fix this is to mix functional and imperative
languages. The problem is no one knows how to do it.
NO mixed languages have reasonable semantics ..
and that includes ALL imperative (and thus OO) languages
(because all imperative languages have a functional subset).
The idea in ML/Ocaml/Felix and Scheme is that you encourage
people to write functional code, and use imperative features only
when necessary for performance, and then you try to have
some way to predict behaviour to some extent, and t he programmer
has to try to avoid those cases where the unspecified behaviour
makes a difference.
For example in Ocaml:
let cnt = ref 0
let next () = incr cnt; cnt
let g x = next(); x ^ string_of_int (!cnt)
let f a b = a ^ b
print_endline (f (g "a" )(g "b") )
WOOPS! Do you know whether it prints a1b2 or a2b1?
I do. It prints a2b1 because Ocaml evaluates arguments right
to left. But that's an implementation detail. Its formally unspecified.
So don't do it. Control the order yourself:
let a1 = g "a" in
let b2 = g "b" in
print_endline (f a1 b2)
Why does Ocaml do this? For performance.
It's related to currying and tail recursion, but left to write argument
order evaluation is not considered tenable.
--
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
