You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 7140 Reporter:@Drup Status: feedback (set by @damiendoligez on 2016-02-25T13:47:04Z) Resolution: open Priority: normal Severity: feature Target version: later Category: typing Monitored by:@Drup@diml@yallop@hcarty
Bug description
Currently, the various form of open only accept a longident ("Foo.Bar"). Even longident-with-application ("Foo(Bar).Baz") is refused by parsing.
This means that locally opening a functor application or an unpacked module is a bit verbose (let module M = ... in let open M in ).
Could it be possible to have a module expression there ? At the very least as a shortcut for what I wrote earlier.
I realize there is going to be a grammar issue with the short syntax for local open, but keeping the short local open restricted feels ok to me.
The text was updated successfully, but these errors were encountered:
There are four kinds of module expression which are not allowed in open, and
each with good reason:
struct ... end does not work because it's components don't have valid
paths. A module must have a name before you can refer to its components.
(Foo : S) does not work for similar reasons. : is an opaque ascription
operator -- (Foo : S).t does not equal Foo.t -- so its components are
unnamed. It can't just be treated as transparent ascription in open
statements because the inner modules would also need to be transparently
ascribed. In the future, there will probably be a proper transparent
ascription operator (:>?) which can be used in both opens and module
aliases.
Foo(Bar) would have two possible meanings:
Execute Foo(Bar) and open the resulting module.
Make the type-level components of Foo(Bar) avaiable in the current scope.
The first option involves performing side effects during open, whereas open should be purely a compile-time operation on scopes. This is similar
to why Foo(Bar).t is a valid path but Foo(Bar).v is not (t for type, v
for value). It would also perpetuate the incorrect assumption of many OCaml
beginners: that functors are compile-time magic and there is only one Foo(Bar) module.
The second option is semantically fine, but would probably cause confusion as
people might expect the value components to also be in scope.
functor (..) -> ... cannot be used to create a structure without
application.
Original bug ID: 7140
Reporter: @Drup
Status: feedback (set by @damiendoligez on 2016-02-25T13:47:04Z)
Resolution: open
Priority: normal
Severity: feature
Target version: later
Category: typing
Monitored by: @Drup @diml @yallop @hcarty
Bug description
Currently, the various form of open only accept a longident ("Foo.Bar"). Even longident-with-application ("Foo(Bar).Baz") is refused by parsing.
This means that locally opening a functor application or an unpacked module is a bit verbose (let module M = ... in let open M in ).
Could it be possible to have a module expression there ? At the very least as a shortcut for what I wrote earlier.
I realize there is going to be a grammar issue with the short syntax for local open, but keeping the short local open restricted feels ok to me.
The text was updated successfully, but these errors were encountered: