[erlang-questions] Ideas for a new Erlang

[Richard A. O'Keefe]

On 28 Jun 2008, at 9:17 pm, Sven-Olof Nystr|m wrote:
> As I already explained in my reply to Richard, I meant expressions in
> a general sense.

Don't.  It's a good way to confuse people, especially yourself.
It's just like those people who call preprocessor directives in
C "statements" and then wonder why putting a semicolon on the
end gets them in trouble.

> Expressions in C or C++ are expressions.

Yes they are.  But declarations, statements, and directives are NOT.
In Erlang, you would confuse yourself and others terribly if you
called patterns expressions.

> So are expressions in Java,
> Common Lisp and most other programming languages. Even regular

> expressions are expressions. Can you give a definition of the concept
> "expression" that excludes guard tests of Erlang and includes all
> other types of expressions?

 From the OED:
"A collection of symbols together expressing an algebraical quantity."
A compatible definition from the Wikipedia:
"An expression in a programming language is a combination of values,
  variables, operators, and functions that are interpreted (evaluated)
  according to the particular rules of precedence and of association
  for a particular programming language, which computes and then  
produces
  (returns, in a stateful environment) another value."
Wolfram's MathWorld doesn't seem to have a definition of 'expression'
as such, but the pages I checked could all be summarised as
"A collection of symbols which is well formed according to some
  grammar having a semantics that determines a value from the symbols
  in a given context."

In Erlang, expressions are described in Chapter 6 of the
reference manual.

In C, C++, Java and so on, "expressions" are precisely the things
accepted by the grammar rules for 'expression' and its associated
static conditions.  It's exactly the same in Erlang.

In Erlang, those things do NOT include guards.

There is no Boolean type in Erlang.  Expressions in Erlang have values
which are Erlang terms.  Guards in Erlang have outcomes (success or
failure) which historically were not represented in any way as Erlang
terms.  Later, as part of the unfortunate bungle, 'true' and 'false'
were abused for this purpose, but the fact that these things are atoms
makes the post-design bodgery obvious.

Do you remember Lincoln's joke?

     Comedian: How many legs does a dog have,
               if you call a tail a leg?
     Straight man: five.
     Comedian: Wrong!  _Calling_ a tail a
               leg doesn't _make_ it a leg!

Guards and expressions don't follow the same rules.
That means it isn't USEFUL to call guards expressions.

> What I really wanted to say was that guard tests of Erlang are strange
> and unusual. I see nothing in your posting that contradicts that.

There is nothing strange or unusual about Erlang guards.
They are utterly banal, within the family of concurrent declarative
languages.  FCP, GHC, Parlog, Strand88 all have essentially the same  
idea;
I _think_ Andorra is similar but by the time I wanted to learn
Andorra it was dead.

Admittedly, within the family of Fortran-like languages (which includes
C, C++, and Java), guards are not to be found.  But if I wanted  
concurrent
Fortran, well, I'd lie down until the feeling passed off.  (And if I  
wanted
concurrent C, I'd want Concurrent C, which had a construct not entirely
unlike Ada's select/Erlang's receive.)
>
>
>> Robert
>>
>> P.S. I have seen attempts, not in Erlang, to include the "guard" bit
>> in the patterns and they were *very* hard to read.
>
> Not sure what that means.

It means things like

	verify(flight(int$Num, atom$Origin, atom$Destination, numb$Cost))
		<- prst('Your flight is fine.") & nl.

-- IBM PROLOG Programmer's Guide, page 63.
The Erlang equivalent would be something like
	verify(#flight{Num, Origin, Destination, Cost})
	    when is_integer(Num), is_atom(Origin),
	         is_atom(Destination), is_number(Cost)
	-> io:write("Your flight is fine.\n");
Somewhat confusingly,
	p1$p2$p3$T
in IBM PROLOG for 370 meant "p1(T) *or* p2(T) *or* p3(T)".
Now try extending that to comparisons...