Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006271OCamllanguage featurespublic2013-12-14 12:142018-11-14 07:37
Reporteryallop 
Assigned Tofrisch 
PrioritylowSeverityfeatureReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.06.0 +dev/beta1/beta2/rc1 
Summary0006271: 'let open' in class expressions
DescriptionIt'd be useful to have 'let open' available in class expressions:

   class c =
     let open M in
     object ... end
TagsNo tags attached.
Attached Files

- Relationships
has duplicate 0007477closedyallop Allow "let module", "let exception" and "let open" in class 
has duplicate 0007529resolvedfrisch Class definition syntax restrictions 

-  Notes
(0010715)
frisch (developer)
2013-12-16 10:36

Note that the following achieves the same effect:

include struct
  open M
  class c = object
    ...
  end
end
(0010743)
yallop (developer)
2013-12-18 00:46

Thanks, Alain! That's a useful workaround, and adequate for my use case.

There are a few other benefits in allowing 'let open' in class expressions. For one thing, there's a pleasing uniformity about having 'let open ... in' available everywhere that 'let ... in' is available. It also handles a few cases that the 'include' approach doesn't: for example, it supports recursive classes where you want careful control over the scope. Perhaps these aren't enough to justify its inclusion, though.
(0010745)
garrigue (manager)
2013-12-18 02:51

Well, "let open" should be simple enough to do, so I'll consider seriously doing it.
Note that on the other hand "let module" would be really difficult.
(0010751)
lpw25 (developer)
2013-12-18 20:37

On a related note, it might be nice to allow open statements within class definitions:

    class c = object
      open M
      ...
    end
(0018090)
frisch (developer)
2017-07-18 15:35

https://github.com/ocaml/ocaml/pull/1249 [^]
(0019453)
trefis (manager)
2018-11-12 18:01

I stumbled upon this because I was about to extend https://github.com/ocaml/ocaml/pull/1506 [^] to classes (well, to Tcl_open).
But the remark from Jacques made me pause:

> Note that on the other hand "let module" would be really difficult.

So I will send a first version without extending Tcl_open, but I'm curious about what would be difficult.
Jacques: do you remember?

When IĀ asked Leo he pointed me in the direction of Translclass.const_path, but looking at it we think that "let module" could be handled the same way as "let" (i.e. keep an environment), so that can't be it.
What are we missing?
(0019454)
garrigue (manager)
2018-11-13 04:57

I'm not sure I thought that in that much detail, but my main concern was how to check that a local module would not escape, particularly when you want to be able to store values with its type in value fields, which are visible in the interface of the class. Actually my conclusion was that one would need something like "module fields", like in Scala, to be able to express that properly. If you only want to be able to introduce a local module, without allowing it to appear anywhere in the interface, this should be easier, but again tracking that it does not escape is probably going to be harder than in the expression case. You at least need an extra pass on the inferred class type. And it's not as expressive as what I had in mind.
(0019455)
trefis (manager)
2018-11-13 10:27

That makes sense, thanks!
(0019458)
yallop (developer)
2018-11-13 22:45

Jacques: for escape tracking, is something additional needed beyond what's currently done to eliminate functor arguments in class definitions? e.g. in definitions like this:

   module M(X: sig type t end) =
   struct class c = object val x : X.t list = [] end end

   module N = M(struct type t = T end)

i.e. is something other than Ctype.nondep_class_declaration needed?
(0019459)
garrigue (manager)
2018-11-14 07:37

You would rather have to ask Xavier, since he is the one who used a different approach for "let module" in expressions.
At first sight, a potential problem is that nondep_class_declaration is currently only used on "finished" classes, whereas we would have to use it during the construction of a class.
I'm not sure it is really a problem (nondep_type_rec does handle non-generalized type nodes), but there may be hidden invariants.

- Issue History
Date Modified Username Field Change
2013-12-14 12:14 yallop New Issue
2013-12-16 10:36 frisch Note Added: 0010715
2013-12-18 00:46 yallop Note Added: 0010743
2013-12-18 02:51 garrigue Note Added: 0010745
2013-12-18 20:37 lpw25 Note Added: 0010751
2014-07-16 14:49 doligez Status new => acknowledged
2017-02-09 12:06 yallop Relationship added has duplicate 0007477
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-03-01 15:39 doligez Category -OCaml general => language features
2017-05-09 16:25 yallop Relationship added has duplicate 0007529
2017-07-18 15:35 frisch Note Added: 0018090
2017-07-20 08:20 frisch Status acknowledged => resolved
2017-07-20 08:20 frisch Fixed in Version => 4.06.0 +dev/beta1/beta2/rc1
2017-07-20 08:20 frisch Resolution open => fixed
2017-07-20 08:20 frisch Assigned To => frisch
2018-11-12 18:01 trefis Note Added: 0019453
2018-11-13 04:57 garrigue Note Added: 0019454
2018-11-13 10:27 trefis Note Added: 0019455
2018-11-13 22:45 yallop Note Added: 0019458
2018-11-14 07:37 garrigue Note Added: 0019459


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker