Faré wrote:
On 1 December 2010 10:25, Daniel Weinreb dlw@itasoftware.com wrote:
Here is a way that CL sucks badly: protocols are not first-class entities. To modify a protocol is something done to the source code *outside* of the Lisp world. It cannot be done programmatically. Adherence to the protocol cannot be enforced. Discrepancies cannot be detected.
I agree.
The relationship between the concept of "protocol" and the concept of "type" should be explored and understood. They're pretty similar but I am not sure what differences they have.
If protcols were first-class, would you be able to make a new one inherit from another?
Java has the concept of an "Interface", which is a lot like a protocol.
I have always liked the idea of having protocols say more than just "these are the functions and these are the arguments, which are optional, ane maybe what their types are. I'd love it if there were a way to say "in order to fulfill this contract, doing write-string of a string must behave exactly the same as doing write-char on each." You could imagine all kinds of integrity constratints. You could specify that some function be commutative, that some be associative with respect to each other, that one have no side effects, that one be idempotent, and so on. We could start by having a well-known template for documenting/commenting the functions in a protocol to be able to say things like this.
Fare knows this, but for everyone else: we have a macro called define-struct-function that lets you specify datatypes for each argument, and expands into check-type's (basically), and also for returned values. And corresponding versions for generics and methods. We don't use them for every single definition, but we try to use them at inter-module boundaries.
In Racket, for instance, modules are first-class (at syntax expansion time) and units are first-class (at runtime), and you can manipulate them programmatically.
First, a common base class can provide implementations of some of the generic functions all by itself. My favorite simple example is an "output stream" protocol, that has a write-character operation and a write-string operation. The common base class provides an implementation of write-string that works by iterating over the characters of the string and calling write-character. Any output stream that can write strings in a more efficient way can override that method.
In my "pure" datastructure library (currently part of fare-utils, to be spun off as lil - lisp interface library), I use mixins to provide these "methods". So instead of adding the method to a base class, I would provide a mixin "write-string-from-write-char", and then could possibly add an opposite mixin "write-char-from-write-string", without creating a paradox that will byte you.
That's good. The usual abstract base class provides a set of things like that. You have to take all or none (although you can override some). Using particular mixins to provide particular helpers is more modular.
This is not perfect. A programmer might just happen to create a vector and put one of those keywords into the +fhash-kind+ slot. (+fhash-kind+ is zero but that's a mere detail.) But it's sort of good enough.
Solution: don't use keywords, but private symbols. Unlike keywords, private symbols are private. They can be faked, but not accidentally. CL doesn't allow you to easily define sublanguages in which things cannot be faked. That's painful.
Yes, I agree with you and Peter. Definitely.
What people usually do in Common Lisp, in my experience, [...]
Patterns mean "I have run out of language." — Rich Hickey
Actually even the Gang-of-Four admit that.
-- Dan
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] If you could kick the person in the pants responsible for most of your trouble, you wouldn't sit for a month. — Theodore Roosevelt