From: bradb on
I think that I might understand what people mean when they talk about
"protocols", but I am not sure. Note - I'm not talking about the Meta
Object Protocol, just invented protocols.
For example, Flexichain (http://common-lisp.net/project/flexichain/)
talks quite a bit about the protocols for accessing data in a sequence.
As I understand it, a protocol is a collection of classes and generic
functions that define an interface for a particular chunk of
functionality. When you talk about protocols, you are implicitly
ignoring the implementation and just talking about how you'd like to
use the code. Obviously the protocol actually needs to be implemented
to be at all useful, but that is beside the point right now.
Is my understanding about right?

Cheers
Brad

From: Zach Beane on
"bradb" <brad.beveridge(a)gmail.com> writes:

> I think that I might understand what people mean when they talk about
> "protocols", but I am not sure. Note - I'm not talking about the Meta
> Object Protocol, just invented protocols.

I don't understand this distinction. Why not consider the MOP? It's a
protocol in the Lisp sense. Section 7.1 of the standard, "Object
Creation and Initialization", is another example of a Lisp protocol.

> For example, Flexichain (http://common-lisp.net/project/flexichain/)
> talks quite a bit about the protocols for accessing data in a
> sequence. As I understand it, a protocol is a collection of classes
> and generic functions that define an interface for a particular
> chunk of functionality. When you talk about protocols, you are
> implicitly ignoring the implementation and just talking about how
> you'd like to use the code. Obviously the protocol actually needs
> to be implemented to be at all useful, but that is beside the point
> right now. Is my understanding about right?

I think you're on the right track, but specific classes belong more to
an implementation of a protocol than to a protocol definition. Lisp
protocol definitions are GF-centric.

Zach
From: Pascal Costanza on
bradb wrote:
> I think that I might understand what people mean when they talk about
> "protocols", but I am not sure. Note - I'm not talking about the Meta
> Object Protocol, just invented protocols.
> For example, Flexichain (http://common-lisp.net/project/flexichain/)
> talks quite a bit about the protocols for accessing data in a sequence.
> As I understand it, a protocol is a collection of classes and generic
> functions that define an interface for a particular chunk of
> functionality. When you talk about protocols, you are implicitly
> ignoring the implementation and just talking about how you'd like to
> use the code. Obviously the protocol actually needs to be implemented
> to be at all useful, but that is beside the point right now.
> Is my understanding about right?

A protocol is a set of functions that are designed to be used together.
A very simple example is a file access protocol, consisting of functions
for opening, reading from, writing to, and closing files. It's important
to consider the set of functions in conjunction because there are
implicit rules how you can use the functions, for example in what order.
In this case, say, you can only read from or write to a file that you
have opened before, and it's typically a good idea to close it in the
end. If you read from or write to a file you haven't opened, you will
get an error, etc.

The notion of a protocol plays a more important role in object-oriented
programming than in plain functional or imperative programming because
you can override functionality in your own code and typically have to
adhere to the implicit rules. There are quite a few examples of such
rules in the CLOS MOP, and also CLOS itself (consider the protocols for
initialization, reinitialization, class change, class redefinition,
etc.). You have to know how these protocols work to be able to write
your own methods correctly. This is independent of the actual object
model - these kinds of protocols don't only exist for generic
function-based approaches but also for more traditional object-centric
approaches. (Consider the interactions between the methods equals and
hashCode in Java.)

A problem in object-oriented approaches is the very fact that protocols
are implicit and are at best described with documentation. There are a
few approaches for handling them explicitly, so that they can be
automatically checked to a certain degree, but as far as I can tell,
they are not good enough for practical purposes.

In functional programming, you would rather use higher-order functions
where you can require that the necessary custom functions are passed
such that necessary "overridings" cannot be forgotten. However, they
have their own limitations, and don't solve the problem of guaranteeing
"correctness."


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: bradb on
Zach Beane wrote:
> "bradb" <brad.beveridge(a)gmail.com> writes:
>
> > I think that I might understand what people mean when they talk about
> > "protocols", but I am not sure. Note - I'm not talking about the Meta
> > Object Protocol, just invented protocols.
>
> I don't understand this distinction. Why not consider the MOP? It's a
> protocol in the Lisp sense. Section 7.1 of the standard, "Object
> Creation and Initialization", is another example of a Lisp protocol.
I guess that MOP should be considered, but I don't personally know
enough about it to rule it in or out. I was excluding it because I
thought/think that MOP defines how generic functions/CLOS work, and if
we discussed the MOP we would quickly get above my level of
understanding. If MOP doesn't define how defgeneric/defmethod should
work, and is only to do with the object side of CLOS (see, I'm still
thinking that objects and generic functions are related to each
other!), then I guess I can grok MOP at that level. Ie, it is only to
do with Objects, nothing to do with generic functions.

> > For example, Flexichain (http://common-lisp.net/project/flexichain/)
> > talks quite a bit about the protocols for accessing data in a
> > sequence. As I understand it, a protocol is a collection of classes
> > and generic functions that define an interface for a particular
> > chunk of functionality. When you talk about protocols, you are
> > implicitly ignoring the implementation and just talking about how
> > you'd like to use the code. Obviously the protocol actually needs
> > to be implemented to be at all useful, but that is beside the point
> > right now. Is my understanding about right?
>
> I think you're on the right track, but specific classes belong more to
> an implementation of a protocol than to a protocol definition. Lisp
> protocol definitions are GF-centric.

It would therefore be possible to define a protocol without using CLOS
at all, only using GFs and some other type defining mechanism - CLOS
just happens to provide for a nice way to make types that can be
related in an inheritance graph?

The obvious advantage to defining a protocol is that you should be able
to change the implementation at will, or just hook into little chunks
of it as you need it. What are the disadvantages? Do GF's impose very
much overhead for protocols?

Cheers
Brad

From: bradb on

Pascal Costanza wrote:
<SNIP>
>
>
> Pascal

Pascal, that was extremely enlightening for me, thank you.

Brad