Enhanced type guard syntax]

[Thomas Arts]

Dear Peter

> The "convolution" is there for a purpose, and tagging makes the reason 
> clear (if the name is well chosen). If the tagging is inappropriate, or 
> doesn't permit nested categories of example (Thomas, did my answer of 
> using n-tuples press any buttons?), or simply not necessary it can be 
> changed or removed globally. But I'm sure that *adding* tags after 
> creating a tagless design will be painful and error prone.

I think this discussion is mixing up two ideas.
1) There is a proposal to write type guards in a different way
2) There is an older discussion, that people like to have some
     type checking support.

W.r.t. 1) if you make a choice, my point was to realize that you might
influence the possibilities for 2).

The discussion between Vlad and Peter seems to rise from a 
misunderstanding between Static type checking and Dynamic
type checking. Peter basically proposes to have tags for all
types at runtime. In the present Erlang compiler, all basic types 
are already tagged, though not by tuples, but by the internal
representation. That is why you can get an runtime type error
when adding an integer to an atom.
If you want to extend that principle with user defined types, you
might do that by tuples and a lot of work, or add something to
the internal representation. No matter how, you need a representation
for it.

Static type checking may use the same representation as the
dynamic one, but checks at compile time whether there is a 
type conflict. At runtime there need not be any type information
available, since you are guaranteed (by the checker) that you
will never add an integer to an atom.

In Erlang, I am convinced, you need a combination of dynamic
and static type checking.

Notation does not solve the type-check problem, but it can
complicate it. Therefore, if you favour the type-guard notation
that Kenneth proposed, I think you should realize the consequences
for the type checking.

Oh, and to answer Mike... one should definitely take away
the type guards as they are today, therewith loosing backward
compatibility. You can otherwise write stupid things like:

f(X/integer) when string(X) ->
....

/Thomas

---
Dr Thomas Arts 
     Program Manager 
     Software Engineering and Management 
IT-university in Gothenburg 
Box 8718, 402 75 Gothenburg, Sweden 
http://www.ituniv.se/

Tel +46 31 772 6031 
Fax +46 31 772 4899