Language change proposal
Richard A. O'Keefe
Wed Oct 29 23:35:46 CET 2003
Chris Pressey persists:
Ah, but the rivers of the Erlang support list are choked with
the bodies of keyboard-pounding language designers, are they
not? Guardians of Truth and Beauty, each and every one of us,
who do not seem to realize that Erlang is not a project in
pursuit of perfect language purity. It is, in fact, an exercise
in return-on-investment (right, Mr. Ericsson?)
And defining a new predefined macro is just about as small an
investment there is.
Predefined macros aren't *investments*, they are *penalties*.
Take it one small step further and add -assert() to -ifdef() and
friends, and I for one have a hard time explaining the difference
in terms that the average non-language-designing Erlang
programmer would appreciate or care about.
It is incredibly simple. -assert (which does not and should not exist;
we should be looking for ways to excise the preprocessor cancer, not
pumping it full of growth hormones) can appear too late. You *CAN'T*
check Erlang version using a feature whose very removal is one of the
things you want to protect against.
Oddly enough, when it comes to reading an Erlang source file, an Erlang
processor has the same two problems that an XML processor has when reading
an XML document.
(1) What character set encoding was used?
One of the long term goals for Erlang is that it should support Unicode;
many existing Erlang users already combine Erlang and XML (hence xmerl,
amongst others), and XML requires Unicoode. If you are going to process
XML in Erlang, it is helpful if you can represent XML identifiers as
Erlang atoms, and at a minimum you need to be able to hold Unicode
characters in strings.
I'd be happy with ISO Latin 1 as the default encoding, but I suppose
Windows programmers wouldn't be, and in today's Europe, it could be
useful to be able to mention the Euro, so 8859-15 might be a good
choice; need I go on?
(2) Which version of the language specification is to be used?
There is no reason to expect that every future version of Erlang
will _have_ a preprocessor. The "erlang declaration" still needs
to be usable, so it _can't_ use a preprocessor kluge.
We come up with the fairly obvious result that something like
is needed, where "-erlang(" must literally be the first 8 characters of
the source file, the Encoding written as an unquoted Erlang atom follows
with no spaces, and then the language version. This also has the nice
effect of making it easy to tell the UNIX 'file' command how to
recognise Erlang source files.
By the way, whatever you call "assert", it's not a macro.
If Chris Pressey _doesn't_ want to see the same kind of preprocessor
mess that makes maintaining other people's C code a challenge, he should
not have wasted our time suggesting it.
More information about the erlang-questions