[erlang-questions] some language changes

[ok]

On 2 Jun 2007, at 5:18 am, James Hague wrote:
> Stuff that's doable:
>
> * destructive updates of local variables (that is, removing the
> single-assignment property)

I thought the aim was a NICE syntax?
Think carefully about 'fun's and ask again 'what is a local variable'?
Take a look at how list comprehensions are actually compiled and ask
whether a variable mentioned in a list comprehension can or should
count as 'local'.  If the concept of 'local variable' is this fuzzy,
what does that say about this idea?

> * local functions
> * ability to use any function as a guard

Presumably s/as/in/, but as explained repeatedly in this list,
this has run-time implications and is not wholly desirable.

> * changing of scope rules, including adding "let...in" and "where"  
> constructs
> * a replacement for records

Both the candidates for that require nontrivial runtime changes;
the message we have now is the result of just such an attempt to
add records without runtime changes, and it is difficult to see
how any other no-runtime-changes approach can avoid the problems.

> * indentation-based syntax (no more commas and semicolons and so on)

Two things have been conflated here.
  (a) Using indentation to indicate the ends of constructs like 'case'.
  (b) Avoiding commas and semicolons.
AWK shows that you can have (b) without having (a).
In fact my own Haskell-like syntax for Erlang provides (b) without
providing (a).  Conversely, you could very well have (a) without (b).

Occam, Python, and Haskell show that indentation-based syntax can be
very nice for people.  However, it does make life harder for tools
that generate code:  the indentation of the output depends on context
which may not be available to the generator.

A major problem with indentation-based syntax is the TAB character.
Some programs (like vi(m)) let you change the implied placement of
tab stops.  Others do not.  I have had some very painful experiences
trying to work with code written on a Macintosh in an IDE which let you
set tab width as you wished, but which did not visibly record that in
the source code.  Haskell works around this by defining in the Report
that tabs are every 8 columns, so that anyone who changes this in their
editor is responsible for the large bleeding hole in their foot.

> * list comprehensions that step through multiple lists simultaneously
> instead of in a nested manner

I have this in Clean and very much appreciate it.
However, I note that we already have the *effect* of this, without the
syntax.  Suppose we want
	[f(X, Y) || X <- L1 & Y <- L2].
Then we can write
	[f(X, Y) || {X,Y} <- lists:zip(L1, L2)]
right now.  That's how Haskell does it.  I find this proctalgic, but
it is certainly possible, and getting the efficiency one would like is
a small matter of compiler optimisation.

Before we even worry about this, wouldn't it be nice to have inline
loops for list comprehensions, instead of out-of-line code that isn't
even tail recursive?  What I mean is this.  Given

	R = [f(X) || X <- L, g(X)]

where g(X) is some guard, I would expect code like this:

	%T := []
	%L := L
	%N := 0
	while is_list(%L) do
	   X := hd(%L)
	   %L := tl(%L)
	   if g(X) -> %T := [f(X)|%T], %N := %N+1 ; true -> skip end
	end
	case %L of [] -> skip end
         R = %reverse(%N, %T)

where %reverse is a really fast list reverse opcode that can (but need
not) reverse the list in place.
	{f(X) || X <- L, g(X)}
would be the same, except for using %reverse_to_tuple(%N, %T) at the
end.  The extension of this to nested and synchronous generators is
obvious.  The merit of this approach is that it uses no extra stack
space, and only the heap space that is going to be part of the result
anyway.  There are a couple of other advantages that I am sure you
can all think of.

This is not something that can be done without compiler back end
changes and a few small additions to BEAM, but it seems to me to be
something pretty much everyone would benefit from anyway.

> * more concise type info in patterns

If we had (inlined) abstract patterns, this would come free.