Re: HTTP error codes
hga@xxxxxx
(03 Aug 2020 16:47 UTC)
|
Re: HTTP error codes
John Cowan
(03 Aug 2020 17:04 UTC)
|
Re: HTTP error codes
John Cowan
(03 Aug 2020 17:07 UTC)
|
Complexity of SRFI 198 interface and naming Lassi Kortela (03 Aug 2020 17:15 UTC)
|
Re: Complexity of SRFI 198 interface and naming
hga@xxxxxx
(03 Aug 2020 17:52 UTC)
|
Re: Complexity of SRFI 198 interface and naming
Lassi Kortela
(03 Aug 2020 18:12 UTC)
|
Re: Complexity of SRFI 198 interface and naming
John Cowan
(04 Aug 2020 15:52 UTC)
|
Re: Complexity of SRFI 198 interface and naming
hga@xxxxxx
(04 Aug 2020 16:24 UTC)
|
Re: Complexity of SRFI 198 interface and naming
Lassi Kortela
(04 Aug 2020 16:36 UTC)
|
Re: Complexity of SRFI 198 interface and naming
John Cowan
(05 Aug 2020 02:30 UTC)
|
Re: Complexity of SRFI 198 interface and naming
John Cowan
(03 Aug 2020 17:53 UTC)
|
Re: Complexity of SRFI 198 interface and naming
Lassi Kortela
(03 Aug 2020 18:06 UTC)
|
> If there's one or more args, the lambda is called with them. But we were planning on a convention of having most lambda values not take any args to avoid complexity, so what should the above do when the value is a lambda and there are no args? Being able to get the lambda could be useful; maybe have a special arg like #t call it without args? That's ugly, have only just now been thinking about this, so I solicit suggestions. I'd vote to do nothing special. People who want to make a foreign error object with a lambda as one of the values can wrap it in (lambda () the-lambda-i-want-to-return). Would this cause a problem in some situation? > I think the best thing is foreign-condition-ref/procedure, which > does not take args. It returns a procedure that does take args, > like this: Why the extra complexity of an additional procedure? I think your reading level precludes you from noticing the problem with the long names and big words. That's 4 separate words in the name of one procedure, and "foreign" and "ref" are the only ones whose complexity is commensurate to the complexity of the task at hand.