On Sun, Aug 19, 2012 at 11:55 PM, john skaller <
skal...@users.sourceforge.net> wrote:
>
> On 20/08/2012, at 4:30 PM, Dobes Vandermeer wrote:
> >
> > 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.
>
> Indeed. Felix does that. I previously described it, in terms
> of unravelling and re-ravelling.
>
> Control analysis is simpler, but with closures it can still
> be very tricky!
>
> Data flow analysis of any kind is very hard.
>
Closures have to use reads/writes from memory rather than using assignments
directly, unless they are inlined.
Data flow analysis kind of hits its limit when you have to take user input
into consideration. If we didn't have to consider user input then we'd be
able to optimize the program down to a bunch of print statements.
> You're getting confused about evaluation. C does eager evaluation
> of arguments. Haskell does lazy.
>
> Felix does either lazy, eager, or unspecified. The default is unspecified.
>
I don't feel confused about it. I'm very clear that "unspecified"
shouldn't be the default!
Most often lazy evaluation is not allowed to interact with "variables", so
it can't really do any damage. There's no way for the result of the
computation to change, and it's often impossible (without adding print
statements) to even detect that lazy evaluation was done.
SSA form you're thinking of you're assuming assignments are eager
> and considering re-orderings that don't change "semantics".
>
Assignments to vars (memory writes) are eager as you've said before. Vals
are not eager (they aren't memory writes) so they can be moved a bit
further. The question is how far can they be safely moved? In the case of
SSA form, the answer is: as far as you want! Only the parts of the
expression that read memory are blocked from being moved past a write.
I think the semantics of a val SHOULD be that it uses the state of
variables as they were at the time the val was initialized; you don't seem
to think this is necessary. Instead you're saying that the semantics are
okay as being "the calculation is performed using the state of variables as
selected by the compiler." This basically means that to get predictable
results you shouldn't use vars or call functions or you'll get behavior
that varies based on the decisions made by the optimizer.
The output of a program with respect to its input is the semantics of that
program. So if operations are reordered in a way that changes the output
of the program with respect to its input, it has modified the semantics of
that program.
It may be that this problem doesn't yet rear its head very often because
the compiler tends to make the same decision for the programs you have
built so far. In cases where you made a val depend on a var you could kind
of see how things turned out and imagine that it will continue to turn out
that way forever. I don't think this is sensible. At some point, the
optimizer will change its mind and my software will break "mysteriously."
So, either a val should never depend on a var, or it should be well-defined
in terms of whether it is eager or lazy in its semantics (i.e. if it is
deferred, it should give the same result as if it were not.)
> The default is to leave it up to the compiler. That means YOU are
> responsible for recognising when the default isn't what you want.
>
I think this is giving too much credit to me ... I'd rather have safe
defaults with faster alternatives I can "try out" later on "hot" pieces of
code that have turned into a bottleneck.
I don't mind the compiler deciding whether the operation is eager or lazy,
I just want to get the same result every time.
> You'd rather the default be determinate. It isn't for good reason:
> it rarely makes any difference unless you're writing very high level
> code, in which case you're smart enough to know you have to change
> the strategy.
>
I'm afraid that when it does cause a bug I'll be bashing my head against
the wall for a week trying to figure it out. Or worse, it'll be some
person I brought on to help who understands Felix and all this fancy stuff
about maybe-lazy evaluation less than I do. And he'll be like "why didn't
you pick a NORMAL language like Python or C++ or Lua??? I hate you!!!"
With something like "val foo = a/b" it seems that the value is evaluated on
the spot... especially if you've used Scala a bit or read a tutorial that
said "a val is a read-only constant". A syntax like "lazy_or_eager val
foo = 123" encourages one to investigate "what's that lazy_or_eager
thing all about?". or "pure total fun foo => a+b" is also something with a
good warning sign on it that you should know what those adjectives mean.
I got caught myself, several times. RF got caught. Mike Maui got
> caught. So far you (Dobes) know about it but haven't been,
> which makes you smarter than the rest of us :)
>
So you already know it's a booby trap, from experience. Why not fix it for
future programmers?
------------------------------------------------------------------------------
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
