[Top][All Lists]
[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
- Re: bug in syncase, (continued)
- Re: bug in syncase, Lynn Winebarger, 2002/11/15
- Re: bug in syncase, Neil Jerram, 2002/11/15
- Re: bug in syncase, Marius Vollmer, 2002/11/16
- Re: bug in syncase, Neil Jerram, 2002/11/17
- Re: bug in syncase, Marius Vollmer, 2002/11/23