raise and raise-continuable are fundamentally different procedures.
The former is a continuation procedure that does not return. The
latter is an ordinary procedure.

From that pure point of view, it does not make much sense to conflate
them into one.

Marc

Am Mo., 27. Juli 2020 um 14:14 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> >> (raise-foreign-error alist)
> >> (raise-continuable-foreign-error alist)
>
> > This also runs against my desire to keep the top level, first class
> > part of the API as small as possible, and having each entry fan out
> > as needed.
>
> I don't understand this. (raise-foreign-error alist continuable?) takes
> two arguments, and the latter one is usually just #f (see below). For
> the user of SRFI 198, wouldn't it be simplest if no #f argument is
> needed? We could also make it an optional argument.
>
> More generally, do extra top-level procedures make an API more
> complicated compared to extra arguments? I would argue with Rich Hickey
> and Alan Perlis that an API can have any number of mutually independent
> procedures operating on the same data structure without complicating the
> API. It's only interdependent (i.e. non-orthogonal, coupled or
> "complected") things that increase complexity. Based on this reasoning,
> an extra procedure and an extra argument are equally (non-)complex ways
> of adding the same feature. An extra procedure has the advantage that
> its name says what it does, whereas you need to remember what an extra
> argument does by it position. Keyword arguments would ameliorate this
> somewhat, but we don't have those (at least not yet).
>
> > I'm making the assumption that most raised errors will
> > be non-continuable; if correct,
>
> That assumption is almost certain to be correct.
>
> > this is as simple as I can make it
> > for those writing code that uses SRFI 198.
>
> IMHO the alternatives are equally simple, but a named procedure gives an
> extra "affordance" (UI designer speak for something visible or tangible
> that guides user behavior in the right direction) compared to an unnamed
> argument.