Hi all,
The following meeting announcement (a talk by Richard Gabriel on
Christopher Alexander's "The Nature of Order") was forwarded to me by
Gregor Kiczales as he thought it might be of interest to lispvan
members, so it's not (strictly speaking) a lispvan meeting. However,
since the speaker (Richard Gabriel) is a famous lisper and the host
(Gregor Kiczales) is a famous lisper and it's being held in Vancouver,
we'll claim it anyhow! ;-)
For those of you who are unfamiliar with Richard Gabriel, he is known
in the Lisp community for many things (see: http://www.dreamsongs.com);
however, he is probably best known for:
His essay on "Worse is Better" (http://www.dreamsongs.com/
WorseIsBetter.html)
His book "Patterns of Software" (http://www.dreamsongs.com/Files/
PatternsOfSoftware.pdf)
In recent years, he has turned his writing and creative efforts
towards poetry; but, at the same time, has remained very involved in
the software industry, promoting a synthesis of art and science. I've
seen him speak on a couple of occasions and he's an excellent (and
very entertaining) speaker.
Christopher Alexander is best known to programmers through his book
"The Timeless Way of Building", which had a big influence on the
Design Patterns movement. His books tend to appeal to both the right
and left sides of our brains. Therefore, Richard Gabriel is probably
one of the best possible choices for a speaker about Alexander's new 4-
book essay called "The Nature of Order" (http://
www.natureoforder.com/).
I look forward to attending the talk. See you there!
- Bill Clementson
Here's the "official" meeting notice:
Topic: The Nature of Order
Presenter: Richard P. Gabriel, IBM Research
Host: Gregor Kiczales, Software Practices Lab, University of British
Columbia
Date: Wednesday, October 8, 2008
Time: 5:00 pm
Venue: The UBC campus in the Hugh Dempster Pavilion building, room DMP
101 (for map, see:
http://regi4.adm.ubc.ca/classroomservices/function/viewlocation?userEvent=ShowLocation&buildingID=DMP&roomID=101)
Summary: The second talk by Richard Gabriel is part of a special
meeting of CPSC 539K. We'll begin with a presentation by Gabriel,
followed by discussion of his talk and our reading from Alexander's
Nature of Order. Everyone is invited to attend the talk.
Christopher Alexander is best known to computer scientists and
software engineers for his work on pattern languages. This work
inspired the classic "Design Patterns: Elements of Reusable Object-
Oriented Software" by Eric Gamma, Richard Helm, Ralph Johnson, and
John Vlissides, as well as the software patterns community and its
dozens if not hundreds of patterns books and 5 conferences a year.
Alexander is an architect whose real interest lies in understanding
the nature of beauty and its objective reality. This project has held
his attention for over 30 years and culminated in the publication of
his gargantuan 4-book essay called "The Nature of Order". In it he
attempts nothing short of proposing a new scientific method and
cosmology to replace the Cartesian / reductionist / mechanistic
approach to science and the neutral underlying space-time-matter view
of the world; and while he's at it, he proposes a *common sense* way
to understand the incomprehensible mathematics of quantum mechanics.
(Along the way he also unifies science, art, and the spiritual.)
We once believed his ideas had something to do with how to design and
build software, and the metaphor of software creation and architecture
& the built-world is still strong. His ideas about centers, life, &
wholeness; the Fundamental Process; the 15 structure-preserving
transformations; deep and personal feeling as a valid scientific means
of observation; sequences and the process of unfolding; the
fundamental unity of function and ornament; patterns as generic
centers; the subdued brilliance of color; the underlying "ground,"
"plenum," Self, and "the I"; and his use of sadness to find beauty are
hard to understand without understanding all of his work - his many
and convoluted books, papers, and essays, and the buildings he's built
- and even the arc of his life. He is a maddeningly simplistic,
complex, and frustrating man, filled with a luminous beauty painted in
grayed storm-swept colors.
I have taken the time, over the past nearly 20 years, to (try to)
understand his work, and to a degree the man. This talk - not the talk
itself but the ideas in it - will leave you confused, profoundly
smarter, reeling, in despair, and suffused by joy about what is
possible for us in software and programming. Whenever I speak of
Alexander and his work, I feel like a shimmering bright and deceptive
Prometheus.
Bio:
"Black Out"
A tavern in Old Europe. Late in the evening. Participants at a
psychology conference chat.
Canadian: In fact I mostly go to computer science conferences.
American: Really, is there anything interesting to discuss?
C: Well, sometimes there is. I have high hopes for this conference
called "Onward!".
A: What is it about?
C: All kinds of things. It was started by Richard Gabriel, and he...
A: Who?
C: Gabriel.
A: You mean Richard Gabriel the *poet*???
Curtain.
On Oct 2, 7:07 pm, Kenny <·········@gmail.com> wrote:
> Slobodan Blazeski wrote:
> > On Oct 2, 12:15 am, Kenny <·········@gmail.com> wrote:
>
> >>billc wrote:
>
> >>>Hi all,
>
> >>>The following meeting announcement (a talk by Richard Gabriel on
> >>>Christopher Alexander's "The Nature of Order") was forwarded to me by
> >>>Gregor Kiczales as he thought it might be of interest to lispvan
> >>>members, so it's not (strictly speaking) a lispvan meeting. However,
> >>>since the speaker (Richard Gabriel) is a famous lisper ..
>
> >>That's the guy who said Common Lisp was a mistake and led the charge on
> >>Patterns, the thing you need when you don't have Lisp?
>
> > Burn the witch... Wait I like his writings.
>
> >>>and the host
> >>>(Gregor Kiczales) is a famous lisper ...
>
> >>The guy who led the charge on aspect-oriented programming, the thing you
> >>need when you don't have... oh, what's the use...
>
> > I thing Pascal Constanza will disagree
>
> Sure, and the McCain spokesman thought Palin gave a /great/ answer to
> the newspaper question.
Politicians are all the same, they want to get/keeep their chairs and
f#ch you up, that's what makes voting for women the lesser evil.
bobi
>
> :)
>
> kzo- Hide quoted text -
>
> - Show quoted text -
From: Pascal Costanza
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <6km4j4F8io2tU1@mid.individual.net>
Kenny wrote:
> Slobodan Blazeski wrote:
>> On Oct 2, 12:15 am, Kenny <·········@gmail.com> wrote:
>>
>>> billc wrote:
>>>
>>>> Hi all,
>>>
>>>> The following meeting announcement (a talk by Richard Gabriel on
>>>> Christopher Alexander's "The Nature of Order") was forwarded to me by
>>>> Gregor Kiczales as he thought it might be of interest to lispvan
>>>> members, so it's not (strictly speaking) a lispvan meeting. However,
>>>> since the speaker (Richard Gabriel) is a famous lisper ..
>>>
>>> That's the guy who said Common Lisp was a mistake and led the charge on
>>> Patterns, the thing you need when you don't have Lisp?
>>
>> Burn the witch... Wait I like his writings.
>>
>>>> and the host
>>>> (Gregor Kiczales) is a famous lisper ...
>>>
>>> The guy who led the charge on aspect-oriented programming, the thing you
>>> need when you don't have... oh, what's the use...
>>
>> I thing Pascal Constanza will disagree
>
> Sure, and the McCain spokesman thought Palin gave a /great/ answer to
> the newspaper question.
For the record: I don't think that aspect-oriented programming is a good
idea.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Oct 3, 10:48 am, Pascal Costanza <····@p-cos.net> wrote:
> Kenny wrote:
> > Slobodan Blazeski wrote:
> >> On Oct 2, 12:15 am, Kenny <·········@gmail.com> wrote:
>
> >>> billc wrote:
>
> >>>> Hi all,
>
> >>>> The following meeting announcement (a talk by Richard Gabriel on
> >>>> Christopher Alexander's "The Nature of Order") was forwarded to me by
> >>>> Gregor Kiczales as he thought it might be of interest to lispvan
> >>>> members, so it's not (strictly speaking) a lispvan meeting. However,
> >>>> since the speaker (Richard Gabriel) is a famous lisper ..
>
> >>> That's the guy who said Common Lisp was a mistake and led the charge on
> >>> Patterns, the thing you need when you don't have Lisp?
>
> >> Burn the witch... Wait I like his writings.
>
> >>>> and the host
> >>>> (Gregor Kiczales) is a famous lisper ...
>
> >>> The guy who led the charge on aspect-oriented programming, the thing you
> >>> need when you don't have... oh, what's the use...
>
> >> I thing Pascal Constanza will disagree
>
> > Sure, and the McCain spokesman thought Palin gave a /great/ answer to
> > the newspaper question.
>
> For the record: I don't think that aspect-oriented programming is a good
> idea.
I really don't understand you, first you write a tons of papers and
implement AspectL on top of MOP, and now you're saying that it's not
such a good idea.
bobi
>
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/- Hide quoted text -
>
> - Show quoted text -
From: Pascal Costanza
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <6km81vF8j5rdU1@mid.individual.net>
Slobodan Blazeski wrote:
> On Oct 3, 10:48 am, Pascal Costanza <····@p-cos.net> wrote:
>> Kenny wrote:
>>> Slobodan Blazeski wrote:
>>>> On Oct 2, 12:15 am, Kenny <·········@gmail.com> wrote:
>>>>> billc wrote:
>>>>>> Hi all,
>>>>>> The following meeting announcement (a talk by Richard Gabriel on
>>>>>> Christopher Alexander's "The Nature of Order") was forwarded to me by
>>>>>> Gregor Kiczales as he thought it might be of interest to lispvan
>>>>>> members, so it's not (strictly speaking) a lispvan meeting. However,
>>>>>> since the speaker (Richard Gabriel) is a famous lisper ..
>>>>> That's the guy who said Common Lisp was a mistake and led the charge on
>>>>> Patterns, the thing you need when you don't have Lisp?
>>>> Burn the witch... Wait I like his writings.
>>>>>> and the host
>>>>>> (Gregor Kiczales) is a famous lisper ...
>>>>> The guy who led the charge on aspect-oriented programming, the thing you
>>>>> need when you don't have... oh, what's the use...
>>>> I thing Pascal Constanza will disagree
>>> Sure, and the McCain spokesman thought Palin gave a /great/ answer to
>>> the newspaper question.
>> For the record: I don't think that aspect-oriented programming is a good
>> idea.
>
> I really don't understand you, first you write a tons of papers and
> implement AspectL on top of MOP, and now you're saying that it's not
> such a good idea.
I didn't write "tons of papers" on aspect-oriented programming. AspectL
was an experiment to see how much of AOP can be implemented on top of
Common Lisp / CLOS and to better understand some of the concepts behind
AOP. My conclusion is that at least the AspectJ model of AOP doesn't fit
very well in a language like Lisp or Scheme.
Some of the ideas developed at the time I experimented with AspectL,
especially wrt dynamic scoping of functions, are valid and I used them
as starting points for developing ContextL. Context-oriented Programming
has some overlap with AOP, but is also sufficiently different from AOP.
I think COP is a good idea, and there is some serious practical evidence
that it makes sense in practice.
The problem with AOP is the notion of pointcuts, the idea to
simultaneously insert before/after/around code in various different
places of some base code. This introduces more problems than it solves,
and is only a very tiny increment in expressiveness in a language with
good metaprogramming and macro facilities.
The important "discovery" of AOP, though, is the notion of crosscutting
concerns, which is a real problem in large software projects. Approaches
like context-oriented programming and feature-oriented programming,
however, show that you can find ways to deal with crosscutting concerns
without buying into the aspect-style pointcut-based models.
HALO was an experiment to see how to integrate a certain pointcut
approach to CLOS based on temporal logics. This gives you some nice ways
to express certain kinds of "business rules" that refer to past
computations in a program. The increase in expressiveness is more
interesting here than compared to what you can express in AspectJ-style
AOP approaches. I think it should be possible to strip off the pointcut
elements from HALO and have a pure temporal reasoning element in the
definition of generic functions, which should give you the same
expressiveness as HALO, but again without buying into an aspect-style
pointcut-based model, which should actually fit better in a Lisp-based
environment. However, we haven't done that yet.
So to summarize: I think the important contribution of AOP is that they
have nailed a problem description very well, aka crosscuttting concerns.
However, they focus too much on solving that problem in a very specific
way thatdoesn't work as well as initially thought, and doesn't translate
well to languages other than the initial target languages (i.e., Java
and friends).
Pascal
P.S.: It's a pity that you have to come up with "grand" terms like
"aspect-oriented programming," "feature-oriented programming" and
"context-oriented programming" to make a point, which probably seems a
bit silly at times, but such labelling is unfortunately part of the game...
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Oct 3, 11:47 am, Pascal Costanza <····@p-cos.net> wrote:
> Slobodan Blazeski wrote:
> > On Oct 3, 10:48 am, Pascal Costanza <····@p-cos.net> wrote:
> >> Kenny wrote:
> >>> Slobodan Blazeski wrote:
> >>>> On Oct 2, 12:15 am, Kenny <·········@gmail.com> wrote:
> >>>>> billc wrote:
> >>>>>> Hi all,
> >>>>>> The following meeting announcement (a talk by Richard Gabriel on
> >>>>>> Christopher Alexander's "The Nature of Order") was forwarded to me by
> >>>>>> Gregor Kiczales as he thought it might be of interest to lispvan
> >>>>>> members, so it's not (strictly speaking) a lispvan meeting. However,
> >>>>>> since the speaker (Richard Gabriel) is a famous lisper ..
> >>>>> That's the guy who said Common Lisp was a mistake and led the charge on
> >>>>> Patterns, the thing you need when you don't have Lisp?
> >>>> Burn the witch... Wait I like his writings.
> >>>>>> and the host
> >>>>>> (Gregor Kiczales) is a famous lisper ...
> >>>>> The guy who led the charge on aspect-oriented programming, the thing you
> >>>>> need when you don't have... oh, what's the use...
> >>>> I thing Pascal Constanza will disagree
> >>> Sure, and the McCain spokesman thought Palin gave a /great/ answer to
> >>> the newspaper question.
> >> For the record: I don't think that aspect-oriented programming is a good
> >> idea.
>
> > I really don't understand you, first you write a tons of papers and
> > implement AspectL on top of MOP, and now you're saying that it's not
> > such a good idea.
>
> I didn't write "tons of papers" on aspect-oriented programming. AspectL
> was an experiment to see how much of AOP can be implemented on top of
> Common Lisp / CLOS and to better understand some of the concepts behind
> AOP. My conclusion is that at least the AspectJ model of AOP doesn't fit
> very well in a language like Lisp or Scheme.
>
> Some of the ideas developed at the time I experimented with AspectL,
> especially wrt dynamic scoping of functions, are valid and I used them
> as starting points for developing ContextL. Context-oriented Programming
> has some overlap with AOP, but is also sufficiently different from AOP.
> I think COP is a good idea, and there is some serious practical evidence
> that it makes sense in practice.
>
> The problem with AOP is the notion of pointcuts, the idea to
> simultaneously insert before/after/around code in various different
> places of some base code. This introduces more problems than it solves,
> and is only a very tiny increment in expressiveness in a language with
> good metaprogramming and macro facilities.
>
> The important "discovery" of AOP, though, is the notion of crosscutting
> concerns, which is a real problem in large software projects. Approaches
> like context-oriented programming and feature-oriented programming,
> however, show that you can find ways to deal with crosscutting concerns
> without buying into the aspect-style pointcut-based models.
>
> HALO was an experiment to see how to integrate a certain pointcut
> approach to CLOS based on temporal logics. This gives you some nice ways
> to express certain kinds of "business rules" that refer to past
> computations in a program. The increase in expressiveness is more
> interesting here than compared to what you can express in AspectJ-style
> AOP approaches. I think it should be possible to strip off the pointcut
> elements from HALO and have a pure temporal reasoning element in the
> definition of generic functions, which should give you the same
> expressiveness as HALO, but again without buying into an aspect-style
> pointcut-based model, which should actually fit better in a Lisp-based
> environment. However, we haven't done that yet.
>
> So to summarize: I think the important contribution of AOP is that they
> have nailed a problem description very well, aka crosscuttting concerns.
> However, they focus too much on solving that problem in a very specific
> way thatdoesn't work as well as initially thought, and doesn't translate
> well to languages other than the initial target languages (i.e., Java
> and friends).
>
> Pascal
>
> P.S.: It's a pity that you have to come up with "grand" terms like
> "aspect-oriented programming," "feature-oriented programming" and
> "context-oriented programming" to make a point, which probably seems a
> bit silly at times, but such labelling is unfortunately part of the game...
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/- Hide quoted text -
>
> - Show quoted text -
Thanks for the thorough explanation, anyway I never used AOP, nor
understand it, except the Kitzales explanation when it sounded like
optimization technique, so I don't think I care very much, though if
you don't recommend it maube it's good to state this in your Closer
page about AspectL.
As per COP I think we agree that's an interesthing idea though in
order to be useful to me it has to be more generalized than only as OO
technique.
Basically in my eyes COP is only adding another level of ambiguosity.
You're shifting the switch clauses into the layers, but what are the
layers if not another switch clause, though they could contain many
objects.
I'm not saying that's bad, the amount of crup is constant you could
move it here or there but it has to show up somewhere, and I have
some ideas where it could be usefull but isn't very good either as add
another enviroment variable of how the objects behave.
If I oversimplify COP layers are just global variables attached to
classes to tell them what the class should be. Like class checks the
global(active layer) and decided to grow some field or drop other.
And I usually think of globals as something BAD.
Reflection, the base you're build ContextL is very powerful and poorly
explained idea, if you could make it closer to the illiterate mases
like me you would be one of the titans of computer science (I hate
this word).
As per the grand terms:
1st. I just used the names that are called, if you have better tell
them
2nd They are not "grand" at all, at least in my eyes. After few
paradigm shifts everything looks like bunch of typing.
cheers
bobi
Fools ignore complexity. Pragmatists suffer it. Some can avoid it.
Geniuses remove it.
A. Perlis
From: Pascal Costanza
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <6kmip3F8bvuaU1@mid.individual.net>
Slobodan Blazeski wrote:
> Thanks for the thorough explanation, anyway I never used AOP, nor
> understand it, except the Kitzales explanation when it sounded like
> optimization technique, so I don't think I care very much, though if
> you don't recommend it maube it's good to state this in your Closer
> page about AspectL.
I could have sworn that I already added a remark in this direction on
the page, but obviously I haven't. I will do so...
> If I oversimplify COP layers are just global variables attached to
> classes to tell them what the class should be.
I obviously don't agree here. ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Kenny
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <48e62d4c$0$4986$607ed4bc@cv.net>
Pascal Costanza wrote:
> Kenny wrote:
>
>> Slobodan Blazeski wrote:
>>
>>> On Oct 2, 12:15 am, Kenny <·········@gmail.com> wrote:
>>>
>>>> billc wrote:
>>>>
>>>>> Hi all,
>>>>
>>>>
>>>>> The following meeting announcement (a talk by Richard Gabriel on
>>>>> Christopher Alexander's "The Nature of Order") was forwarded to me by
>>>>> Gregor Kiczales as he thought it might be of interest to lispvan
>>>>> members, so it's not (strictly speaking) a lispvan meeting. However,
>>>>> since the speaker (Richard Gabriel) is a famous lisper ..
>>>>
>>>>
>>>> That's the guy who said Common Lisp was a mistake and led the charge on
>>>> Patterns, the thing you need when you don't have Lisp?
>>>
>>>
>>> Burn the witch... Wait I like his writings.
>>>
>>>>> and the host
>>>>> (Gregor Kiczales) is a famous lisper ...
>>>>
>>>>
>>>> The guy who led the charge on aspect-oriented programming, the thing
>>>> you
>>>> need when you don't have... oh, what's the use...
>>>
>>>
>>> I thing Pascal Constanza will disagree
>>
>>
>> Sure, and the McCain spokesman thought Palin gave a /great/ answer to
>> the newspaper question.
>
>
> For the record: I don't think that aspect-oriented programming is a good
> idea.
Yeah, but Sarah is a babe, yes? OTOH, she meets the mayor in a gym who
puts her on the city council hoping to get in her... well, never mind...
and then she turns on the guy, takes his job, then rats out the party
boss for <gasp!> doing party business on company time -- since when are
Americans in love with snitches, squealers, tattletales? Oh, right, she
is hot... that voice is getting to me, tho.
Well, the dark ages are ending, McCain has abandoned Michigan, the
wheels are off, game over.
Man, Chrome rocks. But what about Dojo? They talk a good game, but
JQuery Just Works on all the browsers and Dojo...not so much.
kt
From: Patrick May
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <m2r66xn1yy.fsf@spe.com>
Kenny <·········@gmail.com> writes:
> Man, Chrome rocks. But what about Dojo? They talk a good game, but
> JQuery Just Works on all the browsers and Dojo...not so much.
Try Flex talking to Hunchentoot. It doesn't suck. I'm still
working on generating MXML from Lisp, though.
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Kenny
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <48e66a59$0$5665$607ed4bc@cv.net>
Patrick May wrote:
> Kenny <·········@gmail.com> writes:
>
>>Man, Chrome rocks. But what about Dojo? They talk a good game, but
>>JQuery Just Works on all the browsers and Dojo...not so much.
>
>
> Try Flex talking to Hunchentoot. It doesn't suck.
Must be nice having everything all in one package. JQuery add-ons have
dropped in nicely for me so far, but it is always a shopping trip (and I
think I bought the wrong tool-tips add-on).
I wonder if Flash can keep up with compiled JS. You don't mind the Flash
requirement? I realize it is ubiquitous enough, but still.
> I'm still
> working on generating MXML from Lisp, though.
"working on" as in having trouble or as in haven't gotten around to it yet?
Lisp? The old AI programming language? Cool.
kxo
From: Patrick May
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <m2iqs8mn0e.fsf@spe.com>
Kenny <·········@gmail.com> writes:
> Patrick May wrote:
>> Kenny <·········@gmail.com> writes:
>>>Man, Chrome rocks. But what about Dojo? They talk a good game, but
>>>JQuery Just Works on all the browsers and Dojo...not so much.
>>
>> Try Flex talking to Hunchentoot. It doesn't suck.
>
> Must be nice having everything all in one package. JQuery add-ons
> have dropped in nicely for me so far, but it is always a shopping
> trip (and I think I bought the wrong tool-tips add-on).
>
> I wonder if Flash can keep up with compiled JS. You don't mind the
> Flash requirement? I realize it is ubiquitous enough, but still.
It loads relatively slowly, but once it's loaded it's as fast as
a desktop app (not surprisingly). I selected it despite the Flash
requirement because it provided a nice grid control and the chart
displays I needed.
>> I'm still working on generating MXML from Lisp, though.
>
> "working on" as in having trouble or as in haven't gotten around to
> it yet?
The latter. I can do 80+% of what I need with declarative MXML,
which is straightforward to generate. I'd like to take the level of
abstraction up a bit while I'm doing it, though.
The other 20% requires ActionScript. Parenscript helps there,
but the interactions between ActionScript and MXML can be occasionally
opaque, especially in terms of scoping rules. MXML generates
ActionScript and Flex takes advantage of that, which means you have to
think of your UI as an ActionScript program written in two different
syntaxes.
I suspect there's an "Aha!" moment in my near future that will
result in a first cut of CLFlex. Just a few more sessions of pounding
my head against the wall....
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Kenny
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <48e7c7c0$0$4987$607ed4bc@cv.net>
Patrick May wrote:
> Kenny <·········@gmail.com> writes:
>
>>Patrick May wrote:
>>
>>>Kenny <·········@gmail.com> writes:
>>>
>>>>Man, Chrome rocks. But what about Dojo? They talk a good game, but
>>>>JQuery Just Works on all the browsers and Dojo...not so much.
>>>
>>> Try Flex talking to Hunchentoot. It doesn't suck.
>>
>>Must be nice having everything all in one package. JQuery add-ons
>>have dropped in nicely for me so far, but it is always a shopping
>>trip (and I think I bought the wrong tool-tips add-on).
>>
>>I wonder if Flash can keep up with compiled JS. You don't mind the
>>Flash requirement? I realize it is ubiquitous enough, but still.
>
>
> It loads relatively slowly, but once it's loaded it's as fast as
> a desktop app (not surprisingly). I selected it despite the Flash
> requirement because it provided a nice grid control and the chart
> displays I needed.
JS frameworks don't have those? Or was it more like you had zero reason
to avoid Flash (and maybe already knew it) so there was no reason to
hassle with less polished tools? I suppose you also had the means to
acquire the tools.
>
>
>>> I'm still working on generating MXML from Lisp, though.
>>
>>"working on" as in having trouble or as in haven't gotten around to
>>it yet?
>
>
> The latter. I can do 80+% of what I need with declarative MXML,
> which is straightforward to generate. I'd like to take the level of
> abstraction up a bit while I'm doing it, though.
>
> The other 20% requires ActionScript. Parenscript helps there,
> but the interactions between ActionScript and MXML can be occasionally
> opaque, especially in terms of scoping rules. MXML generates
> ActionScript and Flex takes advantage of that, which means you have to
> think of your UI as an ActionScript program written in two different
> syntaxes.
>
> I suspect there's an "Aha!" moment in my near future that will
> result in a first cut of CLFlex.
No Cells? Are you mad? For a GUI? Celtk and Cells-Gtk (and soon Xello)
will show you how to drive an existing framework with Cells.
> Just a few more sessions of pounding
> my head against the wall....
Open source it when you are done and I'll add the Cells.
kt
From: Patrick May
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <m2ej2wm6ys.fsf@spe.com>
Kenny <·········@gmail.com> writes:
> Patrick May wrote:
>> Kenny <·········@gmail.com> writes:
>>>I wonder if Flash can keep up with compiled JS. You don't mind the
>>>Flash requirement? I realize it is ubiquitous enough, but still.
>>
>> It loads relatively slowly, but once it's loaded it's as fast
>> as a desktop app (not surprisingly). I selected it despite the
>> Flash requirement because it provided a nice grid control and the
>> chart displays I needed.
>
> JS frameworks don't have those?
Some have one, some have the others, some have some other bits I
wanted to use. TIBCO's GI was actually my first choice, but there was
a bug in Safari that prevented me from using it.
> Or was it more like you had zero reason to avoid Flash (and maybe
> already knew it) so there was no reason to hassle with less polished
> tools? I suppose you also had the means to acquire the tools.
Actually, I felt rather dirty using Flash. And not in that good,
tingly way.
Aside from the chart widgets, the tools are free (as in beer).
[ . . . ]
> No Cells? Are you mad? For a GUI? Celtk and Cells-Gtk (and soon
> Xello) will show you how to drive an existing framework with Cells.
This application is a trading system. If Cells is fast enough,
it might be a good choice for the backend. Can I get a response in 10
milliseconds when an order book changes?
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Kenny
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <48e7e7db$0$5667$607ed4bc@cv.net>
Patrick May wrote:
> Kenny <·········@gmail.com> writes:
>
>>Patrick May wrote:
>>
>>>Kenny <·········@gmail.com> writes:
>>>
>>>>I wonder if Flash can keep up with compiled JS. You don't mind the
>>>>Flash requirement? I realize it is ubiquitous enough, but still.
>>>
>>> It loads relatively slowly, but once it's loaded it's as fast
>>>as a desktop app (not surprisingly). I selected it despite the
>>>Flash requirement because it provided a nice grid control and the
>>>chart displays I needed.
>>
>>JS frameworks don't have those?
>
>
> Some have one, some have the others, some have some other bits I
> wanted to use. TIBCO's GI was actually my first choice, but there was
> a bug in Safari that prevented me from using it.
I was just going to say one big win would be insulation from browser
variability.
>
>
>>Or was it more like you had zero reason to avoid Flash (and maybe
>>already knew it) so there was no reason to hassle with less polished
>>tools? I suppose you also had the means to acquire the tools.
>
>
> Actually, I felt rather dirty using Flash. And not in that good,
> tingly way.
:)
>
> Aside from the chart widgets, the tools are free (as in beer).
What's your IDE, Eclipse?
>
> [ . . . ]
>
>>No Cells? Are you mad? For a GUI? Celtk and Cells-Gtk (and soon
>>Xello) will show you how to drive an existing framework with Cells.
>
>
> This application is a trading system. If Cells is fast enough,
> it might be a good choice for the backend. Can I get a response in 10
> milliseconds when an order book changes?
10ms is an eternity! I know, I have a feel for that having done
RoboCells in which we handled realtime inputs spaced at 100ms.
Otherwise, not sure what you are asking. Naturally a very interesting
question is how long does the functional computation take. But I will
presume that is in order and what you are asking is if Cells is a pig.
No. (see "RoboCells"). In fact, Cells helps a bit by magically
discerning exactly what needs to be updated when X changes. I tried to
tell the walking dead at ECLM 2008 that Cells is a library about change.
Practically, this means one has complete control over change,
including the aforementioned optimization of changing only those things
that need to change, but also being able to surgically control "oh, I do
not need to update /that/ every 10ms, I can do it every other unless of
courese Y changes by 42%". Stuff like that.
Well, if js/html/css get on my nerves I'll take a look at Fex/MXML. Thx
for the lead.
kt
From: Patrick May
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <m2abdjmbq7.fsf@spe.com>
Kenny <·········@gmail.com> writes:
[ . . . ]
>> Aside from the chart widgets, the tools are free (as in beer).
>
> What's your IDE, Eclipse?
Emacs, of course. Why would I want to use something primitive
and bloated like Eclipse?
>>>No Cells? Are you mad? For a GUI? Celtk and Cells-Gtk (and soon
>>>Xello) will show you how to drive an existing framework with Cells.
>>
>> This application is a trading system. If Cells is fast
>> enough, it might be a good choice for the backend. Can I get a
>> response in 10 milliseconds when an order book changes?
>
> 10ms is an eternity! I know, I have a feel for that having done
> RoboCells in which we handled realtime inputs spaced at 100ms.
>
> Otherwise, not sure what you are asking. Naturally a very interesting
> question is how long does the functional computation take. But I will
> presume that is in order and what you are asking is if Cells is a
> pig.
Well summarized. ;-)
Basically I was asking what the overhead of Cells is. Assuming I
have optimized the behavior that should be triggered when a cell
changes, how long does it take for that behavior to be invoked? I
have one component that needs to do some real work and respond in less
than a milli, but 10 millis is acceptable for most tasks.
I'll try out Cells this week. (By the way, the ASDF install
fails and http://common-lisp.net/project/cells has some dead links.)
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Kenny
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <48e8e4e5$0$4987$607ed4bc@cv.net>
Patrick May wrote:
> Kenny <·········@gmail.com> writes:
> [ . . . ]
>
>>> Aside from the chart widgets, the tools are free (as in beer).
>>
>>What's your IDE, Eclipse?
>
>
> Emacs, of course. Why would I want to use something primitive
> and bloated like Eclipse?
I saw it mentioned on one of the Adobe pages. Integrated help?
Debugging? Preview of MXML? The usual goodies offered by a decent IDE.
I guess your browser does the preview. Does Flash have the equivalent of
FireBug?
>
>
>>>>No Cells? Are you mad? For a GUI? Celtk and Cells-Gtk (and soon
>>>>Xello) will show you how to drive an existing framework with Cells.
>>>
>>> This application is a trading system. If Cells is fast
>>>enough, it might be a good choice for the backend. Can I get a
>>>response in 10 milliseconds when an order book changes?
>>
>>10ms is an eternity! I know, I have a feel for that having done
>>RoboCells in which we handled realtime inputs spaced at 100ms.
>>
>>Otherwise, not sure what you are asking. Naturally a very interesting
>>question is how long does the functional computation take. But I will
>>presume that is in order and what you are asking is if Cells is a
>>pig.
>
>
> Well summarized. ;-)
>
> Basically I was asking what the overhead of Cells is. Assuming I
> have optimized the behavior that should be triggered when a cell
> changes, how long does it take for that behavior to be invoked? I
> have one component that needs to do some real work and respond in less
> than a milli, but 10 millis is acceptable for most tasks.
Cells as a rule is fast but like anything it always comes down to
cases. If you update a kabillion prices and recalculate baskets or
indexes after each one things will be slow, but they would be slow
without Cells. If instead you would defer recalc until needed without
Cells, you can use lazy Cells.
The idea of Cells is about making programming fun, easy, and reliable,
automatically handling state interdepence optimally. They do not
introduce significant overhead, and they offer built-in engiennering
tricks like synapses and lazy cells for optimization. And overall the
design is pretty tight by now, so new optimization tricks are easy (like
a recent "propagate once" hack done while gluing in a physics engine.
>
> I'll try out Cells this week. (By the way, the ASDF install
ASDF, the single largest impediment to Lisp's growth? I thought we
eliminated the Cells install... ah, is the cliki page still there? I'll
see if I can edit that out of existence.
> fails and http://common-lisp.net/project/cells has some dead links.)
Just get the tarball from the c-l.net Cells repository.
cells-manifesto.txt has a ton of information including some fairly
specific doc.
Otherwise, the new URL is: ·········@gmail.com
Cells is fun. I never mind giving noobs ideas on how to think in Cells,
don't hesitate to ask. I am especially interested in doing something
along the lines of Celtk and then Cells-GTk and the stalled OpenAir
project in which a Lisp CLOS framework drives a presentation framework
so well one can pretend the other framework (Tk, GTk, Ajax) does not
exist. With you as the MXML/Flex expert and me worrying about the Cells
integration...the OpenLaszlo Killer?
Speaking of which, does anyone no when is McCLIM going to wrap AJAX?
kt
From: Pascal Costanza
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <6krvp6F9em5mU1@mid.individual.net>
Patrick May wrote:
> (By the way, the ASDF install
> fails and http://common-lisp.net/project/cells has some dead links.)
What an optimist... ;)
Pascal
--
Lisp50: http://www.lisp50.org
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Oct 4, 11:03 pm, Kenny <·········@gmail.com> wrote:
> Patrick May wrote:
> > Kenny <·········@gmail.com> writes:
>
> >>Patrick May wrote:
>
> >>>Kenny <·········@gmail.com> writes:
>
> >>>>I wonder if Flash can keep up with compiled JS. You don't mind the
> >>>>Flash requirement? I realize it is ubiquitous enough, but still.
>
> >>> It loads relatively slowly, but once it's loaded it's as fast
> >>>as a desktop app (not surprisingly). I selected it despite the
> >>>Flash requirement because it provided a nice grid control and the
> >>>chart displays I needed.
>
> >>JS frameworks don't have those?
>
> > Some have one, some have the others, some have some other bits I
> > wanted to use. TIBCO's GI was actually my first choice, but there was
> > a bug in Safari that prevented me from using it.
>
> I was just going to say one big win would be insulation from browser
> variability.
>
>
>
> >>Or was it more like you had zero reason to avoid Flash (and maybe
> >>already knew it) so there was no reason to hassle with less polished
> >>tools? I suppose you also had the means to acquire the tools.
>
> > Actually, I felt rather dirty using Flash. And not in that good,
> > tingly way.
>
> :)
>
>
>
> > Aside from the chart widgets, the tools are free (as in beer).
>
> What's your IDE, Eclipse?
>
>
>
> > [ . . . ]
>
> >>No Cells? Are you mad? For a GUI? Celtk and Cells-Gtk (and soon
> >>Xello) will show you how to drive an existing framework with Cells.
>
> > This application is a trading system. If Cells is fast enough,
> > it might be a good choice for the backend. Can I get a response in 10
> > milliseconds when an order book changes?
>
> 10ms is an eternity! I know, I have a feel for that having done
> RoboCells in which we handled realtime inputs spaced at 100ms.
>
> Otherwise, not sure what you are asking. Naturally a very interesting
> question is how long does the functional computation take. But I will
> presume that is in order and what you are asking is if Cells is a pig.
> No. (see "RoboCells"). In fact, Cells helps a bit by magically
> discerning exactly what needs to be updated when X changes. I tried to
> tell the walking dead at ECLM 2008 that Cells is a library about change.
> Practically, this means one has complete control over change,
> including the aforementioned optimization of changing only those things
> that need to change, but also being able to surgically control "oh, I do
> not need to update /that/ every 10ms, I can do it every other unless of
> courese Y changes by 42%". Stuff like that.
>
> Well, if js/html/css get on my nerves I'll take a look at Fex/MXML. Thx
> for the lead.
>
> kt
Hi,
Is Cells able to handle updates in a "diamond scenario"?
"a": external input
"b": driven from "a"
"c": driven from "a"
"d": driven from "b" and "c"
As "d" is driven indirectly from a single input "a", and processing of
"b" and "c" may take different time, it is important to wait with
updating of "d" until both "b" and "c" is finished. Otherwise, "d" may
publish its value twice, and the first value would be totally
incorrect, like a huge spike in the series.
Cheers,
Piotr
From: Kenny
Subject: Pentagon of Death [was Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order]
Date:
Message-ID: <48F52E98.7050803@gmail.com>
puchacz wrote:
> On Oct 4, 11:03 pm, Kenny <·········@gmail.com> wrote:
>
>>Patrick May wrote:
>>
>>>Kenny <·········@gmail.com> writes:
>>
>>>>Patrick May wrote:
>>
>>>>>Kenny <·········@gmail.com> writes:
>>
>>>>>>I wonder if Flash can keep up with compiled JS. You don't mind the
>>>>>>Flash requirement? I realize it is ubiquitous enough, but still.
>>
>>>>> It loads relatively slowly, but once it's loaded it's as fast
>>>>>as a desktop app (not surprisingly). I selected it despite the
>>>>>Flash requirement because it provided a nice grid control and the
>>>>>chart displays I needed.
>>
>>>>JS frameworks don't have those?
>>
>>> Some have one, some have the others, some have some other bits I
>>>wanted to use. TIBCO's GI was actually my first choice, but there was
>>>a bug in Safari that prevented me from using it.
>>
>>I was just going to say one big win would be insulation from browser
>>variability.
>>
>>
>>
>>
>>>>Or was it more like you had zero reason to avoid Flash (and maybe
>>>>already knew it) so there was no reason to hassle with less polished
>>>>tools? I suppose you also had the means to acquire the tools.
>>
>>> Actually, I felt rather dirty using Flash. And not in that good,
>>>tingly way.
>>
>>:)
>>
>>
>>
>>
>>> Aside from the chart widgets, the tools are free (as in beer).
>>
>>What's your IDE, Eclipse?
>>
>>
>>
>>
>>>[ . . . ]
>>
>>>>No Cells? Are you mad? For a GUI? Celtk and Cells-Gtk (and soon
>>>>Xello) will show you how to drive an existing framework with Cells.
>>
>>> This application is a trading system. If Cells is fast enough,
>>>it might be a good choice for the backend. Can I get a response in 10
>>>milliseconds when an order book changes?
>>
>>10ms is an eternity! I know, I have a feel for that having done
>>RoboCells in which we handled realtime inputs spaced at 100ms.
>>
>>Otherwise, not sure what you are asking. Naturally a very interesting
>>question is how long does the functional computation take. But I will
>>presume that is in order and what you are asking is if Cells is a pig.
>>No. (see "RoboCells"). In fact, Cells helps a bit by magically
>>discerning exactly what needs to be updated when X changes. I tried to
>>tell the walking dead at ECLM 2008 that Cells is a library about change.
>> Practically, this means one has complete control over change,
>>including the aforementioned optimization of changing only those things
>>that need to change, but also being able to surgically control "oh, I do
>>not need to update /that/ every 10ms, I can do it every other unless of
>>courese Y changes by 42%". Stuff like that.
>>
>>Well, if js/html/css get on my nerves I'll take a look at Fex/MXML. Thx
>>for the lead.
>>
>>kt
>
>
> Hi,
>
> Is Cells able to handle updates in a "diamond scenario"?
>
> "a": external input
> "b": driven from "a"
> "c": driven from "a"
> "d": driven from "b" and "c"
>
> As "d" is driven indirectly from a single input "a", and processing of
> "b" and "c" may take different time, it is important to wait with
> updating of "d" until both "b" and "c" is finished. Otherwise, "d" may
> publish its value twice, and the first value would be totally
> incorrect, like a huge spike in the series.
PWUAHAHAHAHAHHAHAA! I thought I invented that. Philip Eby gave it a more
dramatic name when I explained it to him while justifying the Cells
mechanism -- the Pentagon of Death, I think it was. Why Pentagon aka 5?
I settled on a tougher case in which, eg, d did not depend directly on
c, but did so indirectly thru an intermediary depencency c2 which
depended on c. Why does this matter? If a changes c needs to be
recalculated, period, no question. But C might recompute and come up
with the same value, say if A changes from 3 to 6 and C is (mod A 3). In
that case we cannot know C2 is obsolete until C runs, and this defeats
some algorithms (assuming we have a rule that says "never calculate
unecessarily").
I also made it nastier in that...well, it gets complicated, but Cells
tracks dynamic dependencies, not lexical, so I cannot just inspect the
dependency graph as it stands -- the change to 'a' might make 'd' go
after 'c2' for the first time ever in 'd's life.
Philip struggled mightily to find a better way than the Cells algorithm,
but in the end the Pentagon of Death beat every alternative.
Thx for the heads up on the prior art.
cheers,ken
From: Raffael Cavallaro
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <gd5e7c$hjm$1@aioe.org>
On 2008-10-14 17:15:12 -0400, puchacz <···········@gmail.com> said:
> Is Cells able to handle updates in a "diamond scenario"?
>
> "a": external input
> "b": driven from "a"
> "c": driven from "a"
> "d": driven from "b" and "c"
>
> As "d" is driven indirectly from a single input "a", and processing of
> "b" and "c" may take different time, it is important to wait with
> updating of "d" until both "b" and "c" is finished. Otherwise, "d" may
> publish its value twice, and the first value would be totally
> incorrect, like a huge spike in the series.
I'll take a crack at this since I'm just learning cells:
(in-package :cells)
(defmodel diamond-cell ()
((a-external :cell t :initarg :a-external
:initform (c-in 0) :accessor a-external)
(b-from-a :cell t :initarg :b-from-a
:initform 0 :accessor b-from-a)
(c-from-a :cell t :initarg :c-from-a
:initform 0 :accessor c-from-a)
(d-from-b-and-c :cell t :initarg :d-from-b-and-c
:initform 0 :accessor d-from-b-and-c))
(:default-initargs
:b-from-a
(c? (progn (sleep .1) (+ (a-external self) 3)))
:c-from-a
(c? (progn (sleep .3) (+ (a-external self) 9)))
;; note that b and c take different times to compute
:d-from-b-and-c
(c? (* (b-from-a self) (c-from-a self)))))
(defobserver d-from-b-and-c ((self diamond-cell) new old old-bound-p)
(format t
"a-external is ~a~%b-from-a is ~a~%c-from-a is ~a
d-from-b-and-c is ~a~%"
(a-external self) (b-from-a self)
(c-from-a self) new))
(defun test-diamond ()
(cells-reset)
(terpri)
(loop for i from 1 to 3
with our-diamond = (make-instance 'diamond-cell)
do
(setf (a-external our-diamond) i)))
CELLS 6 > (test-diamond)
"----------UTILSRESET----------------------------------"
a-external is 0
b-from-a is 3
c-from-a is 9
d-from-b-and-c is 27
a-external is 1
b-from-a is 4
c-from-a is 10
d-from-b-and-c is 40
a-external is 2
b-from-a is 5
c-from-a is 11
d-from-b-and-c is 55
a-external is 3
b-from-a is 6
c-from-a is 12
d-from-b-and-c is 72
NIL
From: Kenny
Subject: Diamond Disaster [was Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order]
Date:
Message-ID: <48f657f9$0$4975$607ed4bc@cv.net>
Raffael Cavallaro wrote:
> On 2008-10-14 17:15:12 -0400, puchacz <···········@gmail.com> said:
>
>> Is Cells able to handle updates in a "diamond scenario"?
>>
>> "a": external input
>> "b": driven from "a"
>> "c": driven from "a"
>> "d": driven from "b" and "c"
>>
>> As "d" is driven indirectly from a single input "a", and processing of
>> "b" and "c" may take different time, it is important to wait with
>> updating of "d" until both "b" and "c" is finished. Otherwise, "d" may
>> publish its value twice, and the first value would be totally
>> incorrect, like a huge spike in the series.
>
>
> I'll take a crack at this since I'm just learning cells:
>
> (in-package :cells)
>
> (defmodel diamond-cell ()
> ((a-external :cell t :initarg :a-external
> :initform (c-in 0) :accessor a-external)
> (b-from-a :cell t :initarg :b-from-a
> :initform 0 :accessor b-from-a)
> (c-from-a :cell t :initarg :c-from-a
> :initform 0 :accessor c-from-a)
> (d-from-b-and-c :cell t :initarg :d-from-b-and-c
> :initform 0 :accessor d-from-b-and-c))
> (:default-initargs
> :b-from-a
> (c? (progn (sleep .1) (+ (a-external self) 3)))
> :c-from-a
> (c? (progn (sleep .3) (+ (a-external self) 9)))
> ;; note that b and c take different times to compute
> :d-from-b-and-c
> (c? (* (b-from-a self) (c-from-a self)))))
>
> (defobserver d-from-b-and-c ((self diamond-cell) new old old-bound-p)
> (format t
> "a-external is ~a~%b-from-a is ~a~%c-from-a is ~a
> d-from-b-and-c is ~a~%"
> (a-external self) (b-from-a self)
> (c-from-a self) new))
>
>
> (defun test-diamond ()
> (cells-reset)
> (terpri)
> (loop for i from 1 to 3
> with our-diamond = (make-instance 'diamond-cell)
> do
> (setf (a-external our-diamond) i)))
>
> CELLS 6 > (test-diamond)
>
> "----------UTILSRESET----------------------------------"
> a-external is 0
> b-from-a is 3
> c-from-a is 9
> d-from-b-and-c is 27
> a-external is 1
> b-from-a is 4
> c-from-a is 10
> d-from-b-and-c is 40
> a-external is 2
> b-from-a is 5
> c-from-a is 11
> d-from-b-and-c is 55
> a-external is 3
> b-from-a is 6
> c-from-a is 12
> d-from-b-and-c is 72
> NIL
>
Omigod?! How on earth were you able to keep those datanames straight?!
Meanwhile, Omigod! Doc by Kenny?!!!!!! From df-interference.lisp:
;;
;; here we look at just one problem, what i call dataflow interference.
consider
;; a dependency graph underlying:
;;
;; - a depends on b and c, and...
;; - b depends on c
;;
;; if c changes, depending on the accident of the order in which a and b
happened to
;; be first evaluated, a might appear before b on c's list of dependents
(callers). then the
;; following happens:
;;
;; - c triggers a
;; - a calculates off the new value of c and an obsolete cached
value for b
;; - a outputs an invalid value and triggers any dependents, all of
whom recalculate
;; using a's invalid value
;; - c triggers b
;; - b recalculates and then triggers a, which then recalculates
correctly and outputs and triggers
;; the rest of the df graph back into line
;;
;; the really bad news is that outputs go outside the model: what if the
invalid output caused
;; a missile launch? sure, a subsequent correct calculation comes along
shortly, but
;; irrevocable damage may have been done.
;;
Again note that the graph tested is more diabolical than the diamond,
tho different from the Pentagram of Death described earlier.
peace,kzo
On Oct 15, 9:52 pm, Kenny <·········@gmail.com> wrote:
> Raffael Cavallaro wrote:
> > On 2008-10-14 17:15:12 -0400, puchacz <···········@gmail.com> said:
>
> >> Is Cells able to handle updates in a "diamond scenario"?
>
> >> "a": external input
> >> "b": driven from "a"
> >> "c": driven from "a"
> >> "d": driven from "b" and "c"
>
> >> As "d" is driven indirectly from a single input "a", and processing of
> >> "b" and "c" may take different time, it is important to wait with
> >> updating of "d" until both "b" and "c" is finished. Otherwise, "d" may
> >> publish its value twice, and the first value would be totally
> >> incorrect, like a huge spike in the series.
>
> > I'll take a crack at this since I'm just learning cells:
>
> > (in-package :cells)
>
> > (defmodel diamond-cell ()
> > ((a-external :cell t :initarg :a-external
> > :initform (c-in 0) :accessor a-external)
> > (b-from-a :cell t :initarg :b-from-a
> > :initform 0 :accessor b-from-a)
> > (c-from-a :cell t :initarg :c-from-a
> > :initform 0 :accessor c-from-a)
> > (d-from-b-and-c :cell t :initarg :d-from-b-and-c
> > :initform 0 :accessor d-from-b-and-c))
> > (:default-initargs
> > :b-from-a
> > (c? (progn (sleep .1) (+ (a-external self) 3)))
> > :c-from-a
> > (c? (progn (sleep .3) (+ (a-external self) 9)))
> > ;; note that b and c take different times to compute
> > :d-from-b-and-c
> > (c? (* (b-from-a self) (c-from-a self)))))
>
> > (defobserver d-from-b-and-c ((self diamond-cell) new old old-bound-p)
> > (format t
> > "a-external is ~a~%b-from-a is ~a~%c-from-a is ~a
> > d-from-b-and-c is ~a~%"
> > (a-external self) (b-from-a self)
> > (c-from-a self) new))
>
> > (defun test-diamond ()
> > (cells-reset)
> > (terpri)
> > (loop for i from 1 to 3
> > with our-diamond = (make-instance 'diamond-cell)
> > do
> > (setf (a-external our-diamond) i)))
>
> > CELLS 6 > (test-diamond)
>
> > "----------UTILSRESET----------------------------------"
> > a-external is 0
> > b-from-a is 3
> > c-from-a is 9
> > d-from-b-and-c is 27
> > a-external is 1
> > b-from-a is 4
> > c-from-a is 10
> > d-from-b-and-c is 40
> > a-external is 2
> > b-from-a is 5
> > c-from-a is 11
> > d-from-b-and-c is 55
> > a-external is 3
> > b-from-a is 6
> > c-from-a is 12
> > d-from-b-and-c is 72
> > NIL
>
> Omigod?! How on earth were you able to keep those datanames straight?!
>
> Meanwhile, Omigod! Doc by Kenny?!!!!!! From df-interference.lisp:
>
> ;;
> ;; here we look at just one problem, what i call dataflow interference.
> consider
> ;; a dependency graph underlying:
> ;;
> ;; - a depends on b and c, and...
> ;; - b depends on c
> ;;
> ;; if c changes, depending on the accident of the order in which a and b
> happened to
> ;; be first evaluated, a might appear before b on c's list of dependents
> (callers). then the
> ;; following happens:
> ;;
> ;; - c triggers a
> ;; - a calculates off the new value of c and an obsolete cached
> value for b
> ;; - a outputs an invalid value and triggers any dependents, all of
> whom recalculate
> ;; using a's invalid value
> ;; - c triggers b
> ;; - b recalculates and then triggers a, which then recalculates
> correctly and outputs and triggers
> ;; the rest of the df graph back into line
> ;;
> ;; the really bad news is that outputs go outside the model: what if the
> invalid output caused
> ;; a missile launch? sure, a subsequent correct calculation comes along
> shortly, but
> ;; irrevocable damage may have been done.
> ;;
>
> Again note that the graph tested is more diabolical than the diamond,
> tho different from the Pentagram of Death described earlier.
>
> peace,kzo
Hi,
Not sure if I am following; from what you wrote I concluded that Cells
does not analyse the graph of dependencies before starting
recalculations, is this right? And if so, why isn't it determining the
safe update order before starting recalculations? In a single threaded
environment, as your thread has exclusive control over recalculations
and structural changes, if graph structure does not change, you could
be able to do it.
Piotr
From: Kenny
Subject: Re: Diamond Disaster [was Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order]
Date:
Message-ID: <48fa0299$0$4969$607ed4bc@cv.net>
puchacz wrote:
> On Oct 15, 9:52 pm, Kenny <·········@gmail.com> wrote:
>
>>Raffael Cavallaro wrote:
>>
>>>On 2008-10-14 17:15:12 -0400, puchacz <···········@gmail.com> said:
>>
>>>>Is Cells able to handle updates in a "diamond scenario"?
>>
>>>>"a": external input
>>>>"b": driven from "a"
>>>>"c": driven from "a"
>>>>"d": driven from "b" and "c"
>>
>>>>As "d" is driven indirectly from a single input "a", and processing of
>>>>"b" and "c" may take different time, it is important to wait with
>>>>updating of "d" until both "b" and "c" is finished. Otherwise, "d" may
>>>>publish its value twice, and the first value would be totally
>>>>incorrect, like a huge spike in the series.
>>
>>>I'll take a crack at this since I'm just learning cells:
>>
>>>(in-package :cells)
>>
>>>(defmodel diamond-cell ()
>>> ((a-external :cell t :initarg :a-external
>>> :initform (c-in 0) :accessor a-external)
>>> (b-from-a :cell t :initarg :b-from-a
>>> :initform 0 :accessor b-from-a)
>>> (c-from-a :cell t :initarg :c-from-a
>>> :initform 0 :accessor c-from-a)
>>> (d-from-b-and-c :cell t :initarg :d-from-b-and-c
>>> :initform 0 :accessor d-from-b-and-c))
>>> (:default-initargs
>>> :b-from-a
>>> (c? (progn (sleep .1) (+ (a-external self) 3)))
>>> :c-from-a
>>> (c? (progn (sleep .3) (+ (a-external self) 9)))
>>> ;; note that b and c take different times to compute
>>> :d-from-b-and-c
>>> (c? (* (b-from-a self) (c-from-a self)))))
>>
>>>(defobserver d-from-b-and-c ((self diamond-cell) new old old-bound-p)
>>> (format t
>>> "a-external is ~a~%b-from-a is ~a~%c-from-a is ~a
>>>d-from-b-and-c is ~a~%"
>>> (a-external self) (b-from-a self)
>>> (c-from-a self) new))
>>
>>>(defun test-diamond ()
>>> (cells-reset)
>>> (terpri)
>>> (loop for i from 1 to 3
>>> with our-diamond = (make-instance 'diamond-cell)
>>> do
>>> (setf (a-external our-diamond) i)))
>>
>>>CELLS 6 > (test-diamond)
>>
>>>"----------UTILSRESET----------------------------------"
>>>a-external is 0
>>>b-from-a is 3
>>>c-from-a is 9
>>>d-from-b-and-c is 27
>>>a-external is 1
>>>b-from-a is 4
>>>c-from-a is 10
>>>d-from-b-and-c is 40
>>>a-external is 2
>>>b-from-a is 5
>>>c-from-a is 11
>>>d-from-b-and-c is 55
>>>a-external is 3
>>>b-from-a is 6
>>>c-from-a is 12
>>>d-from-b-and-c is 72
>>>NIL
>>
>>Omigod?! How on earth were you able to keep those datanames straight?!
>>
>>Meanwhile, Omigod! Doc by Kenny?!!!!!! From df-interference.lisp:
>>
>>;;
>>;; here we look at just one problem, what i call dataflow interference.
>>consider
>>;; a dependency graph underlying:
>>;;
>>;; - a depends on b and c, and...
>>;; - b depends on c
>>;;
>>;; if c changes, depending on the accident of the order in which a and b
>>happened to
>>;; be first evaluated, a might appear before b on c's list of dependents
>>(callers). then the
>>;; following happens:
>>;;
>>;; - c triggers a
>>;; - a calculates off the new value of c and an obsolete cached
>>value for b
>>;; - a outputs an invalid value and triggers any dependents, all of
>>whom recalculate
>>;; using a's invalid value
>>;; - c triggers b
>>;; - b recalculates and then triggers a, which then recalculates
>>correctly and outputs and triggers
>>;; the rest of the df graph back into line
>>;;
>>;; the really bad news is that outputs go outside the model: what if the
>>invalid output caused
>>;; a missile launch? sure, a subsequent correct calculation comes along
>>shortly, but
>>;; irrevocable damage may have been done.
>>;;
>>
>>Again note that the graph tested is more diabolical than the diamond,
>>tho different from the Pentagram of Death described earlier.
>>
>>peace,kzo
>
>
>
> Hi,
>
> Not sure if I am following; from what you wrote I concluded that Cells
> does not analyse the graph of dependencies before starting
> recalculations, is this right?
That is correct.
> And if so, why isn't it determining the
> safe update order before starting recalculations?
Because it cannot be determined beforehand. See below.
> In a single threaded
> environment, as your thread has exclusive control over recalculations
> and structural changes, if graph structure does not change, you could
> be able to do it.
>
Well suppose one of my rules is:
(make-instance 'hi-mom
:x (c? (if (^a) (^b) (^c))))
[(^a) is just shorthand for (a self) (and yes, had I known about
symbol-macros back then it would just be ^a.]
If A changes from true to false, the dependency graph for x before the
change will include only A and B, not C. But with A false, I need C to
be current. So the dependency graph is useless for lookahead.
Before you suggest a lexical lookahead (which still would not work
because of branching) recall that dependents have dynamic scope: a
dependency is recorded on any other cell read while calculating the
value for the dependent, however deep in a call tree.
kt
From: Kenny
Subject: Re: Diamond Disaster [was Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order]
Date:
Message-ID: <48fa08ac$0$5671$607ed4bc@cv.net>
>> And if so, why isn't it determining the
>> safe update order before starting recalculations?
>
>
> Because it cannot be determined beforehand. See below.
>
>> In a single threaded
>> environment, as your thread has exclusive control over recalculations
>> and structural changes, if graph structure does not change,...
It does. Read this:
In the text that follows, [xxx] signifies a footnote named "xxx" and
listed alphabetically at the end.
Summary
-------
Cells is a mature, stable extension to CLOS[impl] allowing one to create
classes
whose instances can have slot values determined by instance-specific
formulas.
Example
-------
For example, in a text editor application we might have (condensed):
(make-instance 'menu-item
:label "Cut"
:enabled (c? (bwhen (f (focus *window*))
(and (typep f 'text-widget)
(selection-range f)))))
Translated, the enabled state of the Cut menu item follows
whether or not the user is focused on a text-edit widget and
whether they have in fact selected a range of text.
Meanwhile, the selection-range rule might be:
(let (start)
(c? (if (mouse-down? .w.)
(bwhen (c (mouse-pos-to-char self (mouse-pos .w.)))
(if start
(list start c)
(setf start c)))
(setf start nil))))
Now the only imperative code needed is some glue reading the OS event loop
converting raw mouse down and mouse move events into window (the .w.
symbol-macro)
attributes such as mouse-down? and mouse-pos. The desired functionality
is achieved
by declarative rules which (like selection-range above) are entirely
responsible for
deciding the selection range.
A final trick comes from slot observers. Suppose we are thinly wrapping
a C GUI and need to
do something in the C library to actually make menu items available or not.
It might look something like this:
(defobserver enabled ((self menu-item) new-value old-value
old-value-bound?)
(menu-item-set (c-ptr self) (if new-value 1 0)))
ie, Some model attributes must be propagated outside the model as they
change, and observers
are callbacks we can provide to handle change.
Motivation
----------
As a child I watched my father toil at home for hours over paper
spreadsheets with pencil and slide rule. After he changed one value,
he had to propagate that change to other cells by first remembering
which other ones included the changed cell in their computation.
Then he had to do the calculations for those, erase, enter...
and then repeat that process to propagate those changes in a
cascade across the paper.
VisiCalc let my father take the formula he had in mind and
put it into (declare it to) the electronic spreadsheet. Then VisiCalc
could do the tedious work: recalculating, knowing what to recalculate,
and knowing in what order to recalculate.
Cells do for programmers what electronic spreadsheets did for my father.
Without Cells, CLOS slots are like cells of a paper spreadsheet.
A single key-down event can cause a cascade of change throughout an
application. The programmer has to arrange for it all to happen,
all in the right order: delete any selected text, insert
the new character, re-wrap the text, update the undo mechanism, revisit
the menu statuses ("Cut" is no longer enabled), update the scroll bars,
possibly scroll the window, flag the file as unsaved...
Here is a real-world case study:
"The last company I worked with made a product that was a control unit
for some mechanical devices, presenting both sensor readings coming in
from those devices and an interface to program the devices. Consider
it like a very sophisticated microwave oven, perhaps with a
temperature probe.
"The UI code was a frighteningly complex rat's nest. Input data
arriving from the sensors changed certain state values, which caused
the display to update, but the system state also changed, and rules
had to be evaluated, the outcome of which might be tuning to the
running job or warning messages presented to the user, and in the
meantime the user may be adjusting the running job. I'm sure there are
even more interactions I'm leaving out.
"There was no "large idea" in this code to organize these dependencies
or orchestrate the data flow. The individual facilities were
well-formed enough: "message" input and output, GUI widgets and forms,
real-world entities modeled as entities in the code. However, the
connections between these things were ad-hoc and not formalized. Every
change to the system would provoke defects, and the failure usually
involved not propagating some event, propagating it at the wrong time,
or propagating it to the wrong recipients."
--- Steven Harris, on comp.lang.lisp
What Mr. Harris describes is what Fred Brooks [bullet] said was an essential
property of software development, meaning by essential that there was no
way around it, and thus his prediction that a software silver bullet was
in principle impossible.
Which brings us to Cells. See also [axiom] Phillip Eby's developing
axiomatic
definition he is developing in support of Ryan Forseth's SoC project.
Mr. Eby was
inspired by his involvement to develop Trellis, his own Cells work-alike
library
for Python.
DEFMODEL and Slot types
-----------------------
Classes, some of whose slots may be mediated by Cells, are defined by
DEFMODEL, which is exactly
like DEFCLASS but adds support for two slot definition options, :cell
and :unchanged-if. Classes
defined by DEFMODEL can inherit from normal CLOS classes.
New slot definition options
----------------------------
:cell {nil | t | :ephemeral}
:cell is optional. The default is ":cell t", meaning the Cells engine
will manage the slot to give
it the spreadsheet-like characteristics. Specifying NIL signifies that
this slot is entirely
outside any handling by the Cells engine; it is just a plain CLOS slot.
This next bit will not make sense until we have explained propagation of
state change, but
specifying :ephemeral causes the Cells engine to reset the apparent slot
value to NIL immediately and only after fully propagating any value
assumed by the slot, either
by assignment to an input Cell (the vastly more common case) or by a
rule calculation.
Ephemeral cells are necessary to correctly model events in the otherwise
steady-state
spreadsheet paradigm.
:unchanged-if <function-name>
Specifying :unchanged-if is optional. [Come to think of it, it should be
an error to specify
both :cell nil and :unchanged-if.] If specified, the named function is a
predicate
of two arguments, the new and old value in that order. The predicate
determines if a subsequent
slot value (either computed or assigned to an input) is unchanged in the
sense that no propagation
is necessary, either to dependent ruled cells or (getting ahead of
ourselves again) "on change" observers.
The default unchanged test is EQL.
Cell types
----------
The Cells library allows the programmer to specify at make-instance time
that a Cell
slot of an instance be mediated for the life of that instance by one of:
-- a so-called "input" Cell;
-- a "ruled" Cell; or
-- no Cell at all.
Note that different instances of the same class may do different things
Cells-wise with the same slot.
One label widget may have a fixed width of 42 and text "Hi, Mom!", where
another might have
an input Cell mediating the text (so edit logic can assign new values as
the user types) and a
rule mediating the width so the widget can have a minimum width of 42(so
it does not disappear altogether)
yet grow based on text length and relevant font metrics to always leave
room for one more character
(if the GUI design calls for that).
To summarize, the class specification supplied with DEFMODEL specifies
whether a slot can /ever/
be managed by the Cells engine. For those that can, at and only at
instance initialization time
different instances can have different Cell types and rules specified to
mediate the same slot.
Input Cells
-----------
A slot mediated by an input Cell may be assigned new values at runtime.
These are how Cell-based models
get data from the world outside the model -- it cannot be rules all the
way down. Typically, these
input assignements are made by code polling OS events via some
GetNextEvent API call, or by callbacks
registered with an event system such as win32 WindowProc functions.
Other code may poll sockets or
serial inputs from an external device.
Ruled Cells
-----------
Ruled Cells come with an instance-specific rule in the form of an
anonymous function of two variables,
the instance owning the slot and the prior value (if any) computed by
the rule. These rules consist of
arbitrarily complex Common Lisp code, and are invoked immediately after
instance initialization (but see
the next bit on lazy cells).
When a rule runs, any dynamic read (either expressly in the rule source
or during the execution of
some function invoked by the rule) of a slot of any instance mediated by
a Cell of any type establishes a
runtime dependency of the ruled cell on the slot of the instance that
was read. Note then that thanks
to code branching, dependencies can vary after every rule invocation.
Lazy Ruled Cells
----------------
Laziness is cell-specific, applies only to ruled cells, and comes in
four varieties:
:once-asked -- this will get evaluated and "observed" on
initialization, but then not get reevaluated
immediately if dependencies change, rather only when read by application
code.
:until-asked -- this does not get evaluated/observed until read
by application code, but then it becomes
un-lazy, eagerly reevaluated as soon as any dependency changes (not
waiting until asked).
:always -- not evaluated/observed until read, and not reevaluated
until read after a dependency changes.
Dataflow
--------
When application code assigns a new value to an input Cell (a quick way
of saying an instance slot mediated by
an input Cell) -- typically by code polling OS events or a socket or an
input device -- a cascade of recalculation
ensues to bring direct and indirect ruled dependents current with the
new value assigned to the input Cell.
No Cell at All
--------------
Because of all that, it is an error to assign a new value to a slot of
an instance not mediated by any Cell.
The Cells engine can do a handy optimization by treating such slots as
constants and not creating dependencies when ruled
Cells read these. But then we cannot let these Cells vary and still
guarantee data integrity, because
we no longer know who else to update in light of such variation. The
optimization, by the way, extends to
eliminating ruled Cells which, after any computation, end up not
depending on any other cell.
Again, note that this is different from specifying ":cell nil" for some
slot. Here, the Cells engine
has been told to manage some slot, but for some instance the slot has
been authored to bear some value
for the lifetime of that instance.
Observers
---------
To allow the emergent animated data model to operate usefully on the
world outside the model--if only to
update the screen--programmers may specify so-called observer callbacks
dispatched according to: slot name,
instance, new value, old value, and whether the old value actually
existed (false only on the first go).
Observers are inherited according to the rules of CLOS class
inheritance. If multiple primary observer
methods apply because of inheritance, they all get run, most specific last.
ie, observers are a GF with PROGN method combination.
Observers get called in two circumstances: as part of Model object
initialization, in a processing step
just after CLOS instance initialization, and when a slot changes value.
Any observer of a Cell slot
is guaranteed to be called at least once during intialization even if a
cell slot is bound to a constant
or if it is an input or ruled Cell that never changes value.
It is legal for observer code to assign to input Cells, but (a) special
syntax is required to defer execution
until the observed state change has fully propagated; and (b) doing so
compromises the declarative
quality of an application -- one can no longer look to one rule to see
how a slot (in this case the
input slot being assigned by the observer) gets its value. A reasonable
usage might be one with
a cycle, where changing slot A requires a change to slot B, and changing
slot B requires a change to
slot A, such as the scroll thumb position and the amount a document has
been scrolled.
Finally, to make it possible for such a declarative model to talk
intelligibly to imperative systems such as
Tcl/Tk which sometimes requires a precise sequence of commands for
something to work at all, a mechanism exists by
which client code can (a) queue tasks for execution after a data change
has fully propagated and (b) process
those tasks with a client-supplied handler. Tasks are queued with
arbitrary keying data which can be used by
the handler to sort or compress the queued tasks.
Data Integrity
--------------
When application code assigns to some input cell X, the Cells engine
guarantees:
- recomputation exactly once of all and only state affected by the
change to X, directly or indirectly through
some intermediate datapoint. note that if A depends on B, and B
depends on X, when B gets recalculated
it may come up with the same value as before. In this case A is not
considered to have been affected
by the change to X and will not be recomputed.
- recomputations, when they read other datapoints, must see only
values current with the new value of X.
Example: if A depends on B and X, and B depends on X, when X
changes and A reads B and X to compute a
new value, B must return a value recomputed from the new value of X.
- similarly, client observer callbacks must see only values current
with the new value of X; and
- a corollary: should a client observer SETF a datapoint Y, all the
above must
happen with values current with not just X, but also with the value
of Y /prior/
to the change to Y.
- Deferred "client" code must see only values current with X and not
any values current with some
subsequent change to Y queued by an observer
Benefits
--------
Program state guaranteed to be self-consistent, without programmer
effort. Dependencies are identified
by the engine, and change propagation happens automatically.
Greater object re-use. Slots of instances can be authored with rules,
not just literal values. In a sense,
we get greater reuse by allowing instances to override slot derivations
instance by instance. But not slot
expressions, which are still class-oriented. By this I mean the
observers expressing changes in value are
dispatched by the class of the instance and so are not
instance-specific. (Such a thing has been
suggested, however.) Another strong bit of class-orientation comes from
the fact that code reading
slot X of some instance Y obviously does so without knowing how the
returned value was derived. It knows
only that the slot is named X, and will do things with that value
assuming only that it has the
X attribute of the instance Y. So again: the derivation of a slot value
is potentially instance-oriented
under Cells, but its expression or manifestation is still class-oriented.
Natural decomposition of overall application complexity into so many
simple rules and slot observers.
Let's return for a moment to VisiCalc and its descendants. In even the
most complex financial spreadsheet
model, no one cell rule accesses more than a relatively few other
spreadsheet cells (counting a row or
column range as one reference). Yet the complex model emerges. All the
work of tracking dependencies
is handled by the spreadsheet software, which requires no special
declaration by the modeller. They simply
write the Cell rule. In writing the rule, they are concerned only with
the derivation of one datapoint from
a population of other datapoints. No effort goes into arranging for the
rule to get run at the right time,
and certainly no energy is spent worrying about what other cells might
be using the authored cell. That
cell has certain semantics -- "account balance", perhaps -- and the
modeller need only worry about writing
a correct, static computation of those semantics.
Same with Cells. :) The only difference is that VisiCalc has one
"observer" requirement for all cells:
update the screen. In Cells applications, a significant amount of
application functionality -- indeed, all
its outputs -- end up in cell observers. But as discussed above, this
additional burden falls only on
the class designer when they decide to add a slot to a class. As
instances are created and different rules
specified for different slots to achieve custom behavior, the effort is
the same as for the VisiCalc user.
Model Building
--------------
Everything above could describe one instance of one class defined by
DEFMODEL. A real application has
multiple instances of multiple classes. So...
-- cells can depend on other cells from any other instance. Since a rule
gets passed only "self", Cell users
need something like the Family class included with the Cells package
effectively to turn a collection of
instances into a network searchable by name or type.
-- The overall model population must be maintainable by Cell slots such
as the "kids" slot of the Family
class. The burden here is on the Cells engine to allow one cell of one
child to ask for the value of a cell of
another child and vice versa (with different Cells), when both children
are the product of the same rule,
or different rules when "cousins" are exchanging information. So we must
gracefully traverse the parent/kids
tree dispatching kids rules just in time to produce the other instance
sought.
-- kid-slotting: used almost exclusively so far for orderly GUI layout,
a parent must be able to specify
rules for specific slots of kids. Example: a "stack" class wants to
provide rules for child geometry
specifying left, right, or centered alignment and vertical stacking
(with optional spacing) one below
the other. The idea is that we want to author classes of what might be
GUI subcomponents without worrying
about how they will be arranged in some container.
-- finalization: when an instance appears in the "old kids" but not in
the "new kids", a Cells engine
may need to arrange for all Cells to "unsubscribe" from their
dependents. Cells takes care of that if
one calls "not-to-be" on an instance.
Suggested Applications
----------------------
Any application that must maintain an interesting, long-lived data model
incorporating a stream of unpredictable
data. Two examples: any GUI application and a RoboCup soccer client.
An application needing to shadow data between two systems. Examples: a
Lisp GUI imlemented by thinly wrapping a
C GUI library, where Lisp-land activity must be propagated to the C GUI,
and C GUI events must propagate
to Lisp-land. See the Cells-Gtk or Celtk projects. Also, a persistent
CLOS implementation that must echo
CLOS instance data into, say, SQL tables.
Prior Art (in increasing order of priorness (age))
---------
Functional reactive programming:
This looks to be the most active, current, and vibrant subset of
folks working on this sort of stuff.
Links:
FlapJax (FRP-powered web apps) http://www.flapjax-lang.org/
http://lambda-the-ultimate.org/node/1771
http://www.haskell.org/frp/
FrTime (scheme FRP implementation, no great links)
http://pre.plt-scheme.org/plt/collects/frtime/doc.txt
Adobe Adam, originally developed only to manage complex GUIs. [Adam]
COSI, a class-based Cells-alike used at STSCI in software used to
schedule Hubble telescope viewing time. [COSI]
Garnet's KR: http://www.cs.cmu.edu/~garnet/
Also written in Lisp. Cells looks much like KR, though Cells was
developed in ignorance of KR (or any other prior art). KR has
an astonishing number of backdoors to its constraint
engine, none of which have turned out to be necessary for Cells.
The entire constraint programming field, beginning I guess with Guy Steele's
PhD Thesis in which he develops a constraint programming language or two:
http://portal.acm.org/citation.cfm?id=889490&dl=ACM&coll=ACM
http://www.cs.utk.edu/~bvz/quickplan.html
Flow-based programming, developed by J. Paul Morrison at IBM, 1971.
http://en.wikipedia.org/wiki/Flow-based_programming
Sutherland, I. Sketchpad: A Man Machine Graphical Communication System.
PhD thesis, MIT, 1963.
Steele himself cites Sketchpad as inexplicably unappreciated prior
art to his Constraints system:
See also:
The spreadsheet paradigm:
http://www.cs.utk.edu/~bvz/active-value-spreadsheet.html
The dataflow paradigm: http://en.wikipedia.org/wiki/Dataflow
Frame-based programming
Definitive-programming
Commentary
----------
-- Jack Unrue, comp.lang.lisp
"Cells provides the plumbing for data dependency management which every
non-trivial program must have; a developer using Cells can focus on
computing program state and reacting to state changes, leaving Cells to
worry about
how that state is propagated. Cells does this by enabling a declarative
mechanism built via an extension to CLOS, and hence achieves its goal in
a way
that meshes well with with typical Common Lisp programming style."
-- Bill Clementson, http://bc.tech.coop/blog/030911.html
"Kenny Tilton has been talking about his Cells implementation on
comp.lang.lisp
for some time but I've only just had a look at it over the past few
evenings.
It's actually pretty neat. Kenny describes Cells as, conceptually,
analogous to
a spreadsheet cell (e.g. -- something in which you can put a value or a
formula
and have it updated automatically based on changes in other "cell" values).
Another way of saying this might be that Cells allows you to define classes
whose slots can be dynamically (and automatically) updated and for which
standard observers can be defined that react to changes in those slots."
-- "What is Cells?", Cells-GTk FAQ,
http://common-lisp.net/project/cells-gtk/faq.html#q2
"If you are at all familiar with developing moderately complex software
that
is operated through a GUI, then you have probably
learned this lesson: Keeping what is presented through the GUI in-sync
with what
the user is allowed to do, and in-sync with the computational state of the
program is often tedious, complicated work. .... Cells-GTK helps
with these tasks by providing an abstraction over the details; each of
the tasks
just listed can be controlled by (a) formula that specify the value of
attributes of graphic features in the part-subpart declaration (that
declaration
is called 'defpart' in cells-gtk); and, (b) formula that specify the
value of CLOS slots."
-- Phillip Eby, PyCells and peak.events,
http://www.eby-sarna.com/pipermail/peak/2006-May/002545.html
"What I discovered is quite cool. The Cells system *automatically
discovers* dynamic dependencies, without having to explicitly specify that
X depends on Y, as long as X and Y are both implemented using cell
objects. The system knows when you are computing a value for X, and
registers the fact that Y was read during this computation, thus allowing
it to automatically invalidate the X calculation if Y changes....
Aside from the automatic dependency detection, the cells system has
another trick that is able to significantly reduce the complexity of
event cascades, similar to what I was trying (but failing) to do using
the "scheduled thread" concept in peak.events.
Specifically, the cells system understands how to make event-based updates
orderly and deterministic, in a way that peak.events cannot. It
effectively divides time into "propagation" and "non-propagation"
states. Instead of simply making callbacks whenever a computed value
changes, the system makes orderly updates by queueing invalidated cells for
updating. Also, if you write code that sets a new value imperatively (as
opposed to it being pulled declaratively), the actual set operation is
deferred until all computed cells are up-to-date with the current state of
the universe."
_____________
Uncommentary
-- Peter Seibel, comp.lang.lisp:
"I couldn't find anything that explained what [Cells] was and why I
should care."
-- Alan Crowe, comp.lang.lisp:
"Further confession: I'm bluffing. I've grasped that Cells is
interesting, but I haven't downloaded it yet, and I haven't
checked out how it works or what /exactly/ it does."
_________
Footnotes
[Adam] "Adam is a modeling engine and declarative language for
describing constraints and
relationships on a collection of values, typically the parameters to an
application command. When bound to a human interface (HI) Adam provides
the logic that controls the HI behavior. Adam is similar in concept to a
spreadsheet
or a forms manager. Values are set and dependent values are recalculated.
Adam provides facilities to resolve interrelated dependencies and to track
those dependencies, beyond what a spreadsheet provides."
http://opensource.adobe.com/group__asl__overview.html#asl_overview_intro_to_adam_and_eve
________
[bullet] This resolves a problem Fred Brooks identified in 1987: ""The
essence of a software
entity is a construct of interlocking concepts: data sets,
relationships among data items, algorithms,
and invocations of functions... Software systems have
orders-of-magnitude more states than
computers do...a scaling-up of a software entity is not merely a
repetition of the same elements
in larger sizes; it is necessarily an increase in the number of
different elements. In most cases,
the elements interact with each other in some nonlinear fashion, and the
complexity of the whole
increases much more than linearly."
--
http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html
______
[COSI] "The Constraint Sequencing Infrastructure (COSI) is an extension to
the Common Lisp Object System (*(CLOS)) which supports a constraint
based object-oriented programming model. .....
"A constraint is a specialized method which will be automatically
re-run by the COSI infrastructure whenever any of its input values
change. Input values are any of the object attributes that are
accessed by the constraint, and which are therefore assumed to
alter the processing within the constraint.
"Whenever a state change occurs those constraints which depend upon
that state are added to a propagation queue. When the system is
queried a propagation cycle runs ensuring that the state of the
system is consistent with all constraints prior to returning a value."
-- http://www.cliki.net/ACL2/COSI?source
______
[impl] The Cells library as it stands is all about doing interesting things
with slots of CLOS instances, but Cells is not only about CLOS or even
Lisp.
One Cells user is known to have mediated a global variable with a Cell,
some work
was done on having slots of DEFSTRUCTs mediated by Cells, and ports to
C++, Java, and
Python have been explored.
_______
[axiom] Phillip Eby's axiomatic specification of Cells:
Data Pulse Axioms
=================
Overview: updates must be synchronous (all changed cells are updated at
once), consistent (no cell rule sees out of date values), and minimal (only
necessary rules run).
1. Global Update Counter:
There is a global update counter. (Guarantees that there is a
globally-consistent notion of the "time" at which updates occur.)
2. Per-Cell "As Of" Value:
Every cell has a "current-as-of" update count, that is initialized with
a value that is less than the global update count will ever be.
3. Out-of-dateness:
A cell is out of date if its update count is lower than the update
count of any of the cells it depends on.
4. Out-of-date Before:
When a rule-driven cell's value is queried, its rule is only run if the
cell is out of date; otherwise a cached previous value is
returned. (Guarantees that a rule is not run unless its dependencies have
changed since the last time the rule was run.)
5. Up-to-date After:
Once a cell's rule is run (or its value is changed, if it is an input
cell), its update count must be equal to the global update
count. (Guarantees that a rule cannot run more than once per update.)
6. Inputs Move The System Forward
When an input cell changes, it increments the global update count and
stores the new value in its own update count.
Dependency Discovery Axioms
===========================
Overview: cells automatically notice when other cells depend on them, then
notify them at most once if there is a change.
1. Thread-local "current rule cell":
There is a thread-local variable that always contains the cell whose
rule is currently being evaluated in the corresponding thread. This
variable can be empty (e.g. None).
2. "Currentness" Maintenance:
While a cell rule's is being run, the variable described in #1 must be
set to point to the cell whose rule is being run. When the rule is
finished, the variable must be restored to whatever value it had before the
rule began. (Guarantees that cells will be able to tell who is asking for
their values.)
3. Dependency Creation:
When a cell is read, it adds the "currently-being evaluated" cell as a
listener that it will notify of changes.
4. Dependency Creation Order:
New listeners are added only *after* the cell being read has brought
itself up-to-date, and notified any *previous* listeners of the
change. (Ensures that the listening cell does not receive redundant
notification if the listened-to cell has to be brought up-to-date first.)
5. Dependency Minimalism:
A listener should only be added if it does not already present in the
cell's listener collection. (This isn't strictly mandatory, the system
behavior will be correct but inefficient if this requirement isn't met.)
6. Dependency Removal:
Just before a cell's rule is run, it must cease to be a listener for
any other cells. (Guarantees that a dependency from a previous update
cannot trigger an unnecessary repeated calculation.)
7. Dependency Notification
Whenever a cell's value changes (due to a rule change or input change),
it must notify all of its listeners that it has changed, in such a way that
*none* of the listeners are asked to recalculate their value until *all* of
the listeners have first been notified of the change. (This guarantees
that inconsistent views cannot occur.)
7a. Deferred Recalculation
The recalculation of listeners (not the notification of the listeners'
out-of-dateness) must be deferred if a cell's value is currently being
calculated. As soon as there are no cells being calculated, the deferred
recalculations must occur. (This guarantees that in the absence of
circular dependencies, no cell can ask for a value that's in the process of
being calculated.)
8. One-Time Notification Only
A cell's listeners are removed from its listener collection as soon as
they have been notified. In particular, the cell's collection of listeners
must be cleared *before* *any* of the listeners are asked to recalculate
themselves. (This guarantees that listeners reinstated as a side effect of
recalculation will not get a duplicate notification in the current update,
or miss a notification in a future update.)
9. Conversion to Constant
If a cell's rule is run and no dependencies were created, the cell must
become a "constant" cell, and do no further listener additions or
notification, once any necessary notifications to existing listeners are
completed. (That is, if the rule's run changed the cell's value, it must
notify its existing listeners, but then the listener collection must be
cleared -- *again*, in addition to the clearing described in #8.)
10. No Changes During Notification:
It is an error to change an input cell's value while change
notifications are taking place.
11. Weak Notification
Automatically created inter-cell links must not inhibit garbage
collection of either cell. (Technically optional, but very easy to do.)
you could
>> be able to do it.
>>
>
> Well suppose one of my rules is:
>
> (make-instance 'hi-mom
> :x (c? (if (^a) (^b) (^c))))
>
> [(^a) is just shorthand for (a self) (and yes, had I known about
> symbol-macros back then it would just be ^a.]
>
> If A changes from true to false, the dependency graph for x before the
> change will include only A and B, not C. But with A false, I need C to
> be current. So the dependency graph is useless for lookahead.
>
> Before you suggest a lexical lookahead (which still would not work
> because of branching) recall that dependents have dynamic scope: a
> dependency is recorded on any other cell read while calculating the
> value for the dependent, however deep in a call tree.
>
> kt
From: John Thingstad
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <op.uiggbawtut4oq5@pandora.alfanett.no>
P� Fri, 03 Oct 2008 17:16:21 +0200, skrev Patrick May <···@spe.com>:
> Kenny <·········@gmail.com> writes:
>> Man, Chrome rocks. But what about Dojo? They talk a good game, but
>> JQuery Just Works on all the browsers and Dojo...not so much.
>
> Try Flex talking to Hunchentoot. It doesn't suck. I'm still
> working on generating MXML from Lisp, though.
>
Have you looked at XMLisp ?
--------------
John Thingstad
From: Patrick May
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <m2myhkmngk.fsf@spe.com>
"John Thingstad" <·······@online.no> writes:
> P� Fri, 03 Oct 2008 17:16:21 +0200, skrev Patrick May <···@spe.com>:
>> Kenny <·········@gmail.com> writes:
>>> Man, Chrome rocks. But what about Dojo? They talk a good game, but
>>> JQuery Just Works on all the browsers and Dojo...not so much.
>>
>> Try Flex talking to Hunchentoot. It doesn't suck. I'm still
>> working on generating MXML from Lisp, though.
>
> Have you looked at XMLisp ?
No, I thought the Lisp Way was to rewrite from scratch. ;-)
Thanks, I'll take a look at it.
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Kenny
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <48FD67A2.6050800@gmail.com>
[also posted on c.l.l]
Patrick May wrote:
> Kenny <·········@gmail.com> writes:
>
>>Man, Chrome rocks. But what about Dojo? They talk a good game, but
>>JQuery Just Works on all the browsers and Dojo...not so much.
>
>
> Try Flex talking to Hunchentoot. It doesn't suck. I'm still
> working on generating MXML from Lisp, though.
Hmmmm. What if we have a highly dynamic work environment for the user,
such as -- oh, just a wild thought, at random, right out of the blue --
a student working on algebra problems. These are rich structures, not
just strings. That means lots of dynamically generated MXML, IIUC, all
of which has to go through the Flex compiler and... well, this says
"Don't do that!":
http://www.adobe.com/devnet/flex/articles/server_perf_05.html
I like the idea of a mature, rich product and avoiding browser
variation, but...am I missing something? Perhaps you envision a less
dynamically shifting interface widget-wise?
kt
From: Patrick May
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <m2vdvmjd8v.fsf@spe.com>
Kenny <·········@gmail.com> writes:
> Patrick May wrote:
>>>Man, Chrome rocks. But what about Dojo? They talk a good game, but
>>>JQuery Just Works on all the browsers and Dojo...not so much.
>>
>> Try Flex talking to Hunchentoot. It doesn't suck. I'm still
>> working on generating MXML from Lisp, though.
>
> Hmmmm. What if we have a highly dynamic work environment for the user,
> such as -- oh, just a wild thought, at random, right out of the blue
> -- a student working on algebra problems. These are rich structures,
> not just strings. That means lots of dynamically generated MXML, IIUC,
> all of which has to go through the Flex compiler and... well, this
> says "Don't do that!":
>
> http://www.adobe.com/devnet/flex/articles/server_perf_05.html
>
> I like the idea of a mature, rich product and avoiding browser
> variation, but...am I missing something? Perhaps you envision a less
> dynamically shifting interface widget-wise?
Mine is a trading system. As a rule, traders can be quite rude to
programmers, so they don't get fancy GUIs.
Seriously, all I've needed are the usual rich client widgets like
trees, tables, dialog boxes, and charts. I want to generate MXML once,
not dynamically.
That being said, you've got a couple of options with Flex. First,
MXML compiles to ActionScript and integrates well with it, so you can
use parenscript to pass dynamic content after learning a little
ActionScript Fu. Second, and I'm not recommending this, you can use
Flash within your Flex interface.
When will the web version be released? A couple of my kids tried
out the downloadable version, took careful notes, and then turned them
into paper airplanes and lost them.
Good luck,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Kenny
Subject: Re: Vancouver Lisp Users Group meeting for October 2008 - The Nature of Order
Date:
Message-ID: <48fde62b$0$4870$607ed4bc@cv.net>
Patrick May wrote:
> Kenny <·········@gmail.com> writes:
>
>>Patrick May wrote:
>>
>>>>Man, Chrome rocks. But what about Dojo? They talk a good game, but
>>>>JQuery Just Works on all the browsers and Dojo...not so much.
>>>
>>> Try Flex talking to Hunchentoot. It doesn't suck. I'm still
>>>working on generating MXML from Lisp, though.
>>
>>Hmmmm. What if we have a highly dynamic work environment for the user,
>>such as -- oh, just a wild thought, at random, right out of the blue
>>-- a student working on algebra problems. These are rich structures,
>>not just strings. That means lots of dynamically generated MXML, IIUC,
>>all of which has to go through the Flex compiler and... well, this
>>says "Don't do that!":
>>
>> http://www.adobe.com/devnet/flex/articles/server_perf_05.html
>>
>>I like the idea of a mature, rich product and avoiding browser
>>variation, but...am I missing something? Perhaps you envision a less
>>dynamically shifting interface widget-wise?
>
>
> Mine is a trading system. As a rule, traders can be quite rude to
> programmers, so they don't get fancy GUIs.
>
> Seriously, all I've needed are the usual rich client widgets like
> trees, tables, dialog boxes, and charts. I want to generate MXML once,
> not dynamically.
>
> That being said, you've got a couple of options with Flex. First,
> MXML compiles to ActionScript and integrates well with it, so you can
> use parenscript to pass dynamic content after learning a little
> ActionScript Fu.
I am probably going to do nothing *but* JS in Xello, so that does not
sound bad at all. Good news.
Meanwhile, if you have seen me On the Beach, you know how I feel about
widgets so...
> Second, and I'm not recommending this, you can use
> Flash within your Flex interface.
...hell, I have been using OpenGL so far, Flash sounds like a 4GL. Just
gotta check the font support.
> When will the web version be released?
It took a week to create Celtk 1.0 once Peter Herth's LTk showed me how
to pipe Tcl/Tk to wish. So if I fall back on DHTML, a week to get a
Cells model rendering on a client. Then I have to worry about fonts,
playing sounds (I'd hate to give up the sounds)...hmmm, maybe I should
look at ... I think a wild and crazy month should do it.
> A couple of my kids tried
> out the downloadable version, took careful notes, and then turned them
> into paper airplanes and lost them.
Sounds like a success story. I'll need them for my first PR. "Helps kids
realize they should be making paper airplanes instead of grinding out
the formal education paper chase!"
>
> Good luck,
Thx, kxo