freenode/#sicl - IRC Chatlog
Search
9:32:17
no-defun-allowed
That sounds like it would be very effective. I forgot whom but someone told me most of the complexity of drivers was basically in forming a database of how hardware breaks its own specification.
9:34:53
no-defun-allowed
I thought the drivers were classes themselves, so another client object wouldn't be necessary.
9:38:26
MichaelRaskin
no-defun-allowed: I think it is a common understanding. I think I was mentioning this on this channel and on lispcafe when people got too optimistic about possible high-quality drivers for mass-market devices
9:38:50
no-defun-allowed
Then at initialization time, the driver could test for whatever quirks it might need to handle, and change the class of the object, to one which accommodates for that quirk. (That could use something like dynamic-mixins to handle multiple of such quirks for one device.)
9:40:39
MichaelRaskin
no-defun-allowed: I am kind of afraid there are things you do not want to risk probing unless you are OK with them working… (and then there are undiscoverable quirks where you need kernel module parameters, sigh)
9:42:59
beach
Subclassing might work as well. I guess it depends on the number and nature of the differences.
12:15:29
phoe
Whichever day and time you consider the most proper. Frequency, I guess once per two weeks is okay.
12:24:21
phoe
beach: no problem. Could you send me a short abstract on query? I will want one or two short paragraphs like the quoted ones in https://www.reddit.com/r/lisp/comments/gpwfyf/online_lisp_meeting_2/
12:25:25
phoe
beach: nope. The sooner the better, but I want to have it a week before the actual meeting to give everyone's at least a week's notice before the actual meeting happens.
12:59:04
beach
It is not quite complete, but before I continue, I would like remarks on it, remarks about the precision of the text, but especially remarks regarding whether you think it works: http://metamodular.com/SICL/discriminating-automaton.tex
12:59:30
beach
It is not TeX yet, but when it is finished, I'll incorporate it into the specification.
13:01:05
beach
heisig: In case you missed it. I wrote a generic version of TYPEP and it has EQL specializers. I need to figure out how to cache calls to it, and also how to satiate it.
13:02:16
beach
I am both wired and exhausted. I worked too hard on this thing since yesterday. I need to figure out a way to relax.
13:12:23
heisig
beach: Yes, I read about your work on EQL specializers. But I didn't think it through yet.
13:14:19
beach
So if TYPEP contains EQL specializers, we don't currently cache calls, which means we call compute-applicable-methods, etc, in each call. These functions use things like copy-list, nth, etc.
13:16:12
beach
Besides we had to figure out how to cache calls to direct instances of standard-generic-functions with EQL specializers anyway.
13:17:08
heisig
I think you already wrote that bypassing COMPUTE-APPLICABLE-METHODS for standard generic functions is possible.
13:18:23
heisig
The other one could be to follow the generalizers/specializers proposal. But I am not sure that is applicable here.
13:23:38
beach
Yes, my suggestion relies on the fact that we can bypass COMPUTE-APPLICABLE-METHODS for direct instances of STANDARD-GENERIC-FUNCTION.