From fahree at gmail.com  Mon Oct 29 02:32:34 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Mon, 29 Oct 2012 11:32:34 +0900
Subject: [lisp-interface-library-devel] Welcome to LIL
Message-ID: <CAN7nBXcBvmEVkheBiEwqxzFSuOBRmJRTWqCCbk0U7Hwifcc72A@mail.gmail.com>

This mailing-list discusses the Lisp-Interface-Library for data structures
in Interface-Passing Style as well as traditional Object-Oriented Style.

The current official code repository is on github:
https://github.com/fare/lisp-interface-library/

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
A successful [software] tool is one that was used to do something
undreamed of by its author.
                ? S. C. Johnson



From danlentz at gmail.com  Mon Oct 29 20:15:56 2012
From: danlentz at gmail.com (Dan Lentz)
Date: Mon, 29 Oct 2012 16:15:56 -0400
Subject: [lisp-interface-library-devel] Curating libraries
In-Reply-To: <CAN7nBXdoMYe2HyATNgzOPg1qmbZP-WJGYx-rJkYHL5U2E43Dxg@mail.gmail.com>
References: <CAN7nBXdoMYe2HyATNgzOPg1qmbZP-WJGYx-rJkYHL5U2E43Dxg@mail.gmail.com>
Message-ID: <2284752921500208126@unknownmsgid>

----
On Oct 28, 2012, at 10:15 PM, "Far?" <fahree at gmail.com> wrote:

