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

Re: Alternative formulations of keywords

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 12-Apr-06, at 8:16 AM, John Cowan wrote:

Marc Feeley scripsit:

If you try to formalize the cases in which it does work and the cases
in which it doesn't you will realize that it is very hard to specify
precisely.  You have to assume a particular set of powerful analyzes
that are performed by the compiler, and your semantics will depend on
the existence of these analyzes.  This places difficult constraints
on the Scheme implementation.

It's syntactic sugar, so I'm fine with it not working in any case that's
at all tricky.

Please define precisely what is a "tricky case". If you do this exercice you will see that it is very hard to formalize a compile time only mechanism for named optional parameters that is useful.

For example can your proposed approach work in this case:

   (define (f g)
     (g foo: 11 bar: 22))

Plainly no. The compiler should cough with "keywords in call of unknown

or in this case:

   (define (f #!key (x 11) (y 22)) (+ x y))
   (define (g z) (f y: z))
   (define (h) (set! f (lambda (#!key (y 33) (z 44)) (* y z))))

Again, plainly no.  I might have said "only if the compiler can prove
that h is always called before g is", but that's precisely the sort
of tricky analysis neither of us would want to depend on.

Here the error is "keyword y: not known for function f."

In short, the definition of a function must be either global or
lexically apparent for it to be callable with keywords.

Most Scheme systems allow separate compilation (think of "load"). If one file contains:

(define (f #!key (x 11) (y 22)) (+ x y))
(define (g z) (f y: z))

and the other contains:

(set! f (lambda (#!key (y 33) (z 44)) (* y z)))

You have the same problem. So it doesn't suffice for the function definition to be global.

The way I see it you are forbidding the use of higher-order functions in combination with named optional parameters. That would be a serious limitation for a functional language like Scheme.