From danlentz at gmail.com  Thu Nov  1 02:47:23 2012
From: danlentz at gmail.com (Dan Lentz)
Date: Wed, 31 Oct 2012 22:47:23 -0400
Subject: [lisp-interface-library-devel] <invertible>
Message-ID: <CANco9BsHw9pYqdHDqz5zgBS2LbtTryqdwf7fSyoU-eKSQeZy-w@mail.gmail.com>

Further thoughts <invertible> question.  Firstly, am I thinking about
that incorrectly?  I guess what I might have been groping for is a
first class base <operation> interface and then something like:


(define-interface <operation> (<interface>) ()
  (:generic> do ())
  (:abstract))

define-interface <invertible> (<operation>) ()
  (:generic> undo ())
  (:abstract))

(define-interface <insert> (<operation> <invertible>)
  ((place :initarg :place :accessor place)
   (thing :initarg :thing :accessor thing))
  (:parametric (&key place thing)
      (make-interface <insert> :place place :thing thing))
  (:method do ((<i> <insert>))
      (insert (place <i>) (thing <i>)))
  (:method undo ((<i> <insert>))
      (drop (place <i>) (thing <i>)))
  (:singleton))

Which would be a first class thing, and can be abstracted over,
whereas the generic function insert as it stands is static and
defining its inverse with just using dispatching of general functions
does not seem equivalent.  Is there a better way to do this?



On Wed, Oct 31, 2012 at 9:15 AM, Dan Lentz <danlentz at gmail.com> wrote:

