Request for sample usages
Panicz Maciej Godek
(30 Mar 2020 16:07 UTC)
|
||
(missing)
|
||
Re: Request for sample usages
Panicz Maciej Godek
(31 Mar 2020 15:54 UTC)
|
||
Re: Request for sample usages
(no sender)
(31 Mar 2020 18:34 UTC)
|
||
Re: Request for sample usages
(no sender)
(01 Apr 2020 07:05 UTC)
|
||
Re: Request for sample usages
Marc Feeley
(30 Mar 2020 16:15 UTC)
|
||
Re: Request for sample usages
Duy Nguyen
(31 Mar 2020 13:35 UTC)
|
||
Re: Request for sample usages
(no sender)
(31 Mar 2020 13:45 UTC)
|
||
Re: Request for sample usages
Duy Nguyen
(31 Mar 2020 13:48 UTC)
|
||
Re: Request for sample usages Wolfgang Corcoran-Mathe (31 Mar 2020 23:39 UTC)
|
Re: Request for sample usages Wolfgang Corcoran-Mathe 31 Mar 2020 23:38 UTC
On 2020-03-31 20:48 +0700, Duy Nguyen wrote: >>What do you mean by "passing error messages around" in everyday >>programming? Usually, one would invoke the current error handler >>or a special failure continuation to signal errors and wouldn't >>treat errors through a data-directed programming style. >> > >Ah that's what I missed. But I think we're dealing with data-directed >programming style here though (returning #f as fail), perhaps not >severe enough to change control flow, just log the errors for more >analysis later. An example that comes to mind is the (original) Parsec[1] parser’s approach of building up either (A) a collection of parses or (B) a collection of all the errors encountered in parsing. This is a natural use for Either, I think; you can have, say, a function which constructs a list of values or a list of error-reports, and know precisely which is which. [1]: Meijer & Leijen, "Parsec: A Practical Parsing Library" -- Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> "It from bit." --John Wheeler