freenode/#clasp - IRC Chatlog
Search
22:36:12
karlosz
Bike: i kinda changed my mind on that. that's how they do it in cmucl, but it's pseudo-spec-violating
22:36:32
karlosz
since you lose EQ-ness of the function object if you cons a new one on each reference
22:37:01
karlosz
it would be super nice if we could do it so we simplify the mutually closing over labels handling
23:01:21
Bike
yeah. i don't remember the details so much. but like (make-hash-table :test #'eq) failed because the #'eq wasn't the same as the global function
23:16:33
Bike
i was lookinag at changing how multiple values are handled, and expanding multiple-value-call optimizations
23:16:39
drmeister
This is the buildbot for the last couple of days using bir and compile-file-parallel
23:20:00
drmeister
Where is the generic function discriminating interpreter defined? We have one in C++ right?
23:23:46
drmeister
So we don't have an interpreted generic function discriminator class? Did we have one and you changed it to a bytecode interpreter?
23:25:30
drmeister
I thought we had a special C++ class that could be setup to evaluate a discriminating function
23:26:57
Bike
we just have a normal funcallable instance, with the interpreter as its discriminating function.
23:28:39
drmeister
Here's what I'm musing about. We have these crap single-dispatch-generic functions that we can replace with interpreted-discriminating-functions.
23:29:50
drmeister
We can create generic-functions with satiated call histories/specializer profiles that dispatch to C++ methods based on the type of the single argument that it would dispatch on.
23:31:42
drmeister
But we have the usual bootstrapping problem - we can't do this until we have certain facilities in place. We need the aclasp/bclasp compiler
23:45:43
drmeister
If we change those two functions so that they generate something that clos__interpret_dtree_program(SimpleVector_sp program, T_sp generic_function, VaList_sp args) can use...
23:46:14
drmeister
Then I think we can get rid of the SingleDispatchxxx code and use generic functions for C++ methods.
23:48:52
drmeister
This would speed up calling of C++ methods and allow us to compile the discriminating functions if we want to.
1:44:41
drmeister
I'm proposing to replace SingleDispatchGeneric functions with the same dtrees we use for generic functions. It will simplify calling C++ methods - and probably speed it up a bit.
1:45:28
drmeister
I think the simplest way to do it is to get rid of SingleDispatchGenericFunctions and use generic functions in their place.
1:45:57
drmeister
When we expose methods we build up a bogus call-history for the generic function that maps argument types to effective methods (wrapped C++ methods).
1:46:47
drmeister
We then write a function like clos__interpret_dtree_program but it uses the call history to do the dispatch.
1:47:19
drmeister
It will be slower when we are building aclasp - but once aclasp is up we can compile the call histories to dtree programs.
1:48:04
drmeister
The dtree bytecode for these C++ methods should be pretty simple - so we could do that.
1:49:08
drmeister
But we could write a printer for dtree programs and that would make it easier to understand them.
1:49:56
Bike
it's honestly pretty simple. it does the old binary search whatever stuff and then calls a function or whatever
1:50:02
drmeister
There are no EQL specializers and the only types we need to worry about are General_O derived types.
1:51:28
drmeister
We could - but why bother. We do need a specialized dtree compiler then, implemented in C++ so that we can generate the dtree programs at startup.
1:53:42
drmeister
Right - so we could just write an interpreter that searches that alist for a type match and then calls the appropriate effective method.
1:54:12
drmeister
Once the dtree compiler is available we compile all of the call histories and then install the dtree interpreter.
1:57:11
drmeister
As an intermediate step we can continue to use the SingleDispatchGenericMethod object I think.
2:18:39
drmeister
The car's of each entry are a vector of classes representing the classes of the arguments