0001634: Feature wish: enhanced module constraints

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0001634

OCaml

OCaml general

public

2003-04-13 06:02

2003-05-05 16:56

Reporter

administrator

Assigned To

Priority

normal

Severity

feature

Reproducibility

always

Status

acknowledged

Resolution

open

Platform

OS Version

Product Version

Target Version

Fixed in Version

Summary

0001634: Feature wish: enhanced module constraints

Description

Full_Name: Brian Rogoff
Version: OCaml
OS:
Submission from: 12-234-83-176.client.attbi.com (12.234.83.176)

Hi,
  In the latest round of thrashing over the parameterization trick hack for
encoding mutually recursive type and functor instantiations, an old annoyance
reared it's head again so I decided I'd see if you want to fix it.

  The problem is that when we have a signature which exports two types (say,
Set.S, which exports t and elt) and we'd like to enforce that these two types
are
related like in the following, where Ord.t is obviously a polymorphic type

(* Not legal!!! *)

module MakeRec(Ord: OPEN_ORDERED) : (S with type elt = t Ord.t) =
                                                       ^-- how to refer to S.t?
  struct
  ...
  end

the only way I think we can do this now is to expand the signature S out with
the
type equalities coded in the expanded sig. If that's right, that is a
shortcoming
of the module system, and very un-Caml-like in it's verbosity, as I now have to
repeat the whole signature just to get the type equality I want. I understand
that neither "t" (which t does that refer to) nor "S.t" will work there, but
isn't this just syntax? Can't something like the following, also not legal
OCaml, be made to work?

module MakeRec(Ord: OPEN_ORDERED) : (S with type t and type elt = t Ord.t) =
  struct
  ...
  end

where we first mention the t so that we know we're talking about the t in the
struct being defined, and then refer to it.

I trust that fixing this is easier than fixing the recursive module problem :-)

-- Brian

Issue History
Date Modified	Username	Field	Change
2005-11-18 10:13	administrator	New Issue

Relationships

Notes
There are no notes attached to this issue.