Small poll

[Pascal Brisset]

 >  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 wanted to answer "3, of course" until I realized the
follow-up poll questions might be embarrassing.


- Suppose we reject a+42.  Then what about:
        test(A) -> a<42.
  This is exactly the same typo.  Can we also detect it and still
  allow < between arbitrary terms (e.g. keys in data structures) ?
 
  The ML way would be to declare < with the type:
        '<'(T,T) -> bool().
  and allow the programmer to explicitly widen the type of
  operands to term() when needed.  But this does not make sense
  without a clear notion of type inference (i.e. what is the type
  of 'a' ?  atom() ?  The atom 'a' ?  a|42 ?).


- More generally, the verification will not be complete.
  How do we explain the rationale when a programmer complains
  "Hey, the compiler caught this mistake, but not that one" ?


- Should the compiler also reject:
        test(A) ->
            if a+42 == 0  -> true;
               a+42 =/= 0 -> false;
               true       -> fish
            end.
   In other words, do people occasionally rely on the fact that
   exceptions are silently ignored in guards, possibly in more
   elaborate ways than above ?


All things considered, obviously even a local, partial
typechecker would be welcome.

And since Christmas is approaching, #1 on my wishlist would be
a tool which unifies in a consistent way:
- a syntax for function and data type declarations
- erldoc
- typechecking
- uniqatom
- xref
- user-definable, typed behaviours, as in:
      %% File: gen_server.bhv
      +defbehaviour gen_server(InitArg, State, Request, Result).
      +type handle_call(Request, {pid(),term()}, State) ->
            {reply, Result, State}
          | {reply, Result, State, timeout_val()}
          | {noreply, State}
          | {noreply, State, timeout_val()}
          | {stop, Reason, Result, State}
          | {stop, Reason, State}.
- warnings related to the emulation of destructive updates with
  single assignment, as in:
        handle_call({set,NewValue}, From, State) ->
            State1 = State#state{val=NewValue},
            State2 = State1#state{timestamp=now()},
            {reply, ok, State1}.   % Catch this.

-- Pascal