[erlang-questions] some language changes

Matthew O'Gorman mogorman@REDACTED
Wed May 30 15:55:21 CEST 2007


adding support for Var::type  I think would be a great benefit to the
language, I also wish one could do simple or in the argument list like
call(2||3, Var) as apposed to call(X, Var) when X==2; X==3 ->

mog

On 5/30/07, Mats Cronqvist <mats.cronqvist@REDACTED> wrote:
> 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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



More information about the erlang-questions mailing list