Email list hosting service & mailing list manager

New draft Marc Feeley (05 May 2006 20:40 UTC)
Re: New draft Jorgen Schaefer (07 May 2006 23:50 UTC)
Re: New draft Marc Feeley (08 May 2006 11:42 UTC)
Re: New draft Jorgen Schaefer (08 May 2006 13:51 UTC)
Re: New draft felix winkelmann (08 May 2006 03:49 UTC)

Re: New draft Marc Feeley 08 May 2006 11:42 UTC

On 7-May-06, at 7:50 PM, Jorgen Schaefer wrote:

> Marc Feeley <> writes:
>> The new syntax does away with the `#!optional', `#!key' and `#!rest'
>> markers.  Instead, a syntax that is inspired from EBNF is used to
>> denote optional parts (square brackets in the parameter list around
>> the optional parameters).
> Considering that R6RS will standardize brackets as being
> equivalent to parentheses[1], this SRFI will also allow
>   (define (myproc required (optional #f) (key: key #t))
>     ...)
> I assume this is intended, and I want to state that I like this
> syntax, and I definitively prefer it very much over the old.

Yes with SRFI 89 the definition above is equivalent to

   (define (myproc required [optional #f] [key: key #t])

but as a matter of style, the version with brackets is preferred
because it highlights the optional nature of parameters optional and
key.  Note that this SRFI mandates the proposed R6RS treatment of
square brackets, so there is no issue with portability (if a system
supports SRFI 89, square brackets can and should be used).

> It /might/ be preferable to some people if this SRFI would specify
> LAMBDA-KW and DEFINE-KW special forms (the names up for debate of
> course) instead of shadowing R5RS’ forms. A useful module system
> can be used to explicitly shadow the R5RS forms if someone
> requires the extended capabilities in LAMBDA and DEFINE itself.

I know that some people may prefer this and I have explained before
why I am against it.  I want to improve the Scheme language, not
create a new language.

> This SRFI allows the following function definition:
>   (define (foo (bar: bar 2) (baz 3))
>     ...)
> But for this procedure, it would disallow the analogical
> invocation:
>   (foo bar: 5 'baz-value)
> In this example, BAZ is bound to the keyword BAR:, and the
> application then is invalid due to too many arguments. To make
> this dependence on order explicit, I think it would be useful to
> only allow optional arguments to be specified before keyword
> arguments.

I don't see why you would think that this call is invalid.  If you
try the reference implementation you will get:

(define (foo [bar: bar 2] [baz 3])
   (list 'bar= bar 'baz= baz))

(foo bar: 5 'baz-value) ==> (bar= 5 baz= baz-value)
(foo baz-value)         ==> (bar= 2 baz= baz-value)

Perhaps the SRFI spec is unclear.  Can you help me understand why you
interpreted the spec incorrectly so that I can improve the spec?