Small poll

[Ulf Wiger]

Lon, you saved me a lot of typing. I agree with all of what you wrote.

/Uffe

On Thu, 11 Dec 2003 04:39:00 +0100, Lon Willett 
<p0rj2el602@REDACTED> wrote:

> 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
>



-- 
Ulf Wiger