| Anonymous | Login | Signup for a new account | 2013-05-24 07:56 CEST |  |
| Main | My View | View Issues | Change Log | Roadmap |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||
| 0005905 | OCaml | OCaml typing | public | 2013-01-24 09:46 | 2013-05-21 15:17 | ||||||
| Reporter | garrigue | ||||||||||
| Assigned To | |||||||||||
| Priority | normal | Severity | feature | Reproducibility | always | ||||||
| Status | new | Resolution | open | ||||||||
| Platform | OS | OS Version | |||||||||
| Product Version | 4.01.0+dev | ||||||||||
| Target Version | Fixed in Version | ||||||||||
| Summary | 0005905: Allow to define explicit "impure" (i.e. generative) functors | ||||||||||
| Description | For some applications, not having the possibility to declare a functor as generative is a problem. For instance when you define a global map through a functor module DB : functor (X : struct end) -> sig type key let new_key : unit -> key let write : key -> string -> unit let read : key -> string end module MyDB = DB(struct end) The above works fine (i.e. keys are restricted to a single DB) as long as nobody writes the following code: module DB1 = DB(String) module DB2 = DB(String) which makes DB1.key and DB2.key equal. The problem is that to my best knowledge there is no workaround. My proposal is a rather stupid one: add some syntax for impure functors, that are not using their argument, but must be generative. module DB () = ... module DB = functor () -> ... module M = DB () module DB : functor () -> ... Simplest implementation: all this is just syntactic sugar for an argument of name "*" and of type "sig end", and forcing the functor application to be generative in that case. Patch included. | ||||||||||
| Tags | No tags attached. | ||||||||||
| Attached Files | |||||||||||
 Relationships |
|
 Relationships |
|
Notes |
|
|
(0008791) frisch (developer) 2013-01-24 10:21 |
I agree it would be very nice to have generative functors in addition to transparent ones. But why should this notion require a "dummy" argument? It is quite common to have functors taking a non-trivial argument, which should be generative (typical example: a hash-consing functor). I'd rather have a different kind of functors (unfortunately, this requires more innovation on the syntactic side than your proposal). Also, generative functors enable something very useful: unpacking of first-class modules within/as the functor body. This can be used, for instance, to choose at runtime between two implementations of the functor, based on some condition. With runtime types (or a manual version based on GADTs), it is even possible to customize the functor's behavior according to the structure of the abstract types in the argument (example: implement sets as Patricia trees if the elements are integers). Would your proposal make this possible for generator functors? |
|
(0008795) garrigue (manager) 2013-01-25 03:25 |
The idea of using a "dummy" argument is that it requires no new syntax (or very little). And it is just as expressive: you just have to add () as last argument to make your functor generative. The discussion should rather be: since generativeness is a property of functors, is it useful to mark it in functor applications. I believe that this is the case, as this is the application, not the functor, that behaves differently. I have also updated the patch so that it is now possible to unpack first class modules inside impure functors: module type S = sig val x : int end;; let v = (module struct let x = 3 end : S);; module F() = (val v);; |
|
(0008798) garrigue (manager) 2013-01-25 12:15 |
Fixed the patch: if we are to allow unpacking inside impure functors, then we should not allow applying them inside an applicative body... |
|
(0008816) garrigue (manager) 2013-01-31 08:04 |
Fixed the patch again: one cannot coerce an impure functor into an applicative one. The patch is in trunk/experimental/garrigue/impure-functors.diff |
|
(0009314) frisch (developer) 2013-05-21 15:17 |
FWIW, I believe that extending the language with generative functors would indeed be very useful, especially if it allows to unpack first-class modules in their body. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2013-01-24 09:46 | garrigue | New Issue | |
| 2013-01-24 09:46 | garrigue | File Added: impure-functors.diff | |
| 2013-01-24 10:21 | frisch | Note Added: 0008791 | |
| 2013-01-25 03:12 | garrigue | File Deleted: impure-functors.diff | |
| 2013-01-25 03:12 | garrigue | File Added: impure-functors.diff | |
| 2013-01-25 03:25 | garrigue | Note Added: 0008795 | |
| 2013-01-25 12:10 | garrigue | File Deleted: impure-functors.diff | |
| 2013-01-25 12:10 | garrigue | File Added: impure-functors.diff | |
| 2013-01-25 12:15 | garrigue | Note Added: 0008798 | |
| 2013-01-31 08:02 | garrigue | File Deleted: impure-functors.diff | |
| 2013-01-31 08:04 | garrigue | Note Added: 0008816 | |
| 2013-05-21 15:17 | frisch | Note Added: 0009314 | |
|
Issue History |
| Copyright © 2000 - 2011 MantisBT Group |
 |