SRFI 198: clear enough for next draft? Lassi Kortela (02 Aug 2020 11:35 UTC)
Re: SRFI 198: clear enough for next draft? hga@xxxxxx (02 Aug 2020 12:22 UTC)
Re: SRFI 198: clear enough for next draft? Lassi Kortela (02 Aug 2020 13:21 UTC)
Re: SRFI 198: clear enough for next draft? hga@xxxxxx (02 Aug 2020 15:04 UTC)
Re: SRFI 198: clear enough for next draft? John Cowan (06 Aug 2020 03:49 UTC)
Re: SRFI 198: clear enough for next draft? hga@xxxxxx (12 Aug 2020 16:56 UTC)
Re: SRFI 198: clear enough for next draft? John Cowan (06 Aug 2020 03:22 UTC)
Re: SRFI 198: clear enough for next draft? hga@xxxxxx (12 Aug 2020 16:33 UTC)
Re: SRFI 198: clear enough for next draft? John Cowan (05 Aug 2020 06:13 UTC)
Re: SRFI 198: clear enough for next draft? hga@xxxxxx (05 Aug 2020 13:11 UTC)
Re: SRFI 198: clear enough for next draft? Lassi Kortela (05 Aug 2020 15:23 UTC)
Re: SRFI 198: clear enough for next draft? hga@xxxxxx (05 Aug 2020 15:59 UTC)
Re: SRFI 198: clear enough for next draft? Lassi Kortela (05 Aug 2020 16:17 UTC)

Re: SRFI 198: clear enough for next draft? hga@xxxxxx 05 Aug 2020 15:59 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Wednesday, August 05, 2020 10:23 AM
>
> [...]
>
> >> A question: is it expected that only a single property's value
> >> requires locallization?
>
> [ We agree "no." ]
>
> So being able to localize more than just the 'message field is good, and
> it would be nice to agree on a standard calling convention.
>
> Transparently calling lambdas is a particularly nice way to solve
> problems like this, since we don't have to decide ahead of time which
> properties need a lambda (for things like localization).

That only works for the special case of a lambda that takes no
arguments, right?  Not very transparent if you know you have to hand
it a language argument....

> [ Staying out of the Scheme keyword mess. ]
>
>>>     We ***really*** want to encourage this paradigm.
>
> (I interpret this as: really want to encourage raising exceptions.)

Yes, and thus "raise-foreign-error", exactly that text since I assume
you won't be raising a non-continuable "status", and "error" makes its
purpose more clear.

> [ Examples on where and when to do which. ]
>
>> And in the SRFI text we require raise-foreign-error to
>> first call make-foreign-/whatever./
>
> Does it matter to the spec how these internals are handled?

I suppose not, it's either "do exactly what make-foreign-/whatever/
does to create the object to raise", or "call make-foreign-/whatever/
to get the object to raise."

- Harold