[erlang-questions] My biggest beef with Erlang

[Joe Armstrong]

On Nov 26, 2007 12:08 PM, Robert Raschke <rrerlang@REDACTED> wrote:
> > No this has nothing to do with regexps
> >
> > -compile({character_transform, Mod}).
> >
> > would (by analogy with parse_transform)
> > call Mod:character_transform(Bin, Opts) when Bin was the content of
> > the file being compiled
> > it would return Bin'
> >
> > Then you could do anything you like.
> >
> > -compile({tokenezer, Mod}).
> >
> > could maybe call a custom tokeniser after character processing and
> > prior  to calling any
> > parse transforms.
> >
> > /Joe
> >
>
> Hmm, strange convergence of ideas in different mailing lists at the
> moment (the Lua community is discussing stuff like this as well).

  Great minds think alike :-)

>
> All of these ideas appear "neat".  Because you can start inventing your
> own syntax for stuff.  'Tis what computer types love, after all

Absolutely, that's how Erlang started - tinkering around with Prolog :-)

> (although, using the right indentation with the correct editor might
> even come before that :-).
>
> But, unless you are designing a domain specific language, you end up
> with programs that nobody else can understand.  Even worse, almost
> everything (file extension, run-time system, standard documentation)
> makes it appear that you are dealing with Erlang.  But when you look
> inside, it is _not_ Erlang, but someones idea of a "better" Erlang.

I think of these as language extensions rather than a completely new language.


>
> Allowing the dynamic change of programming language syntax was a cool
> thing in the 70's.  It didn't work then, and I seriously doubt it will
> today.
>
> If there are real merits to new operators and syntax, then these must
> be discussed with the keepers of the language.  If the new features
> appear worthy, then they might get added.  If they do not get added,
> and you still think that you must have them, then create yourself a
> new language.  This may be extremely heavily based on Erlang, but it
> is not Erlang!  And it mustn't be called Erlang either.

Absolutely - I think the path to approval of a new feature is

1) implement as a parse transform
2) circulate to people who are interested
3) write an eep
4) discuss the eep
5) adopt into language or reject

The reason I suggested and improvements to parse transforms is because
parse transforms
can only transform valid Erlang forms - which severely limits their usefulness.

Now one of the criteria for acceptance 5) in the above is that the
ideas are not just vaporware
and has actually been tried out by a number of people who can express
some sensible opinion
as to whether or not the new feature is useful.

Thus we have a chicken and egg situation - the main implementors do
not want to add
untested features (for very good reasons of stability) and only do so
after a feature is
well tested - but users cannot test something until it is implemented.

Parse transforms offer a light-weight  mechanism for testing new
language features
without breaking everything else, thus avoiding the chicken and egg situation.

They should - like any program - be well written and documented. I
have read totally incomprehensible Erlang programs using no parse
transforms - the use of parse transformation neither improves nor
degrades the understandability of the program - this entirely depends
upon how the program is written.

/Joe


>
> Sorry for the rant, but this stuff is right up there with "coding
> standards" in my book.
>
> Robby
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>