[m-users.] Using insts to simulate dependent-type features.

[Julian Fondren]

On 2019-07-20 01:19, Julien Fischer wrote:
> On Fri, 19 Jul 2019, Julian Fondren wrote:
> 
>> On 2019-07-19 02:28, Julien Fischer wrote:
>>> Hi Mark,
>>> 
>>> On Fri, 19 Jul 2019, Mark Brown wrote:
>>> 
>>>> On Thu, Jul 18, 2019 at 8:01 PM Julien Fischer 
>>>> <jfischer at opturion.com> wrote:
>>>>> The major issue with using insts like the above is that the 
>>>>> standard
>>>>> library doesn't use polymorphic modes (for the most part), so the
>>>>> subtype information tends to get lost quite easily.
>>>> 
>>>> There's that, and also that it doesn't tend to provide specific 
>>>> modes
>>>> that constrain the subtype. For example, list.append could have 
>>>> these
>>>> additional modes:
>>>> 
>>>> :- mode append(in(non_empty_list), in, out(non_empty_list)) is det.
>>>> :- mode append(in, in(non_empty_list), out(non_empty_list)) is det.
>>>> 
>>>> Similarly for list.reverse, list.reverse_prepend, list.map*, etc.
>>>> Also, some existing modes could be tightened, such as the (in, in,
>>>> out) mode of list.insert.
>>> 
>>> You'd probably want to combine the two things, e.g. define
>>> 
>>>     :- inst non_empty_list(I) for list/1
>>>         --->    [I | list(I)].
>>> 
>>>    :- mode append(in(non_empty_list(I)), in, out(non_empty_list(I))) 
>>> is det.
>>> 
>>> Julien.
>> 
>> It's interesting that Mercury's libraries are not as clever as Mercury
>> allows. I noticed that first with typeclasses, which are omnipresent 
>> in
>> some other languages but which only even appear in nine of Mercury's
>> library modules.
> 
> Something to bear in mind here is that much of Mercury's standard
> library was written *before* type classes were added to the language.
> (If we were starting the standard library again from scratch, we'd
> probably make more use of them.)

Aye. Looking through the mailing list, I came across this post:

http://lists.mercurylang.org/archives/users/1999-October/007242.html

Partial quote:

: now that mmc v. 0.9 is around the corner and the language has 
developed so
: much, it's probably time to start some serious discussion about the 
content
: and structure of v2 of the standard library.
:
: Stdlib v2 should have the following features, IMHO (Fergus et al. have
: already mentioned most/all of these):
:
: - use submodules under a common name space;
: - be carefully constructed so as to make it easy to exploit in higher 
order
: code;
: - use DCG friendly argument ordering conventions in `stateful' ADTs 
(e.g.
: arrays);
: - make extensive use of typeclasses;
: - make extensive use of assertions/promises.

At this point, rather than overhaul the stdlib and suddenly replace
it with a Mercury release, I'd suggest releasing libraries with some
of these features to some library-sharing app (like CPAN, cargo,
NPM) so that it's easier to piecemeal-evolve the library, and easy
to use a v2 variant when wanted, without breaking old code.

This has worked to an extent for OCaml.

Is there already some kind of npm thing written for Mercury? I seem
to remember someone announcing something like that...

> 
> The lack of various advanced mode system feature in the standard
> library is down to a similar reason and also due to stability and
> preformance concerns.
> 
> Julien.