From: cwitty@newtonlabs.com (Carl R. Witty)
Cc: Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de>,
Guile Development <guile-devel@gnu.org>
Subject: Re: bug in syncase
Date: 04 Dec 2002 10:27:52 -0800 [thread overview]
Message-ID: <v4jlm35tz9z.fsf@newtonlabs.com> (raw)
In-Reply-To: Neil Jerram's message of "21 Nov 2002 20:22:45 +0000"
Neil Jerram <neil@ossau.uklinux.net> writes:
> I would say that there are no statements except that transformed Elisp
> code should behave in the same way as Emacs.
...
> 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.
Emacs does not do memoization during eval; macros are re-evaluated
every time they are encountered. However, if you byte-compile a
function (typically by byte-compiling an entire file at install time,
although it's also possible to byte-compile an individual function at
run time), macros are expanded during the byte-compilation process.
This means that Emacs Lisp code which is to run correctly both
interpreted and compiled must be insensitive to when or how often
macro expansion is done; such code -- which includes virtually all
distributed Emacs Lisp code, I would think -- would also work if macro
expansion were memoized. The interactive development process would be
different, though; for a complete clone of Emacs, including the
development process, you would want to have an eval that does no
memoization and some sort of separate compilation phase.
The above is how GNU Emacs 19.x worked, but I would be surprised if
any of the branches or later versions were different.
Carl Witty
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-12-04 18:27 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
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 [this message]
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=v4jlm35tz9z.fsf@newtonlabs.com \
--to=cwitty@newtonlabs.com \
--cc=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).