caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
To: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Records typing
Date: Wed, 13 Nov 2002 15:48:11 +0100	[thread overview]
Message-ID: <3DD2662B.288912D3@ps.uni-sb.de> (raw)
In-Reply-To: <20021113114105Z.garrigue@kurims.kyoto-u.ac.jp>

Jacques Garrigue wrote:
> 
> > # module M' = struct type t = float type r = {f : t} end;;
> > module M' : sig type t = float and r = { f : t; }  end
> 
> There is actually a bug: depending on what is the definition, it is
> either in the interpretation of type declaration or in the
> pretty-printer.

Isn't the problem already appearent on the signature level alone? The
original code snippet displayed:

> # module type T = sig type t type r = { f : t } end;;
> module type T = sig type t and r = { f : t; }  end

There does not seem to be any distinction being made between recursive
and non-recursive type specs in signatures. If that really is the case,
isn't it somewhat incompatible with the treatment of type definitions,
where recursion can trigger boxing? That probably is the origin of the
following anomaly:

  module X = struct type t = float type r = {f:t} end
  module X1 = (X : sig type t = float type r = {f:t} end)
  module X2 = (X : sig type t type r = {f:t} end with type t = float)

X1 is accepted, but X2 isn't.

Maybe I'm wrong, but I believe the whole problem can be circumvented (or
it least be simplified) by basing the decision when to unbox on a pure
syntactic criterion, rather than a semantic one. What I mean is, only
unbox when the types of the record fields are syntactically declared to
be float. A signature using an abbreviation and one using float directly
for a record field would not be compatible. That keeps out recursion
issues and is consistent with the treatment of constructor arity.

	- Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
 as kids, we would all be running around in darkened rooms, munching
 magic pills, and listening to repetitive electronic music."
 - Kristian Wilson, Nintendo Inc.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  reply	other threads:[~2002-11-13 14:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-06 12:57 malc
2002-11-11 11:43 ` Andreas Rossberg
2002-11-13  1:11   ` Jacques Garrigue
2002-11-13  2:41     ` Jacques Garrigue
2002-11-13 14:48       ` Andreas Rossberg [this message]
2002-11-13  9:55     ` malc
2002-11-13 10:08       ` Jacques Garrigue
2002-10-24 10:55         ` Christophe Raffalli

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=3DD2662B.288912D3@ps.uni-sb.de \
    --to=rossberg@ps.uni-sb.de \
    --cc=caml-list@inria.fr \
    --cc=garrigue@kurims.kyoto-u.ac.jp \
    /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).