Re: [Scheme-reports] ANN: first draft of R7RS small language available

["Aaron W. Hsu" <arcfide@x>]

Hey Alex:

Just a few comments here...

On Thu, 21 Apr 2011 10:24:07 -0400, Alex Shinn <alexshinn@x> 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@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports