Thu Dec 11 07:11:23 CET 2003
Lon, you saved me a lot of typing. I agree with all of what you wrote.
On Thu, 11 Dec 2003 04:39:00 +0100, 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
>> 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
> 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 -
>> 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.
More information about the erlang-questions