Enhanced type guard syntax]

[Thomas Arts]

> 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.

/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 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtc_typefun.erl
Type: application/octet-stream
Size: 10229 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030918/98a84313/attachment.obj>