That's Rich *Hickey*, not *Hackey*  :-)

On Fri, Dec 23, 2011 at 7:16 PM, Seth Johnson <[email protected]> wrote:
> On Fri, Dec 23, 2011 at 5:27 PM, Eoin <[email protected]> wrote:
>>
>> I've been following this discussion with some interest. A couple of
>> things spring to mind now:
>> 1. This seems to be the first statement of a problem:
>> "outline structure must be first-class data in shared
>> (cooperative, distributed) environments." Maybe it's been said earlier
>> and I've missed it though.
>
>
> I created a procedural language that was essentially XBASE-plus, and
> part of it was the ability to assign context and state (indeed, any
> component of these notions) to variables.  This was how you could
> navigate.  You could log onto a Uniform Context Transfer Protocol
> server and type commands like:
>
> GET CONTEXT
>
> (and it would return the current use type, link type, use, etc.)
>
> or:
>
> x = STATE
> y = CONTEXT
>
> GET x
> GET y
>
> Or to navigate in a context, you could:
>
> SET CONTEXT TO y
> GO TOP LINK
> do while not eoc()  (endofcontext)
>  PRINT LINK
>  SKIP LINK
> enddo
>
> or you can create the context at runtime:
> SET USE TYPE TO someusetypeilike
> SET LINK TYPE TO somelinktypeilike
> GO TOP USE
> z = CONTEXT
>
> None of Rich Hackey's persistent objects, separation of value from
> identity, and transaction or state transition management.  But it is a
> model of distributed state, so by formalizing that, it is at least one
> way to start thinking about the things he does with Clojure within a
> set definition of distributed state.
>
>
> Seth
>
>> 2. Rich Hickey's talks/videos on state, value and identity (with a nod
>> to AN Whitehead) chime. Not sure if the specifics apply but the
>> approach is interesting.
>> I'd like to have a slightly more informed input to this. Edward, what
>> can you recommend by way of reading/coding for the current Leo data
>> structures?
>>
>> Best regards,
>> Eoin
>>
>> On Dec 20, 2:36 pm, "Edward K. Ream" <[email protected]> wrote:
>>> On Mon, Dec 19, 2011 at 11:59 AM, Edward K. Ream <[email protected]> 
>>> wrote:
>>>
>>> > If all (or almost all) data appears in a Leonine sqlite db we can say
>>> > the following:
>>>
>>> > - There is no need for a Leo cache.
>>> > - There is no need for private @shadow files.
>>> > - We can use the @shadow algorithm for *all* files, including @file,
>>> > @auto, etc.
>>>
>>> Wrong, wrong, wrong.
>>>
>>> @shadow will *never* be the model for most files because it demotes
>>> structure info to second-class status, namely, personal preference
>>> grafted on to the "real" data.  But the *essence* of Leo is that
>>> structure is first-class data.
>>>
>>> @shadow is fine for non-cooperative (private) environments.  In that
>>> case, the "preference" structure is, in fact, the only structure there
>>> is.  But in shared environments outline structure must be part of each
>>> external file.  Thus, sentinels are, in general, essential as well.
>>>
>>> This must be the fourth or fifth time I have rediscovered this basic
>>> principle.  In the past, the emphasis has been mostly on sentinels,
>>> but here we see that the underlying principle is that outline
>>> structure must be first-class data in shared (cooperative,
>>> distributed) environments.  So this is progress of a sort.
>>>
>>> As a direct consequence, any approach that abandons sentinels must be
>>> rejected.  I don't know, in detail, this affects the current
>>> discussion, but I think Seth and Hans have ideas that are compatible
>>> with this principle.
>>>
>>> Edward
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "leo-editor" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to 
>> [email protected].
>> For more options, visit this group at 
>> http://groups.google.com/group/leo-editor?hl=en.
>>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Reply via email to