caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Derek Dreyer <dreyer.publicity@gmail.com>
Cc: Stephen Weeks <sweeks@sweeks.com>, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] question on type checking
Date: Mon, 26 Mar 2007 16:24:17 +0200	[thread overview]
Message-ID: <4607D791.30202@inria.fr> (raw)
In-Reply-To: <db810ed70703212132q6afd09aev367dd988788961eb@mail.gmail.com>

> Very interesting.  So now, looking back at Xavier's POPL'95 paper on
> applicative functors, I see what he means by saying it's a fundamental
> problem with how applicative functors work in OCaml.  I.e. it's not
> just a bug in the typechecker, but in the type system in the original
> paper.  In particular, the definition of signature strengthening on
> page 7 of that paper includes the following case:
>
> (module x_i : M; S)/p =
>    module x_i : (M/p.x); S/p
>
> But I believe this is a mistake, and instead of S/p it should be
>  (S{x_i <- p.x})/p

Thanks for this very interesting suggestion.

As Derek knows, there are two deep limitations in the syntactic
type system for modules used in OCaml, namely

1) at most one type equality can be recorded per type declaration, and
2) structure equality is not tracked, therefore the types F(M).t and F(N).t
   (assuming t is abstract in F's result signature) are distinct even if
   N is an alias for M.

I managed to convince myself that the problems with applicative functors
discussed e.g. in PR#3476 cannot be solved without lifting one of
these limitations, which is something I don't know how to do (neither
theoretically nor implementation-wise).

Derek's suggestion seems to prove me wrong.  The two definitions of
signature strengthening (the one in my papers, used in OCaml, and
Derek's proposal) appear to have the same expressive power in a system
with generative functors, but Derek's definition is definitely
stronger in conjunction with applicative functors.

> In other words, first replace references to x_i (esp. in functor
> applications in types) inside S with references to p.x, and then
> proceed with selfification as usual.  Is there some reason this would
> not work or would be difficult to implement?

Difficult to implement: I don't think so.  Would not work: some formal
soundness argument would be nice of course :-), but there is a
strong intuition that at the point of the ";" in the equation above,
the two paths "x_i" and "p.x" carry the same amount of typing information,
so replacing the latter by the former appears sound.

Best wishes,

- Xavier


      reply	other threads:[~2007-03-26 14:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-20 18:20 Stephen Weeks
2007-03-21 15:51 ` [Caml-list] " Derek Dreyer
2007-03-22  1:13   ` Stephen Weeks
2007-03-22  4:32     ` Derek Dreyer
2007-03-26 14:24       ` Xavier Leroy [this message]

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=4607D791.30202@inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=caml-list@yquem.inria.fr \
    --cc=dreyer.publicity@gmail.com \
    --cc=sweeks@sweeks.com \
    /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).