Enhanced type guard syntax]

Peter-Henry Mander erlang@REDACTED
Fri Sep 19 12:28:43 CEST 2003

Hi Vlad, Hi Thomas,

Vlad said, answering me:

>>Not necessarily, for example:
>>    sum({list_of_integers, Value}) -> ... {integer,Sum}.
>>    sum({list_of_integers, Value}) -> ... Sum.
>>is a design issue.
>>Or am I missing your point?
> No it was my point :-) What I was thinking about was that using this scheme from
> the very start of the development (i.e. prototyping) would make it no nolger be
> rapid, which is a very good thing about Erlang. To introduce the tags at a later
> stage is cumbersome.

Ah, yes, but when prototyping I'm ready to scrap old ideas to introduce 
something better or more specific. Is it true that if the prototype has 
matured to the point where making changes is difficult, it is no longer 
really a suitable prototype?

>>If you return tagged types, it will force users of the function to honor
>>the type scheme, and isn't that what the goal is?
> I am not sure if forcing developers to do things in a more convoluted way is
> always a good thing, even if there are gains somewhere else.

I think that if the prototype demonstrates the need for stricter types, 
an experienced programmer/designer will introduce them as required, and 
avoid the pain later, unless of course the design decision was wrong.

But if the _design_ is wrong, type checking won't help avoid the pain of 
making changes to correct it!

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.

It's a design decision that ought be made early, but it may be delayed 
until a simple prototype indicates the need for stricter parameter types.

But looking at my own code, this tagging scheme isn't pervasive, and I 
get sufficient control over data with the few tags I've (carefully :-) 
chosen to not desire any extra type checking in the compiler.

This may explain why I'm not sure I understand the type-strict argument 
properly. Thomas, I need your opinion on this, you've got an attentive 
student here :-)


More information about the erlang-questions mailing list