Quoting Kenton Varda (2018-08-28 21:34:13) > has a split, where you can either parse the whole thing up front > and forget about it, or write very imperative-looking code with > explicit error checks everywhere. > > Interesting. I would think that for validation errors, at least, you > could return `error` and let that bubble up as needed.
Looking back I think I may have brain-farted when communicating here. There actually isn't much explicit error checking, but nonetheless the need to handle errors kindof infects the whole API in a way that you can't really ignore even if you want to just let the caller handle it. You *could* as you say just throw an error and have it bubble up, but the trouble is it's really hard to reason about *when* stuff gets evaluated in Haskell (because of laziness), and so throwing unchecked exceptions from pure code tends to result in really brittle applications. Right now we end up tracking the possibility of errors in the type system, and while you can abstract the actual handling of them away to a certain extent, the resulting code is awkward in the same way promises are awkward compared to straight-line code. I do have some ideas on how to improve the situation that I want to experiment with down the line; I think it is possible to tame the exception approach, but finding the right API will take some thought & experimentation. > But the traversal limit is indeed rather inherently imperative. > I wonder if there's some other strategy for detecting aliasing that > would be more friendly to a purely-functional approach. At some point I plan to experiment an API that lets you just set a timeout and/or an allocation limit; the nice thing about pure code is there's no worrying about what happens to state when you kill it. -Ian -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
