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