caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Don Syme" <dsyme@microsoft.com>
To: "Xavier Leroy" <Xavier.Leroy@inria.fr>, "Chris Hecker" <checker@d6.com>
Cc: <caml-list@inria.fr>
Subject: RE: [Caml-list] recursive modules redux, & interface files
Date: Fri, 23 Mar 2001 12:33:51 -0800	[thread overview]
Message-ID: <0C682B70CE37BC4EADED9D375809768A48FD7A@red-msg-04.redmond.corp.microsoft.com> (raw)

> A possible approach for Caml would be to have a link-time analysis
> that detects cross-module value recursions that involve only function
> definitions, and allow these (because they are safe -- like in C!).
> Fabrice Le Fessant posted a patch to OCaml a while ago that does
> pretty much this.  I'm still hoping more general, principled solutions
> exist, but they sure are hard to design!


Isn't it feasible to annotate elements of signatures with something that
indicates that an identifier really is bound to a value, rather than a
module??  i.e.

foo.mli:

    value f : int -> int  (* must be bound to a lambda expression or an
identifier in foo.ml *)
    value x : int list (* must be bound to a cons-cell or an identifier
in foo.ml *)
    expr g : int -> int (* may be a computation *)

(The current "val" would be interpreted as "expr". "value" could also be
replaced by "const" or "val rec" or "rec" or whatever)  

I know this is revealing part of how foo.mli is implemented, but that is
really the point: allow the programmer to reveal more when necessary to
prove that things are safe.  I guess you'd have to generalize this to
functors, etc., (the subsumption relation between signatures would allow
"values" to be used as "expressions", but not vice-versa).   

Hasn't there been some work done one such "phase distinction" rules?
Was that by Harper et al.? 

However, this would not solve the problem:

    A.mli    val x : int                B.mli    val y : int
    A.ml     let x = B.y                B.ml     let y = A.x

Perhaps disallowing identifiers on the r.h.s. (as in "let rec") is the
right thing to do, even if a bit of pain when just rebinding function
values.

Cheers,
Don
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr


             reply	other threads:[~2001-03-23 22:51 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-23 20:33 Don Syme [this message]
2001-03-27  9:00 ` Xavier Leroy
  -- strict thread matches above, loose matches on Subject: below --
2001-03-27 17:05 Manuel Fahndrich
2001-03-27 14:38 Don Syme
2001-03-23 10:33 Dave Berry
2001-03-22 18:04 Dave Berry
2001-03-23  7:54 ` Tom Hirschowitz
2001-03-23 12:18   ` Fabrice Le Fessant
2001-03-27  8:49   ` Hendrik Tews
2001-03-22 11:55 Dave Berry
2001-03-22 12:01 ` Markus Mottl
2001-03-27  6:29 ` John Max Skaller
2001-03-18 23:05 Chris Hecker
2001-03-19  0:01 ` Brian Rogoff
2001-03-19 11:04 ` John Max Skaller
2001-03-19 11:41   ` Chris Hecker
2001-03-20 17:43     ` John Max Skaller
2001-03-21  4:03       ` Chris Hecker
2001-03-21  5:10         ` Patrick M Doane
2001-03-21  9:27           ` Chris Hecker
2001-03-21 18:20           ` John Max Skaller
2001-03-22  0:03             ` Patrick M Doane
2001-03-22  0:22               ` Brian Rogoff
2001-03-22  9:11               ` Francois Pottier
2001-03-21 23:24           ` John Prevost
2001-03-22  0:00             ` Patrick M Doane
2001-03-21 18:18         ` John Max Skaller
2001-03-21 18:19         ` John Max Skaller
2001-03-22 11:40   ` Markus Mottl
2001-03-21 18:41 ` Xavier Leroy
2001-03-22  0:23   ` Patrick M Doane
2001-03-22 12:02   ` Hendrik Tews
2001-03-22 13:01     ` Markus Mottl
2001-03-22 16:56       ` Brian Rogoff
2001-03-22 17:13         ` Daniel de Rauglaudre
2001-03-23 17:30         ` Fergus Henderson
2001-03-23 18:04           ` Brian Rogoff
2001-03-26  2:29             ` Fergus Henderson
2001-03-27 22:11         ` John Max Skaller
2001-03-28  4:30           ` Brian Rogoff
2001-04-05 17:07             ` John Max Skaller
2001-03-27  8:21       ` 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=0C682B70CE37BC4EADED9D375809768A48FD7A@red-msg-04.redmond.corp.microsoft.com \
    --to=dsyme@microsoft.com \
    --cc=Xavier.Leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=checker@d6.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).