On Fri, May 6, 2011 at 3:32 AM, Aaron W. Hsu <arcfide@sacrideo.us> wrote:
> On Thu, 05 May 2011 10:05:47 -0400, Andrzej <ndrwrdck@googlemail.com>
> wrote:
>
>> To me it looks like we have two problems:
>> 1) How to clean up the existing mess in 'cond' and 'case' forms (Are
>> other forms affected? How about 'quasiquote').
>
> Mess is probably a bit of a strong word, and R6RS did provide a solution
> to it.

Yes, that indeed was too strong word. Sorry about that. My point was
that although starting from R6RS we can consider this issue as solved
(minus some namespace issues) sentences like the following (in 11.4.5)
remain:

"If all <test>s evaluate to #f, and there is no else clause, then the
conditional expression returns unspecified values; if there is an else
clause, then its <expression>s are evaluated, and the values of the
last one are returned."

> Quoted symbols simply don't work any more in the presence of module
> systems if you want to do real hygienic keyword matching. If syntax-rules
> matches its keywords by symbol instead of identifiers, you've immediately
> introduced a referential transparency bug in your code. Consider the
> following R6RS library:
>
> (library (foo)
>   (export bar)
>   (import (rnrs))
>
> (define-syntax bar
>   (syntax-rules (false)
>     [(_ false) #f]
>     [(_ e) e]))
>
> )
>
> (library (use-foo)
>   (export blah)
>   (import (rnrs) (foo))
>
> (define-syntax blah
>   (syntax-rules ()
>     [(_ id e) (let ([id e]) (bar id))]))
>
> )

Sorry, that's a misunderstanding (I do, however, appreciate your
example very much - it's very informative). By "quoted symbols" I
meant what Andre has mentioned before (I hope I don't misinterpret
it):

(define-syntax bar
  (syntax-rules (false)
    [(_ (quote false)) #f]
    [(_ e) e]))

(define-syntax blah
  (syntax-rules ()
    [(_ id e) (let ([id e]) (bar id))]))

(bar 'false) => #f
(bar expr) => expr
(blah id expr) => expr
(blah 'false expr) => syntax error in let (so the macro hygiene is
guarded by syntax)

It looks to me that this approach would result in hygienic macros
(with or without having keywords as identifiers) and has no problems
with symbol exporting.

However, after thinking about it for a moment I must agree with you -
this solution is only useful as a workaround for library implementors
(so that they don't have to worry about hygiene of macros or about
exporting symbols). To make sure that *every* macro is hygienic the
language should still use keywords as identifiers approach.

> I don't believe that any previous mistakes were made regarding this.
> Things may have been underspecified, but now we have the opportunity to
> correctly specify these in such a way that ensures hygiene is preserved by
> them. I take large issue with using any reserved keywords, as Scheme has
> no reserved keywords, anywhere.

R5RS is self conflicting - as you have pointed out matching keywords
by name is inherently unhygienic, yet that's exactly what R5RS
required. R6RS fixes it by adding an explicit clause "the described
semantics of cond is wrong, follow this example instead". Sure it
solves the fundamental issue but the description is still confusing
both to the language users and implementors.

BTW, scheme does have reserved words: ( ) [ ] #... "..." _ ... . ' ` ,
,@ +inf.0 +nan.0 etc (essentially anything that is not a valid symbol
literal). We are not having a discussion about hygiene issues with
e.g. '_' specifically because '_' is not allowed to be used as an
identifier.

> The latter solution does have some problems, which people have mentioned,
> including things like import conflicts. On the other hand, I would argue
> that these problems at least have effective work arounds, and they are
> minor in comparison with the problems of the other solutions, where you
> simply cannot solve them or work around them.

Yes, I'm also coming to the conclusion that this is a better approach.
I have no problem with it as long as R7RS specification is clear about
the semantics of COND, CASE. Another question is what to do with
symbol conflicts - I haven't thought about this issue much.

BTW, I still don't know whether we should care about UNQUOTE and
UNQUOTE-SPLICING keywords too. What should be a result of the
following:

(display (let ((unquote-splicing apply))
  `(,@(list + 1 2))))
=> (<procedure +> 1 2) ?
=> ((apply <procedure +> (list 1 2))) ?
=> ((unquote-splicing <procedure +> (list 1 2))) ? (that's what I get
in mzscheme)

Andrzej

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