From: Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de>
Cc: Guile Development <guile-devel@gnu.org>
Subject: Re: bug in syncase
Date: Sat, 23 Nov 2002 11:53:54 +0100 (CET) [thread overview]
Message-ID: <Pine.GSO.4.05.10211231145000.25838-100000@sallust.ida.ing.tu-bs.de> (raw)
In-Reply-To: <m3y97m8yga.fsf@laruns.ossau.uklinux.net>
On 21 Nov 2002, Neil Jerram wrote:
> >>>>> "Dirk" == Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> 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
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-11-23 10:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.GSO.4.05.10211161811180.9959-100000@sallust.ida.ing.tu-bs.de>
2002-11-17 12:11 ` bug in syncase Neil Jerram
2002-11-20 17:33 ` Dirk Herrmann
2002-11-21 17:53 ` Dirk Herrmann
2002-11-21 20:22 ` Neil Jerram
2002-11-23 10:53 ` Dirk Herrmann [this message]
2002-11-24 9:25 ` Neil Jerram
2002-11-24 10:33 ` Dirk Herrmann
2002-12-04 1:12 ` Rob Browning
2002-11-23 13:01 ` Marius Vollmer
2002-12-04 18:27 ` Carl R. Witty
2002-12-04 20:54 ` Neil Jerram
2002-12-09 20:28 ` Carl R. Witty
2002-11-14 11:59 Dirk Herrmann
2002-11-15 4:10 ` Clinton Ebadi
2002-11-15 9:29 ` Lynn Winebarger
2002-11-15 9:34 ` Lynn Winebarger
2002-11-15 19:25 ` Neil Jerram
2002-11-16 18:39 ` Marius Vollmer
2002-11-17 10:54 ` Neil Jerram
2002-11-17 20:07 ` Marius Vollmer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.GSO.4.05.10211231145000.25838-100000@sallust.ida.ing.tu-bs.de \
--to=dirk@sallust.ida.ing.tu-bs.de \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).