amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
steenuil has joined #ocaml
ggole has joined #ocaml
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
mmohammadi9812 has joined #ocaml
mxns has joined #ocaml
decentpenguin has quit [Ping timeout: 272 seconds]
mxns has quit [Ping timeout: 264 seconds]
decentpenguin has joined #ocaml
_whitelogger has joined #ocaml
mfp has joined #ocaml
_whitelogger has joined #ocaml
decentpenguin has joined #ocaml
bartholin has joined #ocaml
bartholin has quit [Quit: Leaving]
steenuil has quit [Ping timeout: 265 seconds]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
mmohammadi9812 has quit [Ping timeout: 272 seconds]
mxns has joined #ocaml
mxns has quit [Ping timeout: 240 seconds]
mmohammadi9812 has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
<Leonidas>
can someone explain me why we have opam-bin which has relocation patches and esy which has relocation patches but the compiler is still not relocatable :'(
berberman has quit [Ping timeout: 264 seconds]
berberman has joined #ocaml
<Armael>
because no one has made the work of upstreaming the patches :-(
<octachron>
or made the effort to write patches that are upstreamable rather than an ad-hoc local solution
<Armael>
right :)
jbrown has quit [Ping timeout: 272 seconds]
FreeBirdLjj has joined #ocaml
jbrown has joined #ocaml
<d_bot>
<ulrikstrid> Esy "cheats" by making the path the same length on all machines
DanC has quit [Ping timeout: 268 seconds]
Haudegen has joined #ocaml
mbuf has joined #ocaml
DanC has joined #ocaml
steenuil has joined #ocaml
steenuil has quit [Quit: Leaving]
nicoo has quit [Ping timeout: 240 seconds]
nicoo has joined #ocaml
tane has joined #ocaml
<d_bot>
<Drup> @ostera You use my frontend compiler functions 😄 How do you like them ? I'm surprised you still compile to bytecode. What's the core_erlang thingy ?
<companion_cube>
what makes the compiler non relocatable, in the end? are paths from the stdlib baked in or something?
<d_bot>
<Drup> yeah, the compiler contains the path to know where to look for by default
<companion_cube>
:/
<d_bot>
<ostera> @Drup which ones? 🙈 there's a mix of bytecom and optcomp usage that I want to standardize to optcomp -- tech debt essentially
<d_bot>
<Drup> `Compile_common`/`Compile`/`Optcompile` and all that jazz, it was all inline in two big blurb of code doing everything before
<d_bot>
<Drup> Why do you use optcomp instead of bytecomp ? Your stuff looks more ... byte-y ?
<d_bot>
<ostera> oh yes, I ended up inlining a few things to get a little more control over what's going on
<d_bot>
<ostera> there's a target for compiling erlang through optcomp 🤓
<d_bot>
<Drup> (I mean, as a base. You should be mostly independent)
<d_bot>
<Drup> In particular, I don't understand why you do so many backend steps. Why do you need to do anything past typing ?
<d_bot>
<ostera> but as far as I understand it the .cmo's would be needed to compile other modules that depend on it
<d_bot>
<Drup> also, the `read_signature` bit does not sound good
<d_bot>
<ostera> e.g, a.ml -> a.cmo
<d_bot>
<ostera> b.ml depends on a.ml, but i don't want to recompile it, so having the a.cmo around helps me skip that
<d_bot>
<Drup> > but as far as I understand it the .cmo's would be needed to compile other modules that depend on it
<d_bot>
<Drup> No, only `.cmi` are needed for typing.
<d_bot>
<Drup> `.cmo` is basically `.o`, you don't need it to compiler other files
<d_bot>
<ostera> a-ha, so it'd be needed for linking then
<d_bot>
<ostera> cool!
<d_bot>
<Drup> well, you don't need to link on ocaml stuff, don't you ? You have your erlang files
<d_bot>
<ostera> yes, precisely
<d_bot>
<ostera> removing 42-44 keeps everything working 🆗
<d_bot>
<ostera> regarding the read_signature
<d_bot>
<Drup> As for the `signature` ... I suppose you use that to know what is exposed. That's already contained in the `coercion` thingy.
troydm has quit [Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset]
troydm has joined #ocaml
<d_bot>
<ostera> hmm, perhaps. I ended up reading the .cmi to get my hands on a Types.signature
<d_bot>
<ostera> is there another (cleaner) way to do this?
<d_bot>
<Drup> I would look into the coercion directly
<d_bot>
<Drup> As I said, everything is already there, you might have a little bit of decoding, but it's guaranteed to be correct/consistent
<d_bot>
<ostera> right, i remember looking at this before and getting rather confused by the definition of that type
<d_bot>
<ostera> most of the variants have a module_coercion inside
<d_bot>
<ostera> and it felt more straightforward to work over the signature type
<d_bot>
<ostera> I presume the coercion would take into account the .mli file as well
<d_bot>
<Drup> yes, that's why I suggest using it
<d_bot>
<ostera> alright so help me understand something
<d_bot>
<ostera> (warning IRC, 6 lines of code ahead)
<d_bot>
<ostera> ```ocaml
<d_bot>
<ostera> and module_coercion =
<d_bot>
<ostera> Tcoerce_none
<d_bot>
<ostera> | Tcoerce_structure of (int * module_coercion) list *
<d_bot>
<ostera> (Ident.t * int * module_coercion) list
<d_bot>
<ostera> | Tcoerce_functor of module_coercion * module_coercion
<d_bot>
<ostera> | Tcoerce_primitive of primitive_coercion
<d_bot>
<ostera> | Tcoerce_alias of Env.t * Path.t * module_coercion
<d_bot>
<ostera> `mk_exports` gets that signature and it will prefer it over the `typedtree.str_type`
<d_bot>
<ostera> that was the way I managed to get arity counting working and the explicit exports that erlang requires
<d_bot>
<ostera> (by the way @Drup thanks a million for the feedback 🙌 really appreciate it 😄 )
<d_bot>
<Drup> hmm, the coercion might be a bit too crude :/
<d_bot>
<Drup> but It feels super bad loading again a signature you just computed/used
<d_bot>
<Drup> (For reference: the main case of interest for you is Tcoerce_structure. The first list is the collection of coercion for each field at position `i`. The second list is the same, but for module aliases)
<d_bot>
<Drup> but you won't be able to get the exposed types that way.
<d_bot>
<ostera> is there any way to turn a module_coercion into a signature?
<d_bot>
<Drup> not really, and it won't be the one you want
<d_bot>
<ostera> i see
<d_bot>
<ostera> so i'm bound to my hacky read_signature then
mmohammadi9812 has quit [Ping timeout: 258 seconds]
<d_bot>
<Drup> 😦
<d_bot>
<Drup> maybe we should make the coercions less crude ....
<d_bot>
<ostera> 😄
<d_bot>
<ostera> can I help there?
<d_bot>
<Drup> Alterantively, we could just make the typing return the exposed signature.
<d_bot>
<Drup> that's a fairly trivial patch
<d_bot>
<ostera> trivial like... to you? or is this something that I could manage to do? 😛
<d_bot>
<Drup> no, it's really just threading some info that is already there to bubble up
<d_bot>
<ostera> just saw
<d_bot>
<Drup> you might have to play detective to unravel the indirections :p
<d_bot>
<austindd> Hello all! So I have a question for those of you who are familiar with the fine-grained details of OCaml's type system...
<d_bot>
<austindd>
<d_bot>
<austindd> Would it be possible/feasible to modify the compiler to give more fine-grained warnings/errors about exhaustiveness with extensible variants? In particular, I figured it might be possible (and desirable) to have the compiler inform me when I have covered all the cases that are visible in the outer scope -- so basically every case defined "above" the current expression.
<d_bot>
<austindd>
<d_bot>
<austindd> Does that seem reasonable at all? If we had something like that, it would make extensible variants slightly safer to use, since we could at least be sure that we aren't forgetting a "known" case. Then we would only have to worry about extensions defined further down in the program. Thoughts?
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
<d_bot>
<Drup> @ostera looks good
<d_bot>
<Drup> @austindd You mean an additional warning, on top of exhaustiveness, right ?
<d_bot>
<Drup> Exhaustiveness means that the matching never fails. For extensible variant, that means you always need a catch all clause.
<d_bot>
<octachron> @austindd , it sounds more like an extension to fragile pattern matches. But it would be a really brittle warning.
<d_bot>
<austindd> @Drup Yes, basically an additional warning, or perhaps the existing warning could enumerate examples of “known” cases we haven’t handled **before** it warns us about the `*extension*` catch-all case.
<d_bot>
<octachron> The thing is that "known" cases is not a really solid notions for extension constructors, the number of constructors in scope may vary hazardously from the user point of view .
<d_bot>
<austindd> Yeah, that’s true... and it would also cease to help us as soon as we add a wild-card pattern. :/
Haudegen has quit [Quit: Bin weg.]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
FreeBirdLjj has quit [Ping timeout: 256 seconds]
mxns_ has joined #ocaml
mxns has quit [Ping timeout: 246 seconds]
ransom has joined #ocaml
Haudegen has joined #ocaml
jnavila has joined #ocaml
jnavila has quit [Ping timeout: 256 seconds]
jnavila has joined #ocaml
berberman has quit [Ping timeout: 272 seconds]
berberman_ has joined #ocaml
mxns_ has quit [Ping timeout: 240 seconds]
vicfred has joined #ocaml
mxns has joined #ocaml
ransom_ has joined #ocaml
ransom has quit [Ping timeout: 240 seconds]
osa1 has quit [Quit: osa1]
ggole has quit [Quit: Leaving]
mxns has quit [Ping timeout: 272 seconds]
mxns has joined #ocaml
Hrundi_V_Bakshi has joined #ocaml
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
ransom_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Haudegen has quit [Quit: No Ping reply in 180 seconds.]