[scheme-reports-wg2] Once more: identifiers vs symbols

[Marc Nieper-Wißkirchen]

Outside of library declarations and literals, identifiers in R7RS differ
from symbols in that they may be renamed due to hygienic macro expansion.
While this in general leads to the least surprises, it does not work well
with SRFI 99's record system, which needs symbols as field names and which
has already been debated here. While the power of the syntactic layer of
SRFI 99 (that is SRFI 131 plus minor additions) can be retained by using
position instead of name when subclassing (as in SRFI 136 and R6RS), even
when field names are identifiers, the procedural layer cannot distinguish
renamed symbols.

But...

Why has no one yet thought of using string literals instead of identifiers
when hygiene should not be applicable? String literals seem to possess all
the properties SRFI 99 needs for its field names and can readily be
interned via string->symbol when passing to the procedural layer so that no
performance loss occurs.

For example:

(define-record-type <parent>
(make-parent foo "bar")
parent?
(foo foo set-foo!)
("bar" bar set-bar!))

(define-record-type (<child> <parent>)
(make-child "bar" "baz")
child?
("baz" baz set-baz!))

In this example, foo can be a hygienically renamed field name (which makes
it possible that many fields of this name have been generated using
syntax-rules), while the field named "bar" can be referenced in
constructors of children.

Another advantage of this approach that it still works very well with
syntax-rules macros: These can check the equality of identifiers (in the
sense of bound-identifier=?) and also of string literals (they don't have
the power to check symbol equality, which is a disadvantage of a SRFI
99-approach without out string literals).

I think the idea above can be easily incorporated into SRFI 131 (and the
procedural layer of SRFI 99 when only string literals are used for field
names) making it compatible with R7RS again.

--

Marc

[Jim Rees]

...or SRFI-88 keywords - you would get the interning automatically.

(define-record-type <parent>
(make-parent foo bar:)
parent?
(foo foo set-foo!)
(bar: bar set-bar!))

(define-record-type (<child> <parent>)
(make-child bar: baz:)
child?
(baz: baz set-baz!))

[Cory Burgett]

I'd much rather see a macro system that supports unhygienic injection of
identifiers be added to the large language, which should be able to
accommodate this situation. I'd be okay with syntax-case, but failing that,
I think whatever system is chosen *must* be *hygienic by default* but with
some kind of fine-grained escape hatch. The only system I've seen with this
property other than syntax-case is implicit-renaming macros, but
syntax-case's pattern matching facility is rather convenient. syntax-case
has the further advantages that it's previously been standard, it's
well-researched, and a battle-tested portable implementation is readily
available.

-Cory

Post by Jim Rees
...or SRFI-88 keywords - you would get the interning automatically.
(define-record-type <parent>
(make-parent foo bar:)
parent?
(foo foo set-foo!)
(bar: bar set-bar!))
(define-record-type (<child> <parent>)
(make-child bar: baz:)
child?
(baz: baz set-baz!))
--
You received this message because you are subscribed to the Google Groups
"scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[John Cowan]

Post by Cory Burgett
I'd much rather see a macro system that supports unhygienic injection of
identifiers be added to the large language, which should be able to
accommodate this situation. I'd be okay with syntax-case, but failing that,
I think whatever system is chosen *must* be *hygienic by default* but with
some kind of fine-grained escape hatch.

You might want to look at SRFI 139, syntax parameters, which is already
implemented in Racket and Guile. It takes some wrapping your head around,
but provides an apparent (but not actual) escape from hygiene. It can't
do everything that a full low-level syntax system can, but it can do
quite a lot.
--
John Cowan http://www.ccil.org/~cowan ***@ccil.org
Please leave your values at the front desk.
--sign in Paris hotel
Check your assumptions. In fact, check your assumptions at the door.
--Cordelia Vorkosigan