[m-rev.] for review: improve doc and error messages for existentially typed data

[Julien Fischer]

On Wed, 6 May 2020, Zoltan Somogyi wrote:

> 2020-05-06 13:57 GMT+10:00 Julien Fischer<jfischer at opturion.com>:
>
>>>      --->    some [T] (s(T) => showable(T)).
>>>  :- type list_of_showable == list(showable).
>>>> -% Here's an arbitrary example involving multiple
>>> -% type variables and multiple constraints.
>>> +% Here is an arbitrary example involving multiple type variables
>>> +% and multiple constraints.
>>>  :- typeclass foo(T1, T2) where [ /* @dots{} */ ].
>>>  :- type bar(T)
>>>      --->    f1
>>>      ;       f2(T)
>>> -    ;       some [T]
>>> -            f4(T)
>>> -    ;       some [T1, T2]
>>> -            (f4(T1, T2, T) => showable(T1), showable(T2))
>>> -    ;       some [T1, T2]
>>> -            (f5(list(T1), T2) => fooable(T1, list(T2))).
>>> +    ;       some [T1] f3(T1)
>>> +    ;       some [T1, T2] f4(T1, T2, T) => (showable(T1), showable(T2))
>>> +    ;       some [T1, T2] f5(list(T1), T2) => fooable(T1, list(T2)).
>>>  @end example
>>
>> That last case is using behaviour we don't yet support, the constraint
>> fooable(T1, list(T2)) will result in the error:
>>
>>    Sorry, not implemented: constraints may only constrain type
>>    variables and ground types
>
> So that one block of example code had a *third* bug, besides a duplicate
> function symbol name and shadowing a type variable? Holy cow!

Quite so.  That last one is a limitation of the current RTTI system more
so than an actual bug and we will probably support it one day.
Indeed, it may have been intended that it be supported when that example
was added to the reference manual.

Julien.