<discocaml>
<octachron> Somehow, 5.4.0 ended up being the arraylike-focused release of OCaml 5 .
wbooze has quit [Quit: Leaving]
<discocaml>
<cod1r> ohhhhhhh
<discocaml>
<octachron> Beware that features can theoretically be removed after alpha releases.
ygrek has joined #ocaml
myrkraverk has joined #ocaml
<discocaml>
<lukstafi> Whaaa... so unexpected.
<discocaml>
<lukstafi> Is it like unnamed records? Does it make inline record definitions (in variant cases) kinda redundant?
<discocaml>
<lukstafi> And immutable arrays?!?
<discocaml>
<contificate> > Is it like unnamed records?
<discocaml>
<contificate> yeah, it addresses the lack of anonymous record types (as SML has)
<dh`>
that doesn't seem like a bug if you ask me
<discocaml>
<contificate> "bug" is a strong word
myrkraverk_ has joined #ocaml
<discocaml>
<contificate> I can survive without them, but I can't say I haven't desired such a thing from time to time
myrkraverk has quit [Ping timeout: 252 seconds]
mange has quit [Quit: Zzz...]
ygrek has quit [Remote host closed the connection]
myrkraverk has joined #ocaml
<discocaml>
<octachron> Not really inlined records are "inlined", in other words `A of { x: int; y : int}` is fusing the tag of `A` with the record block, so the unboxing part is not redundant.
myrkraverk_ has quit [Ping timeout: 276 seconds]
Frostillicus has quit [Ping timeout: 265 seconds]
Frostillicus has joined #ocaml
<discocaml>
<lukstafi> So a labeled tuple will be unambiguously boxed?
<discocaml>
<aguluman> Found this as a langauge binding for Ocaml
<dh`>
there are times
<dh`>
but mostly declaring records ahead of time is only a minor nuisance and it saves various complications
<dh`>
I have been dealing with a language recently that has anonymous structs and it leads to really aggravating kinds of type errors
<dh`>
(also didn't help that until it got fixed recently it quietly didn't typecheck certain cases)
<dh`>
it also causes weird things to happen with type inference unless you also add rho-polymorphism, which isn't necessarily desirable
<discocaml>
<contificate> like lots of things, I hope its usage will be tasteful
<discocaml>
<contificate> and not everywhere
<discocaml>
<ape_logic> yes, I want an fd pointing to some buffer in memory
<discocaml>
<ape_logic> I'm displaying some log output as a system notification, and I want to make the notification clickable to open the full log in $PAGER
Haudegen has quit [Quit: Bin weg.]
<discocaml>
<ape_logic> so from what I can tell the best option is to push to a tmp fd like this as a "fake" stdout
<discocaml>
<ape_logic> then I can intercept the output, send as a notification, and forward on to the fd
<discocaml>
<ape_logic> yes, I want an fd pointing to some temp buffer in memory
<discocaml>
<yawaramin> why not a temp file? eg with `Filename.open_temp_file`
<discocaml>
<froyo> > Does it make inline record definitions (in variant cases) kinda redundant?
<discocaml>
<froyo> Not redundant but they add more, uhm idk how to call it so I'll go with "anti-rule", to the language. I think named tuples are a good qol improvement, they're just yet another way to specify the fields of a variant.
<discocaml>
<froyo> I want to name the fields of a variant, I can use inline record or named tuple. the latter incurs an extra indirection and may escape, the former has field access syntax, and I should know those differences. I think we can agree that a small syntactic choice like the good old `a * b => (a * b)` having a runtime cost is a bit unfortunate, but rectifying that is hard. It's a little annoying source of irregularity in the language. And it's a diffi
myrkraverk has quit [Ping timeout: 272 seconds]
<discocaml>
<froyo> one could argue that inline records being special is already a source of irregularity, but simple preexisting rules make that behavior make perfect sense: records are nominal. to use a record you must have declared its type earlier, so how can you use an escaping inline record without a type? how can it be referred to?
<discocaml>
<froyo> > I think named tuples are a good qol improvement, they're just yet another way to specify the fields of a variant.
<discocaml>
<froyo> to clarify, the qol improvement isn't that you can name fields of a variant with them, that's the irregularity. the qol improvement is in e.g. naming a tupled return type
<discocaml>
<froyo> > the good old `a * b => (a * b)` having a runtime cost
<discocaml>
<froyo> not only a runtime cost but also the ability to construct separately and refer to as one variable in patterns.
<discocaml>
<froyo> it's also a bit annoying because, purely from theoretical pov, we already have structural aggregates/products -- objects. they're just living in their own world because they're a bit syntactically alien and rather heavy in runtime repr
<discocaml>
<froyo> the many ways to do one thing :P