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

Re: New draft

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

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

Marc Feeley <feeley@iro.umontreal.ca> 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

  (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

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?