Small poll

[Kostis Sagonas]

I've sent the following at about 3:00 last night, but have not seen
it in the list yet.  I am re-sending it again; apologies if you get
it twice.

Kostis.

---------------------------------------------------------------------

Glad to receive so many responses.  Let me reply on a few of them.


 > On Wed, 10 Dec 2003, Vlad Dumitrescu wrote:
 > 
 > > > test(A) ->
 > > >     a + 42.
 > >
 > > For the "A vs a" problem, there is already a warning being issued. Possibly
 > > the full warnings options should be enabled by default?

First of all, let's disconnect this thread from "unused_variables"
(although the warning **SHOULD** be turned on by default).  Let's
say that the program was:

 test(A) ->
         bar(A),
           a + 42.

 > > Since both a and 42 are constants, I feel it would be easy (besides useful)
 > > to be able to detect it at compile time. The operation should even be
 > > evaluated at compile time, IMHO.
 > 
 > Exactly. And if compile time evaluation fails, give compile time error
 > {badarith,....}.

Regardless of whether this is evaluated at compile time or not, there
are still three options as I wrote in my previous mail:

 1. the compiler happily compiles this program, but simply replaces
       a + 42 with a call to spit {badarith,....}
 2. generate a warning, but also byte code.
 3. the compiler refuses to compile such erroneous code.

I will try to make a case for 3 below.

Option 1, seems strange to me: The compiler has found out that a particular
evaluation will result in an error, but does not inform its user about it
and moreover generates more code (in terms of space) than that needed for
the expression "a + 42" (if the expression is statically evaluated to
badarith) or refuses to do work at compile time, leaving this work for
run-time (which is what the BEAM compiler currently does).

Option 2 on the surface seems a reasonable choice, but is it really ?
I claim that at least 90% of all such cases are programming errors.
As Taavi mentioned, if the programmer _really_ wants to generate an
error, there is throw() and the a + 42 can be its argument (either
as a string or as a tuple).  Seems much, much cleaner to me.

Now let me tell you why I am interested in 3:

  In the context of generating native code, it is really a nuisance
  to have to handle all sorts of illegal combinations of arguments
  to "basic" primitives like "+".  Moreover, in the case of HiPE,
  because the compiler is (much) more sophisticated than the BEAM
  one, it actually discovers quite a lot more cases of such errors.
  Currently, we try our best to "immitate" the behaviour of the BEAM
  compiler, but in sleepless nights like this one, I keep wondering
  whether there should really be a limit to the level of naivety
  one pretends to show, or shouldn't there be?

  (Just in case it is not obvious, this is a more general issue,
   not just related to the simple "a+42" case I chose to illustrate
   my point.)

Cheers,
Kostis.

PS. I am curious whether Eric Newhuis could elaborate on:

       > But we presently rely on this behavior and do not
       > treat it as a warning.

    Exactly how do you "rely" on this?