Re: expansion, memoization, and evaluation...

[Mikael Djurfeldt]

Rob Browning <address@hidden> writes:

> OK, so does that mean that at each invocation, you need to look at the
> incoming types and check to see if you already have a cached method
> that matches the incoming signature?  i.e. if you have
>
>   (blah)
>   (foo bar baz)
>   (blarg)
>
> and foo is a generic function, and last time through, bar and baz were
> integers, but this time bar and baz are strings.  Would the current
> behavior be for goops to check, notice this, and build a new
> "precompiled" invocation for two strings?

Yes.

> For example, if you know that within a given function (or closed set
> of functions) you use some set of symbols, and within the set you
> have big (case foo ...)  statements using those symbols, you may be
> able to compile the object code to use plain integers to represent
> these symbols and then issue c-style switches to handle the case
> statements.

Yes, a wonderful optimization.  :-)

And if the compiler gets source back from the goops optimizer or does
flow analysis, it may know the types of some arguments and some
expressions in the source, and might be able to use native integer or
double representation.  In this context it's nice that a goops
"cmethod" (the result of compile-method) has a fixed type signature.

> (Of course if the guile compiler were implemented targeting C, and if
>  guile were to "Depends: gcc", we might be able to use dlopen/dlsym to
>  support heavyweight online compilation.

Yes, yes, yes!

> Though first-time execution would be awfully painful unless your
> machine was really fast ;>)

I wouldn't be so sure.  Of course we wouldn't get "real-time"
performance but I think the performance of the current goops is
promising considering what *it* does for each "first" invocation:

Traversing and rewriting the entire method source and rebuilding the
entire GF method cache up to eight times... and all of it done on the
Scheme level.

Maybe I shouldn't reveal this :), but I've seen the current goops as a
large-scale experiment to test whether these crazy ideas really work
in practise.  And they actually seem to.  I've made heavy use of goops
in large systems consisting of maybe 50 modules, and I don't have any
complaints on its performance.

Best regards,
Mikael