[m-users.] Using insts to simulate dependent-type features.
Julien Fischer
jfischer at opturion.com
Sat Jul 20 16:42:12 AEST 2019
On Fri, 19 Jul 2019, Julian Fondren wrote:
> 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~.
More generally, the reflection capabilities built into Mercury allow you
to obtain a type descriptor for any given value (see the type_desc
module in the standard library). A type descriptor is a value that
describes a Mercury type. Functionality like (1) and (2) above is built
atop that.
Julien.
More information about the users
mailing list