Add further conversions between data-directed and code-directed programming idioms Marc Nieper-Wißkirchen 06 Jun 2020 17:25 UTC
Re: Add further conversions between data-directed and code-directed programming idioms John Cowan 06 Jun 2020 23:27 UTC
Re: Add further conversions between data-directed and code-directed programming idioms Marc Nieper-Wißkirchen 07 Jun 2020 09:13 UTC
Re: Add further conversions between data-directed and code-directed programming idioms Lassi Kortela 07 Jun 2020 12:18 UTC
Re: Add further conversions between data-directed and code-directed programming idioms Marc Nieper-Wißkirchen 07 Jun 2020 13:25 UTC
Low-level vs high-level exceptions Lassi Kortela 07 Jun 2020 13:59 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 07 Jun 2020 15:45 UTC
Re: Low-level vs high-level exceptions John Cowan 08 Jun 2020 14:29 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 08 Jun 2020 14:36 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 08 Jun 2020 14:52 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 09 Jun 2020 06:11 UTC
Re: Low-level vs high-level exceptions Wolfgang Corcoran-Mathe 09 Jun 2020 13:03 UTC
Re: Low-level vs high-level exceptions John Cowan 14 Jun 2020 00:58 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 14 Jun 2020 10:37 UTC
Re: Low-level vs high-level exceptions John Cowan 14 Jun 2020 14:57 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 14 Jun 2020 15:31 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 14 Jun 2020 15:42 UTC
Re: Low-level vs high-level exceptions John Cowan 16 Jun 2020 01:58 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 16 Jun 2020 07:33 UTC

Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 09 Jun 2020 06:11 UTC

Am Mo., 8. Juni 2020 um 16:52 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:

> My proposed name `either' wasn't a good one, but `exception->either' is neither a good one and possibly worse.  Quoting the R7RS: "By convention, "->" appears within the names of procedures that take an object of one type and return an analogous object of another type."  Thus `exception->either' is a very misleading name. (By the same measures, I neither like `values->either' and hope for a better name before the final version, although it is slightly better.)
>
> `exception->either' works like some kind of guard. Maybe this can be reflected by its name.  If all exceptions were caught, `make-either' wouldn't have been such a bad name because exceptions should be the exceptional case, so `make-either' would mostly just make an Either from the values produced with the extra condition that exceptions are caught and wrapped as well.

What about `either-guard' instead?

The name `either-guard' reflects more what the procedure actually does
(as it can be defined in terms of `guard') and is way better than
`exception->either' in my opinion. However, even `either-guard' isn't
optimal because the guarded code in `guard' is just a body, while it
has to be wrapped into a lambda for `either-guard', so the same name
pattern would be used for slightly different things (reflected by the
fact that `either-guard' is a procedure and `guard' is syntax). We
could make `either-guard' into syntax (so that it takes a body instead
of a thunk). For compiler optimizations, it may even be beneficial. So
the original example would read:

(either-guard read-error?
  (read))

--
Marc