[lisp-interface-library-devel] com.clearly-useful.generic-collection-interface

[Jason Aeschliman]

Hello Faré

>  It notably simplifies the automatic interface wrapping code.

*slaps forehead* ah, of course

>  NB: What does :eponymous-method mean?


it means a generic function of one argument is defined with the same name
as the protocol. types implementing the protocol will have a method on that
function generated (just identity), so the name of the protocol can serve as
a kind of 'conversion' function, and you can define arbitrary methods on it
etc.  it might make more sense to just define two separate protocols, honestly.

>  Maybe we should continue this discussion on the
>  lisp-interface-library-devel mailing-list?

done.

Cheers,

Jason

> 
> On Mon, Oct 29, 2012 at 10:33 PM, Jason Aeschliman
> <j.aeschliman at gmail.com> wrote:
>> Hello Faré,
>> 
>> Thanks for the privilege! I spent some time reading over the code a bit
>> today.
>> In terms of design, it looks like we could use some clear protocols to begin
>> tackling collections well -- I'd like to suggest the ones I've been working
>> on
>> here:
>> https://github.com/jaeschliman/com.clearly-useful.generic-collection-interface/blob/master/protocols.lisp
>> as they seem to me to capture a pretty good minimal read-only definition of
>> some basic containers "types". I think we should use my protocol
>> implementation
>> to define the method groups as I think it's very helpful for organizing
>> code, and allows
>> for type checking outside of the class hierarchy in a useful way.
>> 
> Yes, this looks like an excellent starting point.
> I don't know how much we care about name compatibility with existing
> libraries (e.g. cl-containers), or similar libraries in other
> languages (Clojure, Haskell, Scala, OCaml, etc.), but if we do, now is
> the last time to give a look.
> 
> NB: What does :eponymous-method mean?
> 
>> I'd also like to suggest moving away from the
>> design of having functions like pure:insert and stageful:insert, one of
>> which
>> returns a new value, the other updating in place. This seems to me like it
>> will cause people unneeded headaches down the road. Better to have
>> one function (I'm fond of clojure's conj) which non-destructively augments
>> a collection (/any/ collection) and returns the new one, and another
>> function
>> (conj!, or nconj may be more CL) which operates destructively if possible
>> or throws an error. Keeping these things separate will be very important
>> for usability IMO
>> 
> I feel it's important to have the "same" name for all four flavors (so
> far) of our functions:
> pure, stateful, classy, posh.
> It notably simplifies the automatic interface wrapping code.
> But it also simplifies the amount of information a human must handle.
> If you understand what a function does in one style,
> it's pretty straightforward how it will behave in other styles.
> Usually, you program in only one style at once, and there's no clash.
> When there is a clash, using a package prefix makes it clear.
> 
>> In general, I think some kind of 'design document' could be very helpful…
>> something that just lays out the overall areas the project should be
>> covering,
>> e.g. definition of container protocols, equality and comparison protocols,
>> ips->oop conversion, oop->ips etc.
>> 
> Indeed. The article at https://github.com/fare/lil-ilc2012/ is the
> only thing I have so far, but one of our contributors is thinking
> about writing a tutorial.
> 
> Maybe we should continue this discussion on the
> lisp-interface-library-devel mailing-list?
> 
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> They laughed at Columbus, they laughed at Fulton, they laughed at the
> Wright brothers.  But they also laughed at Bozo the Clown.
>                — Carl Sagan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/lisp-interface-library-devel/attachments/20121031/8619a10c/attachment.html>