Enhanced type guard syntax]
Peter-Henry Mander
erlang@REDACTED
Fri Sep 19 10:31:03 CEST 2003
Hi Gurus,
Maybe thinking about how to achieve some form of parameter checking
using existing pattern matching language features will put some kind of
(skewed) perspective on the problem.
If you _need_ to know what type of parameter is being given as an
argument, would it be more explicit and practical to simply use tagged
tuples?
> is f(X) when list(integer(X)) ->
> a good notation to express that X should be a list of integers?
perhaps this:
f({list_of_integers,X}) ->
will provide a strong enough guard to to prevent illegal use of this
function.
> is f(X,Y) when dictionary(K,V)(X), K(Y) ->
> a good notation for a dictionary of key value pairs with
> polymorphic type K for keys and V for values and a binding
> of the key type for the second argument of the funtion?
again, maybe this will do the job:
f({dictionary_of_key_value_pairs,X},{key_for_dictionary,Y}) ->
(In practice I would think of using a less verbose version!)
After all, type-checking languages are only offering a limited kind of
pattern matching, aren't they?
This scheme also makes it clear that {kelvin,RealNumber} is what it says
it is, not just an abstract numeric type for example. A very desirable
feature in my opinion.
(Combine that with "when float(RealNumber), RealNumber >= 0" to add belt
and braces).
Can someone please write a counter-argument and find the leaks in this
idea, to see if it holds water?
Pete.
Thomas Arts wrote:
> In the discussion on the type guard syntax I am missing
> the vision of what the type language should look like.
> Sure, we have the basic types and it all looks nice for
> integers and atoms.... but before you introduce a new
> syntax for something that is already exist, why not give it
> a thought what you want to achieve with it?
>
> A new notiation does not give you new possibilities in
> type checking! In particular one should consider whether
> one would allow guards with user defined types or guards
> with argumented types, polymorphic types, etc.
>
> For example:
>
> is f(X) when list(integer(X)) ->
> a good notation to express that X should be a list of integers?
>
> would that translate into f(X/list(integer)) ?
>
> is f(X,Y) when dictionary(K,V)(X), K(Y) ->
> a good notation for a dictionary of key value pairs with
> polymorphic type K for keys and V for values and a binding
> of the key type for the second argument of the funtion?
> would that be
> f(X/dictionary(K,V), Y/K) ?
>
> is f(X/list/list) a notation for list of list or should it be
> f(X/list(list)), in which case the type notation for list is both
> a constant and a unary function.
>
> is it possible to catch in a type notation:
> f(X) when 10<X, X<20 ->
> by f(X/[10..20]) ?
>
> My advice is to first discuss a suitable type language, see if that
> is realizable without performance penalties and then propose a
> syntactic sugar notation for it.
>
> One more remark, in the typed lambda calculus they use a type
> definition along with the variable in the same style as proposed,
> but they use : instead of /. I would really be in favour to use that much
> more standard notation, thus f(X:list(A), Y:A) -> ...
> One can use the same notation to give types to functions, as type
> annotations that can be checked by a compiler (without confusing
> it with devision) It will, though, be confused with module application.
> An alternative therefor is ::
> Semantically the : is "is element of" and a small epsilon could be used
> instead. However, we want to keep the ascii character set as convention,
> I guess.
>
> sort([]:list(A)) ->
> []:list(A);
> sort([X|Xs]:list(A)) ->
> ([ Y:A || Y<-Xs, Y<X] ++ [X] ++
> [ Y:A || Y<-Xs, X=<Y]):list(A).
>
> these annotations help the type checker, if available and can be left out
> in compiling for production code.
>
> /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
>
>
>
>
More information about the erlang-questions
mailing list