Re: bug in syncase

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:

    Dirk> In the current implementation, the decision, how the @fop
    Dirk> expression should be changed, would be taken when foo was
    Dirk> set to 2.  In contrast, with my memoization phase I would
    Dirk> like to perform the transformation (including the expansion
    Dirk> of the transformer-macro expression) at the point where bar
    Dirk> gets defined.

    Dirk> In other words: Are there any statements about _when_ the
    Dirk> expansion of the @fop macro and the transformer-macro should
    Dirk> happen?

I would say that there are no statements except that transformed Elisp
code should behave in the same way as Emacs.

In Emacs:

(setq foo 1)
1
(defun fn () 'function-value)
fn
(defun bar () (if (= foo 2) (fn)))
bar
(bar)
nil
(defmacro fn () ''macro-value)
fn
(bar)
nil
(setq foo 2)
2
(bar)
macro-value
(defun fn () 'function-value)
fn
(bar)
function-value

In Guile (current unstable CVS):

guile> (use-modules (lang elisp base))
guile> (define-module (lang elisp base))
#<directory (lang elisp base) 4033e1f0>
guile> (setq foo 1)
1
guile> (defun fn () 'function-value)
fn
guile> (defun bar () (if (= foo 2) (fn)))
bar
guile> (bar)
#nil
guile> (defmacro fn () ''macro-value)
guile> (bar)
#nil
guile> (setq foo 2)
2
guile> (bar)
macro-value
guile> (defun fn () 'function-value)
fn
guile> (bar)
macro-value

So Guile as it stands is already wrong in the last result.  It looks
as though Emacs behaves as though there is no memoization at all.

It strikes me that macros have two meanings that are confused.

1 is to prevent automatic evaluation of arguments.

2 is to gain execution efficiency by expanding/transforming code at
read time.

Apparently Emacs does 1 but not 2.  I wonder if Guile's macros should
offer explicit control over which of 1 and 2 should apply.

        Neil