<sleepydog>
i am a bit closer to my `fPIC` issue; it looks like dune's (ctypes ...) stanza does not compile cstubs with `-fPIC`, when using the default pkg-config build_resolver
<rgrinberg>
that seems wrong, especially if ocamlc -config uses fPIC
<sleepydog>
my ocamlc config includes -fPIC
<sleepydog>
i've patched dune to expose the `errno_policy` parameter for cstubs, so i'm just checking to see if my patch caused it now
Tuplanolla has quit [Quit: Leaving.]
<sleepydog>
yea, without my patch, dune 3.2 doesn't include -fPIC when building the `*_generated_functions_*.o` file. I'll poke around to make sure i'm not doing something stupid and come up with a reproducer
<sleepydog>
i can work around it with a vendored build_resolver for now, too
vicfred has quit [Quit: Leaving]
gentauro has quit [Read error: Connection reset by peer]
gentauro has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot>
<mbacarella> what is the purpose of `Stream`? is it doing something much fancier than it implies?
raskol has quit [Ping timeout: 258 seconds]
<companion_cube>
it's old, it was mostly used for some particular sorts of parsers
raskol has joined #ocaml
waleee has quit [Ping timeout: 255 seconds]
olle has joined #ocaml
rgrinberg has joined #ocaml
raskol has quit [Ping timeout: 246 seconds]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
olle has quit [Ping timeout: 256 seconds]
mbuf has joined #ocaml
rgrinberg has joined #ocaml
gravicappa has joined #ocaml
raskol has joined #ocaml
Haudegen has joined #ocaml
<d_bot>
<mbacarella> oy. re: the ctypes thing above, why not always use -fPIC? surprised it's an option you have to turn on
<d_bot>
<mbacarella> i suppose if you're doing OS kernels/modules you don't want PIC maybe
raskol has quit [Ping timeout: 255 seconds]
zebrag has quit [Quit: Konversation terminated!]
bobo_ has joined #ocaml
spip has quit [Ping timeout: 240 seconds]
tomku has quit [Read error: Connection reset by peer]
raskol has joined #ocaml
tomku has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mro has joined #ocaml
raskol has quit [Ping timeout: 276 seconds]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<d_bot>
<mk-fg> Steam might be a good standard abstraction for iterators, which are fairly common
<Corbin>
*Stream?
<d_bot>
<mk-fg> Yes :)
olle has joined #ocaml
olle has quit [Ping timeout: 260 seconds]
sheb has quit [Quit: Leaving]
bartholin has joined #ocaml
mbuf has quit [Quit: Leaving]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<d_bot>
<octachron> No, `Stream` is deprecated for iterators. `Seq` should be used for that purpose.
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot>
<Bluddy> hmm.. I guess package is an opam concept, right? dune doesn't really care
<d_bot>
<Bluddy> it's just a library and executable soup from dune's perspective
<d_bot>
<Bluddy> (for the most part)
Tuplanolla has joined #ocaml
<d_bot>
<darrenldl> havent figured out how to implement an external package virtual lib hmmm
<d_bot>
<darrenldl> companion_cube: you have experience with that?
<d_bot>
<darrenldl> (very tempted to just expose a api for changing a data source backend directly...
<companion_cube>
opam packages are only an opam concept, the real deal is ocamlfind libraries (and dune libraries, where each library is an ocamlfind (sub)library)
<companion_cube>
otoh from another project, idk how you'd tell dune about the virtual library
<d_bot>
<darrenldl> yeah...im just gonna cheese it i think, just means an extra step for js users
<companion_cube>
I don't have experience with that @darrenldl, I tried these virtual libraries a bit and then removed them
<companion_cube>
it's a bit too magical
<d_bot>
<darrenldl> : D
<companion_cube>
like you say, I tend to use a kind of backend in a ref or something like that
<d_bot>
<darrenldl> very fair statement : v
<companion_cube>
(like a first-class module in a ref)
<d_bot>
<darrenldl> yeah, maybe should have just started with that hmmm
<d_bot>
<darrenldl> oh well, it works nicely when it works
<d_bot>
<anmonteiro> and I've got a private implementation that prints `.rei` too.
<d_bot>
<anmonteiro> happy to open source if people would want it
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<d_bot>
<rgrinberg> i think you want @@import annotations instead
bartholin has quit [Quit: Leaving]
<d_bot>
<Bluddy> why? I want to control what's exported from a module (what's public vs private)
<sleepydog>
mbacarella: thank you for replying to my issue so quickly! I will test your PR tonight :)
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<d_bot>
<rgrinberg> I know that's what you want, but I think that @@export is a lot more complicated to implement and basically has the same benefits
<d_bot>
<rgrinberg> Realistically, the main goal is to reduce duplicate between ml and mli, right?
<d_bot>
<Bluddy> mmm... I want the benefits of public/private control without having to a. synchronize files b. spell out the types.
<d_bot>
<Bluddy> ocaml has all this design to make sure we don't need to write types. it's such a guiding principle, unlike haskell and rust
<d_bot>
<Bluddy> and then we need to write all the types for our interfaces
<sleepydog>
sometimes i feel like i'm the only one who *likes* writing the type annotations :\. It's useful documentation
<d_bot>
<Bluddy> haskell and rust force you to do it at the function level
<d_bot>
<Bluddy> ocaml deliberately doesn't
<d_bot>
<Bluddy> and avoids types that cannot be inferred
raskol has quit [Ping timeout: 272 seconds]
<d_bot>
<rgrinberg> I wonder if ppx_import can be modified to allow you to import types from the inferred mli
<d_bot>
<rgrinberg> into the real mli
<companion_cube>
.mli are more flexible than anything rust or Haskell have, though
<companion_cube>
it's more laborious but you do get a lot of control
<companion_cube>
(e.g. private aliases)
<d_bot>
<orbitz> I used to dislike them, felt like extra work. But they really are fantastic
<d_bot>
<rgrinberg> @Bluddy but you know, there's the usual hack:
<d_bot>
<rgrinberg> ```
<d_bot>
<rgrinberg> open struct
<d_bot>
<rgrinberg> let i'm_private = ..
<d_bot>
<rgrinberg> end
<d_bot>
<rgrinberg> ```
<d_bot>
<rgrinberg> That i'm sure you all know
<d_bot>
<rgrinberg> maybe a little ppx to make this more beautiful would suffice
<d_bot>
<Bluddy> I forgot about this one too. we really need to list these
<sleepydog>
some kind of module cookbook
<companion_cube>
rgrinberg: yeah this one is nice
<companion_cube>
esp. to define local types, imho
<d_bot>
<rgrinberg> Tbh, I like writing mli files. What I would like is to refer to a compilation unit's own mli as a module type
<d_bot>
<rgrinberg> I mostly really hate having to duplicate `module type S = sig .. end` in .ml and .mli files
<d_bot>
<rgrinberg> that gets tedious quickly
<sleepydog>
that would be nice.
<d_bot>
<Bluddy> duplicating large types is a pain. but I guess ppx_import takes care of that
<d_bot>
<Bluddy> and yeah that would be nice @rgrinberg
<d_bot>
<rgrinberg> except that it doesn't let you import from your own compilation unit's cmi 😦
<d_bot>
<geoff> I'll often paste the signatures that the lsp gives for the functions I want to expose into an mli. If I don't have an mli yet, then I start with the to intf generator tool
<d_bot>
<Bluddy> see but that's wasted effort. you just wanted to make the function public
<d_bot>
<Bluddy> I mean it's fine for projects that have really settled down
<companion_cube>
rgrinberg: I use the _intf file trick for that
<d_bot>
<Bluddy> but I don't like it while I'm writing code
<companion_cube>
ugly, but it can be worth it
<d_bot>
<geoff> Well I'll go on to write a docs' comment for it as well
mro has quit [Quit: Leaving...]
<d_bot>
<geoff> If there is still a lot of churn then I don't make the mli yet
<d_bot>
<Bluddy> and then you lose the ability to designate public and private members (unless you use @rgrinberg's trick)
<d_bot>
<geoff> Why does it matter if it is private if you're still writing it though
<d_bot>
<rgrinberg> i use _intf modules as well, but it's annoying toggling .ml and .mli is now broken
<d_bot>
<geoff> Just don't use it outside the file
<d_bot>
<Bluddy> still writing is a relative thing... I don't want to accidentally reach into something I shouldn't have
<d_bot>
<Bluddy> or collaborating
<d_bot>
<Bluddy> there's a reason those concepts exist
<companion_cube>
I tend to name private things with _ (prefix or suffix, depends on which year :D)
<d_bot>
<Bluddy> yeah I've seen that in your code
<d_bot>
<Bluddy> it's the python way
<companion_cube>
`let _foo = …` is probably better because it doesn't even appear in utop
<companion_cube>
it's also convenient when you read the .ml
<companion_cube>
you know what's a local impl detail
<d_bot>
<Bluddy> true
<d_bot>
<geoff> Makes sense
<d_bot>
<Bluddy> but I feel like underscores everywhere would be painful
<d_bot>
<Bluddy> maybe I'll adopt it
<d_bot>
<Bluddy> even in python I tend to not do it
<d_bot>
<rgrinberg> without mli's there's no good incremental compilation, so it's really an option only for tiny projects
<d_bot>
<Bluddy> why? isnt' the cmi produced anyway?
<d_bot>
<rgrinberg> it's produced, but now every time you modify your underscored bindings, all users of the modules will be recompiled
<d_bot>
<Bluddy> oh I see
<companion_cube>
even if the produced .cmi is the same?
<companion_cube>
I mean, if the signature didn't change?
<d_bot>
<geoff> Anyway I don't think it's wasted effort to throw vals into an mli with a binding in emacs
<d_bot>
<rgrinberg> if the signature doesn't change, it should work.
<d_bot>
<orbitz> No need to be overly strict though, if things are changing quickly.
<companion_cube>
good. I do have large .ml whose signature changes rarely in practice
<companion_cube>
(because they have signature-constrainted sub-modules)
<d_bot>
<geoff> I used to have something that did a simplistic version of that but I don't k ow where it went and I haven't rewrote so I just paste right now. Something that checks if a def already exists and replaces it would be nice
<d_bot>
<Bluddy> the mli files are a part of the language that feels antiquated. from the C/C++ era where it made sense to duplicate information
<d_bot>
<rgrinberg> nah, they're the reason why we have effective separate compilation
<companion_cube>
it's also tied to ML modules, LCF provers, etc.
<companion_cube>
you want to hide some types, hide some functions, etc. and .mli are super effective at that
<d_bot>
<orbitz> Duplication is really just restricted to module types anyways right?
<d_bot>
<Bluddy> the modern way to do it would have been to derive it from the .ml file using private/public keywords or something like that
<d_bot>
<orbitz> Ugh, I'd hate that
gravicappa has quit [Ping timeout: 255 seconds]
<d_bot>
<Bluddy> because?
<d_bot>
<geoff> I think it's nice that there isn't stuff in the way when you read the implementation
<d_bot>
<geoff> I'm looking for different information when I read mli vs ml
<d_bot>
<orbitz> Because it makes it more painful to see what the interface of a module is
<d_bot>
<orbitz> Additionally it wouldn't work when you want to apply different signatures to the same structure
<d_bot>
<Alistair> I agree, I think `.mli` files serve as a good form of documentation + allows you to specify the interface *before* actually implementing anything
<d_bot>
<rgrinberg> writing private/public optimizes for the author of the module rather than its user
<companion_cube>
@Bluddy how do you do semi-private things like private aliases?
<d_bot>
<rgrinberg> not that i'm particularly against it, but I would have little use for it
<companion_cube>
or private definitions
<d_bot>
<orbitz> The signature of a structure is distinct from a structure is very powerful
<d_bot>
<geoff> Also if you are using an abstracted type you'd then have to annotate all the functions in the ml no, instead of just inferring like normal and locking down in the mli
<d_bot>
<Bluddy> at worst, you could allow for both. private/public for within-package interfaces, mlis for library boundaries
<d_bot>
<Bluddy> maybe the issue is that mlis are very heavy for intra-library interfaces
<d_bot>
<orbitz> I'm not sure how that is more modern
raskol has joined #ocaml
<d_bot>
<Bluddy> the duplication issues are really annoying
<d_bot>
<orbitz> Not that i find modern to be a desirable adjective
<d_bot>
<Bluddy> having to synchronize changes in 2 places is unpleasant
<d_bot>
<Bluddy> 2 places per file
<d_bot>
<orbitz> It depends on the change
<d_bot>
<Bluddy> as I said, it's too heavy for an interior interface
<d_bot>
<orbitz> I personally don't find it problematic
<d_bot>
<Bluddy> similar to the way functors are heavy for what they're supposed to provide
<d_bot>
<orbitz> If anything I'd say a weak point, that your dancing around, is Ocmal does not have a concept of a library interface
<d_bot>
<orbitz> Are functors heavy? I haven't found that to be so but i also don't use them much
<d_bot>
<Bluddy> one is related to the other 😄
<d_bot>
<orbitz> Not really
<d_bot>
<orbitz> I don't use functors much because they solve a problem i have but i just can't get past the difficulty in using them, i don't use them much because I rarely have the problem they solve
<d_bot>
<Bluddy> if you were using haskell, you'd be using typeclasses without even thinking about it
<d_bot>
<Bluddy> functors solve a similar problem at a much higher syntactic cost
<d_bot>
<orbitz> And? Functors are not typeclasses
<d_bot>
<Bluddy> of course, they allow for certain things that typeclasses don't, but that's true the other way too
<d_bot>
<orbitz> I'm not sure your statement is accurate
<d_bot>
<orbitz> @Bluddy it seems to me typeclasses and functors are quite orthogonal. For example, implicit modules proposal doesn't require functors, but first class modules
raskol has quit [Ping timeout: 255 seconds]
dh` has joined #ocaml
Serpent7776 has quit [Quit: leaving]
raskol has joined #ocaml
perrierjouet has quit [Ping timeout: 244 seconds]
Haudegen has quit [Ping timeout: 240 seconds]
vicfred has joined #ocaml
perrierjouet has joined #ocaml
olle has quit [Ping timeout: 272 seconds]
raskol has quit [Ping timeout: 276 seconds]
<d_bot>
<geoff> I think there is some overlap where you can implement something once and have it work for multiple types (because they implement a typeclass). I use functors for less implicit version of that (2d and 3d versions of modules by passing in modules for 2d and 3d vectors).
<d_bot>
<geoff> Not sure what the right terminology for that would be
spip has quit [Ping timeout: 240 seconds]
spip has joined #ocaml
<d_bot>
<Lewis Campbell> is there any way to have raw C style unions in ocaml? (full disclaimer, I use sum types all the time, they're great, don't need a lecture on that. this is one small weird part of a program).
<d_bot>
<geoff> Not that *I'm* (as a non-expert) aware. Depending on why you want that, GADTs may be able to help you out
<d_bot>
<Lewis Campbell> want to do some virtual machine stuff, and need a way to represent registers/stack. a tagged representation is fine I guess, just a bit pointless since it's typechecked by that point
<d_bot>
<Lewis Campbell> `bits_of_float` and `float_of_bits` in Int64 look promising. That about covers everything
<companion_cube>
@Lewis Campbell no, there is no way
<companion_cube>
unions are kind of too unsafe for OCaml
Tuplanolla has quit [Quit: Leaving.]
<d_bot>
<Lewis Campbell> yeah it's a bit of a style clash