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

[Julien Fischer]

Hi,

On Sat, 20 Jul 2019, Julian Fondren wrote:

> On 2019-07-20 01:19, Julien Fischer wrote:
>>  On Fri, 19 Jul 2019, Julian Fondren wrote:
>>
>>>  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

Are you trying to hold use to something that was written 20 years ago,
by someone who wasn't on the Mercury team at the time? ;-)

> 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;

If that happens (and IMO it should at some point) we will put mechanisms
in place to ensure that existing code that is not aware of the
submodules still compiles.

> :  - be carefully constructed so as to make it easy to exploit in higher 
> order code;

I'm not sure where the author of that post was going with that one.

> :  - use DCG friendly argument ordering conventions in `stateful' ADTs 
> (e.g. arrays);

This was done several release ago.

> :  - make extensive use of typeclasses;

I would observe that Mercury's standard library has got by quite nicely
*without* extensive use of type classes for a very long time now.

Most the abstractions that you would want to make in the standard
library using type classes, e.g. collections, sets etc, are not possible
without the language being extended to support constructor classes.

> :  - make extensive use of assertions/promises.

Given that those things are (still) effectively NYI, that won't happen
anytime soon.

> 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.

We are not ever simply going to replace the standard library; as in the
past any changes will be introduced over a number of releases.

> 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...

IIRC, there have been several attempts but none of them seems to have
ever gained any traction.

Julien.