From: Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de>
Subject: scm_lookupcar
Date: Tue, 25 Jun 2002 22:55:51 +0200 (CEST) [thread overview]
Message-ID: <Pine.GSO.4.05.10206252155500.1223-100000@sallust.ida.ing.tu-bs.de> (raw)
Hi folks,
thinking of incremental steps to separate memoizing and execution, I think
that the current function scm_lookupcar should be split up:
* split the functionality of scm_lookupcar into the following subtasks:
a) a function to transform a symbol into its memoized form:
static SCM symbol2memoized_symbol (SCM symbol, SCM environment);
The function searches the environment for the symbol and returns either a
variable or an iloc (later, a macro object may also be returned). If the
search was not successfull, SCM_UNDEFINED is returned. This function
only delivers the memoized object that could replace the symbol, but it
does not actually change any code. The idea is, that this function will
be used during memoization, but won't have to deal with actual values any
more.
b) a function, that looks up a symbol and automatically memoizes it:
static SCM memoize_symbol_in_car (SCM pair, SCM environment);
The symbol to be looked up is found in the car of the pair. The function
makes use of the function a) to look up the symbol. If the result from
a) is not SCM_UNDEFINED, the car of the pair is overwritten, otherwise it
remains unchanged. The function returns the result that was received
from a).
c) a function that for a variable or an iloc returns a SCM* pointing to the
location of the corresponding value:
static SCM* memoized_symbol2location (SCM obj, SCM environment);
d) a function that for a variable or an iloc returns the value:
static SCM memoized_symbol2value (SCM obj, SCM environment);
e) a function, similar to scm_lookup_car:
static SCM lookup_and_memoize_symbol_in_car (SCM pair, SCM environment);
The functionality is similar to scm_lookupcar, but instead of returning a
pointer to a value, the value itself is returned.
Using these functions, scm_lookupcar can be easily re-implemented. Further,
a lot of code that uses scm_lookupcar can be replaced using these functions.
A negative impact of this change is, that it will slow down memoization a
little bit, since in case of an iloc the environment is scanned twice to
actually obtain the result for scm_lookupcar: First, in function
symbol2memoized_symbol the environment is scanned to obtain the iloc,
second, in function memoized_symbol2location the environment is scanned
according to the iloc data.
I will add these thoughts to workbook/compilation/evaluation.txt.
Best regards,
Dirk Herrmann
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
reply other threads:[~2002-06-25 20:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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.10206252155500.1223-100000@sallust.ida.ing.tu-bs.de \
--to=dirk@sallust.ida.ing.tu-bs.de \
/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).