[erlang-questions] Type syntax

[David Hopwood]

Kostis Sagonas wrote:
> Damien Morton wrote:
>> +1 on less syntactic clutter.
>>
>> The /2-ness of foo is clear from the remainder of the type specification
>>
>> There are redundant parentheses too - are they neeed?
>>
>> -spec(foo :: (integer, float) -> atom)
>>
>> just reads better to me
>>> On Tue, 4 Sep 2007, Kostis Sagonas wrote:
>>>  
>>>> In the new language you would write (or preferably change the above edoc
>>>> comment to be):
>>>>
>>>> -spec(foo/2 :: ((integer(), float()) -> atom())).
>>>>     
>>> What is the reason for the trailing ()s? It would be nice if the syntax
>>> had less redundant visual noise.
> 
> I very much agree with this wish, but:
> 
>    1. As mentioned in some other post in this thread, types like the
>       following one are also allowed
> 
> 		{ok, integer()} | {error, string()}
> 
>       and there needs to be way to distinguish between atoms (i.e.
>       singleton types) and type names.

I'm not necessarily arguing against the current syntax, but I think
that other ways to achieve this should be considered:

a)              {atom(ok), integer} | {atom(error), string}
b)              {'ok', integer} | {'error', string}
c)              {ok, Integer} | {error, String}

Note that c) does not collide with the existing edoc type syntax, e.g.
it would be possible to allow either "Integer" or "integer()" as synonyms
(and "List(...)" or "list(...)" as synonyms in the example below). There
is also some sense to using the same case convention for non-singleton
types as for variables (since a variable is needed to hold any member of
a non-singleton type).

OTOH, an advantage of the existing edoc syntax that is shared by a) but
not by b) or c) (unless "Integer" etc. were reserved variable names, which
would break too much code), is that each type specification corresponds
to a unique Erlang term, which could be used to represent the type in
APIs that require first-class types.

(integer/1, for example, is a conversion function, but that does not
prevent integer/0 from being a function that returns a term representing
the type.)

>   2. We want to be as much as possible compatible with edoc.

After the dialyzer type declarations come into use, there won't be any
more opportunities to change the type syntax incompatibly (although as
noted above, some changes could be made compatibly). So possible changes
should be given careful consideration now.

>   3. Some types can also take parameters. For example, the user might
>      define lists of integers and atoms as:
> 
> 		list(integer() | atom())

a) or b)        list(integer | atom)
c)              List(Integer | Atom)

-- 
David Hopwood <david.hopwood@REDACTED>