[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How many arguments to a macro transformer?



 Apologies for the imcomplete message - my mail program had a hiccup and
 sent the message off unsolicited...

 
   Thanks again for the comments, Keith.  For those who may be puzzled,
   they refer to an updated version of the SRFI that is available at 
   
     http://www.het.brown.edu/people/andre/macros/srfi-72.html
     
   until the editor has had a chance to update the official page.  
  
   > I got the new version 1.9, merged it with the changes I had
   > made, and tried the result on the old test cases.  I noticed
   > that the old test sequence started with the definition of
   > |swap!| and then went on to
   > 
   >   ;; This macro may also be expressed as:
   >   
   >   (define-syntax swap!
   >     (lambda (form)
   >       (let ((a (cadr  form))
   >             (b (caddr form)))
   >         `(,(syntax let) ((,(syntax temp) ,a))
   >           (,(syntax set!) ,a ,b)
   >           (,(syntax set!) ,b ,(syntax temp))))))
   >
   > This second form has been removed from the new test sequence.
   > Indeed, it does not seem to work anymore.  Is it broken on
   > purpose, or have I got something screwed up again?
   
   No, it is broken on purpose.  The model changed a little from the 
   previous version.  Now, for increased safety, identifiers can only 
   capture each other if they were introduced in a single evaluation of 
   a SYNTAX or QUASISYNTAX expression.  So the two instances of TEMP above are 
   actually different and the expanded code will fail. 
   
   One could still make QUASISYNTAX macro-expressible by 
   introducing a form, maybe called WITH-SINGLE-RENAMING-FUNCTION
   (the opposite to WITH-FRESH-RENAMING-SCOPE of the previous version)
   that overrides this default in the obvious way, so that one would write  
   
      (define-syntax swap!
        (lambda (form)
          (let ((a (cadr  form))
                (b (caddr form)))
            (with-single-renaming-function    
             `(,(syntax let) ((,(syntax temp) ,a))
               (,(syntax set!) ,a ,b)
               (,(syntax set!) ,b ,(syntax temp)))))))
  
   I considered addihg such a form, but then realized that it is the same as 
   the trivial combination (quasisyntax (unquote ...)), i.e.,
   
      (define-syntax swap!
        (lambda (form)
          (let ((a (cadr  form))
                (b (caddr form)))
            (quasisyntax   
             ,`(,(syntax let) ((,(syntax temp) ,a))
                (,(syntax set!) ,a ,b)
                (,(syntax set!) ,b ,(syntax temp))))))))
   
   so one might as well introduce quasisyntax from the beginning and
   avoid polluting the namespace with an extra form that would never be
   used except for implementing quasisyntax.  (An advantage of the current
   choice is that with-fresh-renaming-scope is no longer necessary and has 
   been dropped).  
    
   > KW > The appendix of R4RS says that it has been suggested (it doesn't
   > KW > say by whom) that #'<datum> and #`<datum> would be felicitous
   > KW > abbreviations for (syntax <datum>) and (quasisyntax <datum>).
   > KW > Could this be added to the SRFI?
   > >  
   > >  I will add that as a recommendation in the next revision.
   > 
   > Did that happen?  I don't see it.
   
   Sorry - it slipped under the radar.  I'll put it in the following version.
   
  
   > >    * I am specifying an improvement in the semantics of syntax-case
   > >      for better hygiene.
   > 
   > That's good (I think).  So when you are discussing that improvement
   > you certainly need to put what you are discussing into the examples.
   
   
   Actually, in the new version the hygiene modification is now 
   orthogonal to syntax-case, so this particular reason falls away.  
   
   
   > >    * A proposal that does not come with some form of pattern matching 
   > >      won't be regarded as usable by many Schemers.  
   > 
   > They will certainly demand that you _can_ implement pattern matching
   > in your system, but if your system does no more than provide an
   > implementation of syntax-case then they are likely to stay with
   > their own implementation.  In order to understand and love
   > the proposal it would be good to have as many examples as
   > possible of the new stuff.
   
   Agreed.  I have replaced some examples that did not need pattern matching
   for clarity.  The reference implementation comes with some more, but they
   are mixed in with syntax-case examples.  Maybe I whould put in more 
   examples in the document - though the length is becoming a problem.
   A separate tutorial might be also be a good idea.  
   
   In the "improved hygiene" section, I used mostly syntax-rules and 
   syntax-case examples so that 
   
    * people could run them on existing implementations and see the results
    * people could see that the proposed improvements can be integrated
      in syntax-case even if they are not interested in the rest of the 
      proposal
 
   > By the way, the changes I have made to your code are to
   > make a version of simple-macros.scm with the modules
   > ripped out.  This is not because I think modules are a bad
   > idea, I am just trying to understand macros by boiling
   > the implementation down to its bare core.  So I need test
   > cases that use only the core constructs.
   
   The tests file has quite a number of these (though not enough, I admit).
   You just have to sort them out, I'm afraid.  
   
   > KW > The link to Andrew Wright's pattern matcher
   > KW >  http://download.plt-scheme.org/.../match.ss
   > KW > at the end of kffd-match-tut.htm seems to be broken.
   > >  
   > >  Thank you - I removed it.  
   > 
   > Is it still available anywhere else?  I would like to know
   > what you had to change to adapt the run-time pattern matcher to
   > work with macros.  
   
   
   See for example,
   
     http://sol.cs.wcu.edu/~bhauman/scheme/pattern.php
   
   which has links to the original documentation.
   
   I only added one pattern: (syntax id) that will match 
   id using literal-identifier=?  That's the only addition. 
   
   
   > Is there any reason that there could not
   > be one matcher for both purposes?  
   
   
   That is indeed a more minimalistic solution.
   
   Cheers
   Andre