> Dear Dan,
>
> Maybe we should be moving this discussion to another list.
> I've asked admin at common-lisp.net to create lisp-interface-library-devel.
>
>> : Dan Lentz
>> Regarding consolidation under LIL just wondering if someone might have
>> suggestions for individual authors of CL data structure libraries on
>> how to work in a way most cooperative with the effort.  For example I
>> have a small ctrie lib (http://github.com/danlentz/cl-ctrie) the
>> objective should be to refactor based on what unique interface it
>> could provide, such as "concurrent" or "lock-free"?
>>
>> Perhaps this question is somewhat specific to LIL but it is a project
>> I've been following with interest
> It would be delighted to help with such an effort,
> either a merge of the two libraries,
> or a layer to make them work together.
>
> Also, considering that LIL has so few users (just drewc and I, IIUC),
> it is still time to rename basic API functions if you have strong opinions.
>
> While adding support for concurrent data structures
> has long been on my TODO list,
> I admit I haven't given much thought on how to automate (or not)
> whatever locking is required (or not) on various methods
> (not the same methods, depending on the data structure).
> So far, my hypothesis is that nothing needs to be changed
> as far as the signature of map interfaces goes:
> the underlying implementation may or may not be concurrent,
> that doesn't directly affect the calling conventions.
>
> Of course, concurrently accessing a non-concurrent data structure
> may blow up in your face, but
> I don't know how to express linearity constraints in Lisp, yet.
> That's a topic I'm actively researching, though, and suggestions are welcome.
>
> In short, I'd love that to happen, I'm ready to help, and
> a small data structure library is the perfect place to start.
>
> PS: I've added you as a contributor on
>  https://github.com/fare/lisp-interface-library
>
> ??? ? 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 danlentz at gmail.com  Mon Oct 29 20:50:57 2012
From: danlentz at gmail.com (Dan Lentz)
Date: Mon, 29 Oct 2012 16:50:57 -0400
Subject: [lisp-interface-library-devel] Curating libraries
In-Reply-To: <2284752921500208126@unknownmsgid>
References: <CAN7nBXdoMYe2HyATNgzOPg1qmbZP-WJGYx-rJkYHL5U2E43Dxg@mail.gmail.com>
	<2284752921500208126@unknownmsgid>
Message-ID: <3549313487018110526@unknownmsgid>

Fare

I've got ctries, redblack trees, and weight-balanced trees I've been
thinking about trying to integrate with/into LIL.  I would be proud if
any/all of it were to be rolled into the LIL project proper.

Regarding non-concurrent structures with concurrent interface --  I'm
probably not the most qualified to answer but if you we're to ask me I
think that new futures library by deliciousrobot looks interesting.
It implements  cooperative multitasking based on green threads built
using cl-cont.

My access to email is sporadic over the next day or so.  Everyone here
in South Jersey is hunkered down in anticipation of the hurricane.

best regards,
Dan Lentz



From me at drewc.ca  Mon Oct 29 21:32:32 2012
From: me at drewc.ca (Drew Crampsie)
Date: Mon, 29 Oct 2012 14:32:32 -0700
Subject: [lisp-interface-library-devel] Curating libraries
In-Reply-To: <3549313487018110526@unknownmsgid>
References: <CAN7nBXdoMYe2HyATNgzOPg1qmbZP-WJGYx-rJkYHL5U2E43Dxg@mail.gmail.com>
	<2284752921500208126@unknownmsgid>
	<3549313487018110526@unknownmsgid>
Message-ID: <CAPySywasy9WopN5GCcNzY=s+oZHm+q3tym26mkRmMWYKYu7dSw@mail.gmail.com>

cl-cont .. heh ...

This is the call/cc that will/should be included in :interface/monad :

(define-interface <monad> (<type>) ()
  (:singleton)
  (:generic result (<monad> value))
  (:generic bind (<monad>  monadic-value monadic-function)))

(defmacro mlet* (monad bindings &body body)
  (destructuring-bind (monad &optional (functions-spec '<monad>))
      (or (when (listp monad) monad) (list monad))
    `(macrolet ((%mlet* (((symbol monadic-value) &rest rest) &body body)
  `(bind ,monadic-value
 (lambda (,symbol)
   ,@(when (string-equal (symbol-name symbol) "_")
   `((declare (ignorable ,symbol))))
   ,@(if rest
 `((%mlet* ,rest
   , at body))
 body)))))
       (interface:with-interface (,monad ,functions-spec)
 ,@(if bindings
      `((%mlet* ,bindings , at body))
      body)))))

(interface:define-interface <continuation> (<monad>)
  ()
  (:singleton)
  (:generic call/cc (<continuation> function)))

(defmethod result ((m <continuation>) value)
  (lambda (k) (funcall k value)))

;m >>= f  = Cont (\k -> runCont m (\a -> runCont (f a) k))

(defmethod bind ((m <continuation>) mv mf)
  (lambda (k)
    (funcall mv
     (lambda (a)
       (funcall (funcall mf a)
k)))))

; callCC f = Cont $ \k -> runCont (f (\a -> Cont $ \_ -> k a)) k

(defmethod call/cc ((m <continuation>) fn)
  (lambda (k)
    (funcall (funcall fn (lambda (a)
   (lambda (_)
     (declare (ignore _))
     (funcall k a))))
     k)))


;;; Then:

ORG/IPS/MONAD/CONTINUATION> (let (cc)
      (mlet* (<continuation>)
  ((a (result 1))
   (a.5 (lambda (k) (setf cc k) (funcall k 5)))
   (b (result 2))
   (c (result (+ a a.5 b))))
(result (list c cc))))

=>#<CLOSURE (LAMBDA (K) :IN BIND) {CBBCE15}>

ORG/IPS/MONAD/CONTINUATION> (funcall *  #'identity)
=> (8 #<CLOSURE (LAMBDA # :IN BIND) {B88785D}>)

ORG/IPS/MONAD/CONTINUATION> (funcall (second *) 6)
=> (9 #<CLOSURE (LAMBDA # :IN BIND) {B88785D}>)

ORG/IPS/MONAD/CONTINUATION> (funcall (second *) 10)
=> (13 #<CLOSURE (LAMBDA # :IN BIND) {B88785D}>)

So, that is call/cc based on the cont monad, in IPS. w00t.

any questions/comments/etc are most welcome.

Cheers,
drewc

On Mon, Oct 29, 2012 at 1:50 PM, Dan Lentz <danlentz at gmail.com> wrote:

> Fare
>
> I've got ctries, redblack trees, and weight-balanced trees I've been
> thinking about trying to integrate with/into LIL.  I would be proud if
> any/all of it were to be rolled into the LIL project proper.
>
> Regarding non-concurrent structures with concurrent interface --  I'm
> probably not the most qualified to answer but if you we're to ask me I
> think that new futures library by deliciousrobot looks interesting.
> It implements  cooperative multitasking based on green threads built
> using cl-cont.
>
> My access to email is sporadic over the next day or so.  Everyone here
> in South Jersey is hunkered down in anticipation of the hurricane.
>
> best regards,
> Dan Lentz
>
> _______________________________________________
> lisp-interface-library-devel mailing list
> lisp-interface-library-devel at common-lisp.net
>
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/lisp-interface-library-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/lisp-interface-library-devel/attachments/20121029/1e72a149/attachment.html>

From fahree at gmail.com  Mon Oct 29 22:36:55 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Tue, 30 Oct 2012 07:36:55 +0900
Subject: [lisp-interface-library-devel] Curating libraries
In-Reply-To: <CAPySywasy9WopN5GCcNzY=s+oZHm+q3tym26mkRmMWYKYu7dSw@mail.gmail.com>
References: <CAN7nBXdoMYe2HyATNgzOPg1qmbZP-WJGYx-rJkYHL5U2E43Dxg@mail.gmail.com>
	<2284752921500208126@unknownmsgid> <3549313487018110526@unknownmsgid>
	<CAPySywasy9WopN5GCcNzY=s+oZHm+q3tym26mkRmMWYKYu7dSw@mail.gmail.com>
Message-ID: <CAN7nBXfqP4eALuADAVdXHKGqpiKeoVtS2F0KyPVo07jgb6aWNQ@mail.gmail.com>

On Tue, Oct 30, 2012 at 6:32 AM, Drew Crampsie <me at drewc.ca> wrote:
> This is the call/cc that will/should be included in :interface/monad :
>
Yay for the continuation monad!

I propose you create a ips-monad.asd system and put the code
in a new monad/ directory.

> (define-interface <monad> (<type>) ()
>   (:singleton)
>   (:generic result (<monad> value))
>   (:generic bind (<monad>  monadic-value monadic-function)))
>
I would personally use :generic> to elide the <monad> argument,
here and in all definitions you have where it applies.

>   ,@(when (string-equal (symbol-name symbol) "_")
>   `((declare (ignorable ,symbol))))
Shouldn't that be ignore instead?

> ORG/IPS/MONAD/CONTINUATION>
I would put everything in the MONAD package,
or IPS-MONAD if you suspect there might be
any useful non-IPS monad package.

> So, that is call/cc based on the cont monad, in IPS. w00t.
>
Re-w00t!

> any questions/comments/etc are most welcome.
>
How do I combine several monads,
say, non-determinism, continuation, error, state monads?

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
Few facts are more revealing than the direction people travel
when they vote with their feet. ? Don Boudreaux http://bit.ly/afZgx2



From fahree at gmail.com  Mon Oct 29 22:48:52 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Tue, 30 Oct 2012 07:48:52 +0900
Subject: [lisp-interface-library-devel] Curating libraries
In-Reply-To: <3549313487018110526@unknownmsgid>
References: <CAN7nBXdoMYe2HyATNgzOPg1qmbZP-WJGYx-rJkYHL5U2E43Dxg@mail.gmail.com>
	<2284752921500208126@unknownmsgid> <3549313487018110526@unknownmsgid>
Message-ID: <CAN7nBXc0oB2H3ErNKfYumj3PTTbxkV+Bgn=2NryV+sC6rikBvQ@mail.gmail.com>

On Tue, Oct 30, 2012 at 5:50 AM, Dan Lentz <danlentz at gmail.com> wrote:
> I've got ctries, redblack trees, and weight-balanced trees I've been
> thinking about trying to integrate with/into LIL.  I would be proud if
> any/all of it were to be rolled into the LIL project proper.
>
Yes. we already have AVL trees, so redblack and weight-balanced
should be easiest to integrate in the current framework.
Could you write both the pure and stateful variants?

I have some vague ideas on how both pure and stateful data structures
could be deduced from a single specification using IPS (at compile-time?)
to distinguish between the two variants. Something like:
	(update-node! <pure?> node :left l :right r)
Would expand either to in-place modification of the node (stateful case),
or creation of a new node (pure case).
But I haven't tried anything like that yet, so please disregard
unless you're interested in experimenting yourself.

> Regarding non-concurrent structures with concurrent interface --  I'm
> probably not the most qualified to answer but if you we're to ask me I
> think that new futures library by deliciousrobot looks interesting.
> It implements  cooperative multitasking based on green threads built
> using cl-cont.
>
I remember doing green threads on top of arnesi, in philip-jose.
It was great. I should definitely contact deliciousrobot at some point
and send him my code in case he's missing anything, so we can declare
philip-jose dead and consolidate.

> My access to email is sporadic over the next day or so.  Everyone here
> in South Jersey is hunkered down in anticipation of the hurricane.
>
No problem. Take your time, and be safe!

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
Success is getting what you want. Happiness is wanting what you get.
        ? Dale Carnegie



From me at drewc.ca  Tue Oct 30 02:33:05 2012
From: me at drewc.ca (Drew Crampsie)
Date: Mon, 29 Oct 2012 19:33:05 -0700
Subject: [lisp-interface-library-devel] Fwd:  Curating libraries
In-Reply-To: <CAPySywaMddGi2A_QwFOBgw_0wCpohTxbhUs2CtEyfD1ufkyh_A@mail.gmail.com>
References: <CAN7nBXdoMYe2HyATNgzOPg1qmbZP-WJGYx-rJkYHL5U2E43Dxg@mail.gmail.com>
	<2284752921500208126@unknownmsgid>
	<3549313487018110526@unknownmsgid>
	<CAPySywasy9WopN5GCcNzY=s+oZHm+q3tym26mkRmMWYKYu7dSw@mail.gmail.com>
	<CAN7nBXfqP4eALuADAVdXHKGqpiKeoVtS2F0KyPVo07jgb6aWNQ@mail.gmail.com>
	<CAPySywaMddGi2A_QwFOBgw_0wCpohTxbhUs2CtEyfD1ufkyh_A@mail.gmail.com>
Message-ID: <CAPySywbgqFHhekcoUVa2tV489_A+R5v9+eRP4QpaD_5vi6tA9w@mail.gmail.com>

forgot to cc the list, fwded!

---------- Forwarded message ----------
From: Drew Crampsie <me at drewc.ca>
Date: Mon, Oct 29, 2012 at 4:41 PM
Subject: Re: [lisp-interface-library-devel] Curating libraries
To: Far? <fahree at gmail.com>




On Mon, Oct 29, 2012 at 3:36 PM, Far? <fahree at gmail.com> wrote:

> On Tue, Oct 30, 2012 at 6:32 AM, Drew Crampsie <me at drewc.ca> wrote:
> > This is the call/cc that will/should be included in :interface/monad :
> >
> Yay for the continuation monad!
>
> I propose you create a ips-monad.asd system and put the code
> in a new monad/ directory.
>
> K, can do. In my local code, I have one package per file. And I plan on
keeping it that way...

 > (define-interface <monad> (<type>) ()
> >   (:singleton)
> >   (:generic result (<monad> value))
> >   (:generic bind (<monad>  monadic-value monadic-function)))
> >
> I would personally use :generic> to elide the <monad> argument,
> here and in all definitions you have where it applies.
>

Makes sense, it simply was not there when I did that :)

>
> >   ,@(when (string-equal (symbol-name symbol) "_")
> >   `((declare (ignorable ,symbol))))
> Shouldn't that be ignore instead?
>
> > ORG/IPS/MONAD/CONTINUATION>
> I would put everything in the MONAD package,
> or IPS-MONAD if you suspect there might be
> any useful non-IPS monad package.
>

can we say INTERFACE/MONAD ? that package name makes sense to me as it
relies on INTERFACE package and is a part of the new IPS thingie.

>
> > So, that is call/cc based on the cont monad, in IPS. w00t.
> >
> Re-w00t!
>
> > any questions/comments/etc are most welcome.
> >
> How do I combine several monads,
> say, non-determinism, continuation, error, state monads?
>

strangley enough, this is dealt with by monads themselves .

(interface:define-interface <transformer> (<monad>)
  ((inner-monad :accessor inner
:initarg :inner
:initarg inner
 :initform <identity>))
  (:singleton)
  (:parametric (&optional (inner <identity>))
     (make-interface :key-interface inner))
  (:generic inner (<transformer>))
  (:generic lift (<transformer> inner-monadic-value))
  (:method lift (inner-monadic-value)
   inner-monadic-value))

(defmethod result ((m <transformer>) value)
  (lift m (result (inner m) value)))

(defmethod bind ((m <transformer>) mv mf)
  (lift m (bind (inner m) mv mf)))

 and ...

(interface:define-interface <list-transformer>
    (<list> <transformer>)
  ()
  (:singleton)
  (:method* result ((m <list-transformer>) value)
    (call-next-method m
      (result (inner m) value))))

(defmethod lift ((m <list-transformer>) inner-mv)
  (list inner-mv))


(defmethod bind ((m <list-transformer>) mvs mf)
  (loop :for mv in mvs
     :append (bind (inner m) mv mf)))


The double (<list> <transformer>) superclasses is new, but besides that,
the <list-transformer> is pretty much copied straight from haskell.

How to combine the monads? that depends on which order you want them in,
but <foo-transformer> for every one that needs an 'inner' monad.

Does that make sense? There is no inheritance to combine the monads, but
rather <transformer>s (the code, not the robots in disguise).

So, say, (define-interface <foo> (<state-transformer>) (()
(:default-initargs :inner <error>))) or something like that, to combine the
state (toplevel) with the error.

or, heh ... (eval '(<state-transformer> :inner (<error-transformer> :inner
<continuation>)) if we do not need the class define at all etc.

Can tell more about it if required, and do not mind because it will all be
in my docs anyway :)

Cheers,
drewc


?? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics?
> http://fare.tunes.org
> Few facts are more revealing than the direction people travel
> when they vote with their feet. ? Don Boudreaux http://bit.ly/afZgx2
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/lisp-interface-library-devel/attachments/20121029/bf4f7b28/attachment.html>

From danlentz at gmail.com  Tue Oct 30 11:53:28 2012
From: danlentz at gmail.com (Dan Lentz)
Date: Tue, 30 Oct 2012 07:53:28 -0400
Subject: [lisp-interface-library-devel] Curating libraries
In-Reply-To: <CAN7nBXc0oB2H3ErNKfYumj3PTTbxkV+Bgn=2NryV+sC6rikBvQ@mail.gmail.com>
References: <CAN7nBXdoMYe2HyATNgzOPg1qmbZP-WJGYx-rJkYHL5U2E43Dxg@mail.gmail.com>
	<2284752921500208126@unknownmsgid>
	<3549313487018110526@unknownmsgid>
	<CAN7nBXc0oB2H3ErNKfYumj3PTTbxkV+Bgn=2NryV+sC6rikBvQ@mail.gmail.com>
Message-ID: <CANco9BuDNWagyiE7YZ04i5DZtP4s6TQA0kYSdq1_Y2JEc7xLrg@mail.gmail.com>

Fare I will study the AVL implementation and begin work bringing WB and RB
into conformance as soon as power returns (I'm still sitting in the dark
over here; thank heavens for smartphones)  I've been doing a similar type
of thing with pure and stateful, only using dynamically scoped functions
and contextl.  IPS seems to accomplish the same goal but in a way that
improves on this approach in a number of ways, not the least if which is
being more clear and evident to the reader.

In fact DrewC may appreciate I'd been using his CSTM as a means of
implementing the "box" of the root container in my "stateful" type.

Ctries are very different from binary trees of course but also very easy to
implement pure and stateful by virtue of the capability for O(1) "Atomic
Fork" operation which produces a (still mutable) structure that is
independently readable and writable at a small cost to the next few
subsequent lookup operations in both the original and clone Ctries.

No doubt the ctrie is kind of an "odd duck" but also present some
opportunity for harnessing different types of behaviors more difficult with
other structures

Very happy to be participating in this effort,
Dan

On Monday, October 29, 2012, Far? wrote:

> On Tue, Oct 30, 2012 at 5:50 AM, Dan Lentz <danlentz at gmail.com<javascript:;>>
> wrote:
> > I've got ctries, redblack trees, and weight-balanced trees I've been
> > thinking about trying to integrate with/into LIL.  I would be proud if
> > any/all of it were to be rolled into the LIL project proper.
> >
> Yes. we already have AVL trees, so redblack and weight-balanced
> should be easiest to integrate in the current framework.
> Could you write both the pure and stateful variants?
>
> I have some vague ideas on how both pure and stateful data structures
> could be deduced from a single specification using IPS (at compile-time?)
> to distinguish between the two variants. Something like:
>         (update-node! <pure?> node :left l :right r)
> Would expand either to in-place modification of the node (stateful case),
> or creation of a new node (pure case).
> But I haven't tried anything like that yet, so please disregard
> unless you're interested in experimenting yourself.
>
> > Regarding non-concurrent structures with concurrent interface --  I'm
> > probably not the most qualified to answer but if you we're to ask me I
> > think that new futures library by deliciousrobot looks interesting.
> > It implements  cooperative multitasking based on green threads built
> > using cl-cont.
> >
> I remember doing green threads on top of arnesi, in philip-jose.
> It was great. I should definitely contact deliciousrobot at some point
> and send him my code in case he's missing anything, so we can declare
> philip-jose dead and consolidate.
>
> > My access to email is sporadic over the next day or so.  Everyone here
> > in South Jersey is hunkered down in anticipation of the hurricane.
> >
> No problem. Take your time, and be safe!
>
> ??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics?
> http://fare.tunes.org
> Success is getting what you want. Happiness is wanting what you get.
>         ? Dale Carnegie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/lisp-interface-library-devel/attachments/20121030/1ee9f350/attachment.html>

From fahree at gmail.com  Tue Oct 30 22:44:40 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Tue, 30 Oct 2012 18:44:40 -0400
Subject: [lisp-interface-library-devel] Curating libraries
In-Reply-To: <CANco9BuDNWagyiE7YZ04i5DZtP4s6TQA0kYSdq1_Y2JEc7xLrg@mail.gmail.com>
References: <CAN7nBXdoMYe2HyATNgzOPg1qmbZP-WJGYx-rJkYHL5U2E43Dxg@mail.gmail.com>
	<2284752921500208126@unknownmsgid> <3549313487018110526@unknownmsgid>
	<CAN7nBXc0oB2H3ErNKfYumj3PTTbxkV+Bgn=2NryV+sC6rikBvQ@mail.gmail.com>
	<CANco9BuDNWagyiE7YZ04i5DZtP4s6TQA0kYSdq1_Y2JEc7xLrg@mail.gmail.com>
Message-ID: <CAN7nBXe6auK7Umb6wLzvu=YSHFvcRd+Yh_1rpU=jQGPrgXqmaw@mail.gmail.com>

On Tue, Oct 30, 2012 at 7:53 AM, Dan Lentz <danlentz at gmail.com> wrote:
> Fare I will study the AVL implementation and begin work bringing WB and RB
> into conformance as soon as power returns (I'm still sitting in the dark
> over here; thank heavens for smartphones)  I've been doing a similar type of
> thing with pure and stateful, only using dynamically scoped functions and
> contextl.  IPS seems to accomplish the same goal but in a way that improves
> on this approach in a number of ways, not the least if which is being more
> clear and evident to the reader.
>
I'm glad you like it!

> In fact DrewC may appreciate I'd been using his CSTM as a means of
> implementing the "box" of the root container in my "stateful" type.
>
I have no idea what you mean, but it sounds cool :-)

BTW,
1- your file ctrie-lambda scares me!
2- the cas thing should definitely be moved to its own system.

> Ctries are very different from binary trees of course but also very easy to
> implement pure and stateful by virtue of the capability for O(1) "Atomic
> Fork" operation which produces a (still mutable) structure that is
> independently readable and writable at a small cost to the next few
> subsequent lookup operations in both the original and clone Ctries.
>
I can't imagine how that would work, but I suppose I could read the
articles, first.

> No doubt the ctrie is kind of an "odd duck" but also present some
> opportunity for harnessing different types of behaviors more difficult with
> other structures
>
Every structure is an "odd duck", different from all others.
That's the point in having so many of them.

> Very happy to be participating in this effort,
> Dan
>
Yay! Let's happily hack this thing together.

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
There is no such thing as philosophy-free science; there is only science
whose philosophical baggage is taken on board without examination.
	? Daniel C. Dennett, Darwin's Dangerous Idea



From danlentz at gmail.com  Wed Oct 31 00:35:08 2012
From: danlentz at gmail.com (Dan Lentz)
Date: Tue, 30 Oct 2012 20:35:08 -0400
Subject: [lisp-interface-library-devel] Curating libraries
In-Reply-To: <CAN7nBXe6auK7Umb6wLzvu=YSHFvcRd+Yh_1rpU=jQGPrgXqmaw@mail.gmail.com>
References: <CAN7nBXdoMYe2HyATNgzOPg1qmbZP-WJGYx-rJkYHL5U2E43Dxg@mail.gmail.com>
	<2284752921500208126@unknownmsgid>
	<3549313487018110526@unknownmsgid>
	<CAN7nBXc0oB2H3ErNKfYumj3PTTbxkV+Bgn=2NryV+sC6rikBvQ@mail.gmail.com>
	<CANco9BuDNWagyiE7YZ04i5DZtP4s6TQA0kYSdq1_Y2JEc7xLrg@mail.gmail.com>
	<CAN7nBXe6auK7Umb6wLzvu=YSHFvcRd+Yh_1rpU=jQGPrgXqmaw@mail.gmail.com>
Message-ID: <CANco9BtWHCnAkze=ciFREZLtuTsErHbUScutg3gmMbRVA10Dyg@mail.gmail.com>

>
> > In fact DrewC may appreciate I'd been using his CSTM as a means of
> > implementing the "box" of the root container in my "stateful" type.
> >
> I have no idea what you mean, but it sounds cool :-)


Drew seems to have a number of fascinating libraries...  He redid pascal
costanza's contextl based STM library a while back -- I've been calling it
CSTM but maybe I have the name incorrect.

My "box" was implemented as a CSTM transactional-class with one slot:
VALUE.  I used this as a container for the root node of a pure functional
tree to effect a transactionally mutable variant of that structure.  A
transaction would be to replace the root node in this box with the root
node of the updated tree on commit.

I forked LIL and placed some sources taken from my wb and rb trees into
contrib if you're interested to take a look at where I'm starting from.
 It's the majority of the core treeish stuff but pruned to the basic
routines.   Naturally it is just for reference and doesn't compile in this
state.

The implementation is mostly based on Adams purely functional data
structures, plus a couple other papers mentioned in the weight balanced
file.  One good thing is that it seems like it should be straightforward to
translate my use of layers into interfaces, at least at the moment.

I see the AVL trees do "post-balanced" where balancing occurs in the
stateful interface-- is that correct and is that technique something I
should try to replicate?  It would be nice if my binary trees conformed
with your AVL as much as possible I think but on the other hand maybe there
is some value in the Adams approach?  OTOH your way results in a truly
mutable structure in stateful, where my approach was just to have a mutable
"box" containing the current root node.


> BTW,
> 1- your file ctrie-lambda scares me!


yeah, just a plaything.


> 2- the cas thing should definitely be moved to its own system.
>
>
Noted.  I am not sure if Clozure has comparable CAS routines and don't have
a Lispworks license but the original thought was to have some manner of CAS
compatibility layer there.  Actually none of it is used at all in master
branch, and the only part currently used (in the persistence branch) is
CAS-WORD-SAP.


> > Ctries are very different from binary trees of course but also very easy
> to
> > implement pure and stateful by virtue of the capability for O(1) "Atomic
> > Fork" operation which produces a (still mutable) structure that is
> > independently readable and writable at a small cost to the next few
> > subsequent lookup operations in both the original and clone Ctries.
> >
> I can't imagine how that would work, but I suppose I could read the
> articles, first.
>
> I probably did a poor job of describing it, but yes the articles go into
more detail.  As you said though the binary trees are an easier place to
start and get my feet wet with IPS and after that I should be in a better
position to tackle the ctries.

> No doubt the ctrie is kind of an "odd duck" but also present some
> > opportunity for harnessing different types of behaviors more difficult
> with
> > other structures
> >
> Every structure is an "odd duck", different from all others.
> That's the point in having so many of them.
>
> Indeed.  Probably the red-black trees are a little bit redundant with AVL
(except for some small benefits for insert dominant workload) but as they
are so similar to the existing height balanced interface they seem like the
easiest place for me to start. So there is value in that sense.

> Very happy to be participating in this effort,
> > Dan
> >
> Yay! Let's happily hack this thing together.
>
>
Do you have suggestions on workflow?  I forked LIL for now -- should I be
instead (or also) in a branch?  I'm a little bit of a boob when it comes to
git.  Currently your AVL specifics are in the tree, tree-interface files,
but it seems problematic if I were to also include the others into them.
 Just looking for your preference on this type of thing.

BTW I meant to type "noob when it comes to git" above, but on consideration
I'll let the typo stand. :)

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics?
> http://fare.tunes.org
> There is no such thing as philosophy-free science; there is only science
> whose philosophical baggage is taken on board without examination.
>         ? Daniel C. Dennett, Darwin's Dangerous Idea
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/lisp-interface-library-devel/attachments/20121030/f330cacf/attachment.html>

From fahree at gmail.com  Wed Oct 31 06:43:27 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Wed, 31 Oct 2012 02:43:27 -0400
Subject: [lisp-interface-library-devel] Curating libraries
In-Reply-To: <CANco9BtWHCnAkze=ciFREZLtuTsErHbUScutg3gmMbRVA10Dyg@mail.gmail.com>
References: <CAN7nBXdoMYe2HyATNgzOPg1qmbZP-WJGYx-rJkYHL5U2E43Dxg@mail.gmail.com>
	<2284752921500208126@unknownmsgid> <3549313487018110526@unknownmsgid>
	<CAN7nBXc0oB2H3ErNKfYumj3PTTbxkV+Bgn=2NryV+sC6rikBvQ@mail.gmail.com>
	<CANco9BuDNWagyiE7YZ04i5DZtP4s6TQA0kYSdq1_Y2JEc7xLrg@mail.gmail.com>
	<CAN7nBXe6auK7Umb6wLzvu=YSHFvcRd+Yh_1rpU=jQGPrgXqmaw@mail.gmail.com>
	<CANco9BtWHCnAkze=ciFREZLtuTsErHbUScutg3gmMbRVA10Dyg@mail.gmail.com>
Message-ID: <CAN7nBXd6J04hqgbt1UCQ7VuApS3TiQcjgf6rTZ4brN1Gk8LDxg@mail.gmail.com>

> My "box" was implemented as a CSTM transactional-class with one slot: VALUE.
> I used this as a container for the root node of a pure functional tree to
> effect a transactionally mutable variant of that structure.  A transaction
> would be to replace the root node in this box with the root node of the
> updated tree on commit.
>
That would be a nice thing to add to interface/box.lisp
and to use with the define-mutating-interface macro
to automatically deduce shared-mutable objects
from pure interfaces.

> I forked LIL and placed some sources taken from my wb and rb trees into
> contrib if you're interested to take a look at where I'm starting from.
> It's the majority of the core treeish stuff but pruned to the basic
> routines.   Naturally it is just for reference and doesn't compile in this
> state.
>
Forking is fine. I'd rather the work be committed to master
in steps that don't involve breaking the workingness of the system
(i.e. compiles and passes tests) or importing non-working files
(there are a few in funds/ already).

But I prefer working code to non-working code,
even if there is some ugly commit history.

> The implementation is mostly based on Adams purely functional data
> structures, plus a couple other papers mentioned in the weight balanced
> file.  One good thing is that it seems like it should be straightforward to
> translate my use of layers into interfaces, at least at the moment.
>
Any link to Adams?
We should probably maintain a bibliography somewhere.

> I see the AVL trees do "post-balanced" where balancing occurs in the
> stateful interface-- is that correct and is that technique something I
> should try to replicate?
>
For stateful trees, I believe this works great.
For pure trees, I have so far overridden the node method.
I'm wondering if state-passing :post and :pre method combinators
wouldn't be better instead.
And of course I eventually want both pure & stateful
from a single linear logic specification.

> It would be nice if my binary trees conformed with
> your AVL as much as possible I think but on the other hand maybe there is
> some value in the Adams approach?

> OTOH your way results in a truly mutable
> structure in stateful, where my approach was just to have a mutable "box"
> containing the current root node.
>
IIUC, that approach is what my "mutating" macro gives you automatically
from a pure interface.

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
To most Christians, the Bible is like a software license. Nobody
actually reads it. They just scroll to the bottom and click "I agree."



From danlentz at gmail.com  Wed Oct 31 07:47:04 2012
From: danlentz at gmail.com (Dan Lentz)
Date: Wed, 31 Oct 2012 03:47:04 -0400
Subject: [lisp-interface-library-devel] Curating libraries
In-Reply-To: <CAN7nBXd6J04hqgbt1UCQ7VuApS3TiQcjgf6rTZ4brN1Gk8LDxg@mail.gmail.com>
References: <CAN7nBXdoMYe2HyATNgzOPg1qmbZP-WJGYx-rJkYHL5U2E43Dxg@mail.gmail.com>
	<2284752921500208126@unknownmsgid>
	<3549313487018110526@unknownmsgid>
	<CAN7nBXc0oB2H3ErNKfYumj3PTTbxkV+Bgn=2NryV+sC6rikBvQ@mail.gmail.com>
	<CANco9BuDNWagyiE7YZ04i5DZtP4s6TQA0kYSdq1_Y2JEc7xLrg@mail.gmail.com>
	<CAN7nBXe6auK7Umb6wLzvu=YSHFvcRd+Yh_1rpU=jQGPrgXqmaw@mail.gmail.com>
	<CANco9BtWHCnAkze=ciFREZLtuTsErHbUScutg3gmMbRVA10Dyg@mail.gmail.com>
	<CAN7nBXd6J04hqgbt1UCQ7VuApS3TiQcjgf6rTZ4brN1Gk8LDxg@mail.gmail.com>
Message-ID: <CANco9BuvDFaCaSmSSbUxxWDe60r_mbBqaWcQxuHhfpLFyFCG+Q@mail.gmail.com>

I am still digesting everything you said in your previous message, but on
an unrelated topic...

Why did you use association-pair as a base class rather than some type of
box?   (re: your note in interface/tree)  The reason I ask is that in my
code I currently also have both key and value slots hard wired and I think
I preferred my previous approach which amounted to a single "payload" slot
in the node which would contain (the equivalent of) a single-value-box for
sets, an association-pair box for maps, and a specialized kind of
association pair box for seqs.  One  reason this seems to be a better way
is that when implementing persistence (as in on disk) the key and or value
tend to be serialized lisp objects ie octet vectors of some length.
 Keeping them together in a single object makes it much simpler when
manually allocating storage.  Thus nodes will be of a fixed allocation size
(containing essentially 4 pointers :  payload left right height --
typically each being a fixnum offset into a file stream,  mmap index, or
heap address)  Also when creating new nodes in the pure interface, one does
not have to duplicate the long serialized key/value data (if it were to be
physically stored in the node) or, more likely, deal with separate
allocation and pointers to the serialized data of key and value slots.   In
the non persistent case things work as normal of course.

Another benefit, possibly less (or not) important under IPS was that
This leaves the underlying tree node as the same class regardless of the
type of collection, set map or seq, and one can distinguish the type of
collection by simple examination of any tree node just by looking at the
class of its payload box.

I can work either way of course, and like I said wb and rb currently also
use quintuple nodes (kvlrh) but I've thought once or twice that given the
opportunity I'd change back to my previous approach using quad nodes
(plrh).

Thoughts?



On Wednesday, October 31, 2012, Far? wrote:

> > My "box" was implemented as a CSTM transactional-class with one slot:
> VALUE.
> > I used this as a container for the root node of a pure functional tree to
> > effect a transactionally mutable variant of that structure.  A
> transaction
> > would be to replace the root node in this box with the root node of the
> > updated tree on commit.
> >
> That would be a nice thing to add to interface/box.lisp
> and to use with the define-mutating-interface macro
> to automatically deduce shared-mutable objects
> from pure interfaces.
>
> > I forked LIL and placed some sources taken from my wb and rb trees into
> > contrib if you're interested to take a look at where I'm starting from.
> > It's the majority of the core treeish stuff but pruned to the basic
> > routines.   Naturally it is just for reference and doesn't compile in
> this
> > state.
> >
> Forking is fine. I'd rather the work be committed to master
> in steps that don't involve breaking the workingness of the system
> (i.e. compiles and passes tests) or importing non-working files
> (there are a few in funds/ already).
>
> But I prefer working code to non-working code,
> even if there is some ugly commit history.
>
> > The implementation is mostly based on Adams purely functional data
> > structures, plus a couple other papers mentioned in the weight balanced
> > file.  One good thing is that it seems like it should be straightforward
> to
> > translate my use of layers into interfaces, at least at the moment.
> >
> Any link to Adams?
> We should probably maintain a bibliography somewhere.
>
> > I see the AVL trees do "post-balanced" where balancing occurs in the
> > stateful interface-- is that correct and is that technique something I
> > should try to replicate?
> >
> For stateful trees, I believe this works great.
> For pure trees, I have so far overridden the node method.
> I'm wondering if state-passing :post and :pre method combinators
> wouldn't be better instead.
> And of course I eventually want both pure & stateful
> from a single linear logic specification.
>
> > It would be nice if my binary trees conformed with
> > your AVL as much as possible I think but on the other hand maybe there is
> > some value in the Adams approach?
>
> > OTOH your way results in a truly mutable
> > structure in stateful, where my approach was just to have a mutable "box"
> > containing the current root node.
> >
> IIUC, that approach is what my "mutating" macro gives you automatically
> from a pure interface.
>
> ??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics?
> http://fare.tunes.org
> To most Christians, the Bible is like a software license. Nobody
> actually reads it. They just scroll to the bottom and click "I agree."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/lisp-interface-library-devel/attachments/20121031/89dfb2bb/attachment.html>

From fahree at gmail.com  Wed Oct 31 08:58:34 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Wed, 31 Oct 2012 04:58:34 -0400
Subject: [lisp-interface-library-devel] Curating libraries
In-Reply-To: <CANco9BuvDFaCaSmSSbUxxWDe60r_mbBqaWcQxuHhfpLFyFCG+Q@mail.gmail.com>
References: <CAN7nBXdoMYe2HyATNgzOPg1qmbZP-WJGYx-rJkYHL5U2E43Dxg@mail.gmail.com>
	<2284752921500208126@unknownmsgid> <3549313487018110526@unknownmsgid>
	<CAN7nBXc0oB2H3ErNKfYumj3PTTbxkV+Bgn=2NryV+sC6rikBvQ@mail.gmail.com>
	<CANco9BuDNWagyiE7YZ04i5DZtP4s6TQA0kYSdq1_Y2JEc7xLrg@mail.gmail.com>
	<CAN7nBXe6auK7Umb6wLzvu=YSHFvcRd+Yh_1rpU=jQGPrgXqmaw@mail.gmail.com>
	<CANco9BtWHCnAkze=ciFREZLtuTsErHbUScutg3gmMbRVA10Dyg@mail.gmail.com>
	<CAN7nBXd6J04hqgbt1UCQ7VuApS3TiQcjgf6rTZ4brN1Gk8LDxg@mail.gmail.com>
	<CANco9BuvDFaCaSmSSbUxxWDe60r_mbBqaWcQxuHhfpLFyFCG+Q@mail.gmail.com>
Message-ID: <CAN7nBXezsqX2r9TcsqzphP_xVzHO5pssHKchneFsCi3gDSV+TQ@mail.gmail.com>

> Why did you use association-pair as a base class rather than some type of
> box?   (re: your note in interface/tree)
Aha! Someone here is paying attention.

> The reason I ask is that in my
> code I currently also have both key and value slots hard wired and I think I
> preferred my previous approach which amounted to a single "payload" slot in
> the node which would contain (the equivalent of) a single-value-box for
> sets, an association-pair box for maps, and a specialized kind of
> association pair box for seqs.
>
Indeed. I had the same idea, but I was hoping to do it
with a payload mixin, rather than a payload box.
The idea was that eventually, we might want data structures
with a tree shape (or better, several tree shapes!)
but a different payload (either fewer or more slots).
I was hoping that my transformers could ultimately use
the same mixin approach rather than boxes to do their magic.
Database records could similarly be implemented
with one slot per column, plus a few slots per index, etc.
One idea I'd like to realize is that
if C can do it efficiently one way, so can we, except more cleanly.

> One reason this seems to be a better way is
> that when implementing persistence (as in on disk) the key and or value tend
> to be serialized lisp objects ie octet vectors of some length.  Keeping them
> together in a single object makes it much simpler when manually allocating
> storage.  Thus nodes will be of a fixed allocation size (containing
> essentially 4 pointers :  payload left right height -- typically each being
> a fixnum offset into a file stream,  mmap index, or heap address)  Also when
> creating new nodes in the pure interface, one does not have to duplicate the
> long serialized key/value data (if it were to be physically stored in the
> node) or, more likely, deal with separate allocation and pointers to the
> serialized data of key and value slots.   In the non persistent case things
> work as normal of course.
>
But doesn't locality and avoiding indirection favor putting all the data
in the same record using mixins rather than boxes?

> Another benefit, possibly less (or not) important under IPS was that
> This leaves the underlying tree node as the same class regardless of the
> type of collection, set map or seq, and one can distinguish the type of
> collection by simple examination of any tree node just by looking at the
> class of its payload box.
>
The mixin approach also does it.

> I can work either way of course, and like I said wb and rb currently also
> use quintuple nodes (kvlrh) but I've thought once or twice that given the
> opportunity I'd change back to my previous approach using quad nodes (plrh).
>
> Thoughts?
>
Actually, I'm hoping to come up with a scheme for automatic management
of data mixins from the interface class hierarchy.

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
Bragg's principle:
    Everything in the future is a wave, everything in the past is a particle.



From danlentz at gmail.com  Wed Oct 31 13:20:58 2012
From: danlentz at gmail.com (Dan Lentz)
Date: Wed, 31 Oct 2012 09:20:58 -0400
Subject: [lisp-interface-library-devel] Fwd: Curating libraries
References: <-7847897912171679744@unknownmsgid>
Message-ID: <-7602056582317100865@unknownmsgid>

Begin forwarded message:

*From:* Dan Lentz <danlentz at gmail.com>
*Date:* October 31, 2012, 9:15:27 AM EDT
*To:* Far? <fahree at gmail.com>
*Subject:* *Re: Curating libraries*

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
----
Replace the method
the carefully chosen name
deletes the comment

On Oct 31, 2012, at 4:59 AM, "Far?" <fahree at gmail.com> wrote:

Why did you use association-pair as a base class rather than some type of

box?   (re: your note in interface/tree)

Aha! Someone here is paying attention.


The reason I ask is that in my

code I currently also have both key and value slots hard wired and I think I

preferred my previous approach which amounted to a single "payload" slot in

the node which would contain (the equivalent of) a single-value-box for

sets, an association-pair box for maps, and a specialized kind of

association pair box for seqs.


Indeed. I had the same idea, but I was hoping to do it

with a payload mixin, rather than a payload box.

The idea was that eventually, we might want data structures

with a tree shape (or better, several tree shapes!)

but a different payload (either fewer or more slots).

I was hoping that my transformers could ultimately use

the same mixin approach rather than boxes to do their magic.

Database records could similarly be implemented

with one slot per column, plus a few slots per index, etc.

One idea I'd like to realize is that

if C can do it efficiently one way, so can we, except more cleanly.


One reason this seems to be a better way is

that when implementing persistence (as in on disk) the key and or value tend

to be serialized lisp objects ie octet vectors of some length.  Keeping them

together in a single object makes it much simpler when manually allocating

storage.  Thus nodes will be of a fixed allocation size (containing

essentially 4 pointers :  payload left right height -- typically each being

a fixnum offset into a file stream,  mmap index, or heap address)  Also when

creating new nodes in the pure interface, one does not have to duplicate the

long serialized key/value data (if it were to be physically stored in the

node) or, more likely, deal with separate allocation and pointers to the

serialized data of key and value slots.   In the non persistent case things

work as normal of course.


But doesn't locality and avoiding indirection favor putting all the data

in the same record using mixins rather than boxes?


Another benefit, possibly less (or not) important under IPS was that

This leaves the underlying tree node as the same class regardless of the

type of collection, set map or seq, and one can distinguish the type of

collection by simple examination of any tree node just by looking at the

class of its payload box.


The mixin approach also does it.


I can work either way of course, and like I said wb and rb currently also

use quintuple nodes (kvlrh) but I've thought once or twice that given the

opportunity I'd change back to my previous approach using quad nodes (plrh).


Thoughts?


Actually, I'm hoping to come up with a scheme for automatic management

of data mixins from the interface class hierarchy.


??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics?
http://fare.tunes.org

Bragg's principle:

  Everything in the future is a wave, everything in the past is a particle.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/lisp-interface-library-devel/attachments/20121031/70c2d5b6/attachment.html>

From danlentz at gmail.com  Wed Oct 31 14:12:41 2012
From: danlentz at gmail.com (Dan Lentz)
Date: Wed, 31 Oct 2012 10:12:41 -0400
Subject: [lisp-interface-library-devel] requested urls for bibliography
Message-ID: <CANco9BuPFo+rUNTt8CkR-UtJMVgPYksHVk4eWx7hGDPiWCNMrQ@mail.gmail.com>

I used the following references as the basis for implementation of the The
wb and rb trees:

* Implementing Sets Efficiently in a Functional
Language<http://www.google.com/url?sa=t&rct=j&q=implementing%20sets%20efficiently%20in%20a%20functional&source=web&cd=1&ved=0CCEQFjAA&url=http%3A%2F%2Fgroups.csail.mit.edu%2Fmac%2Fusers%2Fadams%2FBB%2F92-10.ps&ei=USyRUO6UBqS00QHp-4HgCA&usg=AFQjCNHX6Xr1MTYSD2wKv6RWJqjcHdwuJw&sig2=fyBudmQYTWdUydEGZQX7Ag>
* Balancing weight-balanced
trees<http://www.google.com/url?sa=t&rct=j&q=weight%20balancing%20tree&source=web&cd=3&ved=0CD0QFjAC&url=http%3A%2F%2Fhagi.is.s.u-tokyo.ac.jp%2F~yh%2Fbst.pdf&ei=oi2RUOb5Hu7W0gGzgYHABA&usg=AFQjCNGv8Su2vlrCIqD2Rr-HjLxTzReLBg&sig2=MDdlqszo2IqDhJbvnehL9Q>
* Weight-Balanced Trees - MIT/GNU Scheme
9.1<http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Weight_002dBalanced-Trees.html>
* kazu-yamamoto wttree <https://github.com/kazu-yamamoto/wttree>

(and to a much lesser extent) a little bit of general background from

* Making Data Structures Persistent* - CMU School of Computer
...<http://www.google.com/url?sa=t&rct=j&q=making%20data%20structures%20persistent&source=web&cd=1&ved=0CCEQFjAA&url=http%3A%2F%2Fwww.cs.cmu.edu%2F~sleator%2Fpapers%2Fmaking-data-structures-persistent.pdf&ei=6C-RUKfNA6nC0QGEjYFw&usg=AFQjCNGsl-xbpzX1UAwiBhapQ5EusOjAgw&sig2=67wXGRY3xVJpcf6CKII51g>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/lisp-interface-library-devel/attachments/20121031/1b2b1576/attachment.html>

From danlentz at gmail.com  Wed Oct 31 14:23:30 2012
From: danlentz at gmail.com (Dan Lentz)
Date: Wed, 31 Oct 2012 10:23:30 -0400
Subject: [lisp-interface-library-devel] requested urls for bibliography
In-Reply-To: <CANco9BuPFo+rUNTt8CkR-UtJMVgPYksHVk4eWx7hGDPiWCNMrQ@mail.gmail.com>
References: <CANco9BuPFo+rUNTt8CkR-UtJMVgPYksHVk4eWx7hGDPiWCNMrQ@mail.gmail.com>
Message-ID: <CANco9Bt=kUH9B2A5AFhUd8gRsfnr8yt7w=vwyR38JpfVOT=RgA@mail.gmail.com>

Sorry abt the previous post  this message provides cleaned up urls

I used the following references as the basis for implementation of the The
wb and rb trees:

* Implementing Sets Efficiently in a Functional Language
    http://groups.csail.mit.edu/mac/users/adams/BB/92-10.ps

* Balancing weight-balanced trees
    http://hagi.is.s.u-tokyo.ac.jp/~yh/bst.pdf

* Weight-Balanced Trees - MIT/GNU Scheme 9.1
    http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Weight_002dBalanced-Trees.html

* kazu-yamamoto wttree
    https://github.com/kazu-yamamoto/wttree

and (to a much lesser extent) a little bit of general background from

* Making Data Structures Persistent* - CMU School of Computer ...
    http://www.cs.cmu.edu/~sleator/papers/making-data-structures-persistent.pdf



From j.aeschliman at gmail.com  Wed Oct 31 18:37:35 2012
From: j.aeschliman at gmail.com (Jason Aeschliman)
Date: Wed, 31 Oct 2012 11:37:35 -0700
Subject: [lisp-interface-library-devel]
	com.clearly-useful.generic-collection-interface
In-Reply-To: <CAN7nBXfcTtZFHCd=NF4c_eWPY+VCBd4Ee-jpKW2LowwXUM_Tbw@mail.gmail.com>
References: <CAN7nBXcy3oUhUjwr+KQVQjdZ27_cDRG49KKNVLagWdP7MnpH9w@mail.gmail.com>
	<774D6D39-4416-486C-B0DF-F6DAC02371DA@gmail.com>
	<CAN7nBXcEGKmUoBQsdiz6ozy9z5zLuVeG7Ze-EF9dGS2PD5f+sw@mail.gmail.com>
	<207208D6-EED5-4D2E-A490-B48AF79F00A4@gmail.com>
	<CAN7nBXfeqRFpdRuwbnwuJWM6JTA8E79qRg6mAAQj_c3W7g2Q6g@mail.gmail.com>
	<28B323AA-5D23-435D-88B4-6ECB05AF1842@gmail.com>
	<0FBA3435-456F-4434-9A82-388A95B089D3@gmail.com>
	<CAN7nBXdd7ADFx_yNcWJ=_0NW1L5ki77wLFAjU-uSXx2bo3Fkvg@mail.gmail.com>
	<A1CA2C3C-C0B7-45D4-950C-386E8505039A@gmail.com>
	<CAN7nBXehihetqurmEGBvLE_85JvepSssC0kEptBPZExVMfkPyA@mail.gmail.com>
	<329926FF-B2F7-4932-ABDA-3CCC6F3994A3@gmail.com>
	<CAN7nBXdubqeNSyhHbhRj1dxicHdqxdY+vK7eydzK_gn6LvBBnA@mail.gmail.com>
	<FEE9DE14-BD9B-4BE2-A46C-4BC8DFDDA61B@gmail.com>
	<CAN7nBXfcTtZFHCd=NF4c_eWPY+VCBd4Ee-jpKW2LowwXUM_Tbw@mail.gmail.com>
Message-ID: <E375C022-AA44-4586-8CB9-81E79B72753A@gmail.com>

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>