unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* (no subject)
@ 2002-11-09  8:29 Dirk Herrmann
  2002-11-09  9:29 ` Memoization, define and all that tomas
  2002-11-09 20:42 ` (no subject) Clinton Ebadi
  0 siblings, 2 replies; 3+ messages in thread
From: Dirk Herrmann @ 2002-11-09  8:29 UTC (permalink / raw)
  Cc: guile-devel


Clinton Ebadi wrote:
> > I don't care how memoization works.  I understand there are
> > optimization issues.  Optimizing isn't important to me, or
> > I would not use an interpretive language as my "extension
> > language".  If you add a disabling mechanism, then you'll
> > have the best of all worlds.  You can memoize/optimize to
> > your heart's content, and I'll disable it for my purposes.
> > If that is not practical and Guile becomes, essentially,
> > an semi-compiled language with constraints on where
> > defines may happen, then my goose will be cooked.
>
> Not to mention how Guile wouldn't be Scheme anymore. Why can't code be
> memiozied and compiled incrementally?

First, why wouldn't guile be scheme any more if conditional definitions
are disallowed?  They are disallowed by R5RS, so actually, if you
understand "being scheme" as "conforming to R5RS" then currently guile is
not scheme and disallowing conditional definitions will bring it one step
closer to "being scheme" :-)

Second, certainly can code be memoized and compiled incrementally.
However, this would have to be done every time the code was read in again,
since in an expression like (if <condition> (define <foo> <bar)) the value
of <condition> may change every time the code is read in.  That is, we
would reduce our possibility to pre-compile code.  Pre compiling code,
however, is one of our options to speed up guile's starting time (aside
from optimizing guile's module system...).

Best regards, 
Dirk Herrmann



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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Memoization, define and all that
  2002-11-09  8:29 (no subject) Dirk Herrmann
@ 2002-11-09  9:29 ` tomas
  2002-11-09 20:42 ` (no subject) Clinton Ebadi
  1 sibling, 0 replies; 3+ messages in thread
From: tomas @ 2002-11-09  9:29 UTC (permalink / raw)
  Cc: guile-devel

On Sat, Nov 09, 2002 at 09:29:40AM +0100, Dirk Herrmann wrote:
> 
> Clinton Ebadi wrote:
> > > I don't care how memoization works.  [...]

[...]

> First, why wouldn't guile be scheme any more if conditional definitions
> are disallowed?  They are disallowed by R5RS, so actually, if you
> understand "being scheme" as "conforming to R5RS" then currently guile is
> not scheme and disallowing conditional definitions will bring it one step
> closer to "being scheme" :-)

Hrm. As marius pointed out elsewhere, this isn't just an issue with define,
but actually with any form which might get expanded before/at compile time.

> Second, certainly can code be memoized and compiled incrementally.
> However, this would have to be done every time the code was read in again,
> since in an expression like (if <condition> (define <foo> <bar)) the value
> of <condition> may change every time the code is read in.

Yes, as far as we can't make sure (e.g. by static code analysis) that
we have a fixed value for <condition>. As soon as <condition> is known,
things look better (and if <condition> isn't known, there might be a
reason to it, that is, the programmer is willing to pay for the overhead).

Of course I'm not favouring a thorough code analysis (is that decidable
at all?), but: if you *know* a thing to be constant -- go ahead and
memoize, if you *don't know* well, take with you a reference to the lexical
environment (you have to do this for macros, in some way or other, don't
you?) and leave things as they are.

With time you can get better by expanding the set of situations you *know*
about. This is what I had in mind when I was talking something about partial
evaluation.

Does this sound plausible?

> That is, we would reduce our possibility to pre-compile code.

But only in those cases which you are about to prohibit. You can always
pre-compile the ``goodies'' (e.g. those lexical spans where `define is
not redefined, etc.). May be I'm overlooking something here, but I tend
to view pre-compilation as a kind of constant folding.

> Pre compiling code, however, is one of our options to speed up guile's
> starting time (aside from optimizing guile's module system...).

Yep. And I think it a bearable burden for the programmer to keep some
things in mind if she intends to write well-compilable code. But as
long as we have eval around (and we won't like to miss this one do we?),
we'll have an instance of the compiler/interpreter around, so it
doesn't hurt postponing things (other than performance, that is). So
the trick might be to just postpone things ``when we don't know better'',
because someone is playing nasty tricks with our basic forms (whatever
they may be, I think define is just an example).

Thanks for your patience in reading my half-baked mumbling.

Regards
-- tomas


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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: (no subject)
  2002-11-09  8:29 (no subject) Dirk Herrmann
  2002-11-09  9:29 ` Memoization, define and all that tomas
@ 2002-11-09 20:42 ` Clinton Ebadi
  1 sibling, 0 replies; 3+ messages in thread
From: Clinton Ebadi @ 2002-11-09 20:42 UTC (permalink / raw)
  Cc: guile-devel

On Saturday 09 November 2002 03:29, Dirk Herrmann wrote:
> > Not to mention how Guile wouldn't be Scheme anymore. Why can't code be
> > memiozied and compiled incrementally?
>
> First, why wouldn't guile be scheme any more if conditional definitions
> are disallowed?  They are disallowed by R5RS, so actually, if you
> understand "being scheme" as "conforming to R5RS" then currently guile is
> not scheme and disallowing conditional definitions will bring it one step
> closer to "being scheme" :-)

I was referring to the part where you would have to reload your code if a 
binding changed and the whole (define define define-private) etc. not 
working.

-- 
http://unknownlamer.org
Truth lies in loneliness
When hope is long gone by


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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-11-09 20:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-11-09  8:29 (no subject) Dirk Herrmann
2002-11-09  9:29 ` Memoization, define and all that tomas
2002-11-09 20:42 ` (no subject) Clinton Ebadi

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).