[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: feeley@xxxxxxxxxxxxxxxx*Subject*: Re: optional argument notation*From*: shivers@xxxxxxxxxxxxx*Date*: Mon, 18 Dec 2000 16:13:52 -0500*Cc*: srfi-14@xxxxxxxxxxxxxxxxx, srfi-13@xxxxxxxxxxxxxxxxx*In-reply-to*: <200012182058.eBIKw2L27020@xxxxxxxxxxxxxxxxxxxxx> (message from Marc Feeley on Mon, 18 Dec 2000 15:58:02 -0500)*References*: <200012182058.eBIKw2L27020@xxxxxxxxxxxxxxxxxxxxx>*Reply-to*: shivers@xxxxxxxxxxxxx

I notice that in all of your documents (including SRFI-1) you use this notation for optional arguments: string-hash s [bound start end] -> integer I find this notation to be missleading because it suggests that you can only pass one or four parameters (but I believe you want 1, 2, or 4). So you should write: string-hash s [bound [start end]] -> integer It must be misleading, since you got it wrong both ways! a [b c d] means these are all OK: a a b a b c a b c d I find the pedantic alternative of writing, e.g., string-hash s [bound [start [end]]] -> integer too ugly and hard to parse. If there *were* a case where optional args were "chunked," it would be rare enough that I could simply mention it in the accompanying text. I will add a little explanatory paragraph to the SRFIs describing the meaning of this notation. How's that? -Olin

**Follow-Ups**:**Re: optional argument notation***From:*Marc Feeley

**References**:**optional argument notation***From:*Marc Feeley

- Prev by Date:
**optional argument notation** - Next by Date:
**Re: predicate->char-set considered harmful** - Previous by thread:
**optional argument notation** - Next by thread:
**Re: optional argument notation** - Index(es):