<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span style="font-family:'Helvetica'; font-size:medium;">Jason Aeschliman <<a href="mailto:j.aeschliman@gmail.com">j.aeschliman@gmail.com</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Subject: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>Re: com.clearly-useful.generic-collection-interface</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span style="font-family:'Helvetica'; font-size:medium;">October 31, 2012 11:37:35 AM PDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>To: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><a href="mailto:lisp-interface-library-devel@common-lisp.net">lisp-interface-library-devel@common-lisp.net</a><br></span></div><br><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Hello Faré</div><div><br></div><div><blockquote type="cite"> It notably simplifies the automatic interface wrapping code.</blockquote></div></div><br><div>*slaps forehead* ah, of course</div><div><br></div><div><blockquote type="cite"> NB: What does :eponymous-method mean?</blockquote></div><div><br></div><div>it means a generic function of one argument is defined with the same name</div><div>as the protocol. types implementing the protocol will have a method on that</div><div>function generated (just identity), so the name of the protocol can serve as</div><div>a kind of 'conversion' function, and you can define arbitrary methods on it</div><div>etc. it might make more sense to just define two separate protocols, honestly.</div><div><br></div><div><blockquote type="cite"> Maybe we should continue this discussion on the</blockquote></div><blockquote type="cite"> lisp-interface-library-devel mailing-list?<br></blockquote><div><br></div><div>done.</div><div><br></div><div>Cheers,</div><div><br></div><div>Jason</div><div><br></div><div></div><blockquote type="cite"><div><br></div><div>On Mon, Oct 29, 2012 at 10:33 PM, Jason Aeschliman<br><<a href="mailto:j.aeschliman@gmail.com">j.aeschliman@gmail.com</a>> wrote:<br><blockquote type="cite">Hello Faré,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Thanks for the privilege! I spent some time reading over the code a bit<br></blockquote><blockquote type="cite">today.<br></blockquote><blockquote type="cite">In terms of design, it looks like we could use some clear protocols to begin<br></blockquote><blockquote type="cite">tackling collections well -- I'd like to suggest the ones I've been working<br></blockquote><blockquote type="cite">on<br></blockquote><blockquote type="cite">here:<br></blockquote><blockquote type="cite"><a href="https://github.com/jaeschliman/com.clearly-useful.generic-collection-interface/blob/master/protocols.lisp">https://github.com/jaeschliman/com.clearly-useful.generic-collection-interface/blob/master/protocols.lisp</a><br></blockquote><blockquote type="cite">as they seem to me to capture a pretty good minimal read-only definition of<br></blockquote><blockquote type="cite">some basic containers "types". I think we should use my protocol<br></blockquote><blockquote type="cite">implementation<br></blockquote><blockquote type="cite">to define the method groups as I think it's very helpful for organizing<br></blockquote><blockquote type="cite">code, and allows<br></blockquote><blockquote type="cite">for type checking outside of the class hierarchy in a useful way.<br></blockquote><blockquote type="cite"><br></blockquote>Yes, this looks like an excellent starting point.<br>I don't know how much we care about name compatibility with existing<br>libraries (e.g. cl-containers), or similar libraries in other<br>languages (Clojure, Haskell, Scala, OCaml, etc.), but if we do, now is<br>the last time to give a look.<br><br>NB: What does :eponymous-method mean?<br><br><blockquote type="cite">I'd also like to suggest moving away from the<br></blockquote><blockquote type="cite">design of having functions like pure:insert and stageful:insert, one of<br></blockquote><blockquote type="cite">which<br></blockquote><blockquote type="cite">returns a new value, the other updating in place. This seems to me like it<br></blockquote><blockquote type="cite">will cause people unneeded headaches down the road. Better to have<br></blockquote><blockquote type="cite">one function (I'm fond of clojure's conj) which non-destructively augments<br></blockquote><blockquote type="cite">a collection (/any/ collection) and returns the new one, and another<br></blockquote><blockquote type="cite">function<br></blockquote><blockquote type="cite">(conj!, or nconj may be more CL) which operates destructively if possible<br></blockquote><blockquote type="cite">or throws an error. Keeping these things separate will be very important<br></blockquote><blockquote type="cite">for usability IMO<br></blockquote><blockquote type="cite"><br></blockquote>I feel it's important to have the "same" name for all four flavors (so<br>far) of our functions:<br>pure, stateful, classy, posh.<br>It notably simplifies the automatic interface wrapping code.<br>But it also simplifies the amount of information a human must handle.<br>If you understand what a function does in one style,<br>it's pretty straightforward how it will behave in other styles.<br>Usually, you program in only one style at once, and there's no clash.<br>When there is a clash, using a package prefix makes it clear.<br><br><blockquote type="cite">In general, I think some kind of 'design document' could be very helpful…<br></blockquote><blockquote type="cite">something that just lays out the overall areas the project should be<br></blockquote><blockquote type="cite">covering,<br></blockquote><blockquote type="cite">e.g. definition of container protocols, equality and comparison protocols,<br></blockquote><blockquote type="cite">ips->oop conversion, oop->ips etc.<br></blockquote><blockquote type="cite"><br></blockquote>Indeed. The article at <a href="https://github.com/fare/lil-ilc2012/">https://github.com/fare/lil-ilc2012/</a> is the<br>only thing I have so far, but one of our contributors is thinking<br>about writing a tutorial.<br><br>Maybe we should continue this discussion on the<br>lisp-interface-library-devel mailing-list?<br><br>—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org/">http://fare.tunes.org</a><br>They laughed at Columbus, they laughed at Fulton, they laughed at the<br>Wright brothers. But they also laughed at Bozo the Clown.<br> — Carl Sagan</div></blockquote></div></blockquote></div><br></body></html>