<companion_cube>
in bytecode it'd be left to right, i think
<cemerick>
talk about a footgun
<companion_cube>
if you want linear order, use let
<companion_cube>
(or, here, match I'd say)
<def>
is it the runtime that is not right?
<def>
runtime performance*
<def>
I can easily imagine it being quadratic :P
<companion_cube>
^
<cemerick>
companion_cube: yeah, the working code `let`s as needed
<d_bot>
<ggole> I've run into that before, it is quite annoying
<companion_cube>
truly, use match, it'll be cleaner
<d_bot>
<ggole> `match`ing on exceptions was very welcome, much less error-prone than `try`
* cemerick
wasn't aware of the match-with-exception option, thanks
<cemerick>
I appreciate the necessity of implementation-defined semantics for all sorts of things, but varying evaluation order in an eager language seems like a truly bad spot for it...with what upside?
<companion_cube>
I'm sure you can find mailing list threads on the why
<companion_cube>
I think relying on evaluation order is a code smell
<companion_cube>
but it's a footgun anyway
<d_bot>
<ggole> There are some minor commuting optimisations (that I don't think ocamlopt even does), and right-to-left is a bit nicer for the bytecode stack
<d_bot>
<craigfe> The feasibility of TRMC seems like a nice validation of the decision to keep evaluation order undefined (at least for constructor args), regardless of the historical reasons for doing so
<zozozo>
well, additionally, if your program is pure, evaluation order does not matter
<d_bot>
<craigfe> (pure _and_ total _and_ used-only-by-programmers-that-don't-care-about-performance)
<cemerick>
hah, I don't think `List.hd`raising instead of returning `None` can be construed as "useful" in the modern era
<companion_cube>
I disagree on that one
<companion_cube>
List.hd should only ever be used if you know it's not []
<cemerick>
I was trying to make a broader point :-)
<companion_cube>
well if it returns None, you need to match
<companion_cube>
so why not match in the first place?
<companion_cube>
if you want a good example I'd volunteer `Map.find`
<cemerick>
let me restate
<zozozo>
for things such as Map.find, I think you can historically see it as: using exceptions internally is the faster way (allows to unwind the stakc frames used to dive into the tree), and before we had flambda, allocating an option and matching on it could be seen as a waste of time and ressources
<companion_cube>
well, do people use flambda in prod, actually? :p
<cemerick>
if you want to cite purity as a blanket for what ails you, exceptions are a very, very poor default choice for control flow
<companion_cube>
I'd say the overhead can still be here
<zozozo>
cemerick: I think people at jane street do
<cemerick>
🤷
<zozozo>
arg, bad hl, sorry
<zozozo>
meant to hl companion_cube earlier, :p
<cemerick>
ah
<companion_cube>
:p
<companion_cube>
pure code + exceptions is an interesting mix I guess
<zozozo>
there should only be 1 people by first nick letter in any cahnnel to help with completion, XD
yomimono has quit [Ping timeout: 240 seconds]
<cemerick>
companion_cube: the point is that you can't claim purity in the presence of exceptions
<companion_cube>
oh, ok
<cemerick>
especially insofar as OCaml makes no distinction between precise and imprecise variants
<companion_cube>
precise variants?
<d_bot>
<ostera> "precise and imprecise variants" ?
<companion_cube>
(I agree, exceptions make order evaluaiton matter in a way that is not the case iwht pure code)