[erlang-questions] some language changes

Mats Cronqvist mats.cronqvist@REDACTED
Wed May 30 15:51:33 CEST 2007


Joe Armstrong wrote:
> Now the book is done I've been thinking about some language changes.
> 
> Here's my list (no particular priority)

   i don't really have any major complaints as far as programming goes. however, 
i spend a lot of time reading other peoples code, and Erlang has some features 
that seems custom made to generate illegible code.
   so i think that if anything, the language should be simplified instead of 
added to, and in particular features that generate verbose and cryptic code 
should be removed or obsoleted. in particular these two;

* get rid of the preprocessor
   IMO, the preprocessor is THE worst feature of erlang. it's ugly, stupid, 
broken and makes it impossible to create programs that deal with source code 
(such as syntax hiliters and refactoring tools). problem is of course that shit 
like the below cannot be parsed until it is preprocessed.

-define(BLA, grump)).
go() -> (?BLA.

   i propose to throw away the existing preprocessor. instead, the source file 
is parsed (by epp_dodger or something derived from it), include files are parsed 
and included and macros substituted. conditional compilation should (i think) be 
disallowed (rarely used and utterly horrible). the resulting parse tree is 
passed to the compiler. this would be largely backward compatible; 99% of all 
macros would work fine (since almost all macros are parseable).
   in this scheme, it would be pretty easy to add a lispy hygienic macro 
facility, which in turn could perhaps replace parse transforms (another 
questionable feature).

* obsolete the type guards
   from rpc.erl:

multicall(Nodes, M, F, A, Timeout)
   when list(Nodes), atom(M), atom(F), list(A), integer(Timeout), Timeout >= 0 ->

   i think it's clear that this is more readable:

multicall(Nodes::list, M::atom, F::atom, A::list, Timeout::int)
   when  Timeout >= 0 ->

   there are of course other candidates for removal (e.g. 'if', 'and', 'or' and 
'catch' (outside of 'try')) but that would mean (seriously) breaking backwards 
compatibility.

     mats



More information about the erlang-questions mailing list