<Leonidas>
I must be missing something. I can of course expose everything from R in Apply like val return = R.return but I would prefer not to pollute the entire module with the R module contents
<Leonidas>
I'm getting "Error: This expression has type unit Applied.R.t but an expression was expected of type unit Applied.t"
xgqt has quit [Quit: WeeChat 3.8]
wingsorc has quit [Ping timeout: 240 seconds]
alexherbo2 has joined #ocaml
Anarchos has joined #ocaml
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<discocaml>
<Kali> change `module R : Runner` to `module R : Runner with type 'a t = 'a t` and module Unit : Runner` to `module Unit : Runner with type 'a t = unit`
<discocaml>
<Kali> change `module R : Runner` to `module R : Runner with type 'a t = 'a t` and `module Unit : Runner` to `module Unit : Runner with type 'a t = unit`
<discocaml>
<Kali> this is necessary because the signature uses the abstract type `'a t`, the definition of which is obscured outside the module
<discocaml>
<Kali> adding those annotations allows knowledge of equality outside of the module
<discocaml>
<Kali> which then allows it to typecheck
xd1le has quit [Quit: xd1le]
alexherbo2 has quit [Remote host closed the connection]
<octachron>
Leonidas, as a general rule, you should avoid storing arguments of functor inside the body of the functor to avoid losing type and module equations.
Haudegen has quit [Quit: Bin weg.]
kakadu has quit [Quit: Konversation terminated!]
trillion_exabyte has quit [Ping timeout: 240 seconds]
Haudegen has joined #ocaml
trillion_exabyte has joined #ocaml
darchitect1 has joined #ocaml
<darchitect1>
hey guys
<darchitect1>
is this chat active usually ?
<darchitect1>
(during Greenwich time)
<Leonidas>
octachron: The reason I do this is because I use the functor argument in other modules using the applied/generated functor and want to retain access to the base operators (map/bind/return etc). I'd gladly change the design to something smarter because I do feel like the whole API is a bit of a mess but don't really know how to make it nicer
<Leonidas>
darchitect1: Yes.
<Leonidas>
But more in Paris time :P
<octachron>
Extension functors (that only adds functions or types) often work better (in the absence of transparent module ascription) since you keep explicitly the link between the extended modules and the original ones.
darchitect1 has quit [Ping timeout: 265 seconds]
<Leonidas>
octachron: What are extension functors? You mean a functor that uses `include` on its argument?
<Leonidas>
This could be a nicer API
<octachron>
Rather functors that only define new functions or types, and let the user of the functor which has more information at end compose the final module.
<octachron>
The issue is that inside the functor, you only have a limited view of the functor arguments.
<octachron>
And you often don't want to capture this limited view.
<Leonidas>
Kali: thanks. Seems like it was enough to add that to module R, if I attempt to substitute the type in `module Unit : Runner` it seems to be a syntax error
<Leonidas>
octachron: how would the user compose the final module?
<octachron>
`module Final = struct include R include Add_more(R) end`
<octachron>
And yet another incomplete type representation
darchitect1 has quit [Ping timeout: 264 seconds]
<companion_cube>
is it bad to be incomplete? :)
<companion_cube>
after all, most ppxes are extremely incomplete too
<octachron>
For a solution which is sold as a panacea, incompleteness is a bad sign. But well, experimenting is fun at least when people are not eager to integrate a doomed experience into the stdlib.
<adrien>
and isn't the incompleteness of all other attempts the reason they didn't succeed?
<octachron>
My personal feeling is more that none of those attempt worked well and thus it made no sense to try to reach completeness.
<octachron>
(and good type system coverage like the one in `refl` is very expensive in term of complexity budget)
Serpent7776 has quit [Read error: Connection reset by peer]
Serpent7776 has joined #ocaml
<companion_cube>
my main worry would be runtime perf overhead
<companion_cube>
but I wish we had *something*
<companion_cube>
instead of handwaving and saying that stuff like serialization is niche, which is… really shortsighted
<octachron>
Last I heard, performance was the reason janestreet did not commit to using `ppx_typerep_conv`
<octachron>
Was there anyone that ever said that serialization is niche?
<companion_cube>
yeah, gasche :p
<companion_cube>
(let me check before I slander him tho)
<companion_cube>
oh actually it's you, my bad. "very precise use cases" is the actual wording.
<companion_cube>
"they don't really seem useful in general" I mean serialization is useful in general, it's not a precise use case
darchitect1 has joined #ocaml
pie_ has quit []
<octachron>
I was speaking of type representation. And I still claim that there are a bad solution to the problem at hand.
pie_ has joined #ocaml
<octachron>
(And I was thinking of serializing the type representation in order to have a potentially safe versionned serialization solution in ... some very precise use cases).
darchitect1 has quit [Ping timeout: 265 seconds]
<companion_cube>
hu, that was really not clear.
<octachron>
Yeah, the rest of the discussion made quite clear that my phrasing was very confusing.