Enhanced type guard syntax]
Thu Sep 18 14:14:35 CEST 2003
> What is the runtime expense of performing such checks?
There is a little overhead when you have the basic datastructures. It
gets wors for datastructures that become complicated, like a record
with fields that contain records, which are lists etc.
I wrote a dynamic type checker in 1998, worked fine. Problem is that the
source code is changed and people tend not to like that :0).
Attached is the main module of that project. I saw that it was made for
the old jam binaries, instead of for the beam. Got really out of sync and
you need to adopt it to R9 if you want to use it. Guess it's two days work
for a good programmer.
> Would this lead the way to a user-defined type system some day, one that
> even supports recursive type definitions?
> -type (blammo, [atom() | blammo()]).
> foo (A/blammo, B/blammo) ->
> blammize (A, B).
That's indeed what we are missing. However, there was a philosophy that
all guards should be executable in constant time. In case of recursively
defined user types, this does not hold any longer.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 10229 bytes
Desc: not available
More information about the erlang-questions