<d_bot>
<salt rock lamp> It'd be nice if it could tell you which env var it was...
xd1le has joined #ocaml
favonia has joined #ocaml
vicfred has quit [Ping timeout: 265 seconds]
daachi has joined #ocaml
<companion_cube>
Or use Sys.getenv_opt
waleee has quit [Ping timeout: 252 seconds]
mbuf has joined #ocaml
adanwan has joined #ocaml
<cemerick>
these are all good and reasonable reactions/suggestions, but ISTM the root problem is that it's incredibly easy (sort of the default, really) for any given OCaml code to cause an ~information-free panic
<cemerick>
top-tier footgun, it is
<d_bot>
<RegularSpatula> The whole time reading this, I was thinking I remembered a discuss post talking about something similar… just looked it up and turns out it was actually by cemerick (https://discuss.ocaml.org/t/exception-vs-result/6931). Definitely an interesting read
rgrinberg has joined #ocaml
<d_bot>
<cemerick> @RegularSpatula it's a hobby horse of mine, I admit
zebrag has quit [Quit: Konversation terminated!]
<rgrinberg>
It's no secret that one has to use the stdlib defensively or eventually pay the price. There's a reason alternative standard libraries are available after all
<cemerick>
there are unfortunately plenty of libraries that raise in spots that are IMO pretty suprising, well away from stdlib
<rgrinberg>
Oh, so it's the exception that you find problematic.
<d_bot>
<RegularSpatula> I got hit by a similar problem as cemerick the other day…of course the docs did say whatever functions I was using could raise an exn, but I still forgot to check it until it happened at runtime
<rgrinberg>
I don't like Not_found because it doesn't include the thing that was not found (and where it was looked for)
<rgrinberg>
Plenty of libraries inherit the stdlib's flaws. It's unfortunate, but can be easily worked around once you get the hang of the main flaws
<cemerick>
rgrinberg: "you get used to it" is not an endorsement of a feature's continued existence
<rgrinberg>
I only endorse avoiding the stdlib whenever possible
<cemerick>
I'm sure it'll never happen, but I'd love to see the smallest of steps to ward people away from continuing to lay such traps, e.g. make usage of `raise` warn by default
<rgrinberg>
Making raise warn by default is absurd :O
<cemerick>
That's true only if one is inured to "that's the way it is" 🤷
<d_bot>
<RegularSpatula> Out of curiosity, I was looking at how many times `caml_raise_not_found` was used in the ocaml runtime...not too many actually. But then looking at `Not_found` in actual `.ml` files in the ocaml repo...soo many times
<d_bot>
<cemerick> @RegularSpatula my most recent OCaml panic adventure (before today's `Not_found`) was tracking down yojson `Type_error`s being thrown in production from calls to `member` (which, *wompwomp*) doesn't actually document that it might throw 🙃 https://ocaml-community.github.io/yojson/yojson/Yojson/Basic/Util/index.html
Everything has joined #ocaml
<cemerick>
I suppose the long-term plan is that effects will eventually make it "easy" to surface which errors might be raised from any given function call, but until then, one really does just need to expect such problems
<d_bot>
<RegularSpatula> yeah I definitely find myself looking at source code a lot to see if a function that I think might/probably will raise actually does or not
* cemerick
wonders how painful it'd be to roll up exceptions-raised through a program's call graph so as to drive user-facing warnings, etc
<rgrinberg>
you all should try using a language without exceptions and see how you like it. the cure is worse than the disease in this case
<d_bot>
<ams> hey have any of you tried running a dune project on alpine linux? I'm having trouble running dune exec cause it doesnt go into the path after running
<d_bot>
<ams> ```bash
<d_bot>
<ams> eval $(opam config env)
<d_bot>
<ams> ```
<cemerick>
rgrinberg: hah, why would you assume we haven't? Just because strictly worse things exist, doesn't mean one should be still
<cemerick>
e.g. absolutely everyone would be better off if some tooling (whether the compiler itself or editor hints or whatever) popped a yellow squiggly to show the potential for a panic, especially insofar as programming practice/culture have been to use them (IMO over-) liberally (e.g. for not-found sorts of "errors")
<rgrinberg>
Sure. Exceptions aren't perfect and can be improved. The tooling around them can also be improved. But they're still miles ahead of anything else out there. All other languages that lack exceptions are full of boiler plate that exceptions neatly avoid
<d_bot>
<RegularSpatula> I tended to use `unrwap()` all the time in Rust which is frowned upon in a lot of rust blogs...but it made things that should stay simple stay simple, rather than match on error for every little thing
<rgrinberg>
We need better exceptions.
<d_bot>
<RegularSpatula> so i see your point about exceptions being nice
<d_bot>
<cemerick> @RegularSpatula my time in haskell really drove home an appreciation for monadic constructions, which end up being incredibly terse (i.e. _not_ checking for errors on every little thing) and mostly only interested only in the happy path
<d_bot>
<cemerick> OCaml doesn't match that experience completely, but comes pretty close most of the time
<d_bot>
<RegularSpatula> does using jane street's `Or_error` count as monadic error handling ?
<d_bot>
<RegularSpatula> never used haskell...so not sure about all the algebra terms
<d_bot>
<RegularSpatula> but i do use or_error whenever possible
<rgrinberg>
There are exceptions in Haskell. They are absolutely crucial for some things
<d_bot>
<RegularSpatula> rgrinberg: in terms of speed or clearer control flow, or something else?
<Corbin>
Exceptions are essential to IEEE 754 support, for example.
<rgrinberg>
Implementing generic timeouts is another
<d_bot>
<RegularSpatula> interesting
<d_bot>
<RegularSpatula> i guess if you didn't have exceptions, you'd have to wrap the five floating point exceptions types that IEEE 754 defines...and that seem like it'd be a pain to do math
<Corbin>
Even total languages should offer some way to forcefully panic or crash, in some situations. I know it's trite, but those situations usually are genuinely *exceptional*, in the sense that the situations can't occur during normal healthy execution.
<rgrinberg>
In Haskell, there's a useful convention that pure functions do not raise non fatal errors.
<rgrinberg>
I say it's a convention, because they still have partial functions.
<rgrinberg>
But if we followed that convention in OCaml, we'd be in just as good of a spot.
<cemerick>
tbc, I don't think anyone that's ever commented on this topic is actually looking to eliminate exceptions
<d_bot>
<RegularSpatula> That's quite a start, haha: "Twenty years ago anarchy threatened floating-point arithmetic."
<Corbin>
cemerick: I'm currently working on a total language, and it is taking a long time to do the research on what's safe to do and what needs to be wrapped in some sort of effect system.
<rgrinberg>
By the way, to say that haskell's monadic constructions solve the issue of error handling in general hand waving.
<cemerick>
rgrinberg: the intention behind my absurd suggestion re: making `raise` warn is to push people towards an analogous convention
<rgrinberg>
I meant *is* hand waving.
<cemerick>
rgrinberg: I didn't say those constructions solve anything in a general sense
<Corbin>
rgrinberg: It's a start, at least. e.g. Go has no error handling tools; it has a social convention that multiple return values can indicate errors. Haskell's Maybe and Either monads can at least be used to manage error values somewhat. There's a nice monad, Async, which is more like a proper future/promise monad.
<cemerick>
I do think one should have a really good reason to not use them, especially in application-level contexts
<cemerick>
Corbin: is anything of the language public yet?
<rgrinberg>
Corbin IMO, the only use Go has as a programming language is to teach newcomers why exceptions are necessary ;).
<rgrinberg>
Yes, the various monadic constructions can go a little further. But they are quite limited and have their own bag of downsides. Which I love to remind people of whenever these discussions come up
<cemerick>
monadic approaches make it so I don't have to nose around thoroughly unexpected traces from prod, which is worth at least two bags of downsides lol
<cemerick>
Corbin: oh, fun, thanks :-)
gravicappa has joined #ocaml
<rgrinberg>
Funny, but I find but that exceptions are what makes it easy for me to write reliable software that I can run confidently in production. I don't need to think about every little edge case, I just need think about where my code must recover from to ensure reliability
<d_bot>
<RegularSpatula> genuinely curious...do you think that comes from having a high level of expertise/experience with ocaml (or whatever tool/library is under question)...like knowing well which areas are going to be problematic in the code, where exceptions may be raised, etc. As opposed to as a beginner (to ocaml in general or to a specific library), if you see a function returning a Result...you can't help but handle it, but may miss some
shawn has quit [Ping timeout: 252 seconds]
<rgrinberg>
It comes from extensively trying the Or_error style and realizing that it does not improve the quality of code in many cases.
<d_bot>
<RegularSpatula> so it's more of experience to know when or_error style is overkill?
<rgrinberg>
I have a rule of thumb at this point. If it's a pure function, try not to raise unless it's invalid_arg.
<rgrinberg>
With side effects, it's more situational
<rgrinberg>
I'd much prefer a function such val read_file : string -> string over the or_error equivalent. Even though it's clear that it can fail
<d_bot>
<RegularSpatula> for the sake of not having to jump through the monad hoops?
<d_bot>
<RegularSpatula> as in it's simpler to just catch the possible exception of read_file somewhere downstream
<rgrinberg>
That too. But also because Or_error is too primitive to allow my code to recover based on what the error is
<d_bot>
<RegularSpatula> ah gotcha
<rgrinberg>
I also retain somewhat usable backtraces this way. Unlike the monads
<d_bot>
<RegularSpatula> that makes sense as well...ive seen code putting stack traces back in to or_error tags (or result)
<rgrinberg>
Yes, I do find that amusing. A lot of effort is spent on beautiful error messages that end up being far less useful than a 3 word error with a stacktrace.
<d_bot>
<RegularSpatula> i do get the feeling that I'm sometimes wading through like "monad soup" or whatever when dealing with a lot of or_error type code...and then i'm just like, raise an exception here and then the code all the sudden flows a lot neater
<rgrinberg>
In the dune source we have the best of both worlds: exceptions everywhere and a monad soup
<rgrinberg>
but yes, avoid using more than one monad at once. It's not a bad technique, but OCaml has poor machinery for it
mro has joined #ocaml
TakinOver has quit [Ping timeout: 240 seconds]
Serpent7776 has joined #ocaml
TakinOver has joined #ocaml
<companion_cube>
Wow rgrinberg with hot takes
<companion_cube>
(I like it)
<companion_cube>
I couldn't write ocaml without exceptions
Haudegen has joined #ocaml
<vsiles>
Armael: I'm reading papers about iris to get to know the framework. I was wondering if there are some projects/examples I could read too. I'd like to start formalizing a small OO language (simple classes/inheritances, and class can refer to themselves so recursion is there)
<vsiles>
I'm reading scala/dotty papers but they are quite involved when you just start :D
<cemerick>
the project I use it in the most has pretty comprehensive benchmarking baked into its CI pipeline to avoid regressions; using the transformers yielded zero perf penalty (and significantly simplified the codebase)
<cemerick>
that's of course no guarantee for anyone else, but even if there was a minor penalty (up to 10% of a slowdown probably would have been acceptable), I would have deemed it worthwhile
<companion_cube>
what kind of stacks of transformers were you using?
<cemerick>
the primary one is a pretty straightforward Writer+Result
<cemerick>
it's got a few wrinkles (it keeps N "buckets" of writable state), but isn't anything crazy
<companion_cube>
I suppose you replaced pure functional code with pure functional code
<cemerick>
but the alternative was using a basically stdlib result, and having some kind of centralized stateful sink for code to spit secondary and tertiary outputs into; that's what was replaced
<cemerick>
no, it was stateful as all hell, and thus was very unpleasant to debug at times
daachi has joined #ocaml
<companion_cube>
surprised you got no performance hit :p
<companion_cube>
if it's not a bottleneck, though, it makes sense
<cemerick>
it's a query language planner and runtime; whatever additional bookeeping is needed for something as simple as a pairing of monads is just noise against the actual work being done
<companion_cube>
ah, indeed
<cemerick>
but then, the amount of bookkeeping probably isn't any different vs. the old stateful sink approach. All the same tasks are being done, just now reasonably managed
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #ocaml
infinity0 has quit [Remote host closed the connection]
daachi has quit [Ping timeout: 265 seconds]
mro has quit [Remote host closed the connection]
daachi has joined #ocaml
Haudegen has joined #ocaml
xd1le has quit [Quit: xd1le]
mro has joined #ocaml
mro has quit [Ping timeout: 252 seconds]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
<d_bot>
<salt rock lamp> will the effects system coming with multicore ocaml provide a 3rd way?
<d_bot>
<salt rock lamp> e.g. instead of raising an exception or using a monad, the exception becomes an effect that needs to be handled
olle has quit [Remote host closed the connection]
spip has quit [Quit: Konversation terminated!]
daachi has quit [Ping timeout: 252 seconds]
hendursaga has quit [Remote host closed the connection]
hendursaga has joined #ocaml
spip has joined #ocaml
mbuf has quit [Quit: Leaving]
rgrinberg has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
daachi has joined #ocaml
zebrag has joined #ocaml
wonko has joined #ocaml
_whitelogger has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bartholin has quit [Quit: Leaving]
Haudegen has joined #ocaml
olle_ has joined #ocaml
rgrinberg has joined #ocaml
<rgrinberg>
Yes. Typed effects seem like they'll replace some current uses for exceptions
abraham has joined #ocaml
jess has quit []
<d_bot>
<salt rock lamp> cool
<d_bot>
<salt rock lamp> as soon as i learned about algebraic effects i got excited about seeing them in a "real" language
<d_bot>
<salt rock lamp> the underlying theory is quite heady, but it's such a great idea
olle_ has quit [Ping timeout: 252 seconds]
<d_bot>
<salt rock lamp> as far as i can tell, there's quite a bit of conceptual overlap with the common lisp "condition" system and delimited continuations like in racket
<d_bot>
<salt rock lamp> o'
<d_bot>
<salt rock lamp> i'm sure the similarities and differences have some theoretical formalization
vicfred has joined #ocaml
<d_bot>
<cemerick> @salt rock lamp FWIW, effect systems don't present an either/or vis a vis monads; you can have a monadic interface to an effect system, or not
<d_bot>
<cemerick> they're just interfaces with operations that collectively ensure certain semantics
Tuplanolla has joined #ocaml
daachi has quit [Ping timeout: 265 seconds]
Anarchos has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wonko has quit [Ping timeout: 260 seconds]
rgrinberg has joined #ocaml
wonko has joined #ocaml
abraham has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
abraham has joined #ocaml
abraham has quit [Client Quit]
abraham has joined #ocaml
abraham has quit [Client Quit]
abraham has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot>
<salt rock lamp> i guess i had in mind explicitly invoking ("performing"?) effects instead of dealing with monads and transformer stacks thereof
abraham has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
abraham has joined #ocaml
<d_bot>
<cemerick> it sounds like you're talking more about the ergonomics / aesthetics of a given approach
<d_bot>
<cemerick> e.g. do-notation and let operators make monadic code "look imperative", but that doesn't change the semantics
<d_bot>
<cemerick> @salt rock lamp Eff is an OCaml-like language that implements an algebraic effect system, you might find it interesting https://www.eff-lang.org/
rgrinberg has joined #ocaml
<d_bot>
<salt rock lamp> yep exactly!
<d_bot>
<rgrinberg> @octachron Is there a way not to repeat the sharing constraints twice in this signature?
<d_bot>
<rgrinberg> ```
<d_bot>
<rgrinberg> let add (type r u) (t : t)
<d_bot>
<rgrinberg> (module Spec : Poll_spec with type update = u and type response = r) =
<d_bot>
<rgrinberg> let module T = struct
<d_bot>
<rgrinberg> module Spec = Spec
<d_bot>
<rgrinberg>
<d_bot>
<rgrinberg> let waiters = ref Poll_map.empty
<d_bot>
<rgrinberg> end in
<d_bot>
<rgrinberg> let res : (r, u) Instance.t =
<d_bot>
<rgrinberg> (module T : Instance.S
<d_bot>
<rgrinberg> with type Spec.update = u
<d_bot>
<rgrinberg> and type Spec.response = r)
<d_bot>
<rgrinberg> in
<d_bot>
<rgrinberg> t := Instance.E res :: !t;
<d_bot>
<rgrinberg> res
<d_bot>
<rgrinberg> ```
<d_bot>
<rgrinberg> I want to substitute the module in res with something like `with module Spec = Spec`, but can't get it to work.
<d_bot>
<salt rock lamp> i know of Eff but haven't tried it. i watched this a while ago, i think it's one of the main contributors? got lost following the theory pretty fast, but it was interesting to see that this stuff has sound foundations, albeit very abstract
<d_bot>
<cemerick> I have a wrapped library with a module Foo.Bar; is there any way to refer to it from a test module with the same name (itself in a wrapped library, so Test.Bar)?
<d_bot>
<rgrinberg> Yes, `Foo.Bar` should be accessible from `Test.Bar`.
abraham has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
mro has joined #ocaml
wonko has quit [Ping timeout: 252 seconds]
infinity0 has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
gravicappa has quit [Ping timeout: 260 seconds]
<d_bot>
<injuly> this bot can talk like a human !?!
<d_bot>
<injuly> or was the message sent by the bot's dev from a terminal
<d_bot>
<NULL> All cats are IRC users
<Armael>
b e e p b o o p
<d_bot>
<salt rock lamp> pretty sure this is the IRC bridge
<d_bot>
<injuly> ah
<d_bot>
<injuly> gooootcha
<cemerick>
The machines are
<d_bot>
<cemerick> ...everywhere
vicfred has quit [Quit: Leaving]
Everything has quit [Quit: leaving]
Serpent7776 has quit [Quit: leaving]
Anarchos has quit [Quit: Vision[0.10.3]: i've been blurred!]
shawn has joined #ocaml
mro has quit [Quit: Leaving...]
rond_ has joined #ocaml
abraham has joined #ocaml
rond_ has quit [Quit: Client closed]
zebrag has quit [Ping timeout: 252 seconds]
zebrag has joined #ocaml
olle_ has joined #ocaml
infinity0 has quit [Remote host closed the connection]
infinity0 has joined #ocaml
<d_bot>
<octachron> @rgrinberg : there is no way to avoid writing the two type constraints somewhere, but once you have the type constructor `Instance.t` writing `let res: _ Instance.t = (module T)` should be sufficient.
infinity0 has quit [Remote host closed the connection]
infinity0 has joined #ocaml
infinity0 has quit [Remote host closed the connection]
infinity0 has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]