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

This page is part of the web mail archives of SRFI 13 from before July 7th, 2015. The new archives for SRFI 13 contain all messages, not just those from before July 7th, 2015.

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