[m-dev.] getting type representation decisions from .int files

[Zoltan Somogyi]

2021-07-05 18:20 GMT+10:00 "Peter Wang" <novalazy at gmail.com>:

> I see. I think a more common case where you might want to replace an
> argument type with a subtype would not involve mutually recursive types,
> which is why the mention of them confused me.

Ok, I used your example, as well as an expanded version of mine,
in the attached diff, which I present for your review.

> Thinking back on it now, while earlier subtype proposals would have
> worked very differently in the end, syntactically the starting point was
> the same. Both Fergus and Mark's proposals didn't place any restrictions
> on the supertype, except to prevent free variables. As I was developing
> my proposal and implementation, I never encountered any need to deviate
> from that, technically or subjectively.

I am afraid I cannot really use that explanation, so my diff now just states the rule
and does not try to give a rationale.

> As discussed previously, those additional type parameters would have to
> be phantom types.

The rest of the manual does not say anything about phantom types
(though maybe it should, it should be a separate change),
and I don't think it would be helpful for them to be introduced in the
subtype section.

> I tried to come up with an example that takes advantage of the current
> design:
> 
>     :- type result(E, Ex)
>         --->    ok(value)
>         ;       error(E)
>         ;       exception(Ex).
> 
>     :- type parse_result(E) =< result(non_empty_list(E), E)
>         --->    ok(simple_value)
>                 % the parser only returns simple values
>         ;       error(non_empty_list(E))
>                 % the parser can return multiple errors
>         ;       exception(E).
>                 % the parser throws/catches errors of the same type
> 
> It is contrived, but at least a little bit realistic.

That is not something I would put forward as an example
for people to follow.
 
> From a quick look, you can insert TeX commands with @math but that will
> do nothing for HTML and Info output. @sub does subscripts which can be
> rendered in HTML, but results in something like S_{i} in Info. I don't
> see that as better.

I don't either, so I am leaving the notation as it was.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.refman3
Type: application/octet-stream
Size: 11956 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/developers/attachments/20210709/eb01f106/attachment.obj>