|Anonymous | Login | Signup for a new account||2013-05-19 11:47 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005905||OCaml||OCaml typing||public||2013-01-24 09:46||2013-01-31 08:04|
|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
let new_key : unit -> key
let write : key -> string -> unit
let read : key -> string
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.
|Tags||No tags attached.|
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?
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);;
|Fixed the patch: if we are to allow unpacking inside impure functors, then we should not allow applying them inside an applicative body...|
Fixed the patch again: one cannot coerce an impure functor into an applicative one.
The patch is in trunk/experimental/garrigue/impure-functors.diff
|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|
|Copyright © 2000 - 2011 MantisBT Group|