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.
I stumbled upon this because I was about to extend #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?
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.
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.
Original bug ID: 6271
Assigned to: @alainfrisch
Status: resolved (set by @alainfrisch on 2017-07-20T06:20:09Z)
Fixed in version: 4.06.0 +dev/beta1/beta2/rc1
Category: language features
Has duplicate: #7477 #7529
Monitored by: @gasche @hcarty @Chris00
It'd be useful to have 'let open' available in class expressions:
class c =
let open M in
object ... end
The text was updated successfully, but these errors were encountered: