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.