Language change proposal

[Richard A. O'Keefe]

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?)
	
False dichotomy.

	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
	between
	
	  -requires_erlang('5.3').
	
	and
	
	  -assert(?ERLANG_VERSION, '5.3').
	
	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

-erlang(Encoding, Version).

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.