seeds Alex Shinn 08 Oct 2015 05:03 UTC
Re: seeds taylanbayirli@xxxxxx 08 Oct 2015 07:55 UTC
Re: seeds Arthur A. Gleckler 08 Oct 2015 17:46 UTC
Re: seeds taylanbayirli@xxxxxx 08 Oct 2015 19:38 UTC
Re: seeds Arthur A. Gleckler 08 Oct 2015 21:47 UTC
Re: seeds taylanbayirli@xxxxxx 09 Oct 2015 08:09 UTC
Re: seeds Kevin Wortman 09 Oct 2015 17:18 UTC
Re: seeds taylanbayirli@xxxxxx 09 Oct 2015 18:33 UTC
Re: seeds Kevin Wortman 13 Oct 2015 17:36 UTC
Re: seeds taylanbayirli@xxxxxx 13 Oct 2015 18:28 UTC
Re: seeds Alex Shinn 14 Oct 2015 01:59 UTC
Re: seeds taylanbayirli@xxxxxx 14 Oct 2015 09:09 UTC
Re: seeds taylanbayirli@xxxxxx 14 Oct 2015 10:06 UTC
Re: seeds Alex Shinn 16 Oct 2015 01:23 UTC
Re: seeds taylanbayirli@xxxxxx 16 Oct 2015 13:34 UTC
Re: seeds Alex Shinn 16 Oct 2015 23:48 UTC
Re: seeds taylanbayirli@xxxxxx 17 Oct 2015 12:08 UTC
Re: seeds Alex Shinn 17 Oct 2015 13:12 UTC
Re: seeds taylanbayirli@xxxxxx 17 Oct 2015 14:09 UTC
What SRFIs are for John Cowan 17 Oct 2015 14:41 UTC
Re: What SRFIs are for taylanbayirli@xxxxxx 17 Oct 2015 15:56 UTC
Re: What SRFIs are for John Cowan 17 Oct 2015 16:55 UTC
Re: What SRFIs are for taylanbayirli@xxxxxx 17 Oct 2015 18:08 UTC
Re: What SRFIs are for John Cowan 17 Oct 2015 18:51 UTC
Re: seeds John Cowan 15 Oct 2015 17:49 UTC
Re: seeds Alex Shinn 09 Oct 2015 02:54 UTC
Re: seeds taylanbayirli@xxxxxx 09 Oct 2015 07:59 UTC
Re: seeds John Cowan 15 Oct 2015 17:51 UTC
Re: seeds taylanbayirli@xxxxxx 15 Oct 2015 23:08 UTC
Re: seeds John Cowan 16 Oct 2015 13:09 UTC
Re: seeds taylanbayirli@xxxxxx 16 Oct 2015 14:01 UTC

Re: seeds John Cowan 15 Oct 2015 17:49 UTC

Kevin Wortman scripsit:

> Well, IIRC Alex Shinn has already proposed a procedure-based API and
> reiterated it several times. And the only complaint lodged against using a
> parameter object seems to be that referencing it costs one procedure call,
> which seems perfectly acceptable for an infrequent operation in a
> functional-leaning language.

The procedure-based API is ideal, except for its lack of backward
compatibility.  Because a Scheme procedure with a functional argument
cannot tell how that functional argument can be safely called, it
must call it blindly according to some fixed protocol.  That means,
for example, that if you have written a hash function that accepts one
argument (the dead minimum) and you pass it to a hash table creator
that expects to pass three arguments to a hash function, or vice versa,
you are hosed.

If Scheme implemented arity inspection akin to SRFI 102, this would not
be a problem: the hash table constructor could inspect the hash function
and safely decide how many arguments to call it with.

(A plausible candidate would be Dybvig's counter-proposal as simplified
by Van Horn:  (procedure-arity proc) returns a exact integer such that the
b'th bit of the result is 0 if b arguments are not acceptable, and 1 if b
arguments are acceptable.  The bits are numbered from 0 in little-endian
order, and the arguments are also numbered from 0.  So the result 0
means that there is no number of arguments that is acceptable:  1, 2, 4,
8 ... means that exactly 1, 2, 3, 4 ... arguments are acceptable, and -1,
-2, -4, -8 means that 0, 1, 2, 3 or more arguments are acceptable.)

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Monday we watch-a Firefly's house, but he no come out.  He wasn't home.
Tuesday we go to the ball game, but he fool us.  He no show up.  Wednesday he
go to the ball game, and we fool him.  We no show up.  Thursday was a
double-header.  Nobody show up.  Friday it rained all day.  There was no ball
game, so we stayed home and we listened to it on-a the radio.  --Chicolini