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: 5072 Reporter: letouzey Assigned to:@alainfrisch Status: resolved (set by @alainfrisch on 2016-12-08T10:55:04Z) Resolution: duplicate Priority: normal Severity: feature Category: typing Duplicate of:#6655 Monitored by:@whitequark dsheets @ygrek@Chris00
Bug description
Hi
As said in the documentation of the core library:
[
The following built-in types and predefined exceptions are always defined in
the compilation environment, but are not part of any module. As a consequence,
they can only be referred by their short names
]
Well, there are rare situations where it would be handy to have
absolute names for int, bool, char, etc, but indeed Pervasives.int isn't
working. Truly, any user can create its own long name for int thanks to
something like
module MyPervasives = struct
type int' = int
type int = int'
end
But it would be nice to have something like that by default.
(By the way, as illustrated above, it's really painful to have only
a type declaration syntax which is recursive, even for type abbreviation).
Maybe this disambiguation need is really specific to my own parish, which is
ocaml code generation from a system where users may have their own naming
conventions and expect nonetheless the obtained code to interact nicely with
ocaml's stdlib. But placing int and others inside Pervasives would probably
also allow to have nicer error message when a beginnner redefines int by
mistake: "foo has type int but is expected to have type Pervasives.int"
is nicer than the same message without Pervasives ...
Best regards,
Pierre Letouzey
The text was updated successfully, but these errors were encountered:
This is a actually a problem for the ocaml compiler developers too...
The reason these types are not in Pervarsives is that they are used internally by the compiler, and they need to be defined before reading Pervasives.
An alternative solution would be to put them in another module, named Builtin for instance, but then we still have the risk of somebody defining a module with the same name.
If somebody has a good solution for this problem, I am interested.
We could just give them a longer name in the compiler (e.g. builtin_int) and then rebind the name with an alias in Pervasives:
type int = builtin_int
We could also take this further by allowing a syntax for "external" types analoguous to how externel definitions are used to bind compiler primitives. For example:
Original bug ID: 5072
Reporter: letouzey
Assigned to: @alainfrisch
Status: resolved (set by @alainfrisch on 2016-12-08T10:55:04Z)
Resolution: duplicate
Priority: normal
Severity: feature
Category: typing
Duplicate of: #6655
Monitored by: @whitequark dsheets @ygrek @Chris00
Bug description
Hi
As said in the documentation of the core library:
[
The following built-in types and predefined exceptions are always defined in
the compilation environment, but are not part of any module. As a consequence,
they can only be referred by their short names
]
Well, there are rare situations where it would be handy to have
absolute names for int, bool, char, etc, but indeed Pervasives.int isn't
working. Truly, any user can create its own long name for int thanks to
something like
module MyPervasives = struct
type int' = int
type int = int'
end
But it would be nice to have something like that by default.
(By the way, as illustrated above, it's really painful to have only
a type declaration syntax which is recursive, even for type abbreviation).
Maybe this disambiguation need is really specific to my own parish, which is
ocaml code generation from a system where users may have their own naming
conventions and expect nonetheless the obtained code to interact nicely with
ocaml's stdlib. But placing int and others inside Pervasives would probably
also allow to have nicer error message when a beginnner redefines int by
mistake: "foo has type int but is expected to have type Pervasives.int"
is nicer than the same message without Pervasives ...
Best regards,
Pierre Letouzey
The text was updated successfully, but these errors were encountered: