Enhanced type guard syntax]

[Robert Virding]

Unfortunately I missed this discussion when it came out but I will give my
opinion now. I don't really know what others have said so I may just be
repeating someone elses opinion.

My first instinctive gut reaction was "Definitely not". It breaks one of
my/our basic principles which I hope we wrote down somewhere.
If we didn'r we definitely should have. That is that you can use the
same pattern on both sides for constructing and destructing a term.
And that can always do it. This should work with all terms including
binaries. This new idea breaks this principle. I can't write:
    A = 1,
    B = 2,
    {A/integer,B/integer} = {A/integer,B/integer},

Well, I can of course, but the meaning of /integer is different on each
side of =. Which is a Bad Thing! As I have said before that as I get
older I value consistency more. Just to be very clear here, it is not
that there is a = here which is important, but this was just a way to
get patterns and terms together concisely.

My second more thought through reaction is still "Defintely not".

Now I will have torea what others have written.

Robert

----- Original Message ----- 
From: "Kenneth Lundin" <kenneth@REDACTED>
To: <erlang-questions@REDACTED>
Sent: Thursday, September 18, 2003 11:37 AM
Subject: Enhanced type guard syntax]


> 
> Below follows a suggestion regarding enhanced syntax for
> writing type guards in function clauses and in other match expressions.
> 
> I post this to see if you in the Erlang community have some (positive
> or negative) opinions regarding this and I hope I get a lot of feedback.
> 
> 
> 
> 
> Enhanced type guard syntax
> ---------------------------------------
> 
> The situation to day is that it is quite cumbersome to write type guards
> for a function and that it
> is unfair that some type constraints can be expressed directly in the
> argument list (list, tuple,Binary)
> while other type constraints must be expressed in the guard
> (integer,atom,float,pid,port,fun) where the argument names have to be
> repeated again.
> The idea is originally from Mats Cronqvist AXD.
> 
> 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.
> 
> % The constraint that it must be a list (with at least one element)
> % can be expressed directly in the argumentlist
> %
> bar([H|T]) ->
>     H.
> 
> 
> 
> 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(),
> 
> The rationale behind this suggestion is that we already have the
> Variable/type syntax in the matchexpressions for binaries (example:
> <<Size,B:Size/binary,Rest/binary>> = <<2,"AB","CD">>)
> It is unfair that some types can be matched without guard syntax while
> others can't.
> It will result in a more compact and intuitive way of writing that will
> encourage writing type constraints which will catch errors as early and
> efficient as possible. The allowed type specifiers should be all the
> type test BIFs named is_XXX/1 but without the "is_" prefix.
> 
> 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.
> 
> 
> /Regards Kenneth Lundin Product Manager of Erlang/OTP
> 
> 
>