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)
|
> 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