Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Feature request.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Andreas Rossberg <AndreasRossberg@w...>
Subject: Re: [Caml-list] Feature request.
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