Hey Alex:

Just a few comments here...

On Thu, 21 Apr 2011 10:24:07 -0400, Alex Shinn <alexshinn@gmail.com> wrote:

> Wel, you've just changed my question - it is not whether
> new bindings are created or not at the implementation
> level, but whether as I said they are the same

I am actually really curious about this. In every implementation with
which I am familiar, importing a binding from a library results in the
same lexical binding. I believe that Andre's second example with MATCH is
an interesting one and I am interested to know how you deal with such a
thing in Chibi. In fact, could you explain in detail how such an
implementation works when it doesn't actually result in the same lexical
bindings? How can it make the match example work?

> The Chibi algorithm is a little unusual, and I may need to
> change it depending on what we do with the standard, but
> I happen to like it a lot.  Whereas in Chez all identifiers are
> effectively bound in the top-level (whether they really are or
> not), in Chibi all identifiers are effectively _unbound_ at the
> top-level.  This means you can import multiple macros using
> the same keywords and not have to rename them, whether
> the keywords are bound or not - it just works.

Just to be clear, I'd like to point out the section in the Chez Scheme
User's Guide that discusses the rationale and the more precise description
of what happens at the interactive top level of Chez Scheme:

http://www.scheme.com/csug8/use.html#./use:h3

In particular, this is done to support mutual recursion. How does Chibi
handle this?

> The option of _not_ renaming I consider to be far more
> important than the ability to rename.  I had honestly never
> considered that you might want to rename deliberately, and
> I see now that might have uses, but it seems the most
> common use will be to avoid conflicts from macros using
> the same keywords.  There are many macros out there
> using common keywords like ":" and "<=", and it's a real
> pain not to be able to use them together without renaming
> one.  You have to keep in mind all the renamings as you
> look at the code, and can't cut&paste examples.

To draw on my experience, I can say that I have never had a conflict
between any of my auxiliary keywords in my use of R6RS, and I have never
had to rename them; I have found more than a few times where I have wanted
to rename them for other purposes, and I was glad that they were
explicitly exported so that I could do this. On the other hand, I have
found the semantics to be quite useful in doing macros that provide
internal functionality as part of their design, without exposing the
internal mechanism to the world. I would want to make sure that the
semantics we define makes it possible for me to continue to do this.
Specifically, something like:

(define-syntax blah
   (syntax-rules (%)
     [(_ % internal representation here) ---] ...
     [(_ main interface here) ---]))
(define-syntax % ---)

I then export only blah, and this makes sure that no one can ever access
the internal interface directly.

> And then there are the special keywords: quote, unquote,
> etc.  If you rename these you can't use the reader shortcuts,
> so when you mix macros that rely on them the syntax
> because a lot more clumsy than usual.

I am not sure what your point is here. I could see an argument for why you
might not want to rename quote, et al., but not a reason that we should
not make it possible to rename them. I actually do a lot of this kind of
thing (mixing and matching quotes and renaming them, and so forth) in
ChezWEB, and while I have to make sure that I remember what ' and ` and so
forth do, I have not found it inherently clumsy.

> This is a very broken state of affairs, and we need to
> explore better ways of handling it.  For example, it might
> be worth allowing import "merging" of keywords, so the same
> keyword can work with multiple macros, but having the binding
> of only one or zero of the macros.

I cannot help but feel extremely nervous about this direction. What do
current implementations do, and how are they supported?

> Pending a better way to deal with keywords, I want to
> leave the standard as open as possible.

But it does seem like you are closing some options off. By not explicitly
exporting keywords, you are limiting some things that users can do. For
example, I could disable the => syntax from all the macros by simply not
importing it if => were exported explicitly. If not, then I would have to
artificially define => in my importing environment, which feels much more
like a hack; that is, I feel like I shouldn't have to do that.

> Note the ability to rename and the option to not rename are
> not mutually incompatible.  Chicken works similar to Chibi
> except that it allows renaming (even if the identifiers aren't
> bound).  I think this may be the best of all worlds.

Could you explain this? I don't understand exactly what you mean here
either.

	Aaron W. Hsu

--
Programming is just another word for the lost art of thinking.

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports