libera/#commonlisp - IRC Chatlog
Search
2:36:11
mfiano
Random thought: Should library authors that have public-facing interfaces that accept any specific or subset of sequences as input, is it a good idea to always use COPY-TREE or the appropriate function before mutating a list "from the outside" that you didn't create, or should the caller always be informed of the semantics and it's their responsibility not to pass a list literal...or both,
2:43:49
mfiano
Nevermind. That question didn't come out the way I wanted it to, and it doesn't make a lot of sense.
3:11:20
Bike
destructive interfaces are ok as long as they are documented as such (and "may destroy" versus "mutates in this particular way" is indicated)
3:11:45
Bike
and often a good idea practically speaking, since consing up a bunch of needless intermediate results slows things down
4:34:38
mfiano
One thing that upsets me about the standard, and I just had to double-check to make sure I was remembering correctly, is there is no way to get a lazy sequence of the keys stored in a hash table, except within the lexical environment of with-hash-table-iterator, and there are all sorts of UB around trying to make it dynamically scoped with a closure or whatnot.
4:35:54
mfiano
I really would like a non-consing alternative to MAPHASH-ing to retrieve all keys, as the starting state in a custom iterator, which is more or less, what I'm trying to accomplish.
9:24:01
beach
That's a very strange question. I mean, the answer is "Of course, it happens all the time. Just look at something like PRINT-OBJECT."
9:27:00
beach
The use of special variables is no different from the use of special variables in ordinary functions.
9:27:12
beach
The use of special variables in methods is no different from the use of special variables in ordinary functions, I mean.
9:29:54
beach
I don't see the relation between &ALLOW-OTHER-KEYS and special variables. Also, &ALLOW-OTHER-KEYS is not reserved for methods. It is used in ordinary functions as well.
9:31:05
lisp123
I was thinking of allowing people to override the primary method based on giving them flexibility in &allow-other-keys
9:35:38
lisp123
Where it is different from normal functions - there is typically no expectation that an ordinary function would be redefined,so arguably special variables should not be an implicit parameter but rather explicit in the parameter list
9:36:02
lisp123
Whereas with generic functions and the capabilities offered by method combinations, maybe its more appropriate
10:01:21
beach
I think you have a special use case in mind. And I am unable to infer it from the question and the additional descriptions you have given. But then, I am notorious for not understanding what people want, unless the description is very detailed. You can hope that someone else is better with that than I am.
10:13:38
beach
Well, in that case, I can tell you about the technique we have adopted in several libraries. Important generic functions have a CLIENT parameter that is not specialized to by the methods in the library. Client code must supply an instance of a standard class as the argument for this parameter. Client code can then override any method by providing a method that does specialize to the standard class in question.
10:14:04
beach
You can see this technique in Eclector, for instance. But also in Clostrum, Trucler, etc.
10:15:49
beach
Functions that are not allowed to take any additional parameter, such as READ for instance (which must be compatible with the standard one), call a generic function, passing the value of the library-provided special variable *CLIENT* as an argument for this parameter. Client code must bind the special variable around a call to a library function.
10:16:54
beach
This way, the library can supply lots of good default methods for all generic functions, while clients with special needs can override any such generic function.
10:24:41
beach
This technique also allows for several clients to exist simultaneously in the same Common Lisp image. For instance, if I want to cross-compile code for SICL using an implementation that already uses Eclector, then the host can use Eclector with its own client, and the cross compiler can pass a SICL-specific client in order to use Eclector as a reader.
10:26:05
lisp123
Important generic functions have a CLIENT parameter that is not specialized to by the methods in the library. -> When (or what factors drive the decision) of when this should be an explicit parameter vs. a special *CLIENT* variable
10:27:56
phoe
so, (let ((eclector:*client* foo)) (cl:read ...)) is equivalent to (eclector:read-with-client foo ...)
10:28:09
beach
If the library function is not trying to imitate the lambda list of any known function, then it can freely use a CLIENT parameter.
10:28:21
lisp123
I get that part for functions that are not allowed to take an additional parameter, but reading the above it seems like its preferable in other cases to make the CLIENT parameter explicit
10:28:39
phoe
when you can't do anything else, though, the oldest trick in the book, one of passing extra arguments via dynamic variables
10:29:58
lisp123
So I guess instead of specialising on keys, the all-encompassing client parameter captures variations
10:31:29
lisp123
(defgeneric foo (object &key &allow-other-keys) -> (defmethod foo ((object class-b) &key (x 1) (y 2) &allow-other-keys)
10:32:05
phoe
yes, but not all functions have &KEY so you cannot use arbitrary keys to configure their behavior