Enhanced type guard syntax]
Fri Sep 19 13:18:13 CEST 2003
> 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
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) ->
Dr Thomas Arts
Software Engineering and Management
IT-university in Gothenburg
Box 8718, 402 75 Gothenburg, Sweden
Tel +46 31 772 6031
Fax +46 31 772 4899
More information about the erlang-questions