Re: [Chicken-users] need help with hygienic macros

[Jörg F . Wittenberger]

On May 12 2013, Peter Bex wrote:

> On Sun, May 12, 2013 at 06:57:12PM +0200, Jörg F. Wittenberger wrote:
> > The idea is to have a definer, `deftig` here, which only abstracts the
> > argument list of the defined procedure away.  Here a literal of the
> > original macro (as used in a limited/extended XSLT implementation to be
> > changed).
> >
> > (define-macro (define-transformer symbol . body)
> >  `(define (,symbol
> >            place
> >            message
> >             root-node
> >            variables
> >             namespaces
> >            ancestor
> >            self-node
> >            nl
> >            mode-choice
> >            proc-chain
> >            ) . ,body))
> >
> > The code references those parameters by their name, with all
> > the downsides of unhygienic macros.
>
> This is indeed fundamentally unhygienic.

That's what's to be replaced.

> > To get rid of the predefined-to-be-kept-in-head list of arguments,
> > I want better macros.  All arguments not changed by keyword to
> > `xml-walk-down` (which would be `foo` or `gosh` in my example) shall
> > just use the values from the enclosing `deftig`.  (Let alone that I can
> > probably sort out keyword-value-pairs from `foo`.)  `gosh` BTW
> > simulates a macro to access a parameter from the procedure defined
> > by `deftig`.  I don't mind it being either `gosh` or `(gosh)`; a one-time
> > change in the source doesn't matter.  BUT the actual argument list
> > of procedures defined by `deftig` is supposed to change without
> > touching every use of `deftig`.  Therefore access to those arguments
> > shall be done by sub-macros (reasonably) available (only) within
> > the body of `deftig`-defined procedures.
>
> That does sound a lot like parameters.  Why not simply parameterize
> the parameters based on arguments to your macros?

Hm, wait... you're not talking about parameterize as in srfi-39 do you?

a) Way too much overhead.
b) no way: atop of the usually straight-forward evaluation it's sometimes
  subject to delay'ed evaluation... (see my other message to 
chicken-hackers
  about how to make a single `(delay <expr>)` being evaluated as often
  as you want just to discard all but the fastest result (nevertheless
  still incurring all the effort to evaluate those results, which never
  take an effect besides the side-effects; and yes... we are talking
  about the same code here.  The xslt-impl. I want to clean up
  does xslt:for-each in one thread per selected element and goes
  though some length to avoid the use of a simple `delay` for
  xsl:variable's since this doesn't work as expected.).

Na; I rather continue to live the the unhygienic macro.
BUT: I hate it!
Just: I can't help myself… :-/

> Cheers,
> Peter