[m-dev.] Mode syntax suggestion (possibly gross)

Tyson Dowd trd at cs.mu.OZ.AU
Wed Sep 27 11:32:24 AEDT 2000


On 26-Sep-2000, Ralph Becket <rbeck at microsoft.com> wrote:
> I suspect this is a horrible idea, but...
> 
> Suggestion: if I have a type foo/N and an inst foo/0 then interpret
> modes in/0 and out/0 as in(foo) and out(foo) respectively in mode
> declarations.
> 
> Justification: if I decide to change a type so that it carries around
> some non-simple data (e.g. going from a bool to a maybe(func(T1) = T2))
> then (a) I have to create a special inst for objects of this type and
> (b) I then have to hunt down every location where the type is used and
> change the modes of those arguments.  Very tedious.
> 
> I know this is somewhat unpleasant, but the current mode syntax *is*
> cumbersome as soon as you try anything interesting.  I'd be happy to
> hear any other, less hacky, suggestions.

This is not a terrible idea.

It's not actually too different to Fergus's sub-typing proposal from
many months ago.

http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-developers/mercury-developers.0002/0093.html

In that proposal, you could introduce a subtype of a type, which would
automagically define an inst for that subtype.

:- type sometype ---> foo ; bar ; baz.

:- subtype somesubtype < sometype ---> foo ; bar.

implies an invisible:

:- inst somesubtype == bound(foo ; bar).

Then whenever you used type `somesubtype' as a type, it would be
substituted with `sometype' and the corresponding mode would be
substituted with the inst `somesubtype'.

:- pred foo(somesubtype::in) is det.

is actually

:- pred foo(sometype::in(somesubtype)) is det.

I think this proposal is quite nice, and I'd like to see it added
someday.


Now your proposal is not that different.

You'd like

:- pred foo(ralphtype::in) is det.

to be viewed as

:- pred foo(ralphtype::in(ralphtype)) is det.

if inst ralphtype exists.


If we had subtyping as in Fergus' proposal, you could just write

:- subtype ralphtype < sometype ---> foo ; bar ; baz.

Then wherever you use sometype you could just use ralphtype and get
close to the substitution you desired.

:- pred foo(sometype::in(ralphtype)) is det.


It would be cleaner if you could just write

:- subtype ralphtype ---> foo ; bar ; baz.

and remove the need for a parent type.  This `:- subtype' is badly
named, it's really just a mechanism for defining a type and a mode
simultaneously.  It would be very nice if you could write

:- subtype mytype ---> foo(pred(int::in) is semidet) ; bar ; baz.

Or something similarly easy to write.



I also planned to use a similar construct for doing automatic laziness
transformations (when I get around to working on that again).
In this case if you wrote 

:- type sometype ---> foo ; bar ; baz.
:- lazy sometype.

it would be turned into

:- type lazysometype ---> foo ; bar ; baz ; thunk(func = lazysometype).
:- subtype sometype < lazysometype ---> foo ; bar ; baz.
:- inst lazysometype == bound(foo ; bar ; baz ; thunk(func = out is det)).

And the mode transformation would be slightly different:

:- pred halflazy(int::in, sometype::out, sometype::lazy(out)) is det.

Non-lazy modes are transformed as usual.  Lazy modes are turned into the
lazy supertype.

:- pred halflazy(int::in, sometype::out(sometype),
		somelazytype::out(lazysometype)) is det.

(Mark Brown actually proposed a very similar idea for doing laziness by
hand).


So I'd like to reintroduce the subtyping proposal for discussion.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list