Yes if we just all agree on this type: http://erratique.ch/software/fut/doc/Fut.html#TYPEresult then we are all compatible without actual library dependencies, thanks to structural typing
I've been abusing this for the past few years, it's great: http://seb.mondet.org/software/pvem/index.html http://seb.mondet.org/software/pvem_lwt_unix/index.html http://seb.mondet.org/talks/compose2015/#/25 http://seb.mondet.org/talks/compose2015/#/26 On Tue, Feb 3, 2015 at 12:10 PM, Daniel Bünzli <[email protected]> wrote: > Le mardi, 3 février 2015 à 16:55, Christophe Troestler a écrit : > > Please lay down a concrete interface showing of what you mean. I > > think we all agree on the goal of writing robust software, we need to > > move the discussion to concrete proposals. > > Sorry don't have the time to work on this; these things come out of > writing code. But as a start I don't see what's the problem with the basic > result monad everybody knows (e.g. see here [1,2]) along with a few > with_resource combinators based on some kind of `finally` [3] and stick to > polymorphic variant errors — along, of course, with Format pretty printers > for these something that is often annoyingly absent in APIs. And I would > completely forget about using lwt's failed state (i.e. only to trap > unexpected exceptions at the highest level). > > Best, > > Daniel > > [1] > This deals only with string errors so it should be generalized to [2], but > a few of the error handling > combinators may be interesting. > > > https://github.com/samoht/assemblage/blob/master/lib/assemblage.mli#L708-L744 > > For example `reword_error` a quick combinator that allows to transform a > lower-level error to a higher level one, i.e. give more context higher up > when you have the info about what you are doing. Since we are using strings > here it's also easy to stack the errors if you wish so (~replace:false > argument) from the lowest-level of what went wrong (e.g. the actual utility > invocation error) to what you were trying to do (e.g. determine the number > of processors in the system) which makes error diagnosis much easier > (context + no error info is lost). Not that it wouldn't be impossible with > lists of polyvars, but one has to see how it comes out in practice. A few > examples: > > https://github.com/samoht/assemblage/blob/master/lib/as_conf.ml#L420-L428 > https://github.com/samoht/assemblage/blob/master/lib/as_conf.ml#L543-L548 > > [2] > This is the classical generalized result type for dealing with errors. > http://erratique.ch/software/fut/doc/Fut.html#TYPEresult > http://erratique.ch/software/fut/doc/Fut.html#VAL(&>>=) ( > http://erratique.ch/software/fut/doc/Fut.html#VAL(&%3E%3E=)) > http://erratique.ch/software/fut/doc/Futu.html#VALread > > [3] > http://erratique.ch/software/fut/doc/Fut.html#VALfinally > This could also be modified or another version provided to propagate > possible errors in the finally handler in the concurrency monad itself. > > > _______________________________________________ > MirageOS-devel mailing list > [email protected] > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
