ChezScheme icon indicating copy to clipboard operation
ChezScheme copied to clipboard

Compile-time properties: Allow lookup on unbound identifiers

Open mnieper opened this issue 5 years ago • 3 comments

In section 11.4 of the Chez Scheme User's Reference, compile-time properties are introduced, allowing to attach properties to identifiers in a lexically scoped way.

In the current implementation, the identifier on which I want to look up a property has to be bound.

https://github.com/cisco/ChezScheme/blob/master/s/syntax.ss#L3724

I want to propose to return #f instead of raising an error to make compile-time properties more applicable. For example, consider one would like to write a pattern matcher together with a template engine akin to syntax-case/syntax. The pattern matcher could attach a property to the identifiers representing pattern variables and the template engine could check each symbol in its input whether it represents a pattern variable by checking whether it carries the property or not. This, however, can only work if the system handles the case that the identifier is not bound at all smoothly.

mnieper avatar Sep 29 '20 06:09 mnieper

I've found the exceptions raised in such cases useful for debugging, so I prefer not to make this change. The lookup routine can catch the exception, e.g., using guard, to handle the cases where one of the identifiers isn't bound:

> (top-level-program (import (chezscheme))
    (define y)
    (define x)
    (define-syntax lookup
      (lambda (x)
        (lambda (p)
          (syntax-case x ()
            [(_ id key)
             (guard (c [else "no"]) (p #'id #'key))]))))
    (define-property x y "yes")
    (pretty-print (lookup x y))
    (pretty-print (lookup q y))
    (pretty-print (lookup x q)))
"yes"
"no"
"no"

dybvig avatar Sep 30 '20 14:09 dybvig

The problem I see with such a catch-all guard is that it catches every error, which can actually make debugging harder.

If you don't want to change the current behavior, what do you think of adding an optional third argument to the lookup procedure? When present, the third argument is delivered when the identifier is not bound.

On the other hand, by signaling an error as in the current version, one can use this tool to find out whether an identifier is actually bound. (There are other ways using alias and free-identifier=?, but they are not straight-forward.)

PS I have proposed Chez's define-property for "standardization" by submitting SRFI 213. I would like to keep it in sync with Chez if possible, so I will update SRFI 213 accordingly.

mnieper avatar Sep 30 '20 15:09 mnieper

Adding an optional third argument would be fine and would allow a property value of #f to be distinguished from no property value.

dybvig avatar Sep 30 '20 18:09 dybvig