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

[Julian Fondren]

On 2019-07-19 19:17, Zoltan Somogyi wrote:
> On Fri, 19 Jul 2019 19:02:34 -0500, Julian Fondren
> <jfondren at minimaltype.com> 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.
> 
> In languages like Haskell, you need to use typeclasses Eq, Ord, Show 
> and Read
> for a lot of tasks. In Mercury, equality, comparison, reading in and 
> writing out
> are defined on all types. That cuts down the number of *explicit* 
> mentions
> of typeclasses a lot.

Oh yes, that makes sense.

Incidentally, from the tutorial I'm working on:

% ----
** In some languages an enum can be converted to an int or a string; Ada 
has special attributes that remember the first and last enum, etc. Does 
Mercury have any 'value-added' information like this?

As soon as this type is defined, Mercury knows how to

1. print out the type values as a string: "sunday", etc.

2. parse a value of this type out of a string, as shown with this code's 
use of ~io.read_from_string/6~.

3. order ~days~ values by their order here: ~monday~ is less than 
~tuesday~, ~sunday~ is less than ~saturday~.

Of the first two features, the language doesn't really emphasize
this. I'd even say that these capabilities are more like /library
conveniences/ than they are features provided by the language. Any
extra relationships you want ~days~ to have, you should add with code.

The third feature is a deliberate property of the language[0], intended
to support generic data structures.

0] 
https://mercurylang.org/information/doc-latest/mercury_ref/The-standard-ordering.html#The-standard-ordering
% ----

I'll just go ahead and rewrite that now...