Re: Symbol slots

[Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se>]

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> In this case I have to re-introduce msymbols and symbol slots.

I see.  I wasn't aware that these were removed.  That may be
unfortunate from the point of view of interoperability with elisp.
It doesn't cost much in the implementation to support both light and
heavy symbols and that makes it easier to let Scheme and efficient
elisp interact in the same data space.

On the other hand, I'm not sure how important this is.  Maybe we
should wait with reintroducing them until we really see what could be
gained.

From the point of view of syncase.scm they are not needed.

> However my point of view is that using global symbol properties is at
> least dangerous.  For example you may want to create a private
> environment to map symbols to your own values---something like
> 
> (define keyword-environment (make-finite-environment))
> (environment-define keyword-environment 'set! 12)
> (environment-ref keyword-environment 'set!) -> 12
> (environment-ref (the-environment) 'set!) -> primitive syntax set!
> 
> Mabe we can use object properties or location tags instead of
> global symbol properties?

You're absolutely right that the current solution is a problem in this
case, but note that it is only a problem when you create "empty"
modules which doesn't contain the default R5RS primitives.
(Redefinition of these aren't allowed.)

However, the current syntax-case system is so much a compromise in
other ways.  (Remember that it's an attempt to paste a macro system on
top of an existing system of a totally different character.)

The worst of these problems is that bindings which the macro output
refers may not exist in the environment of its use.  Such bindings
must currently be explicitly exported along with the macro itself.

The current system is just a stand-in while we wait for the real
syntax-case system.  Radey and I have had plans for this earlier.
Hopefully we can wipe off the dust of it soon.