Small poll

[Lon Willett]

On ons, 2003-12-10 at 18:25, Kostis Sagonas wrote:
> I was wondering whether the Erlang user community would care
> to comment on the following:
> 
> In a function like:
> 
> 	test(A) ->
> 	    a + 42.
> 
> which is either crap (arguably) or a typo (A vs a), how many
> Erlang users:
> 
>  1. Are content with the current situation where the compiler
> 	happily compiles this program
>  2. Would like to see a warning, but a .beam file generated
> 	nevetheless
>  3. Would prefer if the compiler in R10 refused to compile it

I liked the "perlang" suggestion ;-).

Seriously, my preference (in order) would be: #2, #3, #1.  Or maybe #3
by default, but a compiler option to use #2.

I see three uses for writing such code:

1. As a programmer, one wants to know what exceptions will be generated
by certain error conditions, and/or how your program will react to
them.  So one writes a little code that artificially generates such
errors.  Such code is never released to the world.

2. As a tester, one may want to do much the same thing.  I'm not really
sure that this case is really distinct from the first one, but in my
mind it is a different part of the process.  Also, testers tend to be
rather less well versed in the subtleties of compiler behaviour, and
thus less capable of doing tricky things to "fool" the compiler.

3. One wants to generate a particular error in precisely the "standard"
format, regardless of how the internals of the erlang system may change
in future releases.

I believe that case #3 is so rare that it is unimportant (or perhaps it
is even non-existent).  But while they are not something that I would
raise a fuss about, I'm not sure that the first two cases should be
ignored.

Just the other day, I was doing weird things to see what kind of NaNs
libm/pentium produce at runtime.  I think I fooled gcc into actually
performing the nasty operations at run time instead of compile time (and
maybe it generates the same result even when it optimises the operations
away), but I may have made a mistake.  It's nicer when one doesn't have
to play games with the compiler.

(BTW, the semantics of floating point in erlang seem to be rather messed
up.  Is their any intention to clean it up some time?  I usually just
try to pretend that erlang doesn't have floats).

On ons, 2003-12-10 at 22:44, Taavi Talvik wrote:
> Still disagree. Erlang specification does not disallow optimizing
> compilers, which try to evaluate constant expressions compile time.
> 
> Language allready has special construct for throwing exceptions -
> throw(...).
> 
> Why not force explicit usage of throw() instead of obscure evaluation
> side effects?

I agree that an explicit exit() is almost always better.  But isn't
exit() what you want, not throw()?  If so, this demonstrates the point
that people aren't really so aware of the correct way to simulate
errors.  So it might be better (occasionally) if they can just write
straightforward code to generate a desired error condition.

/Lon