[erlang-questions] some language changes
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.
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
* obsolete the type guards
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
More information about the erlang-questions