Lisp and software architecture
Peter Seibel
programming language on software architecture. I'm thinking about what
the heck I'm going to say and how to turn it into an oppotunity to
brag on Lisp. So if you have any good war stories about how using Lisp
(or any other language for that matter) had an affect on the
architecture of the system you were working on, I'd love to hear
them.
-Peter
[1] April 26th at the Software Architecture and Modeling SIG of
SDForum in Palo Alto
--
Peter Seibel * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Sacha
"Peter Seibel" <pe...@gigamonkeys.com> wrote in message
news:m2d5gxp...@gigamonkeys.com...
> Next month I'm goin to be giving a talk[1] about the effect of
Shouldn't the language be considered as an implementation detail ?
It is my beleif that the architecture is on a different level.
Now this might not hold true for dynamic languages. Until now I only used
c++, c# and delphi for large projects, and these are all alike after all. So
I migh be completely wrong here.
On the other hand, it seems to me that my father was doing OO programming
using bare bone pointers back in the days.
That's a good example of a good concept crossing the language frontiers.
I'm a lisp newbie, freelance programmer working for telephone companies.
There is one thing i made and remade in about every language i worked with :
the telephony pricelist.
Though this looks like a simple task, the thing can be quite involved as my
customers need all the configuration options you could imagine and a lot
more too. It kind of became my benchmark implementation for language
testing.
They say lisp is different, so i'm building yet another pricelist using
lisp.
To say the truth, it looks like it'll eventually be quite the same thing as
my other implementations. Maybe am i too much of a newbie still, but hey
they say another thing : you need to build programs in order to learn =P
By the way I wanted to thank you for your book and even more so for
providing it on the web.
It is a great push toward learning lisp.
Sacha
Wade Humeniuk
> Next month I'm goin to be giving a talk[1] about the effect of
> programming language on software architecture. I'm thinking about what
> the heck I'm going to say and how to turn it into an oppotunity to
> brag on Lisp. So if you have any good war stories about how using Lisp
> (or any other language for that matter) had an affect on the
> architecture of the system you were working on, I'd love to hear
> them.
>
Lists. Lists. Lists.
Lisp has them, now C++ has them, can't live without them.
A program is a list (tree). GUIs have drop-down lists.
Sorted, unsorted. Aircraft are put in queues (lists) for
takeoff. Forget fixed sized arrays, its lists lists
lists, any size, no limits. Variable argument lists make a
function extendable without breaking the callers.
Its the thought that rigidity could be expelled from
those Gothic architectures.
Wade
Christopher Browne
> "Peter Seibel" <pe...@gigamonkeys.com> wrote in message
> news:m2d5gxp...@gigamonkeys.com...
>> Next month I'm goin to be giving a talk[1] about the effect of
>> programming language on software architecture. <snip>
>
> Shouldn't the language be considered as an implementation detail ?
> It is my beleif that the architecture is on a different level.
That's the big question.
The "Sapiran/Whorfian Hypothesis" essentially asserts that the
language that you use determines the shape of the thoughts that you
can form.
That would seem to imply that your language will determine what kind
of architectures you are capable of thinking about.
How true that hypothesis is represents an open question in
linguistics.
I think there can be considerable truth to this notion when it comes
to software architecture.
Someone with very primitive views of computer language will have very
different perspectives on what kinds of architecture are possible as
compared to someone with a "livelier view."
To someone who "thinks in COBOL," the world will have a pretty limited
shape.
Someone that speaks "pretty primitive C" probably sees a bit bigger
world.
Start throwing in extra abstractions, which often have language
implications, and there's more to perceive.
- Language parsing (ala Yacc) adds something
- Objects/data classification adds something
- Sequence manipulation "en masse," whether via reduce, mapcar,
or other languages' approaches (as with APL or SQL) adds something
- Associative arrays adds something
Common Lisp throws in some interesting constructs like places (e.g. -
things to which you can apply SETF), macros, closures.
I'm quite sure this has some impact on what kinds of architectures a
designer can imagine...
--
(format nil "~S@~S" "cbbrowne" "gmail.com")
http://linuxfinances.info/info/slony.html
Why isn't phonetic spelled the way it sounds?
nall...@gmail.com
the fact that Nick Allen has been able to coerce a computer into doing
anything more complex than turn off means that there is something
special about lisp that allows one to perform far beyond the normal
scope of their iq
jk
personally I think Emacs would be a great example of something that
probably couldn't have happened in any other language, though I'm not
sure if the topic's far removed enough to be appropriate.
SQL brings up a lot of issues (IE vs ODBMS or RDBMS written in a
non-declarative language)
I thought the Honda Car Crash System described by Kuroda Hisao in Three
Application Stories using Lisp at ILC05 was pretty awesome, but the
paper's probably unusable terse.
does html count as a language? it's screwed it's fair shair of
architectures up...
I guess you could always bring up the word of things successfully
programmed initially in lisp because the architecture was to big and
untried to be pulled off for the first time in any language...
good luck... er, break a leg... er, a neuron...
Nick
Pascal Costanza
> Next month I'm goin to be giving a talk[1] about the effect of
> programming language on software architecture. I'm thinking about what
> the heck I'm going to say and how to turn it into an oppotunity to
> brag on Lisp. So if you have any good war stories about how using Lisp
> (or any other language for that matter) had an affect on the
> architecture of the system you were working on, I'd love to hear
> them.
Googling for "dynamic software architecture" might give you some ideas.
(The idea is that you can change the architecture at runtime. You could
mention examples where people update, for example, web applications
while they're running.)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Rainer Joswig
Peter Seibel <pe...@gigamonkeys.com> wrote:
> Next month I'm goin to be giving a talk[1] about the effect of
> programming language on software architecture. I'm thinking about what
> the heck I'm going to say and how to turn it into an oppotunity to
> brag on Lisp. So if you have any good war stories about how using Lisp
> (or any other language for that matter) had an affect on the
> architecture of the system you were working on, I'd love to hear
> them.
>
> -Peter
>
> [1] April 26th at the Software Architecture and Modeling SIG of
> SDForum in Palo Alto
I think there are lots of architecture- and Lisp-related topics:
- multiparadigm architectures (rules + objects + constraints + ...)
- very object-oriented architectures
- layered language architectures (objects on the bottom,
then functions, then macros)
- architectures which use exotic (non-mainstream) paradigms
- open architectures (-> Xerox, MIT Lispm)
- Meta-level architectures
- Architecture development (RAD, Prototypes, ...)
- Evolvable architectures
- 'Knowledge-based' systems and their architectures
and probably more...
For all of the above one should be able to find papers/examples.
Ken Tilton
>
>> Next month I'm goin to be giving a talk[1] about the effect of
>> programming language on software architecture. I'm thinking about what
>> the heck I'm going to say and how to turn it into an oppotunity to
>> brag on Lisp. So if you have any good war stories about how using Lisp
>> (or any other language for that matter) had an affect on the
>> architecture of the system you were working on, I'd love to hear
>> them.
Too bad you gave up on Cells at the first backtrace. Cells simply fell
out of an attack on an application problem, turned into a paradigm, took
over the whole application. Would never have happened without
first-class functions, closures, macros, CLOS, untyped variables...
kt
Wade Humeniuk
> I'm a lisp newbie, freelance programmer working for telephone companies.
> There is one thing i made and remade in about every language i worked with :
> the telephony pricelist.
> Though this looks like a simple task, the thing can be quite involved as my
> customers need all the configuration options you could imagine and a lot
> more too. It kind of became my benchmark implementation for language
> testing.
> They say lisp is different, so i'm building yet another pricelist using
> lisp.
> To say the truth, it looks like it'll eventually be quite the same thing as
> my other implementations. Maybe am i too much of a newbie still, but hey
> they say another thing : you need to build programs in order to learn =P
>
How about creating a Pricelist expert language instead? Then your
customers can specify/create/maintain their own "pricelists". Start
with one that has a Lisp syntax and then go from there.
Wade
Simon Brooke
('pe...@gigamonkeys.com') wrote:
> Next month I'm goin to be giving a talk[1] about the effect of
> programming language on software architecture. I'm thinking about what
> the heck I'm going to say and how to turn it into an oppotunity to
> brag on Lisp. So if you have any good war stories about how using Lisp
> (or any other language for that matter) had an affect on the
> architecture of the system you were working on, I'd love to hear
> them.
If you're using any Algol family language, up to and including
Java/C#/C++ etc, or FORTRAN and derivatives, then one of the issues is
data object size. Doing the equivalent of
(* pi (factorial 1000))
in most languages requires not only a lot of special libraries but also a
lot of special syntax. This leads you to think about your problem space
in two's complement 32 or 64 bit integers, and in 32 or 64 bit IEEE 754
encoded reals. That in turn leads you to accept rounding errors as
inevitable, even if they're not. You don't expect the equivalent of
(+ 22/7 1/7)
to return exactly 23/7. You expect rounding error. You say 'it's
inevitable'; you say 'it doesn't matter'.
If you use any statically typed language - Algol family, Fortran family,
any of them - you have to make early commitments to the type of an
object that you don't yet know much about. In Java (and its derivatives)
or C++, for example, you can't at all easily move an object about in the
class hierarchy; the class it was born in, it dies in. There's no social
mobility for objects.
All these things (and many others) limit the way you think about a
problem space. They limit what you can build because they limit what you
can think of.
If this post has been any use to you you might want to look at my
currently developing essay 'Post Scarcity Software', which is here
<URL:http://www.jasmine.org.uk:80/dogfood/story/article_42.html>
--
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
"The result is a language that... not even its mother could
love. Like the camel, Common Lisp is a horse designed by
committee. Camels do have their uses."
;; Scott Fahlman, 7 March 1995
Ken Tilton
> "Peter Seibel" <pe...@gigamonkeys.com> wrote in message
> news:m2d5gxp...@gigamonkeys.com...
>
>>Next month I'm goin to be giving a talk[1] about the effect of
>>programming language on software architecture. <snip>
>
>
> Shouldn't the language be considered as an implementation detail ?
> It is my beleif that the architecture is on a different level.
>
> Now this might not hold true for dynamic languages. Until now I only used
> c++, c# and delphi for large projects, and these are all alike after all. So
> I migh be completely wrong here.
>
> On the other hand, it seems to me that my father was doing OO programming
> using bare bone pointers back in the days.
> That's a good example of a good concept crossing the language frontiers.
>
> I'm a lisp newbie, freelance programmer working for telephone companies.
> There is one thing i made and remade in about every language i worked with :
> the telephony pricelist.
> Though this looks like a simple task, the thing can be quite involved as my
> customers need all the configuration options you could imagine and a lot
> more too. It kind of became my benchmark implementation for language
> testing.
> They say lisp is different, so i'm building yet another pricelist using
> lisp.
> To say the truth, it looks like it'll eventually be quite the same thing as
> my other implementations.
Not after you post it to c.l.l. :)
> Maybe am i too much of a newbie still,...
No, that is not the problem. Many newbies (but not you, it seems) go too
far in straining to do things The Lisp Way. This is good, this is how
one learns something new, breaks the mold: throw oneself into it with
gusto, try to be functional, try to leverage CLOS and macros, yada yada.
> but hey
> they say another thing : you need to build programs in order to learn =P
Building programs will not help you; Lisp is a multi-paradigm language,
so you can write code as if it were C. Which it seems you are. Having
solved the problem several times already, you are just writing the same
code in Lisp. What do you think it is going to look like?
Most newbies in your situation are sharp enough to say, "Hey, my Lisp
code looks just like my C code, what am I doing wrong?" Your grand
conclusion is that Lisp is no different than C. Hmmmmm....
ken
bill...@gmail.com
> [1] April 26th at the Software Architecture and Modeling SIG of
> SDForum in Palo Alto
You might want to consider using a Design Patterns based approach to
showing how the choice of a programming language can affect how you
look at a problem from an architectural and modeling standpoint. This
is something that the SIG will relate to easily. Peter Norvig did this
very effectively in his "Design Patterns in Dynamic Programming"
presentation (http://norvig.com/design-patterns/). Obviously, you won't
want to cover the same ground as Peter did; however, you can mold some
of those ideas into your talk. Richard Gabriel also has a lot of good
material for this type of approach in his _Patterns of Software_ book
(http://www.dreamsongs.com/NewFiles/PatternsOfSoftware.pdf). In fact,
you might want to look at some of his OOPSLA presentations as well.
This approach could also lead into a discussion about how the selection
of a programming language with a high level of abstraction capabilities
changes the requirements for the types of modeling tools that you might
need/want to use. For example, many Java programmers use UML modeling
tools but very few Lisp programmers do.
Another good souce of material for the presentation might be some DSL
examples (e.g. - Rainer Joswig's movie -
http://bc.tech.coop/blog/050711.html). This would reinforce the idea of
how the choice of programming language affects the types of patterns
that the programmer "sees" or uses. Also using DSL's, you might want to
weave in some psychological material about how the choice of a
programming language can subconsciously influence your architectural
design choices (e.g. - things that are "really hard" to do in one
programming language but easy to do in another programming language
result in different architectural approaches being taken in the design
of the solution).
--
Bill Clementson
Peter Seibel
Hey, that's not fair. I didn't give up because I couldn't get it to
run--I gave up long before that, when I couldn't find anything that
explained what it was and why I should care. ;-)
-Peter
Sacha
"Wade Humeniuk" <whumeniu+...@telus.net> wrote in message
news:LTAPf.22801$Ui.8488@edtnps84...
Would you mean something like : lay the data, throw lots of parenthesis
around it, back it up with some code to make it work, then refactor until i
get a usefull, higher level language ?
Or maybe lay the finaly language down then wrap the code around it ?
There was this very nice and quite enlightening DSL video :
http://bc.tech.coop/blog/050711.html
That sure sounds neat, i'll give it a try.
Sacha
Sacha
<snip>
>>, so i'm building yet another pricelist using lisp.
>> To say the truth, it looks like it'll eventually be quite the same thing
>> as my other implementations.
>
> looks just like my C code, what am I doing wrong?" Your grand conclusion
> is that Lisp is no different than C. Hmmmmm....
>
I knew this post would be controversial..
> "Hey, my Lisp code looks just like my C code, what am I doing wrong?"
My post was sort of admiting a failure. Maybe should i tackle something
different, get out of the track, then go back to the price list problem when
i'll be able to make it more idiomatic.
Wade Humeniuk suggested going the DSL path , so i'll give it a try first.
Sacha
Ken Tilton
> Ken Tilton <kent...@gmail.com> writes:
>
>
>>>Peter Seibel wrote:
>>>
>>>
>>>>Next month I'm goin to be giving a talk[1] about the effect of
>>>>programming language on software architecture. I'm thinking about what
>>>>the heck I'm going to say and how to turn it into an oppotunity to
>>>>brag on Lisp. So if you have any good war stories about how using Lisp
>>>>(or any other language for that matter) had an affect on the
>>>>architecture of the system you were working on, I'd love to hear
>>>>them.
>>
>>Too bad you gave up on Cells at the first backtrace. Cells simply fell
>>out of an attack on an application problem, turned into a paradigm,
>>took over the whole application. Would never have happened without
>>first-class functions, closures, macros, CLOS, untyped variables...
>
>
> Hey, that's not fair. I didn't give up because I couldn't get it to
> run--I gave up long before that, when I couldn't find anything that
> explained what it was and why I should care. ;-)
Oh, lord, that is easy. Go to the ActiveState site, they named the whole
frickin company after Cells functionality. Then look at what the Tk
crowd calls "actions"-- that is Tk with its little bit of hardcoded
"active state" trying to let the user hardcode some of what Cells does
automatically. You might also check the Adobe site, look for a white
paper on, I forget, Eve? Same thing, and they apparently are
standardizing on that for future software development.
I also find this tool to be a helpful, you might want to give it a try
for things like this:
Try:
http://www.tilton-technology.com/cells-overview.pdf
Look for:
"1.2 The big picture
Cells support a declarative paradigm in which the motivating force
behind an application’s overall behavior is dataflow through a
dependency graph maintained automatically by the system. The benefits
are several.
• Eliminates the class of bug in which program state is internally
inconsistent.
• A corollary benefit: eliminates the housekeeping burden of keeping
consistent the state dependency graph implicit in any application.
• Makes manifest the state dependency graph implicit in any application.
Actual runtime dependencies can be graphed.
• Program semantics are fully encapsulated by the declarative model; the
rule for a cell defines it completely.
• Cells let us tailor instances with rules, not just literals, making
objects more reusable. For example, some GUI schemes allow widgets to
specify their dimensions with options such as :sticky-left or :fixed or
:elastic-right. With cells you can write any algorithm you like to
decide a widget’s geometry. Furthermore, by arranging instances in a
navigable namespace, those algorithms can draw on arbitrary application
state.
• Divides and conquers application complexity. No cell in even the most
complex spreadsheet touches more than a handful of cells, usually just
one or two. The complex solution emerges from multiple small but
high-quality solutions to small problems. Our experience has been the
same with Cells in application development."
Of course, if you have not done much application programming that will
not make any sense to you. Try reading Fred Brooks's "No Silver Bullet",
in which he explains why software can never be easier to develop than it
was in 1986. In part:
"Digital computers are themselves more complex than most things people
build, they have very large numbers of states....Software systems have
orders of magnitude more states than computers do....In most cases, the
elements interact with each other in some nonlinear fashion, and the
complexity of the whole increases much more than linearly."
You never looked at Cells, so i will tell you: Cells manage state.
Again, if you are just a code monkey and are never given responsibility
for anything more than a subroutine here and there, I understand why
that still makes no sense to you. Brooks continued:
"Many of the classical problems of developing software products derive
from this essential complexity."
This is why anyone can write a ten line program, why you have to learn
how to program to pull off a hundred line program, why most thousand
line programs are horrid, and why most 100kloc projects fail.
Cells fixes that.
Well, even with your father pitching it, it took you twenty years to
become a Lispnik:
http://wiki.alu.org/Peter_Seibel's_Road_to_Lisp
Should we look for a Road to Cells Switch Date of 2028?
:)
ken
ps. Thanks for the fat pitch. :)
Ken Tilton
> <snip>
>
>>>, so i'm building yet another pricelist using lisp.
>>>To say the truth, it looks like it'll eventually be quite the same thing
>>>as my other implementations.
>>
>>Most newbies in your situation are sharp enough to say, "Hey, my Lisp code
>>looks just like my C code, what am I doing wrong?" Your grand conclusion
>>is that Lisp is no different than C. Hmmmmm....
>>
>
>
> I knew this post would be controversial..
>
>
>>"Hey, my Lisp code looks just like my C code, what am I doing wrong?"
>
>
> My post was sort of admiting a failure.
Oh, I saw the "sort of". Too sorty for my taste. :)
> Maybe should i tackle something
> different, get out of the track, then go back to the price list problem when
> i'll be able to make it more idiomatic.
>
> Wade Humeniuk suggested going the DSL path , so i'll give it a try first.
Nah, nobody really writes DSLs. We do what Graham says: build up to the
problem domain with a macro here and a macro there, all swimming around
in straight CL.
You should have listened to my suggestion, if you noticed it. :)
ken
William Bland
>> Next month I'm goin to be giving a talk[1] about the effect of
>> programming language on software architecture. <snip>
>> [1] April 26th at the Software Architecture and Modeling SIG of
>> SDForum in Palo Alto
Excellent - I hope to be able to attend.
> You might want to consider using a Design Patterns based approach to
> showing how the choice of a programming language can affect how you
> look at a problem from an architectural and modeling standpoint.
Agreed. I have often surprised people at work by showing them how some of
the patterns that are needed in Java are actually "built in" to Lisp (or
at least much less hassle to implement there). This does seem to to get
people interested.
> ... the choice of a programming language can subconsciously influence
> your architectural design choices (e.g. - things that are "really hard"
> to do in one programming language but easy to do in another programming
> language result in different architectural approaches being taken in the
> design of the solution).
Absolutely agreed. The biggest difference between me doing Java
architecture and Lisp architecture is that when I'm doing Java, I
constantly discard potential architectures as being too much work to
implement and maintain. When I'm doing Lisp I don't find myself doing
that so much, and I can focus on the more important differences between
potential architectures.
Best wishes,
Bill.
Sacha
> Nah, nobody really writes DSLs. We do what Graham says: build up to the
> problem domain with a macro here and a macro there, all swimming around in
> straight CL.
That was my first idea, and that's how i get something very close to a c++
solution.
> You should have listened to my suggestion, if you noticed it. :)
>
I'm not goind to post my code (too ugly i guess) and ask you guys to do my
home work.
What would be the educational value ?
Anyways, thanks for your time, there's no secret, i need to go back to the
drawing board and work out my RSIs.
Sacha
Tolstoy
the upshot was that SA had little to do with programming languages, or
even the design of software beyond the "we need a database component, a
web component" and so on. Choice of programming language is an
implementation detail.
The class seemed to argue that being a Software Architect was about
politics, persuasion, defining the problem, lining up sponsorship,
providing business justification and analysis, and so on. And, of
course, how to choose implementation technologies that line up well
with all these aspects. (I was shocked. Maybe the term has changed,
at least in corporations above a certain size?)
So, seems like the first thing you should do is define Software
Architecture. Are you talking about how to arrange your code to solve
the problem? Or are you talking about how to solve problems, one part
of which is the actual software? Neither? Both?
My own experience is that projects are very much in flux, design
changes with each phone conference, and time is short, you need to show
something NOW and you need to design that prototype so that it is
reasonably robust, and, above all, easy to change when someone on a
phone call says, "But that's not what I meant at all." My goal is to
create "executable specifications" and lisp kicks ass at that.
Could you figure out how technical choices can affect all the
non-technical aspects of a software project? For instance, getting a
prototype out the door in a few days to show sponsors is much better
than a set of beautifully rendered design documents, or, horrors, some
sort of UML representation.
--Keith
Ken Tilton
>>Nah, nobody really writes DSLs. We do what Graham says: build up to the
>>problem domain with a macro here and a macro there, all swimming around in
>>straight CL.
>
>
> That was my first idea, and that's how i get something very close to a c++
> solution.
>
>
>>You should have listened to my suggestion, if you noticed it. :)
>>
>
>
> I'm not goind to post my code (too ugly i guess)
OK, so now you are not "sort of" taking the blame for writing C in Lisp,
you are taking all the credit. I see growth!
> and ask you guys to do my
> home work.
> What would be the educational value ?
Learning? From experts? We won't do the hard work, just the fun redesign
ideas.
You failed once to break with the past on your own, why not get some
help? There are an awful lot of "thanks, everybody!" posts piling up in
the c.l.l archive.
>
> Anyways, thanks for your time, there's no secret, i need to go back to the
> drawing board and work out my RSIs.
Oh, well. Best of luck. I doubt you will succeed. I mentored an
incredibly good programmer during the Google Summer of Code, but he put
the configuration code in an external BLAH.def text file (with non-Lispy
syntax) which he then opened, read, and parsed in Lisp so his WOMP
engine could handle his BLAH project.
I asked him why he did not just write a defwomp macro? His response was
basically, Doh!
He probably would have gotten there a year later once The Lisp Way sunk in.
Did a whack from the Lisp stick diminish the quality of his
enlightenment? Nah, the suddenness of the realization makes the lesson
stick as well as having the same epiphany after months of living with
external config files.
ken
Matthew D Swank
> ps. Thanks for the fat pitch. :)
When is "Cells III, Cells in 3D" due to be committed?
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Paolo Amoroso
> Agreed. I have often surprised people at work by showing them how some of
> the patterns that are needed in Java are actually "built in" to Lisp (or
> at least much less hassle to implement there). This does seem to to get
> people interested.
I read the GoF patterns book a while back, but I seem to remember that
they explicitly state something like this, and mention Lisp and
Smalltalk as examples of languages requiring less or no patterns.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Ken
Matthew D Swank wrote:
> On Wed, 08 Mar 2006 12:36:03 -0500, Ken Tilton wrote:
>
>
>>ps. Thanks for the fat pitch. :)
>
>
> When is "Cells III, Cells in 3D" due to be committed?
Cells3 was done (enough to let me drive Tk froms Cells), but then I
decided it should go a little further, and am meditating on "further".
Unless someone reports a problem Cells3 would solve I will just let it
gestate. I do not want to have to jump to Cells4 in three weeks and put
tfb and Cells-Gtk thru another round of testing.
Cells in 3D is unknown to me, but could be Cello. I love OpenGL, but I
have a portable retail app to get out and Tk solves a /lot/ of
nitty-gritty stuff Cello has not even dreamed of, natively to boot, so I
am hoping I can get by with Celtk (+ Cells Tk).
ken
Patrick May
> So, seems like the first thing you should do is define Software
> Architecture. Are you talking about how to arrange your code to
> solve the problem? Or are you talking about how to solve problems,
> one part of which is the actual software? Neither? Both?
In addition to the points you've raised, one of the most
important distinctions between architecture and design is that a
software architecture must address non-functional requirements
(performance, resiliency, scalability, extensibility, and all the rest
of the "ilities").
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
p...@spe.com | (C++, Java, Jini, CORBA, UML)
Pascal Bourguignon
> I read the GoF patterns book a while back, but I seem to remember that
> they explicitly state something like this, and mention Lisp and
> Smalltalk as examples of languages requiring less or no patterns.
It's not that Lisp requires less patterns, it's that every macro you
write in lisp IS a pattern!
(Well, but perhaps the simpliest purely syntactic sugar ones).
Also, UML case tools, particularly those that implement rules for
automatic model transformations and which generate automatically the
resulting C++ sources, are not needed either when you write lisp, once
again because you have macros to implement these model transformation
rules, and to generate the final Lisp code.
--
__Pascal Bourguignon__ http://www.informatimago.com/
COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
protons, etc.) comprising this product are exactly the same in every
measurable respect as those used in the products of other
manufacturers, and no claim to the contrary may legitimately be
expressed or implied.
Holger Schauer
> Paolo Amoroso <amo...@mclink.it> writes:
>> I read the GoF patterns book a while back, but I seem to remember that
>> they explicitly state something like this, and mention Lisp and
>> Smalltalk as examples of languages requiring less or no patterns.
I'm reading it right now, and it's "less". They even say quite
concretely which patterns they included in the book which are somewhat
build-in in Lisp/Smalltalk.
> It's not that Lisp requires less patterns, it's that every macro you
> write in lisp IS a pattern!
I don't think that the pattern you have in mind is the kind of
patterns the GoF book talks about. Many aspects of what I've read so
far deal more with how to structure your data and functionality so
that the resulting code becomes quite flexible and maintainable
("encapsulate the concept that varies" seems to be the mantra of the
book). I take that to be quite independent of the language you
actually use.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Ihre Kontinentalfestplatte ist fragmentiert. Möchten Sie
den Assistenten zur Driftbeschleunigung starten?"
-- Andreas Meier in de.alt.sysadmin.recovery
Tayssir John Gabbour
> Cells support a declarative paradigm in which the motivating force
> behind an application's overall behavior is dataflow through a
> dependency graph maintained automatically by the system. The benefits
> are several.
Ironically enough, only this morning I looked at Cells. I suspect it
may be genuinely useful.
Seems the main use is to define constraints between things, and then
simply forget about them, knowing that the constraints will be
maintained without additional thought on your part.
A good exposition is in Jim Veitch's paper [1] where he described a
similar system for Boeing, for modelling planes.
* Showed eager updating of parts of a plane when some other part
affecting it changes.
* Then converted it to lazy updating, so recalculations only happen
when a) you look at the part and b) some other part which affects it
was updated.
[1] "A History and Description of CLOS". Took only few lines of code to
illustrate the concept, though the guy actually uses DO* (ugh). Hmm,
little surprise that the Cadence/Ltk guys seem to be poking around
Cells, I guess, as they work on CAD systems too.
> · Eliminates the class of bug in which program state is internally
> inconsistent.
>
> · A corollary benefit: eliminates the housekeeping burden of keeping
> consistent the state dependency graph implicit in any application.
Maybe a problem is that sounds too technojargony.
Tayssir
Ken Tilton
> Ken Tilton wrote:
>
>>Cells support a declarative paradigm in which the motivating force
>>behind an application's overall behavior is dataflow through a
>>dependency graph maintained automatically by the system. The benefits
>>are several.
>
>
> Ironically enough, only this morning I looked at Cells. I suspect it
> may be genuinely useful.
>
> Seems the main use is to define constraints between things, and then
> simply forget about them, knowing that the constraints will be
> maintained without additional thought on your part.
Right. But the actual constraint languages included, inter alia, partial
and multi-way constraints. I have not needed those so I have not played
with those, tho Cells4 will likely support the non-deterministic thing
that results.
The problem is that the constraint languages proved nearly impossible to
program. I am looking for a productivity aid in conventional
programming, not to search large solution spaces ala the typical good
constraint application.
>
> A good exposition is in Jim Veitch's paper [1] where he described a
> similar system for Boeing, for modelling planes.
The prior (and concurrent) art of Cells is vast.
>
> * Showed eager updating of parts of a plane when some other part
> affecting it changes.
> * Then converted it to lazy updating, so recalculations only happen
> when a) you look at the part and b) some other part which affects it
> was updated.
>
>
> [1] "A History and Description of CLOS". Took only few lines of code to
> illustrate the concept, though the guy actually uses DO* (ugh). Hmm,
> little surprise that the Cadence/Ltk guys seem to be poking around
> Cells, I guess, as they work on CAD systems too.
>
>
>
>>· Eliminates the class of bug in which program state is internally
>>inconsistent.
>>
>>· A corollary benefit: eliminates the housekeeping burden of keeping
>>consistent the state dependency graph implicit in any application.
>
>
> Maybe a problem is that sounds too technojargony.
How about "best thing since sliced bread!"? People get upset if one
sounds like a carnival barker.
Me and the COSI guyhave tried the spreadsheet metaphor, but listeners
invariably respond "Oh, I use Excel, I do not need a spreadsheet."
So it is a lot like Lisp. A few of us know about Lisp/Cells, and use it
to program/managestate, and would not do it any other way given our
druthers, but the rest just slog on ignorantly with
Java/manualstatemanagement until the mindshare reaches a critical mass
and it becomes OK to explore.
kt
Pisin Bootvong
object oriented design than that of Java/C++.
One concept of OO is to "tell object to do something" instead of to
"tell it how to do something".
So instead of saying.
cat.position.x = rat.position.x;
cat.position.y = rat.position.y;
You can do
cat.catch(rat);
But the problem with OO object like C++, Java and C# is that:
"You cannot teach existing object new trick."
In those close-object languages, If you don't have access to the
class's source code, you cannot add method to that class.
So if you want a person to be able to run you probably need to add
helper class.
class PersonTrick {
static void run(Person p){
// Code to manipulate person to make him run via his public
method.
}
}
And the method call becomes awkward as
PersonTrick.run(person);
(Or you can teach this trick in subclass of Person, but that will only
work if you control creation of the object).
But with Ruby/Smalltalk you can add the trcik directly to the class as.
class Person
def run
# code to make I run
end
end
And you call it as
person.run
So you can see how code looks nicer and the method is where it really
belongs.
Since Common Lisp 's generic function is not tied to a single class,
CLOS always support Open class design; you can always add generic
function specialized on third party's class (The only quirk is that
most standard function in CL is not generic function so you can not
specialize those function with your own class).
Ken Tilton
> X-No-Archive:yes
> Ken Tilton wrote:
>
>>Peter Seibel wrote:
>>
>>>Ken Tilton <kent...@gmail.com> writes:
>>>
>>>>Too bad you gave up on Cells at the first backtrace. Cells simply fell
>>>>out of an attack on an application problem, turned into a paradigm,
>>>>took over the whole application. Would never have happened without
>>>>first-class functions, closures, macros, CLOS, untyped variables...
>>>
>>>Hey, that's not fair. I didn't give up because I couldn't get it to
>>>run--I gave up long before that, when I couldn't find anything that
>>>explained what it was and why I should care. ;-)
>
>
> 3 years. Semaphor/Cells was poorly documented;
> there seemed little
> reason to examine it further.
Hang on, I listed several reasons in that doc and quoted them in this
thread. You have not responded to those points, but simply say "bad
doc!". I admit the latter freely, what do you have to say to my points
about Cells being the long-sought Silver Bullet?
If someone brings you cold fusion in a mason jar, are you going to say
"No Pyrex beaker?"?
You and Mr. Seibel stand in curious contrast to Vasilis Margioulas (sp?)
who downloaded Cells, downloaded Celtic (pretty much same as Celtk), saw
how it all worked, decided to see if it would make development easier,
built Cells-Gtk and sent it to me in the middle of the night my time
without asking me one question or even letting me know he existed.
He decided, "Yes", btw.
What does Vasilis have that you lack? I better duck that pitch. :)
No seriously, youse guys are looking for a shrink-wrapped library, and I
freely acknowledge Cells (ne Semaphors until the Savages of c.l.l set
upon me) requires an enthusiastic explorer.
I am exactly the same way. If I /need/ X, I will bang on it and support
groups and even read documentation (sorry, Edi) until it works. If I do
not need it, it better come with an installer. :)
I need all the Silver Bullets I get, apparently you do not.
>
>
>>Oh, lord, that is easy. Go to the ActiveState site, they named the whole
>>frickin company after Cells functionality.
>
>
> http://www.google.com/search?hl=en&lr=&q=cells+SITE%3AActiveState.com&btnG=Search
> comes up empty, an extraordinary thing on Google!-) Please tell us
> what "Cells functionality" has to do with the ActiveState site.
I did. Here let me help. I will take your own reply and delete the span
of sentences across which your attention could not, well, span:
>>>Oh, lord, that is easy. Go to the ActiveState site, they named the whole
>>>frickin company after Cells functionality.
....snip...
>>>You never looked at Cells, so i will tell you: Cells manage state.
Of course if you have chimed in just to abuse me, you probably still do
not get it. Or maybe you do not know where is the "active state" in Tk?
Uhh, you get to tell a widget a "variable" to track. Then when you
change the variable (in any which way), the widget reacts sensibly to
the change. The alternative is for the programmer to carry that burden:
"Oh, gee, I just changed X. I happen to recall that widget Y reflects in
some way the value of X. I must tell widget Y to update itself. Oh, and
then there is this menu item M that is available only when Y...".
If you are yawning, you /are/ just here to abuse me. :)
>
>
>>I also find this tool to be a helpful, you might want to give it a try
>>for things like this:
>> http://www.google.com/
>
>
> cf., above.
>
>
>>Try:
>> http://www.tilton-technology.com/cells-overview.pdf
>
>
> This document is great...
Oh great, now I am hearing things. :)
>... but was apparently posted on July 2, 2003:
> http://web.archive.org/web/*/http://www.tilton-technology.com/cells-overview.pdf
> But you were already posting about Semaphor/Cells (in one form or
> another) prior to October, 2000, e.g.,
So the complaint is tardiness? That is why you have not tried a Silver
Bullet? Reminds me of why I lost interest in open source.
> http://groups.google.com/group/comp.lang.lisp/msg/0a1564e6719bbbce?dmode=source&hl=en
> There you called it "Semaphors". Later the name changed to "Cells":
> http://groups.google.com/group/comp.lang.lisp/msg/97297a72116fede6?dmode=source&hl=en
>
> So decent Cells documentation was slow to appear. Today your site links
> to a "Cells tutorial" at Bill Clementson's blog but the link is broken.
> It should probably be http://bc.tech.coop/blog/030911.html
OK, you found it and make absolutely no comment on the actual
functionality of Cells, merely rant on about tardiness. Which is my
point above, you are not /really/ interested in Cells. That is why the
doc seems so bad. You are blaming me for your own approach to the project.
>
>
>>You never looked at Cells, so i will tell you: Cells manage state.
>
>
> Hey, people looked! "Semaphor"/"Cells" documentation was poor to
> nonexistent. (BTW did you _pay_ someone else to write that PDF, above?
> The "author:" tag is blank!8-))
>
>
>>Well, even with your father pitching it, it took you twenty years to
>>become a Lispnik:
>> http://wiki.alu.org/Peter_Seibel's_Road_to_Lisp
>>Should we look for a Road to Cells Switch Date of 2028?
>>:)
>
>
> Unfair (along with "code monkey" comment).
You are unaware that Mr. Seibel jokingly refers to himself as Javamonkey.
btw, I am serious, not putting anyone down. If one does not have to
develop applications with a significant amount of long-lived,
interdependent state, usually something that arises when one must
process an unpredictable stream of related data and maintain therefrom a
coherent model of everything that has transpired (a common example being
a GUI application in which the user types this then clicks here and
wants a complex drawing or document to result), then one likely cannot
understand the advantage of managed state.
You know, the first person Bricklin and ??? showed VisiCalc to said "So
what?". That was another programmer, I think. The second was someone who
did finance and so did spreadsheets on paper. He wanted to buy their
company. Something like that.
> Mr. Siebel surely deserves
> at least another 2 years (the time to post decent Cells documentation).
>
>
>>ps. Thanks for the fat pitch. :)
>
>
> Looked like a strike (swing and a miss) from here.
The flamewar is of little interest compared with the possibility that
there might be a better way to program complex applications. Nothing you
have written shows that you have actually tried Cells in a toy
application to see if I am right, so I am afraid my friend that you are
not even in the ballpark. Which might explain your umpiring.
You know what is funny? You do not even realize that you are not arguing
with me, you are arguing with the history of programming. The prior art
goes back to 1963 and a draw program called Sketchpad that included what
might be the first implementation of constraints. It continues to today
(literally, at 1:43PM EST), when a friend wrote to ask about the broken
Clementson link, telling me a co-worker had just re-invented Cells. In
between we have the KR system in Garnet, and the non-open COSI project
presented at LUGM '99. I hesitate to mention the entire constraints
research programme (kicked off in the 80s by our own Guy Steele's
computer language cum PhD thesis "A Constraint Programming Language")
which continues to today, because they IMO went a bridge too far with
multiway and partial constraints and ended up with unprogrammable
systems. But the spirit is the same: the automatic management of complex
interdependent states given only declarative rules the system must
enforce. Translating for Tayssir, "It is the cat's meow." :)
Thanks for the intentional pass[1], but next time try to say something
/substantive/ about Cells or the more general concept of constraints,
don't just whine about tardy doc. Intentional passes are boring to watch.
:)
ken
ps. In Steele's early 80s paper he marvels that something as wonderful
as constraints did not catch on after Sketchpad/63. Twenty years they
still have not caught on. The only difference is that, after exchanges
like this, I am not at all surprised. :)
[1] In baseball, a fat pitch is a fastball out over the plate, very easy
to hit out of the park. Pitchers in winning situations have been known
to do this to baseball legends in their last at bat before retirement.
An intentional pass is everyone standing around while the pitcher throws
four balls deliberately out of the strike zone (allowing the batter to
take first base uncontested) because he does not want to give the batter
a chance to hit the ball. k
bradb
from http://common-lisp.net/project/cells/ & tried to follow the cells
basic tutorial & Bill's tutorial.
I have a problem though, no where in the cells source directory can I
find a definition for the DEF-C-ECHO macro.
Am I missing something blindingly obvious? Or is Cells ment to be
installed someother way? ASDF-INSTALL failed (crashed) on a recentish
SBCL. Should I try to install from CVS?
Kenny, your post inspired me to look past the lack of documentation
(examples and docs within the package acutally do look pretty good),
but so far I've had no luck getting any traction well using cells.
Cheers
Brad
Ken Tilton
> Your energetic post got me interested in Cells, so I downloaded the tgz
> from http://common-lisp.net/project/cells/ & tried to follow the cells
> basic tutorial & Bill's tutorial.
> I have a problem though, no where in the cells source directory can I
> find a definition for the DEF-C-ECHO macro.
> Am I missing something blindingly obvious?
No, I did a second version of Cells and changed def-c-echo to
def-c-output. That name is not working out either, look for it to become:
def-slot-change-handler
... or something similarly uninterpretive. But for now you will likely
find it at the end of propagate.lisp. The arguments and functionality
are unchanged, so you can just do a global replace on any examples you find.
> Or is Cells ment to be
> installed someother way? ASDF-INSTALL failed (crashed) on a recentish
> SBCL. Should I try to install from CVS?
>
> Kenny, your post inspired me to look past the lack of documentation
> (examples and docs within the package acutally do look pretty good),
yeah, I got pretty chatty in commenting some of the test code, and I
usually recommend that to people who bother to ask.
> but so far I've had no luck getting any traction well using cells.
If you have any GUI stuff to do I could send you Cells3 when it
stabilizes. It will include Celtk as a demo app. Still no doc, just a
test function that exercises every Tk widget and makes the state even
more active <g> using Cells.
ken
bill...@gmail.com
> installed someother way? ASDF-INSTALL failed (crashed) on a recentish
> SBCL. Should I try to install from CVS?
I'm always surprised when I hear of people having trouble installing
cells. Every time I've tried it, it's worked first time. I just tried
it again with both OpenMCL and SBCL and it worked fine on both of those
implementations. Basically, all I did was:
1. (asdf-install:install :cells) ; take the '0' debugger option if you
need to bypass gpg key checking
2. create a symlink to the cells directory (for some reason
asdf-install didn't do this) or cd to the cells directory
3. (asdf:oos 'asdf:load-op :cells)
4. (asdf:oos 'asdf:load-op :cells-test)
This last statement loads & runs all the test programs in the cells
test directory, so you'll get a lot sample output as well. I did steps
1-4 with OpenMCL (v1.0) and steps 3-4 (since I already had cells
installed) with SBCL (v0.9.6). These steps don't differ from how I
would install any other lisp library, so I'm surprised that you're
encountering problems.
--
Bill Clementson
Paolo Amoroso
> thread. You have not responded to those points, but simply say "bad
> doc!". I admit the latter freely, what do you have to say to my points
Incidentally, the best documentation for Cells may be that of
Garnet/KR. Reading this material is enough to understand what Cells
is about, and it can be picked up from the several examples in a
matter of hours.
Folks, especially novices: do check Lisp source code. You may be
surprised at how much you understand.
Thomas F. Burdick
> Your energetic post got me interested in Cells, so I downloaded the tgz
> from http://common-lisp.net/project/cells/ & tried to follow the cells
> basic tutorial & Bill's tutorial.
> I have a problem though, no where in the cells source directory can I
> find a definition for the DEF-C-ECHO macro.
> Am I missing something blindingly obvious? Or is Cells ment to be
> installed someother way? ASDF-INSTALL failed (crashed) on a recentish
> SBCL. Should I try to install from CVS?
Cells definately works with recent SBCLs, as that's what I use. I
keep intending to make a new release, as CVS does contain some (rather
obscure) bug fixes, so CVS isn't a bad idea.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Ken Tilton
> X-No-Archive:yes
> Ken Tilton wrote:
>
>>goat_ro...@yahoo.com wrote:
>>
>>>X-No-Archive:yes
>>>Ken Tilton wrote:
>>>
>>>
>>>>Peter Seibel wrote:
>>>>
>>>>
>>>>>Ken Tilton <kent...@gmail.com> writes:
>>>>>
>>>>>
>>>>>>Too bad you gave up on Cells at the first backtrace. Cells simply fell
>>>>>>out of an attack on an application problem, turned into a paradigm,
>>>>>>took over the whole application. Would never have happened without
>>>>>>first-class functions, closures, macros, CLOS, untyped variables...
>
>
> indicating Kenny-knows-what!
... unhygienic variable capture, special variables, non-standard method
combination....
> I admit the latter freely, what do you have to say to my points
>
>>about Cells being the long-sought Silver Bullet?
>
>
> Sorry, I can't speak to that: I haven't tried it.
Nonsense. I listed some of the prior art, some of which you knew. Tell
us the implications you see, if any, of automatic management of
long-lived, interdependent state. I will make it easy for you: how did
Visicalc improve on paper spreadsheets? And remember, this is why Brooks
said a Silver Bullet was impossible.
Or are you actually not interested at all in programming?
>
>
>>If someone brings you cold fusion in a mason jar, are you going to say
>>"No Pyrex beaker?"?
>
>
> No, I would run away yelling "No lead beaker?"
<g>
> And FWIW I have a well-worn copy of Sutherland's dissertation,
> "SKETCHPAD, A MAN-MACHINE GRAPHICAL COMMUNICATION SYSTEM" not 4 feet
> away to my left
Awesome. Just googled it. Thanks. Never saw that before.
> (I could pick it out of my bookshelves blindfolded).
> I've read it no less than 3 times over the years.
Three times?! There is the problem. You like to read doc. I like to
write code. We better call the whole thing off.
> It is very
> well-written and easy to understand. He wrote it _before_ he received
> his Ph.D.
As if! "This paper is based in part on a thesis submitted to the
Department of Electrical Engineering, M.I.T., in partial fulfillment of
the requirements for the Degree of Doctor of Philosophy."
> If you write documentation as clearly as Sutherland did and publish it
> with your code then people will more willingly accept your products.
Look, Sutherland /had/ to write his thesis. His whole frickin'
publish-or-perish career depended on the paper: "Reprinted from
proceedings of the AFIPS Spring Joint Computer Conference, Detroit,
Michigan, May 21-23, 1963, pp. 329-346."
Hope you did not send your shirts out.*
ken
* Adding insult to injury, when a baseball player learns they have been
sent down to the minor leagues for bad performance and must be on the
bus in a few hours to join the lowly new team, sometimes it so happens
they just sent their shirts to the cleaners (to be picked up in three
days--doh!).
bradb
lucky, you might even get a patch against the documentation :)
Brad
bradb
Cheers
Brad
Ken Tilton
> No luck with the demos, sorry. Now the function CV is undefined.
Help us help you help us to help you. :)
I really really think you are running demo code developed under Cells I
using the Cells II package. CV became C-IN or C-INPUT for the
terseness-challenged.
Any code in any doc I recall would be Cells I code, since I have not
written any doc since Cells I.
(a) Post the code
(b) Tell us where you got it
(c) Tell us if (cells::test-cells) runs to completion
(d) Consider asking on the Cells list (tho I think we are close to
nailing this)
kt
Ken Tilton
>>write code.
>
>
> I read any documentation I believe is useful. I try to write
> documentation before writing code. As code changes I update the
> documentation. Writing, whether code or documentation, helps clarify my
> ideas.
I see. You are weak at solving problems over the keyboard. Documentation
and re-documentation is the only way you can build interesting software.
As a consequence, all your code is documented, however slowly it is
produced. Your feature turns out to be a bug.
I prefer the "code as design" school of thought.
http://www.developerdotstar.com/mag/articles/reeves_design_main.html
The Cells code /is/ my frickin documentation. (Just thought of that one.
<g>)
I imagine Messrs. Burdick and Margioulas got the stupid stuff to run
(meaning the regression test suite), then looked at the regression test
code and thought "WTF is C? and HTH does it work?". Then they did "find
definition" and... read the design.
That's my story and I am sticking to it.
kt
bradb
http://www.tilton-technology.com/01-Cell-basics.lisp and
http://bc.tech.coop/blog/030911.html
c) (cells::test-cells) appears to run properly and returns NIL
d) Probably a good idea, I have stolen a bit of the thread here.
I really does look like I am using example code that doesn't map to the
library version :(
It would be really nice if the basic cells tutorial lived in CVS
somewhere & was part of the test suite. It would also be nice if you
could get the cells library from CVS without needing to get other bits
and pieces.
Cheers
Brad
Ken Tilton
> a & b) The example code is from
> http://www.tilton-technology.com/01-Cell-basics.lisp and
> http://bc.tech.coop/blog/030911.html
> c) (cells::test-cells) appears to run properly and returns NIL
> d) Probably a good idea, I have stolen a bit of the thread here.
>
> I really does look like I am using example code that doesn't map to the
> library version :(
> It would be really nice if the basic cells tutorial lived in CVS
Too easy. :) OK, you mean "01-cells-basics.lisp" included on the site? I
will pull that into the next release. Thanks for a good idea.
> somewhere & was part of the test suite. It would also be nice if you
> could get the cells library from CVS without needing to get other bits
> and pieces.
Which were they? I made my own personal suite of CL utilities into a
subdirectory of Cells just to avoid this.
kt
Ken Tilton
> a & b) The example code is from
> http://www.tilton-technology.com/01-Cell-basics.lisp and
Oh, sorry, you said that. OK, I will add this to the Cells source tree
and update.
> http://bc.tech.coop/blog/030911.html
I have also updated the web page link to point to Bill's write-up. Of
course that is still Cells I code.
I will write to Bill and ask if I can pull that into my source tree
along with his comments and then update it to fit cells, well, cells3.
thx for the report.
kt
bradb
> subdirectory of Cells just to avoid this.
>
Actually, you're right there is a link to CVS from here
http://common-lisp.net/project/cells/. I use CVS all the time, but
what I don't usually do is pull from repos. Most Sourceforge pages
have the exact command that you need in order to get the latest CVS, in
your case this is (I think) cvs -z3 -d
:pserver:anonymous:anon...@common-lisp.net:/project/cells/cvsroot co
cell-cultures/cells. It would be nice to have that somewhere on the
main page to ease CVS access.
Though that puts cells into cell-cultures/cells, which isn't _really_
what I want.
Cheers
Brad
Edi Weitz
> It would be nice to have that somewhere on the main page to ease CVS
> access.
<http://common-lisp.net/faq.shtml>
--
European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
Ken Tilton
>>Which were they? I made my own personal suite of CL utilities into a
>>subdirectory of Cells just to avoid this.
>>
>
>
> Actually, you're right there is a link to CVS from here
> http://common-lisp.net/project/cells/. I use CVS all the time, but
> what I don't usually do is pull from repos. Most Sourceforge pages
> have the exact command that you need in order to get the latest CVS, in
> your case this is (I think) cvs -z3 -d
> :pserver:anonymous:anon...@common-lisp.net:/project/cells/cvsroot co
> cell-cultures/cells. It would be nice to have that somewhere on the
> main page to ease CVS access.
Actually, I think c-l.net has the advantage over SourceForge here with
nightly tarballs, so no one has to study the CVS /language/ just to get
a little source.
But you do have to know to scroll down to find the little "download
tarball" link.
Of course if you want to /track/ an active project one, well, I use
TortoiseCVS so I /still/ do not need to learn CVS.
ken
bradb
because I've used that view cvs interface a bit before, I guess you
very quickly filter stuff out :)
Brad
Tayssir John Gabbour
> No luck with the demos, sorry. Now the function CV is undefined.
Does anyone else have problems with DEF-C-OUTPUT? Its OLD-VALUE always
reporting NIL to me... but that doesn't make sense; I expect it to hold
whatever the last slot value was.
Adapted from cells-test/hello-world.test (I tried both latest CVS Cells
and the tarball, with SBCL PPC Darwin 0.9.9):
(use-package :cells)
(use-package :utils-kt)
(defmodel computer ()
((happen :cell :ephemeral :initform (c-in nil) :accessor happen)
(location :cell t
:initform (c? (case (^happen)
(:leave :away)
(:arrive :at-home)
(t .cache))) ;; ie, unchanged
:accessor location)
(response :cell :ephemeral
:initform nil
:initarg :response
:accessor response)))
(macrolet ((fmt (name)
`(format t
"~%~A: ~15A (previously ~:[an unbound ~A~;~A~])"
,name new-value old-value-boundp old-value)))
(def-c-output response () (fmt "response"))
(def-c-output happen () (fmt "happen "))
(def-c-output location () (fmt "location")))
(defun hello-world ()
(let ((dell (make-be 'computer
:response (c? (bwhen (h (happen self))
(if (eql (^location) :at-home)
(case h
(:knock-knock "who's
there?")
(:world "hello, world."))
"<silence>"))))))
(dotimes (n 2)
(setf (happen dell) :knock-knock))
(setf (happen dell) :arrive)
(setf (happen dell) :knock-knock)
(setf (happen dell) :world)
(values)))
CL-USER> (hello-world)
happen : NIL (previously an unbound NIL)
location: NIL (previously NIL)
response: NIL (previously NIL)
happen : KNOCK-KNOCK (previously NIL)
response: <silence> (previously NIL)
happen : KNOCK-KNOCK (previously NIL)
response: <silence> (previously NIL)
happen : ARRIVE (previously NIL)
location: AT-HOME (previously NIL)
happen : KNOCK-KNOCK (previously NIL)
response: who's there? (previously NIL)
happen : WORLD (previously NIL)
response: hello, world. (previously NIL)
; No value
Ken Tilton
> bradb wrote:
>
>>No luck with the demos, sorry. Now the function CV is undefined.
>
>
> Does anyone else have problems with DEF-C-OUTPUT? Its OLD-VALUE always
> reporting NIL to me...
That just happens to be the case, partly because it is a silly example,
mostly because most of the slots are ephemeral, which are actually not
the norm in real world programming.
The silly example has the location start out as neither :at-home nor
:away, but instead nil. Hell, I'll go so far as to call that a bug since
that is not a sensible location. I should probably have it be :at-home
if nothing has yet transpired, but the example wants the system to be
away for the first few knocks. And so it goes. :)
if you add (setf (happen dell) :leave) you should see the location
output go from :at-home to :away.
As for ephemerals, oddly enough, Cells being good at modelling
long-lived state created a problem: how does one model events, which
happen but then are no more?
Ask on the Cells list and I will expand further on why events must be
handled differently, but ephemerals are how I hacked events into the
paradigm: slots specified as ephemeral revert to nil immediately after
propagating any non-nil value they assume, but not as a state change
seen by the model.
> but that doesn't make sense; I expect it to hold
> whatever the last slot value was.
Yep. Ephemerals are the oddball in this regard.
ken
Frank Buss
> Actually, I think c-l.net has the advantage over SourceForge here with
> nightly tarballs, so no one has to study the CVS /language/ just to get
> a little source.
SourceForge has nightly tarballs, too:
http://sourceforge.net/docs/E04/#nightly_tarballs
But it is different from c-l.net: It is a backup of the repository itself,
with all versions included. The same is possible with rsync read-only
access to the subversion repository.
But I don't see the advantage to download the head revision of all files in
CVS or SVN. If you are a developer and you want the latest source, use
checkout and then only bandwith saving updates. If you can't install a SVN
or CVS client, you are not a developer :-)
If you are a more normal user, then use official releases, only.
> Of course if you want to /track/ an active project one, well, I use
> TortoiseCVS so I /still/ do not need to learn CVS.
There is not much to learn for CVS or SVN, if you just want to track an
active project: an initial checkout (e.g. "svn co
https://svn.sourceforge.net/svnroot/lispbuilder lispbuilder" for the Common
Lisp Application Builder project at http://sf.net/projects/lispbuilder )
and a "svn up" (started in the project directory, no other options are
needed) everytime you want to be up-to-date is sufficient. Same with cvs,
only the path for the "co" command is different.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Ken Tilton
> Ken Tilton wrote:
>
>
>>Actually, I think c-l.net has the advantage over SourceForge here with
>>nightly tarballs, so no one has to study the CVS /language/ just to get
>>a little source.
>
>
> SourceForge has nightly tarballs, too:
>
> http://sourceforge.net/docs/E04/#nightly_tarballs
>
> But it is different from c-l.net: It is a backup of the repository itself,
> with all versions included. The same is possible with rsync read-only
> access to the subversion repository.
>
> But I don't see the advantage to download the head revision of all files in
> CVS or SVN. If you are a developer and you want the latest source, use
> checkout and then only bandwith saving updates. If you can't install a SVN
> or CVS client, you are not a developer :-)
You have been using that crap too long if you think software needs to be
that obtuse.
:)
ken
Frank Buss
> You have been using that crap too long if you think software needs to be
> that obtuse.
Do you have an alternative? With SVN it is even easier to do version
management than with CVS, which I've used for many projects. And I have
used other version management systems, like Continuus and ClearCase and
compared to CVS they were constantly in the way of my workflow :-)
Ken Tilton
> Ken Tilton wrote:
>
>
>>You have been using that crap too long if you think software needs to be
>>that obtuse.
>
>
> Do you have an alternative? With SVN it is even easier to do version
> management than with CVS, which I've used for many projects. And I have
> used other version management systems, like Continuus and ClearCase and
> compared to CVS they were constantly in the way of my workflow :-)
>
(a) I can only tell you what I have heard, first that Subversion was
better, then something else even betterer which I forget.
(b) My larger point is that TortoiseCVS managed somehow to be
user-friendly while sitting atop CVS. I suppose that under extreme
circumstances everything in CVS can find a use, the design mistake was
not making simple things simple. Like TortoiseCVS did.
kt
Tayssir John Gabbour
> Tayssir John Gabbour wrote:
> > Does anyone else have problems with DEF-C-OUTPUT? Its OLD-VALUE always
> > reporting NIL to me...
>
> That just happens to be the case, partly because it is a silly example,
> mostly because most of the slots are ephemeral, which are actually not
> the norm in real world programming.
Aaah, yes that makes sense. My understanding is that with discrete
processes, we basically have a choice between cells being T or
:ephemeral ("states" and "events").
And :delta seems to be absent from your sourcetree, which makes sense
too.
Do you think it would be an improvement to have :cell T by default, and
if you want to cause an event, you'd do something other than setting
the slot-value? Like:
(setf (happens obj) :new-state) ;stays :new-state until changed
(eventf (happens obj) :new-event) ;reverts to initform immediately
Incidentally, if anyone could clarify a couple quick questions I'd be
grateful:
* So, cells only update other cells in their own object instance (not
even cells allocated as :class)? Which means a cell in one object has
to explicitly set another object's c-in cell?
* What other notable vars are there, like .cache and the ^slotnames?
Thanks,
Tayssir
Ken Tilton
> Ken Tilton wrote:
>
>>Tayssir John Gabbour wrote:
>>
>>>Does anyone else have problems with DEF-C-OUTPUT? Its OLD-VALUE always
>>>reporting NIL to me...
>>
>>That just happens to be the case, partly because it is a silly example,
>>mostly because most of the slots are ephemeral, which are actually not
>>the norm in real world programming.
>
>
> Aaah, yes that makes sense. My understanding is that with discrete
> processes, we basically have a choice between cells being T or
> :ephemeral ("states" and "events").
>
> And :delta seems to be absent from your sourcetree, which makes sense
> too.
That is either vestigial or will be resurrected if it ever comes up
again. I honestly forget if I found :delta slots were obsoleted by
synapses or closures or something, and it is too late to figure out now.
The idea was to have, say, consecutive (setf (foo bar) 42) forms
propagate each time, but then:
(setf (foo bar) 0)
..not propagate at all. Kind of a second-order thang. This came up in a
physics simulation, of a pendulum, IIRC.
>
> Do you think it would be an improvement to have :cell T by default,
? It is. Do you mean eliminate the :ephemeral alternative? I will guess
yes based on the next:
> and
> if you want to cause an event, you'd do something other than setting
> the slot-value? Like:
> (setf (happens obj) :new-state) ;stays :new-state until changed
> (eventf (happens obj) :new-event) ;reverts to initform immediately
No. Eventhood (if you will) is an attribute of the slot, so the slot
should always behave eventishly. :)
Likewise outputs (ne echos, defined by def-c-output) are GFs specialized
on the slot-name (and class and new and old values, but the point is
that, unlike the rules one associates with a slot, they cannot be varied
instance by instance.
>
>
> Incidentally, if anyone could clarify a couple quick questions I'd be
> grateful:
>
> * So, cells only update other cells in their own object instance (not
> even cells allocated as :class)?
No. And, not to quibble, I would say cells can depend on cells of any
instance (so, yes, propagation (updating, as you say) can flow between
cells of different instances).
> Which means a cell in one object has
> to explicitly set another object's c-in cell?
You have been looking at the Cells-Gtk code, haven't you? :) SETFs of
c-ins are rampant there. They are the equivalent of GOTOs, and largely
defeat the declarative quality Cells provides.
It is probably my fault. I used that trick to deal with circularities
when in a weak moment i decided it was simpler than having a mechanism
in Cells to deal with cycles. I do not think I will ever ban the trick
outright, but I will always be looking for an excuse to do so. :) Cells3
at least forces one to wrap such behavior in a "mother, may I?" macro.
>
> * What other notable vars are there, like .cache and the ^slotnames?
self, .cause (if that is still working <g>), and .parent, though the
last two are just symbol macros you can track down.
ken
Thomas F. Burdick
> > Which were they? I made my own personal suite of CL utilities into a
> > subdirectory of Cells just to avoid this.
> >
>
> Actually, you're right there is a link to CVS from here
> http://common-lisp.net/project/cells/. I use CVS all the time, but
> what I don't usually do is pull from repos. Most Sourceforge pages
> have the exact command that you need in order to get the latest CVS, in
> your case this is (I think) cvs -z3 -d
> :pserver:anonymous:anon...@common-lisp.net:/project/cells/cvsroot co
> cell-cultures/cells. It would be nice to have that somewhere on the
> main page to ease CVS access.
Oops, I hear some maintenance work calling. Use this command instead:
cvs -z3 -d :pserver:anonymous:anon...@common-lisp.net:/project/cells/cvsroot co cells
The cells-cultures stuff isn't how things are organized anymore.
Ken Tilton
> X-No-Archive:yes
> Ken Tilton wrote:
>
>>I see. You are weak at solving problems over the keyboard. Documentation
>>and re-documentation is the only way you can build interesting software.
>>As a consequence, all your code is documented, however slowly it is
>>produced. Your feature turns out to be a bug.
>
>
How witty, mirroring my flame. <yawn> Get your own style.
> You are weak at solving problems by thinking. Hacking and
> re-hacking code randomly is the only way you can build software.
You don't like monkeys?
> As a
> consequence, none your code is documented, however slowly it is
> produced. Your bug turns out to be a feature.
I don't know, it sounds like we both go through the same exploratory
process since you confess to having to go back and re-document when you
realize the design arising from your original effort needed more work.
ie, the documentation you write and re-write does not actually produce
good design, it just lets you think slower. I understand, I need that,
too, on rare occasions.
What I do not understand is how your approach works in the best
applications of Lisp, when, as Graham says, we are not even sure what
kind of program we are writing. Do you just keep writing documentation
and (peeking ahead) doing math formulae and symbolic logic until you
know? Gosh.
>
> One such programmer was preparing a new system feature for a
> convention. While working late one evening he described his problem. I
> immediately recognized and explained the solution, a simple algebraic
> transformation requiring at most 20 LOC. But he was very poor at math
> and could not understand.
I can identify with him. We are not smart like you. I am just a simple
applications guy. Stalled a wing in Calc III.
> Instead he worked an 80-hour week "changing
> the code until it works" (his words).
Can you possibly be unaware of Tilton's Law? "That code works signifies
nothing."
> He was still hacking code at the
> convention. He claimed to have succeeded just before the doors opened.
>
> When first hired he appeared to be an extremely hardworking individual.
> We soon realized he was little more than a human random code generator.
>
> Documentation written by such programmers is useless since they do not
> understand their code.
Well, there are monkeys and then there are monkeys. My secret weapon is
my lack of intelligence. If I cannot understand my code (more likely if
it becomes painful to live with) I change it. That is trick number one.
Trick number two: every change must lead to more code being deleted than
new code is written. Bonus points for every clarifying comment that can
be deleted because the clarifyee gets deleted.
But you do remind me of the project when I worked with a bunch of brits
who thought they were better than everyone. Typical yobs. One of them
finally complimented me for always being able to solve problems, even
when everyone else was stumped. I responded that I just kept trying
different things until something worked, at which point one them
startled us all by shouting, "That's right!". Like you he was deeply
resentful that anything less than an anal-retentive, theoretically
founded, tediously documented, correctness proven, UML diagrammed,
change controlled approach could succeed.
The exercise left for the reader is exactly how not planning prevails
where planning fails. Compare and contrast Grant vs. McClellan, Patton
vs. Montgomery, and Reinhold Messner vs. seige mountaineering.
Happily, we have come full circle and are back on topic. How does Lisp
affect software architecture? Lisp is so expressive that we can design
over the keyboard. We are programming at a higher level, sometimes with
awesome tools such as DEFMACRO, sometimes just because we have this vast
library of utilities polished by almost fifty years of use, and always
because we do not have to fuss endlessly with static typing. That means
we can reach for the stars in our designs, and the resulting
applications reflect it. They themselves become meta-applications or,
with Foderaro, programmable applications.
All flamewar fun aside, thanks for looking so closely at Cells. I know
literate programming is not "heavy commenting", but I am pretending I
never heard that and the code is at least getting surrounded by a lot of
discussion. But only as sections get re-visited, so you still might
hate it.
kt
Tayssir John Gabbour
> Tayssir John Gabbour wrote:
> > * So, cells only update other cells in their own object instance (not
> > even cells allocated as :class)?
>
> No. And, not to quibble, I would say cells can depend on cells of any
> instance (so, yes, propagation (updating, as you say) can flow between
> cells of different instances).
Ok, now it make a lot more sense. It seems that the way you determine
whether cell-1 depends on cell-2 is IFF cell-1 looked at cell-2 the
last time cell-1's c? code ran.
Shneaky shneaky. (If true.)
Thanks,
Tayssir
Ken Tilton
Yes. So dependencies will vary after every invocation of, say:
(c? (if (^a)(^b)(^c)))
between A and B or A and C.
Interestingly, this means inelegant code can create problems:
(c? (let ((b (^b))(c (^c)))
(if (^a) b c)))
...always produces dependencies A, B, and C, which is a lie.
Note, btw, that dependencies are dynamic, not lexical: call a function
that accesses a cell and you still get a dependency.
>
> Shneaky shneaky. (If true.)
Sweet, right? It was not always that way, but then I finally grokked
special variables and that changed everything.
kt
Alan Crowe
>
> cvs -z3 -d :pserver:anonymous:anon...@common-lisp.net:/project/cells/cvsroot co cells
>
> The cells-cultures stuff isn't how things are organized anymore.
Thank you. I'm following the thread, thinking I must try
cells sometime soon:
509 man cvs
510 cvs -z3 -d :pserver:anonymous:anon...@common-lisp.net:/project/cells/cvsroot cocell-cultures/cells
512 cvs -z3 -d :pserver:anonymous:anon...@common-lisp.net:/project/cells/cvsroot co cell-cultures/cells
542 rm -r *
545 cvs -z3 -d :pserver:anonymous:anon...@common-lisp.net:/project/cells/cvsroot co cells
549 history | grep 'cvs\|rm'
Alan Crowe
Edinburgh
Scotland
Tayssir John Gabbour
> BTW any explication here on these threads should also be in the
> Cells documentation.
Alternatively, anyone could update the cliki page and cut 'n paste that
documentation. You could do that. So could I.
Taking initiative is a cost of democratic ideals like transparency and
ability to redistribute your modified code. Most people are trained to
use software for which pains are taken not to allow them to copy/modify
it. And I hear some large percentage of my fellow US citizens (like
80%?) spend much of their lives in workplaces where they don't have
serious power over decisionmaking, and are penalized for taking
initiative.
People are weakened by these sharp divisions (like between consumption
and production), but we can break out of them.
Collaboration is an important and human activity. Maybe every
historically important endeavor we can name required it, when we
examine the history closely (even though contemporary culture likes to
single out and deify certain individuals, and even through children are
graded like beef in a pretense of separating out those who are innately
useful for society).
So anyway, some people will prefer to specialize on what they wish to
do. Ok, so the question becomes, do I have the interest and ability to
pick up the slack? If so, maybe I'll do some small thing. Doesn't have
to be big; these small things add up.
Tayssir
Ken Tilton
> Ken Tilton <kent...@gmail.com> writes:
>
>
>>>Peter Seibel wrote:
>>>
>>>
>>>>Next month I'm goin to be giving a talk[1] about the effect of
>>>>programming language on software architecture. I'm thinking about what
>>>>the heck I'm going to say and how to turn it into an oppotunity to
>>>>brag on Lisp. So if you have any good war stories about how using Lisp
>>>>(or any other language for that matter) had an affect on the
>>>>architecture of the system you were working on, I'd love to hear
>>>>them.
>>
>>Too bad you gave up on Cells at the first backtrace. Cells simply fell
>>out of an attack on an application problem, turned into a paradigm,
>>took over the whole application. Would never have happened without
>>first-class functions, closures, macros, CLOS, untyped variables...
>
>
> Hey, that's not fair. I didn't give up because I couldn't get it to
> run--I gave up long before that, when I couldn't find anything that
> explained what it was and why I should care. ;-)
What part of...
[negligibly updated from "Cells Basics", the first link under "cells
tutorials" on http://www.tilton-technology.com/cells_top.html, to be
re-posted in the next hour or three]
cells
-----
think of a clos slot as a cell in a paper spreadsheet, a financial
modeling tool popular enough to make visi-calc the first business
killer app for microcomputers.
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 repeating that process to propagate those changes in a
cascade across the paper.
visi-calc let my father take the formula he had in mind and
put it in (declare it to) the electronic spreadsheet. then visi-calc
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...
with cells, the programmer looks at program state differently. one
asks, "how could i compute, at any point of runtime, a value for
a given slot of an arbitrary instance, based only on other runtime state
(other slots of other instances)." great fun, by the way, as well as
enforcing good programming practices like encapsulation.
an example will help. consider indeed the state of the "cut" menu item.
in some applications, programmers have a dozen places in their code
where they tend to the status of the cut menu item. one might be:
(defun do-clear (edit-structure)
(when (selected-range edit-structure)
<set up undo>
<toss selected text>
<etc><etc>
(menu-item-enable *edit-cut* nil)
(menu-item-enable *edit-copy* nil)
(menu-item-enable *edit-clear* nil)))
other programmers wait until the user clicks on the edit menu,
then decide just-in-time from program state whether the cut item
should be enabled:
(defmethod prep-for-display ((m edit-menu))
<lotsa other stuff>
(when (typep (focus *app*) 'text-edit-widget)
(menu-item-enable (find :cut (items m) :key #'item-name)
(not (null (selected-range (focus *app*)))))))
this latter programmer is ready for cells, because they
have already shifted from imperative to declarative thinking;
they have learned to write code that works based not on what
has happened lately, but instead only on the current program
state (however it got that way).
the cell programmer writes:
(make-instance 'menu-item
:name :cut
:label "cut"
:cmd-key +control-x+
:actor #'do-cut
:enabled (c? (when (typep (focus *app*) 'text-edit-widget)
(not (null (selected-range (focus *app*)))))))
...and now they can forget the menu item exists as they work
on the rest of the application. the menu-item enabled status
will stay current (correct) as the selected-range changes
and as the focus itself changes as the user moves from field
to field.
that covers the spirit of cells. now let's look at the syntax
and mechanics, with examples you can execute once you have
loaded the cells package. see the read-me.txt file in the
root directory into which the cello software was unzipped.
we'll model a falling stone, where the distance fallen is half
the product of the acceleration (due to gravity) and the
square of the time falling.
|#
(in-package :cells)
(cells-reset)
(defmodel stone ()
((accel :cell t :initarg :accel :initform 0 :accessor accel)
(time-elapsed :cell t :initarg :time-elapsed
:initform (c-in 0)
:accessor time-elapsed)
(distance :cell t :initarg :distance :initform 0 :accessor distance))
(:default-initargs
:distance (c? (/ (* (accel self)
(expt (time-elapsed self) 2))
2))))
(def-listener accel ((self stone) new old old-bound-p)
(trc "listener sees accel" :new new :old old :oldp old-bound-p)) ;;
TRC provides print diagnostics
(def-listener time-elapsed ((self stone)) ;; short form (I'm lazy)
(trc "listener sees time-elapsed" :new new-value :old old-value :oldp
old-value-boundp))
(def-listener distance ((self stone))
(format t "~&listener sees distance fallen: ~d feet" new-value))
#|
let's look at non-standard syntax found in the forms above,
in the order in which they appear:
(defmodel ...
defmodel is just a defclass wrapper which also sets up plumbing for cells.
... :cell t ...
without this option, a model instance slot cannot be powered
by a cell (and cell slot access overhead is avoided).
with this option, one can specify what kind of cell
is to be defined: ephemeral, delta or t (normal). we'll leave
those esoteric cell slot types for another tutorial and just
specify t to get normal cells (the ones used 99% of the time).
time-elapsed ... :initform (c-in 0)...
(c-in <value>) allows the cellular slot (or "cell", for short)
to be setf'ed. these are inputs to the dataflow,
which usually flows from c? to c? but has to start somewhere.
since modern interactve applications are event-driven, in
real-world cello apps most cv dataflow inputs are slots closely
corresponding to some system value, such as the position slots
of a cell-powered mouse class. moving on...
a naked value such as the 32 supplied for accel cannot be changed; a
runtime error results from any such attempt. this makes cells faster,
because some plumbing can be skipped: no dependency gets recorded between
the distance traveled and the acceleration. on the other hand, a more
elaborate model might have the acceleration varying according to the
distance
between the stone and earth (in which case we get into an advance
topic for another day, namely how to handle circularity.)
next: (:default-initargs
:distance (c? (/ (* (accel self)
(expt (time-elapsed self) 2))
2)
c? associates a rule with a cellular slot (or "cell", for short). any
read operation on another cell (directly or during a function call)
establishes a dependency of distance on that cell -- unless that cell
can never change. why would a cell not be able to change?
cell internals enforce a rule that a cell with a naked value (ie, not
wrapped
in cv or c?) cannot be changed by client code (ok, (setf slot-value) is
a backdoor).
cell internals enforce this, simply to make possible the optimization
of leaving off the overhead of recording a pointless dependency.
next: (def-listener...
here is the signature for the def-listener macro:
(defmacro def-listener (slotname (&optional (self-arg 'self)
(new-varg 'new-value)
(oldvarg 'old-value)
(oldvargboundp 'old-value-boundp))
&body listener-body) ....)
def-listener defines a generic method with method-combination progn,
which one can specialize on any of the four
parameters. the method gets called when the slot value changes, and during
initial processing by:
(to-be....)
to-be brings a new model instance to life, including calling
any listeners defined for cellular slots.
why not just do this in initialize-instance? we build complex
models in the form of a tree of many model instances, any of
which may depend on some other model instance to calculate
some part of its state. models find the one they are curious
about by searching the tree.
this means we cannot just bring a model instance to life at
make-instance time; some cell rule may go looking for another
model instance. we must wait until the instance is
embedded in the larger model tree, then we can kick off to-be.
likewise, when we yank an instance from the larger model we
will call not-to-be on it.
the good news is that unless i am doing little tutorial examples
i never think about calling to-be. trees are implemented in part
by a "kids" (short for "children") cell. the listener on that cell
calls to-be on new kids and not-to-be on kids no longer in the list.
now evaluate the following:
|#
#+evaluatethis
(defparameter *s2* (make-instance 'stone
:accel 32 ;; (constant) feet per second per second
:time-elapsed (c-in 0)))
#|
...and observe:
0> listener sees accel :new 32 :old nil :oldp nil
0> listener sees time-elapsed :new 0 :old nil :oldp nil
listener sees distance fallen: 0 feet
getting back to the output shown above, why listener output on a new
instance?
when we call to-be we want the instance to come to life. that means
evaluating every rule so the dependencies get established, and
propagating cell values outside the model (by calling the listener
methods) to make sure the model and outside world (if only the
system display) are consistent.
;-----------------------------------------------------------
now let's get moving:
|#
#+evaluatethis
(setf (time-elapsed *s2*) 1)
#|
...and observe:
0> listener sees time-elapsed :new 1 :old 0 :oldp t
listener sees distance fallen: 16 feet
behind the scenes:
- the slot value time-elapsed got changed from 0 to 1
- the time-elapsed listener was called
- dependents on time-elapsed (here just distance) were recalculated
- go to the first step, this time for the distance slot
;-----------------------------------------------------------
to see some optimizations at work, set the cell time-elapsed to
the same value it already has:
|#
#+evaluatethis
(setf (time-elapsed *s2*) 1)
#| observe:
nothing, since the slot-value did not in fact change.
;-----------------------------------------------------------
to test the enforcement of the cell stricture against
modifying cells holding naked values:
|#
#+evaluatethis
(let ((*c-debug* t))
(handler-case
(setf (accel *s2*) 10)
(t (error)
(cells-reset) ;; clear a *stop* flag used to bring down a runaway
model :)
(trc "error is" error)
error)))
#| observe:
c-setting-debug > constant accel in stone may not be altered..init to
(c-in nil)
0> error is #<simple-error @ #x210925f2>
Without turning on *c-debug* one just gets the runtime error, not the
explanation to standard output.
;-----------------------------------------------------------
nor may ruled cells be modified arbitrarily:
|#
#+evaluatethis
(let ((*c-debug* t))
(handler-case
(setf (distance *s2*) 42)
(t (error)
(cells-reset)
(trc "error is" error)
error)))
#| observe:
c-setting-debug > ruled distance in stone may not be setf'ed
0> error is #<simple-error @ #x2123e392>
;-----------------------------------------------------------
aside from c?, cv, and def-listener, another thing you will see
in cello code is how complex views are constructed using
the family class and its slot kids. every model-object has a
parent slot, which gets used along with a family's kids slot to
form simple trees navigable up and down.
model-objects also have slots for md-name and md-value (don't
worry camelcase-haters, that is a declining feature of my code).
md-name lets the family trees we build be treated as namespaces.
md-value just turns out to be very handy for a lot of things. for
example, a check-box instance needs some place to indicate its
boolean state.
now let's see family in action, using code from the handbook of
silly examples. all i want to get across is that a lot happens
when one changes the kids slot. it happens automatically, and
it happens transparently, following the dataflow implicit in the
rules we write, and the side-effects we specify via listener functions.
the silly example below just shows the summer (that which sums) getting
a new md-value as the kids change, along with some listener output. in
real-world
applications, where kids represent gui elements often dependent on
each other, vastly more can transpire before a simple push into a kids
slot has run its course.
evaluate:
|#
(defmodel summer (family)
()
(:default-initargs
:kids (c-in nil) ;; or we cannot add any addend kids later
:md-value (c? (reduce #'+ (kids self)
:initial-value 0
:key #'md-value))))
(def-listener md-value ((self summer))
(trc "the sum of the values of the kids is" new-value))
(def-listener .kids ((self summer))
(trc "the values of the kids are" (mapcar #'md-value new-value)))
;-----------------------------------------------------------
; now just evaluate each of the following forms one by one,
; checking results after each to see what is going on
;
(defparameter *f1* (make-instance 'summer))
#|
observe:
0> the sum of the values of the kids is 0
0> the values of the kids are nil
;----------------------------------------------------------|#
#+evaluatethis
(push (make-instance 'model
:fm-parent *f1*
:md-value 1) (kids *f1*))
#| observe:
0> the values of the kids are (1)
0> the sum of the values of the kids is 1
;----------------------------------------------------------|#
#+evaluatethis
(push (make-instance 'model
:fm-parent *f1*
:md-value 2) (kids *f1*))
#| observe:
0> the values of the kids are (2 1)
0> the sum of the values of the kids is 3
;----------------------------------------------------------|#
#+evaluatethis
(setf (kids *f1*) nil)
#| observe:
0> the values of the kids are nil
0> the sum of the values of the kids is 0
now before closing, it occurs to me you'll need a little
introduction to the semantics of ^slot-x macros generated
by the defmodel macro. here is another way to define our stone:
|#
#+evaluatethis
(setq *s2* (make-instance 'stone
:accel 2
:time-elapsed (c-in 3)
:distance (c? (+ (^accel) (^time-elapsed)))))
#| in the olden days of cells, when they were called
semaphors, the only way to establish a dependency
was to use some form like:
(^some-slot some-thing)
that is no longer necessary. now any dynamic access:
(1) during evaluation of a form wrapped in (c?...)
(2) to a cell, direct or inside some function
(3) using accessors named in the defmodel form (not slot-value)
...establishes a dependency. so why still have the ^slot macros?
one neat thing about the ^slot macros is that the default
argument is self, an anaphor set up by c? and its ilk, so
one can make many rules a little easier to follow by simply
coding (^slot). another is convenient specification of
synapses on dependencies, a more advanced topic we can
ignore a while.
|#
... did you not understand?
ken
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
bradb
tutorial is now up to date :) <ducks>
Seriously, thanks for fixing it up Kenny. Assuming that the basic
tutorial more or less works, I will indeed check it out. I'm sure that
others will too.
Cheers
Brad
Ken Tilton
> At least if nothing else good comes of all this, the cells-basic
> tutorial is now up to date :) <ducks>
<heh-heh> No need to duck, I was laughing about that already. The only
downside is if I decide screw you guys, I'm going home.
The larger point is that it really is a two-way street. You raised an
issue with the doc and it got fixed. Coincidence? I don't think so. :)
Doc whiners who never ask the maintainers anything remind me of this story:
"A guy named Saul finds himself in dire straits. His business has gone
bust and he's in serious financial trouble. He's so desperate that he
decides to ask God for help. He begins to pray: "God, please help me.
I've lost my business and if I don't get some money, I'm going to lose
my house as well. Please let me win the lottery." Lottery night comes,
and somebody else wins it. Saul again prays: "God, please let me win the
lotto! I've lost my business, my house and I'm going to lose my car as
well." Lotto night comes, and Saul still has no luck.
Once again, he prays: "My God, why have you forsaken me? I've lost my
business, my house, and my car. My wife and children are starving. I
don't often ask you for help, and I have always been a good servant to
you. PLEASE just let me win the lottery this one time so I can get my
life back in order." Suddenly there is a blinding flash of light as the
heavens open and Saul is confronted by God Himself:
"Saul, meet me halfway on this: buy a ticket."
>
> Seriously, thanks for fixing it up Kenny. Assuming that the basic
> tutorial more or less works, I will indeed check it out. I'm sure that
> others will too.
Just do not use what I just posted in case the referendum produces a new
name for listeners, and definitely do not run it until new code appears
in the repository, which could be a while since I plan private distros
to select users for beta testing.
Tayssir John Gabbour
> (defmodel summer (family)
> ()
> (:default-initargs
> :kids (c-in nil) ;; or we cannot add any addend kids later
> :md-value (c? (reduce #'+ (kids self)
> :initial-value 0
> :key #'md-value))))
>
> (def-listener md-value ((self summer))
> (trc "the sum of the values of the kids is" new-value))
>
> (def-listener .kids ((self summer))
> (trc "the values of the kids are" (mapcar #'md-value new-value)))
Hmm, the SUMMER example in CVS and the tarball doesn't seem to work.
(def-c-output .kids ...) works as expected, but (def-c-output .md-value
...) doesn't execute at all.
Apparently, ".md-value" (with the dot prefix) isn't a typo; "md-value"
doesn't work either.
Tayssir
Ken Tilton
> Ken Tilton wrote:
>
>>(defmodel summer (family)
>> ()
>> (:default-initargs
>> :kids (c-in nil) ;; or we cannot add any addend kids later
>> :md-value (c? (reduce #'+ (kids self)
>> :initial-value 0
>> :key #'md-value))))
>>
>>(def-listener md-value ((self summer))
>> (trc "the sum of the values of the kids is" new-value))
>>
>>(def-listener .kids ((self summer))
>> (trc "the values of the kids are" (mapcar #'md-value new-value)))
>
>
> Hmm, the SUMMER example in CVS and the tarball doesn't seem to work.
Right. I posted the version that brings that up-to-date, and that is
already out-of-date because exit polling tells me "def-observer"
trounced "def-listener" and the change is in. And anyway you need Cells3
to run it. RSN.
Peter Seibel
> bradb wrote:
>> At least if nothing else good comes of all this, the cells-basic
>> tutorial is now up to date :) <ducks>
>
> <heh-heh> No need to duck, I was laughing about that already. The
> only downside is if I decide screw you guys, I'm going home.
>
> The larger point is that it really is a two-way street. You raised
> an issue with the doc and it got fixed. Coincidence? I don't think
> so. :)
>
> Doc whiners who never ask the maintainers anything remind me of this
> story:
Hey, I didn't whine about the doc; I don't care one way or the other.
I just explaind why it was thta I never bothered to look deeply into
Cells, in response to your claim that it was because I was unable to
get it running. I'm glad to see that you're still working on it and on
the examples and so forth so if I even feel inclined to check it the
road will be easier than it would have been a couple years ago.
-Peter
--
Peter Seibel * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Ken Tilton
> Ken Tilton <kent...@gmail.com> writes:
>
>
>>bradb wrote:
>>
>>>At least if nothing else good comes of all this, the cells-basic
>>>tutorial is now up to date :) <ducks>
>>
>><heh-heh> No need to duck, I was laughing about that already. The
>>only downside is if I decide screw you guys, I'm going home.
>>
>>The larger point is that it really is a two-way street. You raised
>>an issue with the doc and it got fixed. Coincidence? I don't think
>>so. :)
>>
>>Doc whiners who never ask the maintainers anything remind me of this
>>story:
>
>
> Hey, I didn't whine about the doc; I don't care one way or the other.
> I just explaind why it was thta I never bothered to look deeply into
> Cells, in response to your claim that it was because I was unable to
> get it running.
Stop bobbing and weaving. :) Your response was as you say, explaining
that you could not find anything explaining what it was and why you
should bother. That explanation is what I am addressing. And I cannot
believe you did not explain how what I posted did not address both what
Cells is and why you should bother.
> I'm glad to see that you're still working on it and on
> the examples and so forth so if I even feel inclined to check it...
<sigh> Wait, I have an idea....
Peter Seibel
> Peter Seibel wrote:
>> Ken Tilton <kent...@gmail.com> writes:
>>
>>>bradb wrote:
>>>
>>>>At least if nothing else good comes of all this, the cells-basic
>>>>tutorial is now up to date :) <ducks>
>>>
>>><heh-heh> No need to duck, I was laughing about that already. The
>>>only downside is if I decide screw you guys, I'm going home.
>>>
>>>The larger point is that it really is a two-way street. You raised
>>>an issue with the doc and it got fixed. Coincidence? I don't think
>>>so. :)
>>>
>>>Doc whiners who never ask the maintainers anything remind me of this
>>>story:
>> Hey, I didn't whine about the doc; I don't care one way or the
>> other.
>> I just explaind why it was thta I never bothered to look deeply into
>> Cells, in response to your claim that it was because I was unable to
>> get it running.
>
> Stop bobbing and weaving. :) Your response was as you say, explaining
> that you could not find anything explaining what it was and why you
> should bother. That explanation is what I am addressing. And I cannot
> believe you did not explain how what I posted did not address both
> what Cells is and why you should bother.
It looks like it might. But like I said, I don't really care any more.
You've been selling Cells up and down for years now; when you first
started I was interested and excited enough to go looking for this
kind of material; unfortunately it didn't exist then. Now I'm in a
more wait and see (i.e. lazy) mode. Some day I may have a problem that
I'll say, hmmm, this seems like a perfect thing for Cells, maybe I
should go check it out again. Or maybe I'll see that people other than
you are making good use of it and that'll excite my interest again.
But for now it's been pushed well down stack of things to check out.
Tin Gherdanarra
> Next month I'm goin to be giving a talk[1] about the effect of
> programming language on software architecture. I'm thinking about what
> the heck I'm going to say and how to turn it into an oppotunity to
> brag on Lisp. So if you have any good war stories about how using Lisp
> (or any other language for that matter) had an affect on the
> architecture of the system you were working on, I'd love to hear
> them.
>
>
> [1] April 26th at the Software Architecture and Modeling SIG of
> SDForum in Palo Alto
>
I'm sure this is not what you had in mind, because
it does not involve a large application. However, it
is interesting how the author attributes his way to
important insights to Lisp and documents how he got
a different angle on the classic of fibonacci numbers.
Maybe you can use it as an appetizer for your talk:
http://fare.livejournal.com/59015.html
Break a leg.
John Thingstad
This could all be gotten from comp.lang.lisp..
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Tin Gherdanarra
"this all" mean?