-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implicits as constructor arguments #48
Comments
I agree this would be a good idea. Syntactically, what about:
|
Yes, that works. As a pleasant side effect, this also introduces a way to bind existential type variables in patterns, if you don't mind passing the types explictly during construction: module type T = sig type t end
type t = T: {X:T} -> {Y:T} -> X.t * Y.t -> t
let f (T{X}{Y}(x, y)) =
(* X.t and Y.t available as names for the types of x and y *)
...
f (T{Int}{String}(3, "four")) Can implicit constructor arguments without value components be optimized away so that they don't have a runtime representation? |
I'm not sure, but probably not. If you made the module type abstract then some users of the type would not be aware that the module contains only types. |
It'd be convenient to have implicits as constructor arguments so that we could write
It's currently possible to achieve something similar with first-class modules in a few cases:
but this technique doesn't work for higher-kinded examples, besides being rather cumbersome.
The text was updated successfully, but these errors were encountered: