<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=windows-1252"

 http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

<br>

<br>

Faré wrote:

<blockquote

 cite="mid:AANLkTikQLdHusYP-wC98ieVVxeVAecevdoz+K03wxR3d@mail.gmail.com"

 type="cite">

  <pre wrap="">On 1 December 2010 10:25, Daniel Weinreb <a class="moz-txt-link-rfc2396E" href="mailto:dlw@itasoftware.com"><dlw@itasoftware.com></a> wrote:

  </pre>

<pre wrap="">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.

  </pre>

</blockquote>

I agree.<br>

<br>

The relationship between the concept of "protocol"<br>

and the concept of "type" should be explored and<br>

understood.  They're pretty similar but I am not<br>

sure what differences they have.<br>

<br>

If protcols were first-class, would you be able<br>

to make a new one inherit from another?<br>

<br>

Java has the concept of an "Interface", which is<br>

a lot like a protocol.<br>

<br>

I have always liked the idea of having protocols<br>

say more than just "these are the functions<br>

and these are the arguments, which are optional,<br>

ane maybe what their types are.  I'd love it<br>

if there were a way to say "in order to fulfill<br>

this contract, doing write-string of a string<br>

must behave exactly the same as doing<br>

write-char on each."  You could imagine all<br>

kinds of integrity constratints.  You could<br>

specify that some function be commutative,<br>

that some be associative with respect to<br>

each other, that one have no side effects, that<br>

one be idempotent, and so on.  We could<br>

start by having a well-known template<br>

for documenting/commenting the functions<br>

in a protocol to be able to say things like this.<br>

<br>

Fare knows this, but for everyone else:<br>

we have a macro called define-struct-function<br>

that lets you specify datatypes for each argument,<br>

and expands into check-type's (basically),<br>

and also for returned values.  And corresponding<br>

versions for generics and methods.  We don't<br>

use them for every single definition, but we<br>

try to use them at inter-module boundaries.<br>

<br>

<blockquote

 cite="mid:AANLkTikQLdHusYP-wC98ieVVxeVAecevdoz+K03wxR3d@mail.gmail.com"

 type="cite">

  <pre wrap="">

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.

  </pre>

  <blockquote type="cite">

    <pre wrap="">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.

    </pre>

  </blockquote>

  <pre wrap=""><!---->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.

  </pre>

</blockquote>

That's good.  The usual abstract base class provides<br>

a set of things like that.  You have to take all or<br>

none (although you can override some).  Using<br>

particular mixins to provide particular helpers<br>

is more modular.<br>

<blockquote

 cite="mid:AANLkTikQLdHusYP-wC98ieVVxeVAecevdoz+K03wxR3d@mail.gmail.com"

 type="cite">

  <pre wrap="">

  </pre>

  <blockquote type="cite">

    <pre wrap="">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.

    </pre>

  </blockquote>

  <pre wrap=""><!---->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.

  </pre>

</blockquote>

Yes, I agree with you and Peter.  Definitely.<br>

<blockquote

 cite="mid:AANLkTikQLdHusYP-wC98ieVVxeVAecevdoz+K03wxR3d@mail.gmail.com"

 type="cite">

  <pre wrap="">

  </pre>

  <blockquote type="cite">

    <pre wrap="">What people usually do in Common Lisp, in my experience, [...]

    </pre>

  </blockquote>

  <pre wrap=""><!---->Patterns mean "I have run out of language." — Rich Hickey

  </pre>

</blockquote>

Actually even the Gang-of-Four admit that.<br>

<br>

-- Dan<br>

<blockquote

 cite="mid:AANLkTikQLdHusYP-wC98ieVVxeVAecevdoz+K03wxR3d@mail.gmail.com"

 type="cite">

  <pre wrap="">

[ François-René ĐVB Rideau | Reflection&Cybernethics | <a class="moz-txt-link-freetext" href="http://fare.tunes.org">http://fare.tunes.org</a> ]

If you could kick the person in the pants responsible for most of your

trouble, you wouldn't sit for a month. — Theodore Roosevelt

  </pre>

</blockquote>

</body>

</html>