unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Tom Lord <lord@regexps.com>
Cc: djurfeldt@nada.kth.se, owinebar@free-expression.org,
	dirk@sallust.ida.ing.tu-bs.de, neil@ossau.uklinux.net,
	guile-devel@gnu.org, djurfeldt@nada.kth.se,
	djurfeldt@nada.kth.se
Subject: Re: goops and memoization
Date: Tue, 3 Dec 2002 18:49:59 -0800 (PST)	[thread overview]
Message-ID: <200212040249.SAA24200@morrowfield.regexps.com> (raw)
In-Reply-To: <xy7heduwmds.fsf@linnaeus.i-did-not-set--mail-host-address--so-tickle-me> (message from Mikael Djurfeldt on Wed, 04 Dec 2002 03:25:51 +0100)



       > Have you considered the approach of writing a custom optimizer (not O,
       > but another optimizer) that can do a good job of "compiling" (scheme
       > to scheme):
       >
       >
       > 	(lambda (ms) (M (O (U ms))))
       >
       > ?


       Hmm... could you please clarify this suggestion.  What is the
       core idea?  To specify O in a custom language and compile it?
       To optimize the composition of M O and U?  Something else that
       I have missed?


O, I am presuming, optimizes method selection, presumbably by ordering
tests of argument types in favorable orders and by generating
special-case tests where, otherwise, a generic search would be
required.   Have I missed something?

So, O is a fairly straightforward scheme->scheme transform.  It can
almost certainly be expressed in very regular form (a "custom
language" (such as a pattern-matching macro plus quasiquote) -- or
simply a narrow Scheme subset).

M and U are similar.

You can write them as three separate functions, and write a customized
optimizer that folds them together.  It might even be able to take
advantage of non-general optimizations that apply only to these
functions.

You could look at the custom optimizer as a constant-folding exercise,
an abstract-evaluation exercize, or a partial-evaluation exercize
(where you are partially evaluating "(apply (compose M O U)
free-ms)").

The reason I think this is a plausible approach is just that the three
transforms involved (M O and U) don't need to be arbitrary code -- you
can do very well here just by thinking of them as pattern-matching
rewrite systems -- and such systems compose cleanly and should be easy
to optimize.

Clearer?  or did I just make it worse :-)


(I used to suspect that Aubrey secretly generated `eval' using
techniques along these lines but eventually concluded: nah, he just
writes very consistent code. :-)

-t



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


  reply	other threads:[~2002-12-04  2:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.GSO.4.05.10212011757340.18607-100000@sallust.ida.ing.tu-bs.de>
2002-12-01 18:00 ` goops and memoization Neil Jerram
2002-12-02  8:45 ` Mikael Djurfeldt
2002-12-02  9:14   ` Mikael Djurfeldt
2002-12-03  0:13   ` Lynn Winebarger
2002-12-03  7:59     ` Mikael Djurfeldt
2002-12-03  8:38       ` Tom Lord
2002-12-04  2:25         ` Mikael Djurfeldt
2002-12-04  2:49           ` Tom Lord [this message]
2002-12-03 17:17       ` Lynn Winebarger
2002-12-04  2:41         ` Mikael Djurfeldt
     [not found] <Pine.GSO.4.05.10212021836430.21423-100000@sallust.ida.ing.tu-bs.de>
2002-12-04  2:19 ` Mikael Djurfeldt
     [not found] <Pine.GSO.4.05.10212021650410.21423-100000@sallust.ida.ing.tu-bs.de>
2002-12-04  1:53 ` Mikael Djurfeldt
2002-12-04  2:38   ` Tom Lord
2002-12-04  2:56   ` Rob Browning
2002-11-16 13:41 Dirk Herrmann
2002-11-17 10:56 ` Neil Jerram
2002-11-20 18:11   ` Dirk Herrmann
2002-11-21  3:11     ` Mikael Djurfeldt
2002-11-21  3:28       ` Mikael Djurfeldt
2002-11-21 23:50         ` Neil Jerram
2002-11-22  1:08           ` Mikael Djurfeldt
2002-11-22  1:13             ` Mikael Djurfeldt
2002-11-24  9:41               ` Neil Jerram
2002-11-24 16:32                 ` Mikael Djurfeldt
2002-11-21 20:31       ` Neil Jerram
2002-11-22  0:49         ` Mikael Djurfeldt
2002-11-29 22:48       ` Neil Jerram
2002-11-29 23:31         ` Neil Jerram
2002-11-21 20:36     ` Neil Jerram
2002-11-24 16:42       ` Dirk Herrmann

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=200212040249.SAA24200@morrowfield.regexps.com \
    --to=lord@regexps.com \
    --cc=dirk@sallust.ida.ing.tu-bs.de \
    --cc=djurfeldt@nada.kth.se \
    --cc=guile-devel@gnu.org \
    --cc=neil@ossau.uklinux.net \
    --cc=owinebar@free-expression.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).