unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mikael Djurfeldt <mdj@kvast.blakulla.net>
Cc: Neil Jerram <neil@ossau.uklinux.net>,
	 guile-devel@gnu.org, djurfeldt@nada.kth.se
Subject: Re: goops and memoization
Date: Mon, 02 Dec 2002 10:14:00 +0100	[thread overview]
Message-ID: <xy7lm38zstj.fsf@linnaeus.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: <xy7ptskzu5q.fsf@linnaeus.i-did-not-set--mail-host-address--so-tickle-me> (Mikael Djurfeldt's message of "Mon, 02 Dec 2002 09:45:05 +0100")

Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:

> Mixing different stages as it is currently done introduces a lot of
> dependencies between different parts of guile.  This makes
> maintaining guile quite hard - our current discussion is already an
> example of the problem.

Just to clarify my points:

Working on the output of procedure-source does not introduce
dependencies.  On the contrary: Since the output of procedure-source
is required to be Scheme code, we have a completely clean separation
of different parts of Guile.  Regardless of how the evaluator changes,
this representation will remain valid and method compilation will
continue working.

However, working on the memoized representation *would* introduce a
dependency between Goops code and the current version of the
evaluator.  (I have the view, though, that that is acceptable.)

The current problem arises not because of how compile-method retrieves
its input, but because of how the result of the work of compile-method
is "returned" to the rest of the system.  Previously, it was OK to
regard the compile-method output as an executable representation, now
it is not.

The core of the problem is that while there exists a well-defined
interface for retrieving the representation of the method,
procedure-source, there doesn't exist a well-defined interface for
giving a compiled method back to the evaluator.

A standardized way would be to pass Scheme code in the form of a
lambda expression to "eval", but it is simply not possible to use that
standard interface, because methods need to preserve their local
environment.

So, again, if you want to preserve separation of parts of Guile, you
should provide the interface for giving compiled method source (output
of compile-method) back to Guile.

If you are prepared to sacrifice separation for efficiency, you should
implement compile-method in C and let it operate on the memoized
representation.

Best regards,
Mikael


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


  reply	other threads:[~2002-12-02  9:14 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 [this message]
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
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=xy7lm38zstj.fsf@linnaeus.i-did-not-set--mail-host-address--so-tickle-me \
    --to=mdj@kvast.blakulla.net \
    --cc=djurfeldt@nada.kth.se \
    --cc=guile-devel@gnu.org \
    --cc=neil@ossau.uklinux.net \
    /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).