On 24/04/2012, at 3:53 AM, Raoul Duke wrote:
> is it worth having the compiler spit out warnings / reports about what
> optimizations like elisions happened?
Not sure. The problem here is that Felix itself generates variables
freely, expecting elision. Same with labels that turn out not to be
used.
For example an expression
val x = f ( g y );
is "unravelled" to
val tmp = g y;
val x = f tmp;
then "re-ravelled" to
val tmp = g y;
val x = f ( g y);
then tmp is elided to get back where we started. If YOU write:
val tmp = g y;
val x = f tmp;
you end up with
val x = f (g y);
too. Saves on one variable. Similar things happen with functions/inlining,
in fact "re-ravelling" is in fact inlining. It's also called "lazy evaluation".
It doesn't make sense to warn about elision of compiler generated
variables or functions, and its not that easy to distinguish the ones
we should warn about (yes, the compiler knows which ones the user
wrote). What about variables in child functions that are inlined?
What about parameters that are replaced by arguments?
What about dead code that is eliminated? (I mean, variables
in dead code)?
Actually, there *is* a diagnostic (commented out).
Felix produces some very high quality diagnostics .. and some
very bad ones (that give no idea of the problem or where it is),
and in some cases nothing.
Ideally, it would be like Clang, which has superb diagnostics,
and a switch to turn each one on and off. Ideally Felix would support
a whole host of such things too, with switches and configuation
data to control the diagnostics (and, translations to other human
languages).
It probably makes sense to warn about elision when the RHS is
a generator. In this case, however, its a C function pointer.
To be proper, the TYPE of functions and generators should be distinct.
Then elision warnings could be produced if side-effects were being lost.
It's still hard though for reasons like above (what about side effects
inside a function where the whole function is elided simply because
it is never called?)
What about error functions, which are elided, eliminating the program
terminating side effect, if the compiler proves the function can't
be called? Felix generates "match failures" at the end of every match,
unless the match manifestly ends in a wildcard. But after some calculations
it might prove all cases are handled, and elide the match failure warning.
The bottom line is this: handling errors well in a compiler is harder
than generating highly optimised correct code. It's a lot more work,
and a lot more code.
you can see this running various C/C++ compilers that give different
warnings .. and I'm sure each one produces some warning that annoys
you a lot.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
