Small poll

[Joe Armstrong]

On Wed, 17 Dec 2003, Kostis Sagonas wrote:

> Robert Virding wrote a mail quoting my mail, and he finished it as
> follows:
> 
>  > ... deleted ...
>  >
>  > Sorry for getting worked up about this but I wish people would think
>  > through their suggestions a bit more and consider the deeper
>  > implications of them.
>  > 
>  > Finally one definite reason not to outlaw a+42 is that it is one of my
>  > standard ways of generating an error in code, being much shorter to
>  > write than exit(some_bogus_exit_value).
> 
> I will try to avoid the temptation of replying directly to the first
> statement above, and instead reply to the following question of Robert.
> 
>  > 3. What is the point is the compiler transforming it to
>  >    exit({badarith,...})? What are you exactly gaining by doing it?
>  >    Not saving code anyway, and hardly runtime either. 
> 
> 
> Ah, Robert, you seem to have very limited imagination

  <<<< limited imagination -- never  - I've never heard anybody accuse
Robert of limited  imagination before -- he has  his little quirks, we
all  do, but  limited imagination  is  not among  them... deciding  to
totally rewrite the compiler one week before it's to be released and a
month after the last final-final code stop might be a more appropriate
failing :-) >>>>


>... let me help
> you here.  Consider the code:
> 
> 	-module(a42).
> 	-export([test/0]).
> 
> 	test() ->
> 	  catch f(),
> 	  ok.
> 	
> 	f() when a+42 == 0 ->
> 	  %% extremely long sequence of code here
> 	  ok_1;
> 	f() ->
> 	  Y = ackerman(), % very long computation here
> 			  % (without side-effects)
> 	  X = a+42,
> 	  mod:funct(X,Y),
> 	  %% possibly lots more other code here
> 	  ok_2.
> 
> 	ackerman() -> .... 
> 
> 
> QUESTION 1
> ----------
> Do the "semantics" of Erlang (BTW, I would really like to see them
> formally specified before people use this term again) allow a compiler
> to transform the code above to just:
> 
> 	-module(a42).
>         -export([test/0]).
> 
>         test() ->
> 	  ok.

  ABSOLUTELY NOT - the programs mean *completely* different things.

  In  your example  the  compiler writers  job  is to  make sure  that
ackerman() gets evaluated as quicky as  possible - it is NOT to change
the meaning of the program.

  Programs are ONLY correct wrt to specifications - period - end of story.

  Here is the spec (which you didn't show us :-)

  << 

  Write me  a program,  that performs a  long and  evolved computation
(say by  calling the ackerman function)  - then generate  an error and
return ok.

  This is to  be used in a regression test where  we test the speed-up
introduce by our new big-num acceleration hardware.

  >>
  
  One  good  property  that  a  programming language  should  have  is
"predictability" the  programmer should be able  to naively understand
the (space-time) consequences of their  code - break this rule and you
are in trouble.

  I *hate* compilers that make  assumptions about my code and optimize
away my so-called "mistakes".

  If the  programmer tells the system  to do something  stupid then it
should do something stupid.

  << aside -- why is this: Once  upon a time I had to program a "radar
controller" when I worked for the Eiscat scientific association. The radar
controller had lots of lamps on the front panel.

  The hardware  guys wanted me  to write an *incorrect*  program which
would cause the red error lamp on the front panel to light up.

  This  proved *impossible*  because  a "smart"  compiler refused  all
programs  which were  incorrect  and thus  I  could not  write a  test
program that light the red lamp.

  I  struggled for  weeks -  eventual  we had  to throw  away all  the
control software  and re-write it from  scratch so that  I could write
"incorrect" programs.

  Moral - the system should do *exactly* what you tell it and nothing
else >>



> 
> QUESTION 2
> ----------
> Can the savings in time and code space be made arbitrarily big, or not?

  No - the compiler/run-time system should make the code do exactly
what the programmer said the code should do - what one should optimize
are the artificial artifacts introduced by compilation - ie minimize
garbage collection times, instruction dispatching times etc.

> 
> QUESTIONS 3-N
> -------------
>  - Do the two occurrences of "a+42" need to be treated differently
>    by the compiler in the above example, or not?

     No 

>  - Is "a+42" an expression that always generates an error in Erlang?
> 	(as far as the user is concerned)

     Yes

>  - Is it just me that finds this Erlang-ism confusing to say
>    the least?  (I.e., is this a user-friendly language design?)

     I don't find this strange at all - I guess it's just you :-)

  /Joe



> 
> 
> Kostis.
> 
> PS. I am very well aware that the subject has shifted from
>     warnings vs. errors to something else now, but I could
>     not resist.  Apologies.
>