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

*To*: shivers@xxxxxxxxxxxxx*Subject*: Re: optional argument notation*From*: Marc Feeley <feeley@xxxxxxxxxxxxxxxx>*Date*: Mon, 18 Dec 2000 16:35:24 -0500*Cc*: srfi-14@xxxxxxxxxxxxxxxxx, srfi-13@xxxxxxxxxxxxxxxxx*In-reply-to*: <200012182113.QAA05432@xxxxxxxxxxxxxxxxxxxxxxx> (shivers@xxxxxxxxxxxxx)*References*: <200012182058.eBIKw2L27020@xxxxxxxxxxxxxxxxxxxxx> <200012182113.QAA05432@xxxxxxxxxxxxxxxxxxxxxxx>

> 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? By doing this you will be going against a long standing standard (BNF, etc). So my preference is that you use the pedantic form string-hash s [bound [start [end]]] -> integer Otherwise, why don't you use a different kind of parens, for example string-hash s {bound start end} -> integer or even a marker such as string-hash s #!optional bound start end -> integer Marc

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

**Re: optional argument notation***From:*shivers

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