guile-devel
[Top][All Lists]
Advanced

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

Re: bug in syncase


From: Dirk Herrmann
Subject: Re: bug in syncase
Date: Sat, 23 Nov 2002 11:53:54 +0100 (CET)

On 21 Nov 2002, Neil Jerram wrote:

> >>>>> "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:
[example deleted]
> 
> In Guile (current unstable CVS):
[example deleted]
> 
> 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.

There is a mechanism in scheme that allows to prevent memoization:  eval.
If it is correct that emacs does not perform memoization, then it might be
that the whole concept of the @fop memoization is wrong.  Could you check
whether it is possible to achieve emacs' behaviour by replacing the @fop
solution by a solution based on eval (or some elisp equivalent of this)?
I would postpone working on @fop until this is solved - there are still
enough other things to do for me :-)

Best regards
Dirk





reply via email to

[Prev in Thread] Current Thread [Next in Thread]