caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Andreas Rossberg" <AndreasRossberg@web.de>
To: "Jean-Christophe Filliatre" <Jean-Christophe.Filliatre@lri.fr>,
	"Lukasz Lew" <ll189417@zodiac.mimuw.edu.pl>
Cc: <caml-list@inria.fr>
Subject: Re: [Caml-list] Feature request.
Date: Sat, 12 Apr 2003 22:35:49 +0200	[thread overview]
Message-ID: <001f01c30133$4995cda0$d04606d5@wiko> (raw)
In-Reply-To: <16019.48771.767140.795030@gargle.gargle.HOWL>

Jean-Christophe Filliatre <Jean-Christophe.Filliatre@lri.fr> wrote:
>
>  >   I found that it would be usefull if some of the language
constructions
>  >   could be made localy. For example "open ... in" or "type ... in".
>  >   Why "open in" isn't in standard parser?
>  >
>  >   Why some constructions are restricted to global (module) use?
>
> Be aware that it may easily lead to scope issues.
>
> In SML, there used to be  local exceptions (exception E in ...) and it
> was breaking type soundness, since an exception could obviously escape
> the scope  of its declaration (unless  the compiler is  doing a static
> analysis over exceptions possibly  raised, difficult yet feasible, but
> SML was not).

Local exceptions are still allowed in SML and never raised any soundness
issue. You probably mean local datatypes, for which there indeed was an
issue in SML'90, in that the language spec allowed an expression like

  let
    datatype t = C
  in
    C
  end

where the generative type t escapes its scope. Due to the way generativity
and datatypes were modelled in the semantics, this was unsound. SML'97 does
properly restrict the scope of local type names (i.e. the type of a let body
is not allowed to mention local type names).

> I guess  that with a  "type ... in"  construct, a type  could probably
> escape its scope the same  way, leading to serious issues in assigning
> legal types to expressions.

All these problems already occur (and are solved) for local modules in
OCaml. I believe adding "let type" or "let exception" is merely a question
of finding a good trade-off between language economics on one hand and
uniformity on the other.

  - Andreas




-------------------
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


      parent reply	other threads:[~2003-04-16 16:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-08 11:31 Lukasz Lew
2003-04-08 16:15 ` Alain.Frisch
2003-04-08 19:06   ` Lukasz Lew
2003-04-08 18:03 ` Tim Freeman
2003-04-09  6:32 ` Jean-Christophe Filliatre
2003-04-09  7:44   ` Alain.Frisch
2003-04-12 20:35   ` Andreas Rossberg [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='001f01c30133$4995cda0$d04606d5@wiko' \
    --to=andreasrossberg@web.de \
    --cc=Jean-Christophe.Filliatre@lri.fr \
    --cc=caml-list@inria.fr \
    --cc=ll189417@zodiac.mimuw.edu.pl \
    /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).