Hi, Yes I agree that we should have good documentation to show how to implement more advanced macros. The main reason (I beleve) for the "experts" to spend time using syntax-case let-syntax syntax-parameters etc is for yielding a user friendly framework to the user who will typically use syntax-rules. If we would stick with defmacros or define-macro we would push the burden to the novice end user and not to the expert. Now this is what hygiene buy's you, and what it cost. Sticking to define-macros would mean that we will get plenty of bug's caused by leaking macros and we would spend a considerable time on guile-user and irc to hunt down these bug's. Also In guile and most schemes we have standardized on this setup and not complying to the standard essentially means that you are out of thee cooperation.
But I think that your good point is that we should create/link to good documentation for the syntax-case system and essentially explain the model one needs to have in the head in order to use it effectively. Regards Stefan On Fri, Sep 13, 2013 at 8:40 PM, Panicz Maciej Godek <godek.mac...@gmail.com > wrote: > > Well, while syntax-rules macros are quite easy to understand > >> > (at least from the user's point of view), although sometimes a little >> > tricky, the syntax-case system I find still too difficult to use. >> > define-macro, on the other hand, is very easy to explain >> > even to beginner programmers, although the resulting macros >> > are much more difficult to analyse. >> If you, or the other people who are confused by syntax-case, can point >> to the parts of the manual that confuse you, so we can clear them up, I >> think we'd all appreciate it. >> >> > The order of presentation in the manual is that syntax-rules macros > are explained first, because they are more limited, and there's no > need to get into details regarding syntax objects. > > I used to explain the "syntax-rules" macros to my friends by > first showing "what we want to transform into what", and then packing > it up in some magic to work (because basically that's how I > understand them). The advantage was that the meaning of the macro > is readily visible and there's no need to analyse the code. > > The manual however makes very little reference to define-macro system > to explain how syntax-case works. It is easy to see that lisp programs > are lists of symbols, and so they can be processed like any other > lists of symbols before they are evaluated -- that's the essentials > of lisp macros. In case of "syntax-case" some new mysterious > notions appear: namely, the unfamous syntax objects. And while it > is easy to imagine how the list of symbols look like, all we read > about in the manual is that "the syntax expander represents > identifiers as annotated syntax objects, attaching such information > to those syntax objects as is needed to maintain referential > transparency". We don't know what sort of information is that, and > why is it better to use syntax-case over define-macro. > > Especially if we compare the "anamorphic if" definition from the > manual, > (define-syntax aif > (lambda (x) > (syntax-case x () > ((_ test then else) > (syntax-case (datum->syntax x 'it) () > (it > #'(let ((it test)) > (if it then else)))))))) > > with the most straightforward "anamorphic if" with define-macro: > > (define-macro (aif test then else) > `(let ((it ,test)) > (if it > ,then > ,else))) > > (Even if the latter is not exactly right, as is argued in section > 6.10.5, it generally does its job) > > Also, I have to admit that I still don't understand what the > syntax-case macro above is doing. Furthermore, it isn't clear why > syntax->datum takes only one argument, and datum->syntax takes > two (a syntax object and the "datum" itself) > > > >> Fundamentally, syntax-case shouldn't be harder to use than define-macro >> 99% of the time, if you remember >> >> - macros are functions from "syntax-objects" to syntax-objects >> - syntax-objects are smart symbols >> - syntax->datum to remove the smartness >> - datum->syntax is for when you want to break hygiene (but syntax >> parameters are better where applicable) >> - use quasisyntax to construct lists of syntax-objects instead of >> quasiquote to construct lists of symbols. >> > > > Maybe showing a sufficient number of examples would be > more helpful, because I haven't got a clue "where syntax > parameters are applicable" or how I could use quasisyntax > and unsyntax. > > By the way, I've had another problem when defining a macro. > I've been trying to implement something like dynamical scoping, > but such that it wouldn't require introducing global variables > > The idea is that one can write > > (with-default ((a 5)) > (define (f x) (+ x (specific a)))) > > and that later the procedure could be used like that: > (f 10) > ===> 15 > (specify ((a 20)) > (f 10)) > ===> 30 > > The first attempt was that there could be a global hash table > *specifics* that would store the lists of values, and that > "specific" could be a local macro that would expand to a hash > reference. So I tried to implement that using syntax-rules > in the following way: > > (define-syntax with-default > (syntax-rules () > ((_ ((name value) ...) > actions ...) > (let-syntax ((specific (syntax-rules (name ...) > ((_ name) > (hash-ref *specifics* 'name value)) > ;; don't mind shadowing for now > ...))) > actions ...)))) > > However, when I tried to use it, it seemed that the let-syntax > behaves as if it wasn't there (so it didn't behave at all!): > > (with-default ((a 5)) > (define (f x)(+ x (specific a)))) > > The situation was (again) resolved by creating a nasty combination > of "define-macro" and "syntax-rules", namely: > > (define-macro (with-default bindings . actions) > (match bindings > (((names values) ...) > `(let-syntax ((specific (syntax-rules ,names > ,@(map (match-lambda > ((name value) > `((_ ,name) > (hash-ref *defaults* > ',name ,value)))) > bindings)))) > ,@actions)))) > > It's not that I like it. I really don't. But I don't know how how > else this could be achieved, nor why the former solution > so stubbornly resists to work. > > Thanks, > M. > >
