From: Rob Browning <rlb@defaultvalue.org>
Cc: Dirk Herrmann <dirk@ida.ing.tu-bs.de>, guile-devel@gnu.org
Subject: Re: expansion, memoization, and evaluation...
Date: Tue, 03 Dec 2002 22:07:33 -0600 [thread overview]
Message-ID: <8765uah1fe.fsf@raven.i.defaultvalue.org> (raw)
In-Reply-To: <xy78yz6wjc7.fsf@linnaeus.i-did-not-set--mail-host-address--so-tickle-me> (Mikael Djurfeldt's message of "Wed, 04 Dec 2002 04:31:36 +0100")
Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:
> In the on-line (interpreter) case the types are retrieved from the
> arguments and the rewrite rules depend on knowing the bindings of
> variables in the source. Yes, this is equivalent to what the current
> goops source does, although the only optimization which is done
> currently is supplying a "next-method" efficiently.
You may have already said this, but if the method is called later with
"different types", then does it have to notice that and recompute?
> In the off-line case the types would need to be supplied by
> flow-analysis in the compiler. This means that just as the
> optimizer needs to be folded into evaluation in the on-line case,
> the optimizer needs to be folded into compilation in the off-line
> case. That is, the compiler needs to supply the optimizer with
> something equivalent to what compile-method now gets from
> procedure-environment.
Ahh. Flow-analysis would be great, though I'm not sure we'd be likely
to have it immediately. Any chance some alternate optimization might
be easier when you're doing offline compilation? Unfortunately I
don't know enough about what goops is already doing to comment very
concretely yet, but I can imagine that you might be able to get
similar performance with an alternate approach when you can control
the object code you're emitting.
> Does this answer your questions?
I think so, yes, thanks.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
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 4:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-04 2:41 expansion, memoization, and evaluation Rob Browning
2002-12-04 2:57 ` Mikael Djurfeldt
2002-12-04 3:10 ` Rob Browning
2002-12-04 3:31 ` Mikael Djurfeldt
2002-12-04 4:07 ` Rob Browning [this message]
2002-12-04 7:07 ` Mikael Djurfeldt
2002-12-04 21:11 ` Rob Browning
2002-12-04 21:47 ` Mikael Djurfeldt
2002-12-05 0:07 ` Rob Browning
2002-12-05 16:27 ` Marius Vollmer
2002-12-05 17:07 ` Rob Browning
2002-12-04 8:09 ` klaus schilling
2002-12-04 10:55 ` Mikael Djurfeldt
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=8765uah1fe.fsf@raven.i.defaultvalue.org \
--to=rlb@defaultvalue.org \
--cc=dirk@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).