Erlang language issues

[Chris Pressey]

On Wed, 17 Apr 2002 11:56:44 +0200 (MET DST)
Richard Carlsson <richardc@REDACTED> wrote:

> On Wed, 17 Apr 2002, Vlad Dumitrescu wrote:
> 
> > Would a "block comment" concept be wrong for Erlang? Difficult to
> > implement?
> 
> Not difficult to implement; just a question of deciding on the
> delimiters. Joe Armstrong also proposed this, mainly to make it easier
> to write edoc documentation, and it has been agreed that block comments
> should be added to the language, probably for the next release. (Should
> have told you this before, Vlad - sorry.)
> 
> After some initial attempts at inventing new delimiters, all of which
> had subtle problems, we came to the conclusion that the normal C comment
> delimiters /* ... */ were probably the best choice.
> 
> Flames, anybody?

Yes.  I object to the characterization of any part of C as 'normal'.

:-)

The only pressing reason to have block comments that I can see is to
interleave Erlang code with some other language code, like Javascript and
HTML.  Personally I find that approach, with any two languages, very ugly
- polyglots are interesting curiousities, but relying on them during real
work is headache-y.

I know next to nothing about XML, but - isn't it supposed to provide
alternatives for this sort of thing?  By supplying a 'structured document'
approach?  Parts of a document can be in Erlang, parts can be in HTML,
parts can be Javascript, parts can be English commentary, and parts can be
diagrams and theme music and whatever else.  The Erlang part can be
automatically extracted just before compilation - it's not as if the
compiler should care what's in comments.  But I know nothing about XML, so
maybe I'm on the wrong track with that idea.

Erlang is in theory self-documenting - but choosing appropriate function
and variable names is a lot harder than it sounds.  Many functions should
probably be nested, but aren't, resulting in some very strange names,
suffixed with _tail or 0.  And single-letter variable names are a hard
habit to break, when called for - sometimes they are OK, in utility
functions where there is not much that can be assumed about the values. 
Other times they are disastrous, although, probably worse in a
non-single-assignment language like C.

Chris