eureton has quit [Quit: Simple IRC: The quit option.]
ollehar has joined #ocaml
artart78 has quit [Ping timeout: 260 seconds]
yomimono has quit [Ping timeout: 265 seconds]
yomimono has joined #ocaml
amiloradovsky has quit [Ping timeout: 244 seconds]
yomimono has quit [Ping timeout: 244 seconds]
yomimono has joined #ocaml
kleisli_ has quit [Remote host closed the connection]
kleisli_ has joined #ocaml
_whitelogger has joined #ocaml
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ransom has joined #ocaml
yomimono has quit [Ping timeout: 256 seconds]
yomimono has joined #ocaml
borne has quit [Ping timeout: 244 seconds]
mfp has quit [Ping timeout: 244 seconds]
delysin has joined #ocaml
reynir has quit [Ping timeout: 244 seconds]
reynir has joined #ocaml
Guest86335 has quit [Ping timeout: 240 seconds]
yomimono has quit [Ping timeout: 240 seconds]
Guest86335 has joined #ocaml
yomimono has joined #ocaml
_whitelogger has joined #ocaml
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
waleee-cl has quit [Quit: Connection closed for inactivity]
osa1 has joined #ocaml
narimiran has joined #ocaml
snowpanda has quit [Quit: Leaving...]
reynir1 has joined #ocaml
reynir has quit [Ping timeout: 240 seconds]
reynir1 is now known as reynir
Serpent7776 has joined #ocaml
osa1 has quit [Ping timeout: 240 seconds]
andreas303 has joined #ocaml
artart78 has joined #ocaml
kleisli__ has joined #ocaml
kleisli_ has quit [Ping timeout: 240 seconds]
mbuf has joined #ocaml
mcc has quit [Quit: Connection closed for inactivity]
Johann has quit [Remote host closed the connection]
Haudegen has joined #ocaml
ransom has joined #ocaml
yomimono has quit [Ping timeout: 240 seconds]
yomimono has joined #ocaml
osa1 has joined #ocaml
borne has joined #ocaml
bartholin has quit [Quit: Leaving]
gahr_ is now known as gahr
sgnb` has quit [Remote host closed the connection]
olle has joined #ocaml
yomimono has quit [Ping timeout: 264 seconds]
yomimono has joined #ocaml
mbuf has quit [Quit: Leaving]
ggole has joined #ocaml
* olle
mooo
SoF has quit [Quit: Ping timeout (120 seconds)]
SoF has joined #ocaml
chewbranca has quit [Ping timeout: 244 seconds]
chewbranca has joined #ocaml
yomimono has quit [Ping timeout: 260 seconds]
yomimono has joined #ocaml
mfp has joined #ocaml
jbrown has quit [Ping timeout: 244 seconds]
yomimono has quit [Ping timeout: 260 seconds]
yomimono has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
<Putonlalla>
How can you use Dune build code generated by Thrift? I can't find any mechanism in the documentation to generate the necessary rules.
mbuf has joined #ocaml
sarna has joined #ocaml
<mbuf>
After '#require "ocaml-compiler-libs.common"' in utop, using 'Btype.hash_variant "Foo"' throws "Error: Reference to undefined global 'Btype'". Why? Using dune.2.7.1 and OCaml version 4.10.0
sarna has quit [Client Quit]
yomimono has quit [Ping timeout: 256 seconds]
<def>
mbuf: use utop-full
yomimono has joined #ocaml
<mbuf>
def, thanks! that works!
Johann has joined #ocaml
aaaaaa has joined #ocaml
Haudegen has joined #ocaml
malc_ has joined #ocaml
mbuf has quit [Quit: Leaving]
waleee-cl has joined #ocaml
kleisli__ has quit [Ping timeout: 260 seconds]
Guest86335 has quit [Ping timeout: 240 seconds]
Guest86335 has joined #ocaml
yomimono has quit [Ping timeout: 256 seconds]
yomimono has joined #ocaml
vicfred has joined #ocaml
osa1 has quit [Ping timeout: 244 seconds]
Tuplanolla has joined #ocaml
dckc has quit [Ping timeout: 260 seconds]
dckc has joined #ocaml
<olle>
Going back to the module vs file/folder discussion, what if I want to separate data from behaviour in OCaml?
<olle>
Wait
<olle>
It's the exact same question.
<olle>
Sometimes I feel like type theory forgets macro architecture.
andreas303 has quit [Ping timeout: 240 seconds]
aaaaaa has quit [Quit: leaving]
malc_ has quit [Ping timeout: 244 seconds]
<companion_cube>
data is types, behavior is functions
<companion_cube>
you're welcome
<olle>
companion_cube: yeah, but usually we mix them in the same file. I was thinking maybe to split it, but then we end up in same discussion on how to split a module.
<d_bot>
<Et7f3> we aren't in oop 👀
<olle>
et, oh, you admit that OOP is better with regard to macro architecture? ;D
<olle>
OOP never spit behaviour and data, btw, that's the whole point.
andreas303 has joined #ocaml
<d_bot>
<Et7f3> I think SmthFactory SmthSerializer where each behaviour of your type go in his in own file and you get 15 files for say ocaml list
<olle>
OOP usually has generics
<olle>
Serializer<T>
<companion_cube>
olle: ell sometimes you need behavior to be associated with data? like, private types?
<olle>
companion_cube: exactly!
<olle>
that's were "folder privacy" comes in.
<Drup>
OOP definitely regularly splits behavior and data, or even a given behavior into lot's of tiny pieces. especially when inheritance come into play
<Drup>
maybe your idealize OOP doesn't, but that's not the general rule
<olle>
Sure, it depends on *which* behaviour.
<Drup>
(you just have to write a visitor pattern in Java to realize that)
<Drup>
In any case, I guess you are complaining about the lack of mutual recursion accross modules in different files ?
<companion_cube>
there's no pure OOP, just like there's no pure FP, in practice
<olle>
Drup: No, more like missing "crate privacy" as in Rust, where you can split impl into multiple files while keeping struct private fields.
<companion_cube>
maybe snalltalk was it, but the other languages are not pure OOP
<Drup>
smalltalk is so OOP that every other OOP language promptly decided to have a completely different notion of object, and forget about the whole thing :D
<companion_cube>
well, there's objective-C and oberon in the same style, a bit
bartholin has joined #ocaml
<Drup>
olle: ah, library level abstractions
<theblatte>
olle: pretty sure you can do that in OCaml+dune
<Drup>
you can write your code to make it work, but it's a bit annoying
<companion_cube>
olle: rust has per-crate compilation, OCaml has per-file compiolation, more or less
<companion_cube>
dune doesn't make it possible to have cyclic dependencies
<companion_cube>
at least the .cmi have to be toplogically sorted
<Drup>
companion_cube: it's not about cyclicity, he wants the signature around the library, so that type defs are exposed underneath
<theblatte>
I'm talking about having some modules/types be internal to your library, not cyclic dependencies
<Drup>
you can do it, by writing a single .mli for you whole library and no other. It also works with dune
<Drup>
bunzli does that often, actually
<Drup>
I'm not terribly fond of the style, but it has its uses
<companion_cube>
Drup: the kind of thing you can do in rust, imho, is not possible in OCaml (bar the one signature file, of course)
<Drup>
it's a bit all-or-nothing, unfortunately
<companion_cube>
(sorry I have like 15s lag)
<olle>
bunzli?
<companion_cube>
what you cannot do in OCaml, at all, is to have mutually recursive types *declared* in different files, including the ability of making them private or private aliases; that goes with OCaml doing scoping in file order instead of unordered
<companion_cube>
ain't no fix for that :p
<Drup>
It's a valid problem tho. they have a way to partially brake abstraction in F* to go around that, I should look into it at some point
<olle>
Drup: C# also has partial classes.
<Drup>
olle: yeah but it's very easy to do in OOP, even OCaml has it. it's much harder for modules
<olle>
The #haskell channel said they could hack it by doing submodules with no privacy, or something.
<olle>
Drup: Easy in OOP? How?
<olle>
companion_cube: are you in the forest? :D 15s lag.
<companion_cube>
no privacy is a bit of a deal breaker
<companion_cube>
olle: no, my VPS had some weird load, it's better now
<olle>
kk
<Drup>
in OCaml ? private fields are exposed to inherited classes, done.
<olle>
Drup: Inheritance doesn't work, it's cutting the wrong way.
<Drup>
(or did you forgot that OCaml had classes ? :3)
<olle>
Imagine you want to add two or more toString() methods.
<olle>
It needs to be interfaces, but then you have to put everything in one file.
<companion_cube>
Drup: OCaml has classes, but no core type is an object :D
<Drup>
that's another debate, you just ask for partial breaking of abstraction, ocaml's classes support it just fine, and it's a feature that is generally not-so-hard to add in OOP
<companion_cube>
so it's kind of … meh
<olle>
Drup: Noooo, it's the same debate. :(
<Drup>
it's much harder to add in modules
<companion_cube>
it's just a different world of values that has no intersection with the stdlib or 90% of the ecosystem
waleee-cl has quit [Quit: Connection closed for inactivity]
narimiran has quit [Ping timeout: 264 seconds]
reynir has quit [Ping timeout: 256 seconds]
reynir has joined #ocaml
<olle>
I'd argue no OOP system supports it properly.
mfp has quit [Ping timeout: 265 seconds]
<companion_cube>
no statically typed OOP, maybe?
<olle>
companion_cube: It's always private, protected or public properties, never "folder private" or "module private". :|
<olle>
And interface implementation always goes in the same file.
mfp has joined #ocaml
<olle>
I'm thinking that using composition instead of inheritance breaks encapsulation.
<companion_cube>
rust definitely has these :p
<olle>
Rust yes :)
<companion_cube>
java has package private iirc
<olle>
I'd like to see an example on how they hack it in Haskell... Gonna ask them.
<Drup>
the same way as in OCaml
<Drup>
exactly what I described above
<olle>
Drup: Dune...?
<Drup>
the single .mli trick I explained above.
<olle>
Drup: Is there a link? Or can I find it by searching dune and lib api mli?
<Drup>
not really, it's folklore
<olle>
^^
<Drup>
but if you use dune, it's literally, "write a,b,c.ml with no .mli, and only write one big .mli with submodules A B and C"
<Drup>
one big lib.mli*
<companion_cube>
(foo.mli if your library is called foo)
remexre has joined #ocaml
<olle>
Drup: So A could access abstract types from B?
<Drup>
there is no abstract type in A, since there is no .mli
<companion_cube>
they're only made abstract in the foo.mli
<Drup>
the only types that are abstract are in Foo.A, which is guarded by foo.mli
<olle>
Got it
<olle>
Yeah, that's cool :)
<Drup>
(you don't need dune to do it, it's only submodules and stuff)
<olle>
Drup: Well, I also want to prevent client code to ever access anything in A
<Drup>
yeah, you just remove A from foo.mli
<olle>
OK
spew has joined #ocaml
<d_bot>
<Et7f3> can we use module type of ? to generate the foo.mli ?
<d_bot>
<Et7f3> maybe dune-print-intf could help here
reynir1 has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
reynir2 has joined #ocaml
reynir has quit [Ping timeout: 246 seconds]
reynir2 is now known as reynir
reynir1 has quit [Ping timeout: 256 seconds]
olle has quit [Ping timeout: 240 seconds]
andreas303 has quit [Remote host closed the connection]
andreas303 has joined #ocaml
malc_ has joined #ocaml
yomimono has quit [Ping timeout: 256 seconds]
<inkbottle>
Based on "Functional Pearls: Monadic Parsing in Haskell", Graham Hutton and Erik Meijer, Journal of Functional Programming.