[Caml-list] Feature request.

[Caml-list] Feature request.

[Lukasz Lew]

Hi.

  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?

- Lukasz Lew



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

Re: [Caml-list] Feature request.

[Alain.Frisch]

On Tue, 8 Apr 2003, Lukasz Lew 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?

Local modules can help you !

If X is a structure item (open, type, exception,...), you can
encode  (X in e) as:

  let module Foo = struct
    X
    let result = e
  end in
  Foo.result

I wrote a Camlp4 syntax extension to support this:

http://www.eleves.ens.fr/home/frisch/soft#openin

It defines the following construction:
    open M in e
and the generalization:
    struct ... end in e


There is a small run-time overhead, because of the creation of the local
structure. Also, note that type variables defined outside a local
structure are not visible within the structure; the following does not
work:

 let f (x : 'a) =
   let module Foo = struct
     exception E of 'a;;
     raise (E x)
   end in
   ()


-- Alain

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

Re: [Caml-list] Feature request.

[Tim Freeman]

From: Lukasz Lew <ll189417@zodiac.mimuw.edu.pl>
>  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?

I don't know.

>  Why some constructions are restricted to global (module) use?

You can do "let module ... in", so "global" is not equivalent to
"module".  I don't like open statements anyway because they require me
to read many of the opened modules to discover which module provides
the symbol.  I prefer to establish one-letter module names if I feel
the need for brevity, so "let module" is all I need.

-- 
Tim Freeman                                                  tim@fungible.com
Which is worse: ignorance or apathy? Who knows? Who cares?
GPG public key fingerprint ECDF 46F8 3B80 BB9E 575D  7180 76DF FE00 34B1 5C78 

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

Re: [Caml-list] Feature request

[Lukasz Lew]

On Tue, 8 Apr 2003 Alain.Frisch@ens.fr wrote:
> On Tue, 8 Apr 2003, Lukasz Lew 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?
> 
> Local modules can help you !
> 
> ...
Yes, this all looks very nice, and even will be usefull for me, but i ask:
Why it isn't built in?
I mean: is there any reason (performance propably) for treating some 
constructinons diffrently.
There is global "let ident = expr " and local "let ident = expr in"
There is global "type ident = typedef" and no local pair.

Local modules are fine, but they are not so user friendly.

-- Lukasz Lew


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

Re: [Caml-list] Feature request.

[Jean-Christophe Filliatre]

Lukasz Lew writes:
 > 
 >   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).

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.

Just a guess...	

-- 
Jean-Christophe Filliâtre (http://www.lri.fr/~filliatr)

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

Re: [Caml-list] Feature request.

[Alain.Frisch]

On Wed, 9 Apr 2003, Jean-Christophe Filliatre wrote:

> 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

What kind of type unsoundness ?  A local exception cannot be matched
outside its scope (except by match-all pattern, of course), and that's
all.

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

This is exactly the same issue as for local modules, and OCaml can detect
it.

# let module A = struct type t = X end in A.X;;
This `let module' expression has type A.t
In this type, the locally bound module name A escapes its scope

-- Alain

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

Re: [Caml-list] Feature request.

[Andreas Rossberg]

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