Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: "Sylvain BOULM'E" <Sylvain.Boulme@lip6.fr>
To: Markus Mottl <mottl@miss.wu-wien.ac.at>
Cc: caml-list@inria.fr
Subject: Re: Problem binding type parameters in modules
Date: Mon, 18 Jan 1999 15:59:05 +0100	[thread overview]
Message-ID: <199901181459.PAA01741@ventoux.lip6.fr> (raw)
In-Reply-To: Your message of "Sat, 16 Jan 1999 13:21:35 +0100." <199901161221.NAA00134@miss.wu-wien.ac.at>

Hello !!

The problem you mentionned, comes from the type rule of O'Caml :
"there is a the type generalization ONLY on values..."

For exemple (as an application is not a value), 

In the environnement :
  module type FOO1 =
  sig
    type 'a foo
    val empty : 'a foo
  end;;

  let id x = x;;

The following definition fails to typecheck :
  module Bar : FOO1 =
  struct
    type 'a foo = 'a list
    let empty = id [];;
 end;;


This restritriction has been made to deals with "polymorphic references".
Indeed, without this restriction the following lines success to typecheck :
  let empty = ref [];;
  let push x = empty:=x::!empty;;
  (push 1);;
  (push true);;
which shows that there is no typesystem any more.

so in "let empty=ref []", empty has type '_a list ref where the "_" in the
"'_a" means that "'_a" could be instanced only once.

Actually, the restriction may seems a bit strong, but it seems difficult to
decide if an expression should be polymorphic or not....

To solve your problem, you may use functors:

  module type FOO1 = functor (M:sig type elt end) ->
  sig
    type foo
    val empty : foo
  end;;

  module Bar: FOO1 = functor (M:sig type elt end) ->
  struct
    type foo = M.elt list
    let empty = id [];;
 end;;


-----------------------------------------------------------

The main drawback about your propositions in "subtyping and inheritance -
correction", is the semantic of methods becomes very hard to understand 
(because
it depends on the context). It is already not easy to understand the difference
between subtyping and polymorphism on objects, but actually you don't care, 
because
it doesn't affect the behaviour of methods (you may only have difficulties to
typecheck). 

Best regards.

Sylvain





  reply	other threads:[~1999-01-18 18:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-01-16 12:21 Markus Mottl
1999-01-18 14:59 ` Sylvain BOULM'E [this message]
1999-01-18 17:07   ` Problem binding type parameters in modules + subtyping and inheritance Markus Mottl
1999-01-18 19:16     ` Jerome Vouillon
1999-01-18 20:37       ` Markus Mottl
1999-01-19  8:50 ` Problem binding type parameters in modules Hendrik Tews

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=199901181459.PAA01741@ventoux.lip6.fr \
    --to=sylvain.boulme@lip6.fr \
    --cc=caml-list@inria.fr \
    --cc=mottl@miss.wu-wien.ac.at \
    /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