Three wishes

[Richard A. O'Keefe]

Roger Price <rprice@REDACTED> wrote:
	Erlang allows variable name scope extrusion from if, case or receive
	primitives, "Concurrent programming in Erlang", section 2.8.1.

"Scope extrusion" is a bad way to think about Erlang.
A better way to think about it is to think of there being a *single*
scope level for *all* variables in a clause;
a variable which is defined in some but not all branches of a conditional
form is unavailable rather than out of scope.

	I would like an option which supresses this scope extrusion, and
	makes the variables introduced within an if, case or receive
	unknown outside.  I would also like this option to be the
	default compiler behaviour.

This would massively break backwards compatibility, all in the name of
adding a rather dubious feature (Erlang variables are not otherwise
locally scoped, the proposed begin ... end feature not having been
adopted).

	The current scope extrusion is counter-intuitive, and adds
	unwanted complexity.

It is perfectly intuitive provided you first form your intuition.
It is exactly what you get in Prolog and other related languages.
And it does not *add* complexity, it *removes* it:  there is no notion
of nested scopes in the language, only that certain variables are known
to have paths on which they are not defined.

	Is there any case in which it is a "must have"?

Why yes, in the common case of things like

	if X > Y -> Sign = 1,  Abs = X - Y
         ; X < Y -> Sign = -1, Abs = Y - X
         ; X ==Y -> Sign = 0,  Abs = 0
        end,
        ... use Sign and Abs ...

where the *point* of the conditional is to bind several variables
rather than to compute a value.

	Wish 2: Block comments
	
	Some programming languages provide line comments, e.g. Erlang, TeX,
	Scheme, whereas others provide block comments, e.g. ML, Haskell, SGML.
	Both forms of comment have their uses, and I would like to be able to use
	block comments as well as line comments in an Erlang program.
	
And Erlang's ancestors had PL/I-style /*...*/ comments too.
This is a "feature" that was *removed* in the history of the language.
See the Ada Quality an Style Guidelines and the Ada Rationale for reasons
why PL/I-style comments are not such a good idea as all that.  (If you
think that they are good for commenting out chunks of code, you are sadly
mistaken; they are extremely error prone for that use.)

	Wish 3: ISO latin 9

	Confusion between the two is very common.  I would like Erlang
	to be an ISO latin 9 language.
	
What does it mean to "be" an ISO Latin 9 language?
What about people like me?  On none of my machines is there a locale
that supports *both* 8859-15 *and* my country.  I really have no choice
but to use Latin 1.  (What would *really* suit my country would be
Latin 4 or Latin 6, but there is no locale available to me which uses
those either.)

The intention was expressed many years ago that Erlang should become a
Unicode language, and I for one have proposed an

    -encoding(<<encoding name>>).

declaration, so that

    -encoding(iso_8859_15).

should suit you.

	None of these changes should affect the time or space efficiency
	of a Erlang compiler.

Support for Latin-0, or anything outside Latin-1, will require some fairly
major changes to allow general Unicode characters in atoms and fairly
major rework of the lexical analyser.  There are also some rather serious
design questions about the relationship between strings and binaries.
(It's not just the compiler that's affected by "being an ISO Latin 9
language", it's the runtime and libraries as well.)

These things HAVE to come, but it would be a pity to spend time on one
specific 8-bit character set instead of going straight for the big one.
(After all, the first 256 characters of Unicode are identical to Latin 1,
not to Latin 0.)