freenode/#sicl - IRC Chatlog
Search
5:29:19
beach
I am going to write up an appendix of the SICL specification describing principles (as opposed to implementation details) of the bootstrapping technique we use. That way, we would have a more complete view of what needs to be done, and I think that will simplify any modification of the bootstrapping procedure. In the past, I have not been able to formulate such principles, but I think I am ready now.
9:43:09
beach
This activity is PURE GOODNESS. I have been focused on what object resides in what first-class global environment during bootstrapping, but that's an implementation decision. But converting the description to mention relative object purity, I can stay independent of a particular environment, and I can examine the implementation decisions based on this new description.
9:45:46
beach
In the past, I also imagined drawing a diagram of what function calls what other function and what function accesses what object, but I imagined doing it based on first-class global environments. Now I think I can do something similar, but using (say) colors do indicate object purity.
9:47:04
beach
I can then highlight "inconsistencies" such as ENSURE-CLASS-USING-CLASS having to call two different versions of FIND-CLASS with different purity.
9:48:59
beach
Thanks. Yes, I hope so. And I think this is my only chance to communicate this crap to others.
9:49:20
beach
With the diagram of different first-class global environments, I have failed miserably.
9:50:40
beach
Indeed. To me too. Every time I take a break from it for a few weeks, I have to learn it all over again.
9:51:14
heisig
One could even turn these invariants you describe into :before and :after methods on various environment accessors.
9:52:04
heisig
Not that it is strictly necessary, but I always prefer actual code over English text. The former is easier to keep up to date.
12:37:57
beach
I am starting to understand why there is no diagram notation for Common Lisp function calls. :)
15:00:20
beach
Someone once told me about a clever way of checking the validity of initialization arguments for object creation and initialization. But i can't remember it. I am asking because in SICL, I currently don't check this validity.
15:01:41
Bike
gathering the valid initargs is fairly straightforward, and then you can cache them in various ways
15:04:20
Bike
converting most make-instance calls into a call to a constructor function dealing with the specific initargs in that call, so that keyword arguments don't have to be sorted or checked
15:04:38
Bike
and then if the class is redefined or such things you recompute all constructors for it
15:06:09
Bike
in clasp each class has a valid-initargs slot. the value in this slot is computed lazily (i.e. when make-instance is actually called) and used for later calls. the MOP dependency mechanism is used to recompute or invalidated the valid-initargs whenever a relevant method is defined on initialize-instance or etc.
15:07:03
Bike
the actual checking is just the obvious iteration, given the plist passed to make instance, and a list of initargs
15:12:10
beach
For the "ctor stuff", I suppose that the validity is already check for calls with initargs known at compile time, yes?
15:12:40
Bike
ok so to be more specific: what's cached per class is the valid initargs of the relevant methods. the slot initargs are checked by just looking at the list of slots.
15:13:55
Bike
beach: Yes. Just to be clear, (make-instance 'foo :a a :b b) will be rewritten as something like (let ((f (ensure-ctor 'foo :a :b))) (funcall f a b)). If the initargs aren't valid, the F function will just signal an error. But it has to be possible to swap out the function at runtime in case something is redefined.
15:14:32
Bike
"if the initargs aren't valid, F will be a function that signals an error without having to do any check at runtime"
15:15:28
beach
Though, caching or no caching, the code to inspect the relevant methods must exist, so that should be written and tested first.
15:16:41
Bike
it's not hard to gather the relevant keywords, although unfortunately the built in reader isn't actually enough
15:17:35
Colleen
Clhs: standard generic function function-keywords http://www.lispworks.com/documentation/HyperSpec/Body/f_fn_kwd.htm
15:18:07
Bike
now i don't remember what i mean. i thought there was some reason not to use function-keywords but i don't remember it.
15:21:15
beach
I guess if there are several applicable methods for a class, then it's the union of the keyword arguments that are valid.
15:23:24
Bike
you also have to treat &allow-other-keys correctly. clasp's valid-initargs computer either returns a list of keywords, or T to indicate there was an &allow-other-keys
15:25:08
beach
Next question, is there a clever way of handling default initargs? I can see only looping over the class-default-initargs, and check each one against the ones given to make-instance.
15:26:52
Bike
i don't know anything cleverer. that's another thing you can work out ahead of time with the ctors system, though.
15:28:45
beach
OK, thanks again. This was not my main task today, but typing up my appendix on bootstrapping principles, I stumbled on this issue.