> Ok I've been rereading the LIL manifesto and its a lot clearer to me
> this time around thanks to our discussion and the exercise of thinking
> about a specific task, such as the rb/wb trees.   (probably the
> repetition can't be hurting either :-)  So I'm jotting down a list of
> general questions/thoughts etc that are not necessarily apropos of
> anything we've been discussing and in no particular order.  I'll try
> not to get too annoying with these, but here is one to start off:
>
> One thought that popped up* was, "Gee, wouldn't <invertible> make a
> good interface?"  Ie the inverse of insert is drop;  The inverse of
> divide is join.  If we defined <invertible> with generics DO and UNDO
> then we could do things like rollback a series of operations.  But
> then I realized that insert/drop/divide/join etc are all functions not
> interfaces.  So if not as an interface what would be the appropriate
> means of doing this?
>
> Generic functions could do it of course but then <invertible> would
> not be a first class thing at least not in the sense of the other IPS
> facilities.
>
>
> * actually the rollback idea should be duly credited as result of
> reading through billitch's transaction code in fact-database



From fahree at gmail.com  Thu Nov  1 05:23:56 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Thu, 1 Nov 2012 01:23:56 -0400
Subject: [lisp-interface-library-devel] <invertible>
In-Reply-To: <CANco9BsHw9pYqdHDqz5zgBS2LbtTryqdwf7fSyoU-eKSQeZy-w@mail.gmail.com>
References: <CANco9BsHw9pYqdHDqz5zgBS2LbtTryqdwf7fSyoU-eKSQeZy-w@mail.gmail.com>
Message-ID: <CAN7nBXcuZzQd9x=-L81OSzUUwOK9azsbzRAMOKpYCgV01mu8-A@mail.gmail.com>

On Wed, Oct 31, 2012 at 10:47 PM, Dan Lentz <danlentz at gmail.com> wrote:
> Further thoughts <invertible> question.  Firstly, am I thinking about
> that incorrectly?  I guess what I might have been groping for is a
> first class base <operation> interface and then something like [...]
>
I don't know if <invertible> fits nicely in IPS,
but you might be interested in "reversible programming",
"bidirectional computing", "logic programming", and whichever
other paradigms were named to deal with this kind of stuff. e.g.
	http://www.seas.upenn.edu/~harmony/

You could also have an <invert> function that takes an <invertible>
interface as parameter and swaps do and undo methods.
Beware that your method cannot be actually named cl:do.

But it's only trickier since which operation is inverse
of which other operation crucially depends on how you curry your arguments.

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
The problem with being a citizen of the world is
that you don't get to travelling abroad much.



From danlentz at gmail.com  Thu Nov  1 23:16:07 2012
From: danlentz at gmail.com (Dan Lentz)
Date: Thu, 1 Nov 2012 19:16:07 -0400
Subject: [lisp-interface-library-devel] Red Black Trees for pure interface
	are online
Message-ID: <CANco9Bu_ix1+FU0s07fi4Vcgq82XdsxCMUWYtQqqPLqpc4OzqA@mail.gmail.com>

The source is available for review and comment in my LIL fork
(https://github.com/danlentz/lisp-interface-library)  I still am in
the process of putting together an official battery of tests, but
informally things seem to be working just fine.  There are still some
loose ends to clean up of course.

There are also a number of additionional operations there in support
of providing the backend of a <set> interface (union, intersection
etc) I also have a number of set interface methods nearly ready but
not as yet published to github.



From fahree at gmail.com  Fri Nov  2 01:36:30 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Thu, 1 Nov 2012 21:36:30 -0400
Subject: [lisp-interface-library-devel] Red Black Trees for pure
	interface are online
In-Reply-To: <CANco9Bu_ix1+FU0s07fi4Vcgq82XdsxCMUWYtQqqPLqpc4OzqA@mail.gmail.com>
References: <CANco9Bu_ix1+FU0s07fi4Vcgq82XdsxCMUWYtQqqPLqpc4OzqA@mail.gmail.com>
Message-ID: <CAN7nBXfys--eVLOSzCkt_K29nZ9exS=q8LJrUs+HSNyqckncdg@mail.gmail.com>

Dear Dan,

Congrats for your new trees!

Some quick remarks:
* is it pure only? then a lot of it should go to pure, not interface.
* edit package files to import/export symbols
* remove is a reserved word in the cl package; that's why I used "drop".
* there are already generic tests for maps - you should just use them.
* some of your node/foo functions should just be regular foo functions
not just for tree nodes;
* on the other hand there is a node function that is already the
"smart" constructor.
* your pure and stateful trees may use <empty-is-nil> and
<empty-is-empty-object> mixins respectively
* there should be a separate API for sets. jaeschliman had something about that.
* there should be a parametric functor from maps to sets
* join and/or map/2 can be used to implement union, intersection, etc.
* I wouldn't use the unbound thing. for sets? Use T as value (or NIL?)
* Use (empty) in a defmethod> instead of (leaf) in a defun
* kvlrh should be kvlrb

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
Lie, n.:
        A very poor substitute for the truth, but the only one
discovered to date.


On Thu, Nov 1, 2012 at 7:16 PM, Dan Lentz <danlentz at gmail.com> wrote:
> The source is available for review and comment in my LIL fork
> (https://github.com/danlentz/lisp-interface-library)  I still am in
> the process of putting together an official battery of tests, but
> informally things seem to be working just fine.  There are still some
> loose ends to clean up of course.
>
> There are also a number of additionional operations there in support
> of providing the backend of a <set> interface (union, intersection
> etc) I also have a number of set interface methods nearly ready but
> not as yet published to github.



From fahree at gmail.com  Fri Nov  2 02:03:58 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Thu, 1 Nov 2012 22:03:58 -0400
Subject: [lisp-interface-library-devel] Interface design
Message-ID: <CAN7nBXe95HWHCmqQA3WU3XQfED-t4GFDy_08xes3fmRsXDJfVw@mail.gmail.com>

I invited Jason Aeschliman to join us.
He has been doing some good interface design at
https://github.com/jaeschliman/com.clearly-useful.generic-collection-interface/
and I think it would be great to move that design to LIL.

(Jason, can you read this message?)

A few remarks, though:

* I hadn't thought about recognizers, but Jason did
 that's his :eponymous-method t statements.
 Now that I think of it, recognizers, like constructors,
 require special treatment in OO style, unlike in IPS.
 I'm adding a note in the TODO file about that;
 I need to somehow enhance my linear type system to handle this case.

* The most developed actual data structure library currently is
 cl-containers. There are also mixin libraries for Scala
 (they call them "traits"), and possibly Clojure, Haskell, etc.
 It might be a good idea that whoever develops our interfaces
 had a thought about compatibility with these existing interfaces
 (lots of not-so-sexy work, Sigh).

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
If this country is worth saving, it's worth saving at a profit. ? H. L. Hunt
This country can only be saved if it can be saved at a profit. ? Patri Friedman



From j.aeschliman at gmail.com  Fri Nov  2 02:21:22 2012
From: j.aeschliman at gmail.com (Jason Aeschliman)
Date: Thu, 1 Nov 2012 19:21:22 -0700
Subject: [lisp-interface-library-devel] Interface design
In-Reply-To: <CAN7nBXe95HWHCmqQA3WU3XQfED-t4GFDy_08xes3fmRsXDJfVw@mail.gmail.com>
References: <CAN7nBXe95HWHCmqQA3WU3XQfED-t4GFDy_08xes3fmRsXDJfVw@mail.gmail.com>
Message-ID: <63E04783-9B22-4D55-9615-4C7C51D9C0AB@gmail.com>


> (Jason, can you read this message?)

yep. I sent something to the list yesterday, but it looks like it didn't go through?
I'll try sending it again.


From j.aeschliman at gmail.com  Fri Nov  2 02:22:02 2012
From: j.aeschliman at gmail.com (Jason Aeschliman)
Date: Thu, 1 Nov 2012 19:22:02 -0700
Subject: [lisp-interface-library-devel] Fwd:
	com.clearly-useful.generic-collection-interface
References: <E375C022-AA44-4586-8CB9-81E79B72753A@gmail.com>
Message-ID: <0F1DEEA7-7B83-4064-BCD3-C55D05575FC7@gmail.com>



Begin forwarded message:

> From: Jason Aeschliman <j.aeschliman at gmail.com>
> Subject: Re: com.clearly-useful.generic-collection-interface
> Date: October 31, 2012 11:37:35 AM PDT
> To: lisp-interface-library-devel at common-lisp.net
> 
> 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/20121101/4a59c27c/attachment.html>

From fahree at gmail.com  Fri Nov  2 07:10:15 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Fri, 2 Nov 2012 03:10:15 -0400
Subject: [lisp-interface-library-devel] Common Lisp
Message-ID: <CAN7nBXeaoAYnibr9RKO=e-_bePfv5HGfnL+0=gekFmha62bOtA@mail.gmail.com>

Dear Volkan,

are you still maintaining your CL data structure libraries?

I've started a movement to consolidate libraries:
http://fare.livejournal.com/169346.html

I would like to migrate all data structures to my lisp-interface-library,
and subsequently declare previous libraries obsolete.
https://github.com/fare/lisp-interface-library/

I haven't added heaps (either binomial or binary) to LIL yet, though,
so for the moment I'm just probing you as a library author.
https://github.com/vy/binomial-heap
https://github.com/vy/bk-tree
http://web.itu.edu.tr/~yazicivo/

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
Be careful what you set your heart on ? for it will surely be yours.
        ? James Baldwin, "Nobody Knows My Name"



From fahree at gmail.com  Fri Nov  2 07:18:14 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Fri, 2 Nov 2012 03:18:14 -0400
Subject: [lisp-interface-library-devel] Consolidating Common Lisp Libraries
Message-ID: <CAN7nBXfQo8eGZX4Ptba1kD0ScSZiLp63Mx6zL1T7kvHDPDiKrw@mail.gmail.com>

Dear Karol,

are you still maintaining your CL data structure libraries?

I've started a movement to consolidate libraries:
http://fare.livejournal.com/169346.html

I would like to migrate all data structures to my lisp-interface-library,
and subsequently declare previous libraries obsolete.
https://github.com/fare/lisp-interface-library/

I haven't added sets or arrays to LIL yet, though,
so for the moment I'm just probing you as a library author.
https://github.com/ks/X.FDATATYPES/

Would you agree to the principle of merging libraries?
Do you have time to help?

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
Just as men both want many women and want to truly love a woman, women want
both a man who is appealing to many women and to be truly special to a man.
	? Obsidian Files



From karol.skocik at gmail.com  Fri Nov  2 09:36:26 2012
From: karol.skocik at gmail.com (karol skocik)
Date: Fri, 2 Nov 2012 10:36:26 +0100
Subject: [lisp-interface-library-devel] Consolidating Common Lisp
	Libraries
In-Reply-To: <CAN7nBXfQo8eGZX4Ptba1kD0ScSZiLp63Mx6zL1T7kvHDPDiKrw@mail.gmail.com>
References: <CAN7nBXfQo8eGZX4Ptba1kD0ScSZiLp63Mx6zL1T7kvHDPDiKrw@mail.gmail.com>
Message-ID: <CAB6KDOWTckrhKbXSft+-EGtRt-7yVdiT4jWnx1Vf2qSU6FYUfQ@mail.gmail.com>

HI Fare,

> are you still maintaining your CL data structure libraries?
>

when a bug is reported once in a while I fix it, yes, but can't promise when.

> I've started a movement to consolidate libraries:
> http://fare.livejournal.com/169346.html
>
> I would like to migrate all data structures to my lisp-interface-library,
> and subsequently declare previous libraries obsolete.
> https://github.com/fare/lisp-interface-library/
>
> I haven't added sets or arrays to LIL yet, though,
> so for the moment I'm just probing you as a library author.
> https://github.com/ks/X.FDATATYPES/
>
> Would you agree to the principle of merging libraries?
>

Yes, I am ok with obsoleting the library when it's part of a bigger thing,
and actually getting used for something.

> Do you have time to help?

Should have in a near future (couple of weeks) - I could spend a few
hours per week.
I lost a contract recently plus I am moving as well, so I have to sort
that out first.

Is there some general guidance written how to proceed with integration into LIL?

Cheers,
  Karol

>
> ??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
> Just as men both want many women and want to truly love a woman, women want
> both a man who is appealing to many women and to be truly special to a man.
>         ? Obsidian Files



From fahree at gmail.com  Fri Nov  2 10:29:16 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Fri, 2 Nov 2012 06:29:16 -0400
Subject: [lisp-interface-library-devel] Consolidating Common Lisp
	Libraries
In-Reply-To: <CAB6KDOWTckrhKbXSft+-EGtRt-7yVdiT4jWnx1Vf2qSU6FYUfQ@mail.gmail.com>
References: <CAN7nBXfQo8eGZX4Ptba1kD0ScSZiLp63Mx6zL1T7kvHDPDiKrw@mail.gmail.com>
	<CAB6KDOWTckrhKbXSft+-EGtRt-7yVdiT4jWnx1Vf2qSU6FYUfQ@mail.gmail.com>
Message-ID: <CAN7nBXcHKGYAV_DD2g8BjPLxf8X9FZPo9D6GnGdLfW3K0jH7xg@mail.gmail.com>

>> I've started a movement to consolidate libraries:
>> http://fare.livejournal.com/169346.html
>>
>> I would like to migrate all data structures to my lisp-interface-library,
>> and subsequently declare previous libraries obsolete.
>> https://github.com/fare/lisp-interface-library/
>>
>> I haven't added sets or arrays to LIL yet, though,
>> so for the moment I'm just probing you as a library author.
>> https://github.com/ks/X.FDATATYPES/
>>
>> Would you agree to the principle of merging libraries?
>>
>
> Yes, I am ok with obsoleting the library when it's part of a bigger thing,
> and actually getting used for something.
>
Of course. Excellent!

>> Do you have time to help?
>
> Should have in a near future (couple of weeks) - I could spend a few
> hours per week.
> I lost a contract recently plus I am moving as well, so I have to sort
> that out first.
>
> Is there some general guidance written how to proceed with integration into LIL?
>
At this point, it's
1- read the lil-ilc2012 article and/or slides.
2- create new interfaces for the new protocols (Jason Aeschliman was
working on that)
3- implement the interfaces, lifting your existing code, into the package PURE.
4- use the automated transform to reexpose wrapped versions of the code
 in POSH, STATEFUL, CLASSY.

For the POSH and CLASSY versions,
I wonder if we should take the (mostly) universal order from FSet
for a default version.
What irks me is that it is NOT actually universal;
but that might still be better than just a number comparison,
especially if we signal a serious condition in the unequal case.

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
It's better to know nothing that to know what ain't so. ? Josh Billings



From j.aeschliman at gmail.com  Fri Nov  2 19:44:34 2012
From: j.aeschliman at gmail.com (Jason Aeschliman)
Date: Fri, 2 Nov 2012 12:44:34 -0700
Subject: [lisp-interface-library-devel] Consolidating Common Lisp
	Libraries
In-Reply-To: <CAN7nBXcHKGYAV_DD2g8BjPLxf8X9FZPo9D6GnGdLfW3K0jH7xg@mail.gmail.com>
References: <CAN7nBXfQo8eGZX4Ptba1kD0ScSZiLp63Mx6zL1T7kvHDPDiKrw@mail.gmail.com>
	<CAB6KDOWTckrhKbXSft+-EGtRt-7yVdiT4jWnx1Vf2qSU6FYUfQ@mail.gmail.com>
	<CAN7nBXcHKGYAV_DD2g8BjPLxf8X9FZPo9D6GnGdLfW3K0jH7xg@mail.gmail.com>
Message-ID: <9E39C575-5269-4846-9E85-03F5AEF26357@gmail.com>


> 2- create new interfaces for the new protocols (Jason Aeschliman was
> working on that)

Just for reference, here's some work I've done for OOP style collections:
https://github.com/jaeschliman/com.clearly-useful.generic-collection-interface/blob/master/protocols.lisp

seq is proper-list-like
indexable is vector-like
associative is hash-table-like

these protocols are only for accessing, I haven't given any thought yet to
protocols for modifying collections. I haven't done anything for sets or trees
yet either. I will say that in terms of reading, it makes sense to me to treat sets
as maps from object-> value, where the meaning of 'value' differs depending
on what kind of set it is, a plain set would be obj->t, a counted set obj->number
etc, so testing for set membership could just be contains-key-p

Cheers,

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/lisp-interface-library-devel/attachments/20121102/f3bfefed/attachment.html>

From fahree at gmail.com  Sat Nov  3 02:57:07 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Fri, 2 Nov 2012 22:57:07 -0400
Subject: [lisp-interface-library-devel] fold-left vs fold-left*
Message-ID: <CAN7nBXd45QxhyzrRKZ4qYahU1CiKo63beGJVsYkrZ-jerinAwA@mail.gmail.com>

I am refactoring the LIL API to accommodate for sets, multisets,
queues and arrays as well as maps.
I find that the current fold-left, fold-right, for-each interfaces don't match,
because they assume two values (key value) associated with each entry,
whereas in the case of sets or arrays, only one value is warranted.
Other functions similarly could be shared if only one value were meant.

Therefore, I propose that fold-left, fold-right, for-each be one-value
functions,
and that for maps, a value is a key-value pair.
The generic name for the one value is entry, as in first-entry, etc.

If you are using any of for-each, fold-left, fold-right on maps, it
will soon change to
for-each*, fold-left*, fold-right*.

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
A man is usually more careful of his money than he is of his principles.
                ? Edgar Watson Howe



From fahree at gmail.com  Sat Nov  3 12:35:32 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Sat, 3 Nov 2012 08:35:32 -0400
Subject: [lisp-interface-library-devel] sets, multisets, etc.
Message-ID: <CAN7nBXdi0E_8sqYLcAzr-QZ0o7P7-suGbtVh=FKNEONT9u7dVg@mail.gmail.com>

I started work on sets, multisets, etc.
To count multisets, I added a monoid-fold to foldable, and this led to
quite some refactoring.
A lot of work.

More work ahead -- is anyone interested as a learning strategy,
in refactoring the tests so they map the interface hierarchy,
and/or simply in adding tests for sets and multisets?

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
"I'm going to live forever, or die trying!" ? Spider Robinson



From fahree at gmail.com  Sat Nov  3 15:52:33 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Sat, 3 Nov 2012 11:52:33 -0400
Subject: [lisp-interface-library-devel] API design
Message-ID: <CAN7nBXegRrTpNOjQ=Doi4zSYuwZDzd9mp61uHWEd8ZQ0W7Q_qw@mail.gmail.com>

So I'm adding an API for sets, soon to be followed by sequences and arrays.

Also, drewc is using something called quick-build, which is similar in
principle to faslpath,
and proposes we should use it for LIL. I'd like to try, but it's yet
more work. Sigh.

Stupid questions:
1- Should all symbols have a simple home package (e.g. pure, stateful,
interface, classy, posh, stylish), or should they be visible from said
package but have a home package based on wherever the symbol was
originally defined?
2- When iterating over a multiset, should we see a multiply-member
element multiple times, or should we see each element once, with a
count? Or should we have both interfaces?
3- How much efforts should I make to mimic the typeclasses of Haskell
or the interfaces of Clojure?
4- So far I've avoided clashes with package CL. Should I clash more readily?

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
God must love the Common Man; He made so many of them.



From danlentz at gmail.com  Sun Nov  4 01:18:53 2012
From: danlentz at gmail.com (Dan Lentz)
Date: Sat, 3 Nov 2012 21:18:53 -0400
Subject: [lisp-interface-library-devel] AP5 -- but I guess you knew that
	already...
Message-ID: <-8214169163419042188@unknownmsgid>

So I just stumbled into AP5 and couldn't wait to report my "discovery"
to this list as there are many ways it directly applies to the
relations between the LIL interfaces -- ie the very thing we are doing
right now.

But several mouse clicks later I see you've known about this for a
long time and even have it as s "recommended library" on tunes.org...

Does it work ?  Why aren't you using it?

----
Replace the method
the carefully chosen name
deletes the comment



From fahree at gmail.com  Mon Nov  5 12:29:40 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Mon, 5 Nov 2012 07:29:40 -0500
Subject: [lisp-interface-library-devel] AP5 -- but I guess you knew that
	already...
In-Reply-To: <-8214169163419042188@unknownmsgid>
References: <-8214169163419042188@unknownmsgid>
Message-ID: <CAN7nBXdvRjDkTfid-F+CB_Vboz7qfFcDbvvt_quhnGub38j9Rg@mail.gmail.com>

On Sat, Nov 3, 2012 at 9:18 PM, Dan Lentz <danlentz at gmail.com> wrote:
> So I just stumbled into AP5 and couldn't wait to report my "discovery"
> to this list as there are many ways it directly applies to the
> relations between the LIL interfaces -- ie the very thing we are doing
> right now.
>
> But several mouse clicks later I see you've known about this for a
> long time and even have it as s "recommended library" on tunes.org...
>
> Does it work ?  Why aren't you using it?
>
Yes, AP5 works, or at least used to work.
Yes, it is a sensible approach to defining data models.
I'm not using it because I haven't had the opportunity to determine
the tools used for data modelling, so far, only to work below or above
that part of software design. However, thanks for mentioning it right
now, because I might...

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
It is said that pragmatism trumps ideology in a crisis. What actually happens
in a crisis, certainly in this one, is that the ruling party gets to
rechristen its ideology as pragmatism. ? Christopher Caldwell



From fahree at gmail.com  Wed Nov  7 04:26:12 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Tue, 6 Nov 2012 23:26:12 -0500
Subject: [lisp-interface-library-devel] Giving my LIL talk online
Message-ID: <CAN7nBXcf4fG0i263OBeCGSuETTBn6GgwQKp+cOUiniJvoEe0ow@mail.gmail.com>

Dear LIL hackers,

I want to give my LIL talk again, and this time record it, and
I'm looking for a public to keep me real and try to answer the questions.
My friend Kohei is willing to attend, and our current prospective dates are
November 15th in the evening (after 8pm EST),
or on November 16th in the morning (anytime before noon EST).
17th evening, morning and evening on 18th & 19th are also possible.

Commands such as date -d '20:00EST' can help you translate between
my time and yours. In the other way, TZ=US/Eastern date -d '08:00'.

Is any of you interested in attending over Google Hangout?
I'll share my screen over Hangout, and do my thing.
My target time was 50 minute, but I ran out of time,
so realistically, 90 minute for complete thing + questions is a safer bet,
though I'll try to cut through less important stuff (unless you all
want a longer version).

Thanks!

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
Always remember that you are unique.  Just like everyone else.



From fahree at gmail.com  Sun Nov 11 15:04:40 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Sun, 11 Nov 2012 10:04:40 -0500
Subject: [lisp-interface-library-devel] Giving my LIL talk online
In-Reply-To: <CAN7nBXcf4fG0i263OBeCGSuETTBn6GgwQKp+cOUiniJvoEe0ow@mail.gmail.com>
References: <CAN7nBXcf4fG0i263OBeCGSuETTBn6GgwQKp+cOUiniJvoEe0ow@mail.gmail.com>
Message-ID: <CAN7nBXe7pgcSzp2ayVrckMLytLJ+2cv6hA9s0dBRRULjW+399A@mail.gmail.com>

OK, so let's make it on Thursday the 15th in the evening at 8pm EST.

Thu Nov 15 20:00:00 EST 2012
Thu Nov 15 17:00:00 PST 2012
Fri Nov 16 01:00:00 UTC 2012
Fri Nov 16 10:00:00 JST 2012

I'll use Google Hangout as from my Google+ account as fahree at gmail.com,
https://plus.google.com/108564127390615114635/posts

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
Apparently a government can prevent itself and its successors indefinite
from doing bad things, just by writing a note to itself that says
"don't do bad things." ? Mencius Moldbug on constitutions


On Tue, Nov 6, 2012 at 11:26 PM, Far? <fahree at gmail.com> wrote:
> Dear LIL hackers,
>
> I want to give my LIL talk again, and this time record it, and
> I'm looking for a public to keep me real and try to answer the questions.
> My friend Kohei is willing to attend, and our current prospective dates are
> November 15th in the evening (after 8pm EST),
> or on November 16th in the morning (anytime before noon EST).
> 17th evening, morning and evening on 18th & 19th are also possible.
>
> Commands such as date -d '20:00EST' can help you translate between
> my time and yours. In the other way, TZ=US/Eastern date -d '08:00'.
>
> Is any of you interested in attending over Google Hangout?
> I'll share my screen over Hangout, and do my thing.
> My target time was 50 minute, but I ran out of time,
> so realistically, 90 minute for complete thing + questions is a safer bet,
> though I'll try to cut through less important stuff (unless you all
> want a longer version).
>
> Thanks!
>
> ??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
> Always remember that you are unique.  Just like everyone else.