forget

[C.Reinke]

> I didn't mean to get into a philosophical dicussion about programming
> languages. While I find the topic very interesting, this might not be the 
> right place... :-)

Okay, don't want to highjack the list for my language design
interests;-) But thanks to Joe et.al. for their explanations!

Let me just record that I only partially agree with Joe: concurrency
support and the failure tolerance support on top of that *are* the
most interesting and the defining features of Erlang for me. Still,
the way these are layed out, I doubt that any non-functional
language would have been a good choice for the sequential aspect. 

I just hope that more "modern" fpls will some day catch up with
Erlang's concurrency support (no offense meant, but to get to where
Erlang is now, with all its accumulated support for practical
programming, its designers had to take 1990s fp technology and run
with it, whereas most of the more modern fpls, apart from having to
catch up on practical programming support, still don't take
concurrency as seriously as Erlang did:-(.

> >It's not just the variable names, it's that each part of the code
> >does its own thing, and has to be understood on its own and in all
> >its connections to the usage context.
> 
> Doesn't one have to do that anyway? Just because one knows that a function 
> returns (say) a certain tuple, it doesn't means one has understood it...

But one might be able to understand the common structure/programming
pattern and the specific use of that structure in isolation.

> >I guess I'd prefer something like "..,let <lhs> = <rhs>,.." to stand
> >for an implicit "..,forget(<vars(lhs)>),<lhs> = <rhs>,.." instead of
> >having an explicit forget bif or the current f() in the shell.
> 
> It should maybe be more like
>     local <vars> in <lhs> = <rhs>, <lhs> = <rhs>... end
> because one might have already bound variables in <lhs> that one wants to 
> keep bound.

Strictly speaking, I should agree with explicit binders, but I chose
what looks like a minimal extension that doesn't shadow any currently
permitted programs and might have a chance of being accepted by
Erlang programmers (hmm, you are one, and you don't..;). In
particular, my suggestion wouldn't eliminate the existing construct,
so if you wanted to do so, you could write (slightly less flexible):

  .., let <lhs> = <rhs>, <lhs> = <rhs>, ... 

Claus