caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Problem with universal functions in a module
Date: Thu, 8 Jan 2015 16:21:57 +0100	[thread overview]
Message-ID: <20150108152157.GA4890@frosties> (raw)
In-Reply-To: <CA+MHO51EFKeytTdd01JUMFKD3UoUq+L5ATrCG4GqKFWWvLXY7w@mail.gmail.com>

On Thu, Jan 08, 2015 at 09:45:47AM +0000, Ben Millwood wrote:
> Parametric polymorphic values in OCaml's type system can be thought of as
> "choose an assignment of the variables in this type, and you can use this
> value with that monomorphic type". But there's no monomorphic type that
> lets 'helper' do the right thing, so you actually need something more
> expressive than ordinary polymorphic types.
> 
> In Haskell there's higher-rank polymorphism, which in this case would look
> something like 'helper :: (forall a. T a -> b) -> Helper b', so that you
> could only pass sufficiently-polymorphic arguments to helper. However, as
> Jeremy said, there's a lot of added complexity involved.

In ocaml that is 'a . 'a -> 'b, or for GADTS: type a . a -> 'b.
The problem is the former is only allowed in records and objects, not
for function arguments and the later is only for annotating code and
not for signatures.


I don't see how there can be much added complexity involved. The
higher-rank polymorphism is already allowed in records and objects so
the type system knows how to deal with them. At least when they are
annotated. I wouldn't need ocaml to infere those types.

> On 7 January 2015 at 17:26, Jeremy Yallop <yallop@gmail.com> wrote:
> 
> > On 7 January 2015 at 13:50, Goswin von Brederlow <goswin-v-b@web.de>
> > wrote:
> > > Why are function arguments less general than their original function?
> >
> > Polymorphic arguments complicate type checking and make type inference
> > impossible, so OCaml doesn't allow them.
> >
> > > B) is there some way around this I'm not seeing?
> >
> > I don't think that there's any way of passing polymorphic arguments
> > that works out simpler than using a record.
> >
> > Of course, in your simple example code it's possible to eliminate the
> > GADT altogether, which would also eliminate the need for polymorphic
> > arguments.  Perhaps GADTs play a more essential role in your real
> > code, though.

The real use case has a GADT as input for a functor. The functor
defines the boxing, an equality and unbox_with_equal operation and
that helper record. Actually I have a few flavours of the same for
different input types: type 'a t, type ('a, 'b) t and GADTs with
detached witness: type 'a key + type 'a value and so on.

I wish I could make a generic helper record with

    type ('b, 'c) helper = { fn : 'a 'b -> 'c }

*sigh*

MfG
	Goswin

  reply	other threads:[~2015-01-08 15:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-07 13:50 Goswin von Brederlow
2015-01-07 15:30 ` Goswin von Brederlow
2015-01-07 17:26 ` Jeremy Yallop
2015-01-08  9:45   ` Ben Millwood
2015-01-08 15:21     ` Goswin von Brederlow [this message]
2015-01-08 16:25       ` Leo White
2015-01-09  1:02         ` Jacques Garrigue
2015-01-10 18:02           ` Goswin von Brederlow
2015-01-10 17:52         ` Goswin von Brederlow
2015-01-10 18:49           ` Leo White
2015-01-12 14:28             ` Goswin von Brederlow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150108152157.GA4890@frosties \
    --to=goswin-v-b@web.de \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).