Enhanced type guard syntax]

[Bengt Kleberg]

Kenneth Lundin wrote:
...deleted
> Examples as it is today:
> ------------------------
> 
> % The constraint that A and B must be integers
> % must be expressed in the guard notation with the arguments repeated
> %
> foo(A, B) when integer(A), integer(B) ->
>      A * B.

to help beginners i find it to be a good idea to use ''modern'' erlang 
as much as possible in examples, etc. this example should (imho) be:

foo(A, B) when is_integer(A) and is_integer(B) ->
	A*B.

...deleted
> Proposed solution
> ------------------
> 
> Examples with new suggested syntax:
> -----------------------------------
> 
> % The type constraint expressed directly in the argument list
> % Shorter to write
> % Exactly the same semantics as the foo example above
> % The compiler has potential of handling these type constraints more
> efficiently than today
> % and this syntax makes the different type of guards more visible
> %
> foo(A/integer, B/integer) ->
>      A * B.
> 
> 
> {X/float, Y/float} = graph:coordinates(),

this seems to be the best way.


> Alternative syntax
> -------------------
> 
> Of course some other special character can be used to distinguish the
> type constraint from other tokens and one idea could be to make this as
> an extension to the '_' (don't care) notation which then indicates don't
> care the value but it should be of a certain type.
> 
> foo(A = $integer, B = $integer) ->
>      A*B.
> 
> foo(A = _$integer, B = _$integer) ->
> 
> Advantages with this solution could be that it does only introduce the
> new variants of typed don't care.
> 

surely this alternative syntax is confusing? when i see 'A = _$integer' 
i take it to mean that the value is of interest, and the type might be 
integer, but i do not care.

foo( _A/integer, _B/integer ) ->

is ''the best'' way to express 'do not care about value, but type must 
be correct'.


bengt, who really wants type checking, please.