howard yeh wrote:
> I just realized.
>
> Wikipedia: "Lisp was invented by John McCarthy in 1958..."
>
> On which day should I open the champagne and party?
Same Q. Exactly when did that guy poke his head in John's door and say,
"Sorry, I banged out a few lines assembler, want to give Lisp a try?"?
"S.R. Russell noticed that eval could serve as an interpreter for LISP,
promptly hand coded it, and we now had a programming language with an
interpreter."
http://www-formal.stanford.edu/jmc/history/lisp/node3.html#SECTION00030000000000000000
We have at least a few months to figure this out. From the same page:
"The implementation of LISP began in Fall 1958. "
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
howard yeh wrote:
> I just realized.
>
> Wikipedia: "Lisp was invented by John McCarthy in 1958..."
>
> On which day should I open the champagne and party?
Ah, silly me. Direct link:
http://www.iwriteiam.nl/HaCAR_CDR.html#Steve
"early 1959".
The publication date PC mentioned is not bad either, but I think the
idea (summer '56) or the working implementation justify more champagne.
My solution has been to start drinking champagne in 2006 and continue
until early 2009, which I am defining as June 30 to be safe.
hth, kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
> From: Ken Tilton <···········@optonline.net>
> Ah, silly me. Direct link:
> http://www.iwriteiam.nl/HaCAR_CDR.html#Steve
Answer from Steve Russell
I don't remember how we decided to use the address for the first
element, but I suspect it had to do with guessing that it would be
referenced more, and that there were situations where a memory cycle
would be saved when the pointer was in the address.
I suppose I could tease Steve et al about premature optimization?
> My solution has been to start drinking champagne in 2006 and continue
> until early 2009, which I am defining as June 30 to be safe.
Why is an alcoholic beverage necessary to celebrate Lisp?
Given that we're celebrating the conception and gestation and birth
of Lisp, maybe we should "make love not alcohol"? Too bad that's
not practical because there's a severe shortage of females in the
Lisp community.
(I never met even one female Lisp activist in California, except
once somebody from M.I.T. who was in Berkeley for a Lisp
conference, and she's no longer living as I belatedly learned in
this newsgroup earlier this year.)
On Jun 1, 3:55 pm, ···················@spamgourmet.com (Robert Maas,
http://tinyurl.com/uh3t) wrote:
> Why is an alcoholic beverage necessary to celebrate Lisp?
> Given that we're celebrating the conception and gestation and birth
> of Lisp, maybe we should "make love not alcohol"? Too bad that's
> not practical because there's a severe shortage of females in the
> Lisp community.
> (I never met even one female Lisp activist in California, except
> once somebody from M.I.T. who was in Berkeley for a Lisp
> conference, and she's no longer living as I belatedly learned in
> this newsgroup earlier this year.)
Females will remain scarce for as long as we continue to scare them
off by not treating them as peers. This will always be the case if
we're more concerned about their apparatus for conception, gestation
and all of that - rather than about their brains.
agt
viper-2 wrote:
> On Jun 1, 3:55 pm, ···················@spamgourmet.com (Robert Maas,
> http://tinyurl.com/uh3t) wrote:
>
>
>>Why is an alcoholic beverage necessary to celebrate Lisp?
Yeah!...Hang on, I thought you were saying why do we need a Lisp
anniversary to drink...
>>Given that we're celebrating the conception and gestation and birth
>>of Lisp, maybe we should "make love not alcohol"? Too bad that's
>>not practical because there's a severe shortage of females in the
>>Lisp community.
>>(I never met even one female Lisp activist in California, except
>> once somebody from M.I.T. who was in Berkeley for a Lisp
>> conference, and she's no longer living as I belatedly learned in
>> this newsgroup earlier this year.)
>
>
> Females will remain scarce for as long as we continue to scare them
> off by not treating them as peers. This will always be the case if
> we're more concerned about their apparatus for conception, gestation
> and all of that - rather than about their brains.
So there we are at the last Lisp-NYC meeting at the Westside Brewery and
someone in our group is being terribly loud -- I think it was Naughton
but I was making so much noise I could not be sure -- when Heow our
fearless leader approaches and asks us to hold it down, a neighboring
table had asked if we could not just STFU a little. I looked over and
made eye contact with an attractive young woman out with her parents.
"You don't like Lisp?", I yelled across the room before Heow could clamp
his hand over my mouth.
"Matlab," she replied. "I used to do Lisp."
I joined their table. Three way cool people. The father was a retired
civil engineer and had the most amazing eyes, always smiling through
them, either that or he was terrified to have been invaded by The Kenny.
Turns out she had gotten a PhD from Columbia in Computer Science and
then decided to go medical and was now a doctor using Matlab to crunch
numbers. Damn, I forgot to tell her about Cells... well, I saw her
talking to our fearless leader later, she may be joinging Lisp-NYC.
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On Jun 2, 11:56 am, Ken Tilton <···········@optonline.net> wrote:
> viper-2 wrote:
>
> ... I looked over and
> made eye contact with an attractive young woman out with her parents.
>
> "You don't like Lisp?", I yelled across the room before Heow could clamp
> his hand over my mouth.
>
> "Matlab," she replied. "I used to do Lisp."
>
> I joined their table. Three way cool people. The father was a retired
> civil engineer and had the most amazing eyes, always smiling through
> them, either that or he was terrified to have been invaded by The Kenny.
>
> Turns out she had gotten a PhD from Columbia in Computer Science and
> then decided to go medical and was now a doctor using Matlab to crunch
> numbers. Damn, I forgot to tell her about Cells... well, I saw her
> talking to our fearless leader later, she may be joinging Lisp-NYC.
Hmmm. Very disappointing Kenny, I would have thought that after all
that eye contact inspired you to invade their table - and left you so
utterly tongue-tied and vacuous that you forgot to mention Cells (8-
O ) - you would have made quite sure that did, in fact, join Lisp-NYC.
Maybe you felt threatened?
;-e
agt
viper-2 wrote:
> On Jun 2, 11:56 am, Ken Tilton <···········@optonline.net> wrote:
>
>>viper-2 wrote:
>>
>>... I looked over and
>>made eye contact with an attractive young woman out with her parents.
>>
>>"You don't like Lisp?", I yelled across the room before Heow could clamp
>>his hand over my mouth.
>>
>>"Matlab," she replied. "I used to do Lisp."
>>
>>I joined their table. Three way cool people. The father was a retired
>>civil engineer and had the most amazing eyes, always smiling through
>>them, either that or he was terrified to have been invaded by The Kenny.
>>
>>Turns out she had gotten a PhD from Columbia in Computer Science and
>>then decided to go medical and was now a doctor using Matlab to crunch
>>numbers. Damn, I forgot to tell her about Cells... well, I saw her
>>talking to our fearless leader later, she may be joinging Lisp-NYC.
>
>
> Hmmm. Very disappointing Kenny, I would have thought that after all
> that eye contact inspired you to invade their table - and left you so
> utterly tongue-tied and vacuous that you forgot to mention Cells (8-
> O ) - you would have made quite sure that did, in fact, join Lisp-NYC.
> Maybe you felt threatened?
Jeez, for once I take the high road and act like a civilized -- oh, your
nickname is viper, yes, I let you down old man.
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On Jun 2, 1:26 pm, Ken Tilton <···········@optonline.net> wrote:
> viper-2 wrote:
> > On Jun 2, 11:56 am, Ken Tilton <···········@optonline.net> wrote:
>
> >>viper-2 wrote:
>
> >>... I looked over and
> >>made eye contact with an attractive young woman out with her parents.
>
> >>"You don't like Lisp?", I yelled across the room before Heow could clamp
> >>his hand over my mouth.
>
> >>"Matlab," she replied. "I used to do Lisp."
>
> >>I joined their table. Three way cool people. The father was a retired
> >>civil engineer and had the most amazing eyes, always smiling through
> >>them, either that or he was terrified to have been invaded by The Kenny.
>
> >>Turns out she had gotten a PhD from Columbia in Computer Science and
> >>then decided to go medical and was now a doctor using Matlab to crunch
> >>numbers. Damn, I forgot to tell her about Cells... well, I saw her
> >>talking to our fearless leader later, she may be joinging Lisp-NYC.
>
> > Hmmm. Very disappointing Kenny, I would have thought that after all
> > that eye contact inspired you to invade their table - and left you so
> > utterly tongue-tied and vacuous that you forgot to mention Cells (8-
> > O ) - you would have made quite sure that did, in fact, join Lisp-NYC.
> > Maybe you felt threatened?
>
> Jeez, for once I take the high road and act like a civilized -- oh, your
> nickname is viper, yes, I let you down old man.
My fangs are quite harmless except when I'm in combat mode against
Cylons - and I suspect you would pass the Cylon test (i.e. test
negative).
It's natural to feel threatened, at first.;-) The trick is to recruit
enough female lispers to Lisp events, conferences etc. Eventually
they'll just blend into the background and you won't notice the gender
difference.
BTW, that should have been "... you would have made quite sure that
she did, in fact, join Lisp-NYC".
agt
viper-2 wrote:
> On Jun 2, 1:26 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>viper-2 wrote:
>>
>>>On Jun 2, 11:56 am, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>viper-2 wrote:
>>
>>>>... I looked over and
>>>>made eye contact with an attractive young woman out with her parents.
>>
>>>>"You don't like Lisp?", I yelled across the room before Heow could clamp
>>>>his hand over my mouth.
>>
>>>>"Matlab," she replied. "I used to do Lisp."
>>
>>>>I joined their table. Three way cool people. The father was a retired
>>>>civil engineer and had the most amazing eyes, always smiling through
>>>>them, either that or he was terrified to have been invaded by The Kenny.
>>
>>>>Turns out she had gotten a PhD from Columbia in Computer Science and
>>>>then decided to go medical and was now a doctor using Matlab to crunch
>>>>numbers. Damn, I forgot to tell her about Cells... well, I saw her
>>>>talking to our fearless leader later, she may be joinging Lisp-NYC.
>>
>>>Hmmm. Very disappointing Kenny, I would have thought that after all
>>>that eye contact inspired you to invade their table - and left you so
>>>utterly tongue-tied and vacuous that you forgot to mention Cells (8-
>>>O ) - you would have made quite sure that did, in fact, join Lisp-NYC.
>>>Maybe you felt threatened?
>>
>>Jeez, for once I take the high road and act like a civilized -- oh, your
>>nickname is viper, yes, I let you down old man.
>
>
> My fangs are quite harmless except when I'm in combat mode against
> Cylons - and I suspect you would pass the Cylon test (i.e. test
> negative).
>
> It's natural to feel threatened, at first.;-) The trick is to recruit
> enough female lispers to Lisp events, conferences etc. Eventually
> they'll just blend into the background and you won't notice the gender
> difference.
>
> BTW, that should have been "... you would have made quite sure that
> she did, in fact, join Lisp-NYC".
heh-heh, got it ok the first time, thx.
actually, upon reflection I recall that I struck out. At my advanced
stage of flirtery it was just a moment -- a glance held too long by me
ignored in a notice-that-I-am-ignoring you kinda way -- so I had
forgotten it. As for making sure she joined, clearly you are in the hard
sell school. And sometimes that is counterproductive, as with children,
cats, and Woody Allen.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
viper-2 <········@mail.infochan.com> writes:
> The trick is to recruit enough female lispers to Lisp events,
> conferences etc. Eventually they'll just blend into the background and
> you won't notice the gender difference.
The day I stop noticing that women are women is the day I day. Quite
possibly some time _after_ the day I die.
--
Robert Uhl <http://public.xdi.org/=ruhl>
You don't eat children. You sell them into slavery, then use the money
to buy endangered species and eat those. --Stuart the Nice
Robert Uhl wrote:
> viper-2 <········@mail.infochan.com> writes:
>
>
>>The trick is to recruit enough female lispers to Lisp events,
>>conferences etc. Eventually they'll just blend into the background and
>>you won't notice the gender difference.
>
>
> The day I stop noticing that women are women is the day I day. Quite
> possibly some time _after_ the day I die.
>
Reminds me of the day we teachers in an inner-city team-teaching school
(four teachers to a team) sat around trying to figure out if the
administration was trying to balance teachers on a team racially. There
were 4-5 grownups sitting around saying things like "Wait...Beyers? Is
he white? No...". We often simply could not retrieve that information
without stopping and thinking for more than a few seconds. We started
laughing at how hard it was.
fwiw, kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On Jun 3, 9:24 pm, Ken Tilton <···········@optonline.net> wrote:
> Robert Uhl wrote:
> > viper-2 <········@mail.infochan.com> writes:
>
> >>The trick is to recruit enough female lispers to Lisp events,
> >>conferences etc. Eventually they'll just blend into the background and
> >>you won't notice the gender difference.
>
> > The day I stop noticing that women are women is the day I day. Quite
> > possibly some time _after_ the day I die.
>
> Reminds me of the day we teachers in an inner-city team-teaching school
> (four teachers to a team) sat around trying to figure out if the
> administration was trying to balance teachers on a team racially. There
> were 4-5 grownups sitting around saying things like "Wait...Beyers? Is
> he white? No...". We often simply could not retrieve that information
> without stopping and thinking for more than a few seconds. We started
> laughing at how hard it was.
I'm pretty sure that that kind of thinking is true for only a tiny
minority, for others it might be well-intended but only a dream.
The USA is not a post racial society. The nomination of a Barack
Obama, someone who voted "present" over 100 times while he was a State
Senator in Illinois, makes the point. Much of his white support is
clearly not genuine.
agt
On Jun 3, 8:29 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> viper-2 <········@mail.infochan.com> writes:
> > The trick is to recruit enough female lispers to Lisp events,
> > conferences etc. Eventually they'll just blend into the background and
> > you won't notice the gender difference.
>
> The day I stop noticing that women are women is the day I day. Quite
> possibly some time _after_ the day I die.
In a professional context women generally prefer to be noticed as
colleagues and equals first, and as women second.
agt
> From: viper-2 <········@mail.infochan.com>
> The trick is to recruit enough female lispers to Lisp events,
> conferences etc. Eventually they'll just blend into the background
> and you won't notice the gender difference.
Are there any free Lisp events in the near future in my local area
(Santa Clara Valley, around San Jose, California)? That MacSyma
conference (more than 20 years ago) that Ellen Lewis invited me to
was in Berkeley, at a time when I had a car and money to pay for
gasoline, so I could attend. Now with no car and no money, my
attendance region is quite smaller, whatever a day pass on Santa
Clara Valley Transit will allow.
Ken Tilton <···········@optonline.net> writes:
> howard yeh wrote:
>> I just realized.
>> Wikipedia: "Lisp was invented by John McCarthy in 1958..."
>> On which day should I open the champagne and party?
>
> Ah, silly me. Direct link:
>
> http://www.iwriteiam.nl/HaCAR_CDR.html#Steve
>
> "early 1959".
AIM-8 is dated March 4 1959. I would take this as the birthday of
LISP. Before that it was in gestation.
--
__Pascal Bourguignon__
On Jun 2, 5:07 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Ken Tilton <···········@optonline.net> writes:
> > howard yeh wrote:
> >> I just realized.
> >> Wikipedia: "Lisp was invented by John McCarthy in 1958..."
> >> On which day should I open the champagne and party?
>
> > Ah, silly me. Direct link:
>
> > http://www.iwriteiam.nl/HaCAR_CDR.html#Steve
>
> > "early 1959".
>
> AIM-8 is dated March 4 1959. I would take this as the birthday of
> LISP. Before that it was in gestation.
Cool, March 4 it is! Fire up your drinking societies! We have 9 months
to argue about where each local meetup should be. Hey Paris, un petit
bar ou des bouteilles de crémant sur le pont des arts? Munich, y'all
can call set up tents and call it Aprilfest. I think LispNYC already
knows what they need to do (hint, it's not "meet in a church" ;)
Thomas F. Burdick wrote:
> On Jun 2, 5:07 pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
>>Ken Tilton <···········@optonline.net> writes:
>>
>>>howard yeh wrote:
>>>
>>>>I just realized.
>>>>Wikipedia: "Lisp was invented by John McCarthy in 1958..."
>>>>On which day should I open the champagne and party?
>>
>>>Ah, silly me. Direct link:
>>
>>> http://www.iwriteiam.nl/HaCAR_CDR.html#Steve
>>
>>>"early 1959".
>>
>>AIM-8 is dated March 4 1959. I would take this as the birthday of
>>LISP. Before that it was in gestation.
>
>
> Cool, March 4 it is! Fire up your drinking societies! We have 9 months
> to argue about where each local meetup should be. Hey Paris, un petit
> bar ou des bouteilles de cr�mant sur le pont des arts? Munich, y'all
> can call set up tents and call it Aprilfest. I think LispNYC already
> knows what they need to do (hint, it's not "meet in a church" ;)
Don't remind me. :(
So what the Hell is aim-8 other than an incredibly good hi-fi speaker
based on the google hits?
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton <·········@gmail.com> wrote:
+---------------
| Thomas F. Burdick wrote:
| > ····@informatimago.com (Pascal J. Bourguignon) wrote:
| >>AIM-8 is dated March 4 1959. I would take this as the birthday of
| >>LISP. Before that it was in gestation.
| >
| > Cool, March 4 it is! Fire up your drinking societies! ...
...
| So what the Hell is aim-8 other than an incredibly good
| hi-fi speaker based on the google hits?
+---------------
MIT AI (Lab) Memo (hence, "AIM") #8 (hence, "AIM-8"), specifically:
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-008.pdf
March 4, 1959
Artificial Intelligence Project--RLE and MIT Computation Center
Memo 8
RECURSIVE FUNCTIONS OF SYMBOLIC EXPRESSIONS AND
THEIR COMPUTATION BY MACHINE
by J. McCarthy
[Caveat: It's a ~6 MB scan of a typed memo.]
Note: The version above has a "bugfix" page:
An Error in Memo 8
The definition of given on page 15 has two errors...
prepended to it dated March 13, 1959! ;-} ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Ken Tilton <·········@gmail.com> wrote:
> +---------------
> | Thomas F. Burdick wrote:
> | > ····@informatimago.com (Pascal J. Bourguignon) wrote:
> | >>AIM-8 is dated March 4 1959. I would take this as the birthday of
> | >>LISP. Before that it was in gestation.
> | >
> | > Cool, March 4 it is! Fire up your drinking societies! ...
> ...
> | So what the Hell is aim-8 other than an incredibly good
> | hi-fi speaker based on the google hits?
> +---------------
>
> MIT AI (Lab) Memo (hence, "AIM") #8 (hence, "AIM-8"), specifically:
>
> ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-008.pdf
> March 4, 1959
> Artificial Intelligence Project--RLE and MIT Computation Center
> Memo 8
> RECURSIVE FUNCTIONS OF SYMBOLIC EXPRESSIONS AND
> THEIR COMPUTATION BY MACHINE
> by J. McCarthy
>
> [Caveat: It's a ~6 MB scan of a typed memo.]
>
> Note: The version above has a "bugfix" page:
>
> An Error in Memo 8
> The definition of given on page 15 has two errors...
>
> prepended to it dated March 13, 1959! ;-} ;-}
Damn, nine days to get it thru change control even back then.
Anyway, Wikipedia says March 4, 1959 is also the day Pioneer 4 missed
the Moon and became an artificial planet (to put a nice spin on it). No
notable human births that year, but Shemp the fourth Stooge was born in
1895 on that date. Julian date 111111, 1000000 in a leap year.... looks
liek we'll have the spotlight to ourselves.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton <···········@optonline.net> writes:
> So what the Hell is aim-8 other than an incredibly good hi-fi speaker
> based on the google hits?
Also, have a look at:
http://www.informatimago.com/develop/lisp/small-cl-pgms/aim-8/
if you want to play with it.
--
__Pascal Bourguignon__
howard yeh wrote:
> I just realized.
>
> Wikipedia: "Lisp was invented by John McCarthy in 1958..."
>
> On which day should I open the champagne and party?
The first publication that mentioned the name "Lisp" was published in
October 1958.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> howard yeh wrote:
>
>> I just realized.
>>
>> Wikipedia: "Lisp was invented by John McCarthy in 1958..."
>>
>> On which day should I open the champagne and party?
>
>
> The first publication that mentioned the name "Lisp" was published in
> October 1958.
>
Cool, Cells does not even exist yet*, I have time to clean up the code!
Here is another date:
"My desire for an algebraic list processing language for artificial
intelligence work on the IBM 704 computer arose in the summer of 1956
during the Dartmouth Summer Research Project on Artificial Intelligence"
http://www-formal.stanford.edu/jmc/history/lisp/node2.html#SECTION00020000000000000000
That might be better considered the date of conception (it *is* a quote
from a section Dr. McCarthy called "Lisp prehistory") with date of birth
reserved for the first interpreter.
Oops. Howard, I'm afraid we'll have to put the champagne on ice**:
"I wrote the first implimenation of a LISP interpreter on the IBM 704 at
MIT in early in 1959. I hand-compiled John McCarthy's "Universal LISP
Function"." http://www.iwriteiam.nl/HaCAR_CDR.html (scroll 80% down to
"Email from Steve Russell")
kt
* But that might have changed, it *is* Friday after all.
** Let's see an NLP program parse *that*.
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
>
> Pascal Costanza wrote:
>> howard yeh wrote:
>>
>>> I just realized.
>>>
>>> Wikipedia: "Lisp was invented by John McCarthy in 1958..."
>>>
>>> On which day should I open the champagne and party?
>>
>>
>> The first publication that mentioned the name "Lisp" was published in
>> October 1958.
>>
>
> Cool, Cells does not even exist yet*
What part of "first public mention" is it that you miss?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>
>>
>> Pascal Costanza wrote:
>>
>>> howard yeh wrote:
>>>
>>>> I just realized.
>>>>
>>>> Wikipedia: "Lisp was invented by John McCarthy in 1958..."
>>>>
>>>> On which day should I open the champagne and party?
>>>
>>>
>>>
>>> The first publication that mentioned the name "Lisp" was published in
>>> October 1958.
>>>
>>
>> Cool, Cells does not even exist yet*
>
>
> What part of "first public mention" is it that you miss?
Nice retreat! Anyway, this has been pointed out to me:
http://www.cs.indiana.edu/l/www/ftp/techreports/TR619.pdf#page=99
Cells, 9/24/2005 - ????
You can relax. :)
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
>
> Pascal Costanza wrote:
>> Ken Tilton wrote:
>>
>>>
>>>
>>> Pascal Costanza wrote:
>>>
>>>> howard yeh wrote:
>>>>
>>>>> I just realized.
>>>>>
>>>>> Wikipedia: "Lisp was invented by John McCarthy in 1958..."
>>>>>
>>>>> On which day should I open the champagne and party?
>>>>
>>>>
>>>>
>>>> The first publication that mentioned the name "Lisp" was published
>>>> in October 1958.
>>>>
>>>
>>> Cool, Cells does not even exist yet*
>>
>>
>> What part of "first public mention" is it that you miss?
>
> Nice retreat! Anyway, this has been pointed out to me:
>
> http://www.cs.indiana.edu/l/www/ftp/techreports/TR619.pdf#page=99
>
> Cells, 9/24/2005 - ????
I think the first public mention of Cells was in December 2001. See
http://groups.google.com/group/comp.lang.lisp/msg/97297a72116fede6
Seven years after, and still no finished application to show to anybody?
That must suck. :-P
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>
>>
>> Pascal Costanza wrote:
>>
>>> Ken Tilton wrote:
>>>
>>>>
>>>>
>>>> Pascal Costanza wrote:
>>>>
>>>>> howard yeh wrote:
>>>>>
>>>>>> I just realized.
>>>>>>
>>>>>> Wikipedia: "Lisp was invented by John McCarthy in 1958..."
>>>>>>
>>>>>> On which day should I open the champagne and party?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The first publication that mentioned the name "Lisp" was published
>>>>> in October 1958.
>>>>>
>>>>
>>>> Cool, Cells does not even exist yet*
>>>
>>>
>>>
>>> What part of "first public mention" is it that you miss?
>>
>>
>> Nice retreat! Anyway, this has been pointed out to me:
>>
>> http://www.cs.indiana.edu/l/www/ftp/techreports/TR619.pdf#page=99
>>
>> Cells, 9/24/2005 - ????
>
>
> I think the first public mention of Cells was in December 2001. See
> http://groups.google.com/group/comp.lang.lisp/msg/97297a72116fede6
Cells, ne Semaphor. Oct 13, 2000:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/9fafce47d3e2d69/03a9fe9e6c33fabd?lnk=gst&q=semaphor#03a9fe9e6c33fabd
That's an historical date in two ways, the other being it started the
War With the Yobbos of #lisp with the subject including "CLIM Killer?".
Meanwhile:
"OK, one more last thing: I am just a simple programmer, and everything
i have done has been in support of application development, so don't ask
me anything deep. But i do tend to chew the scenery with grandiose
claims, just ignore those or refute them, i don't mind."
I want extra credit for consistency.
Here, too:
"In twenty-five words or less, and glossing over some complexity,
Semaphors let you define selected slots of (CLOS) ModelObject instances
as if they were cells in a spreadsheet."
>
> Seven years after, and still no finished application to show to anybody?
You don't count this?: http://www.tilton-technology.com/Acrostic.html
We showed CliniSys (80kloc) to IBM, they loved it. That had Cells in the
persistent ODB enforcing business rules as well as Cells in the GUI.
> That must suck. :-P
No, what sucked is that IBM then blew a sale we had been developing on
our own. To Johnson & Johnson, a little company here in NJ.
Oh. You are talking about the Algebra software. Yeah, I had a talk with
the monkeys about that, they promise no more work on Arc.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
> I am just a simple programmer, and everything
> i have done has been in support of application development, so don't ask
> me anything deep.
Don't worry.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>> I am just a simple programmer, and everything i have done has been in
>> support of application development, so don't ask
>> me anything deep.
>
>
> Don't worry.
Thanks. You know the crazy thing is that aside from miniscule
experimentations just for the sake of it I have never done a thing with
Cells that was not motivated by application requirements and a prime
consideration has always been ease of use for the programmer as they
tackle their applications.
By contrast, Steele did constraints as a pure exercise in what only
/seemed/ as if it would be cool to have when programming and paid no
attention to ease of programming, producing in the end something even
less programmable than Prolog.
How do you keep ContextL on track and easy to use without ever writing
applications?
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
> Pascal Costanza wrote:
>> Ken Tilton wrote:
>>
>>> I am just a simple programmer, and everything i have done has been in
>>> support of application development, so don't ask
>>> me anything deep.
>>
>> Don't worry.
>
> Thanks. You know the crazy thing is that aside from miniscule
> experimentations just for the sake of it I have never done a thing with
> Cells that was not motivated by application requirements and a prime
> consideration has always been ease of use for the programmer as they
> tackle their applications.
That may be a reason why you have difficulty explaining what the
essential ideas behind Cells are, and why people have to guess.
Note that the emphasis is on "explaining", not on "bragging about." It's
totally not useful at all to hear over and over again how absolutely
great some tool is, when it is hard to understand what the tool actually
does, not to speak of the details that are sometimes very important.
There are enough tools out there that work 80% of the time. It's the
last 20% that typically hurt you when they are missing. Without an
explanation whether you have thought about potential border cases or
not, it's hard to tell whether one will ever run into a situation where
they have painted oneself into a corner.
Again, the emphasis is on "explaining." "It worked for me most of the
time, and if it doesn't work, I can easily fix things" is not very
informative. (Read again: informative!)
> By contrast, Steele did constraints as a pure exercise in what only
> /seemed/ as if it would be cool to have when programming and paid no
> attention to ease of programming, producing in the end something even
> less programmable than Prolog.
It's obvious that you misunderstand the goal of research. Research is
about understanding the essential concepts, not about whether there are
enough bells and whistles to make life easy for programmers. The goal of
research is to explain, not to brag about.
> How do you keep ContextL on track and easy to use without ever writing
> applications?
You should double-check your subconscious assumptions.
You have often said that a problem with the Lisp community is that
people don't write enough applications and don't write enough libraries.
But that's not true. Lispers write lots of applications and libraries,
and are actually very successful at that. They are so successful at
that, that they don't need to brag about how good they are in
comp.lang.lisp.
I mean, what the hell? Who cares about comp.lang.lisp?!? [1]
That's why you couldn't deliver your rant at ECLM, because after a day
of presentations about very impressive applications and libraries that
are not only excellent, but actually pay several people's bills, it
would have been very questionable to state that we don't have enough
applications and libraries. Especially from someone whose demo sucked
big time.
You seem to have lost touch with what's really going on out there.
Pascal
[1] Note: There's a hint in there that could help you answer your
question about ContextL.
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>
>> Pascal Costanza wrote:
>>
>>> Ken Tilton wrote:
>>>
>>>> I am just a simple programmer, and everything i have done has been
>>>> in support of application development, so don't ask
>>>> me anything deep.
>>>
>>>
>>> Don't worry.
>>
>>
>> Thanks. You know the crazy thing is that aside from miniscule
>> experimentations just for the sake of it I have never done a thing
>> with Cells that was not motivated by application requirements and a
>> prime consideration has always been ease of use for the programmer as
>> they tackle their applications.
>
>
> That may be a reason why you have difficulty explaining what the
> essential ideas behind Cells are, and why people have to guess.
My real problem is the 10% who have no problem understanding Cells --
which kinda confirms my expectations -- so it make sit a little hard to
get motivated to do any more than this:
http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?rev=1.13&root=cells&view=markup
The fact is, you simply have not read it. I know because I know what is
in there and if you had read it you would have something more
substantial to say. And you do not. Or you would.
>
> Note that the emphasis is on "explaining", not on "bragging about."
You do not like?:
http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?rev=1.13&root=cells&view=markup
Or is it just inconvenient to your thesis?
Get used to the bragging, kid. Anyone using OpenLaszlo or Adobe Adam or
anything like it is pretty happy.
> It's
> totally not useful at all to hear over and over again how absolutely
> great some tool is, when it is hard to understand what the tool actually
> does, not to speak of the details that are sometimes very important.
You could not back up your comments on the Cells code, but maybe you
have something concrete to offer on why this is hard to understand?:
http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?rev=1.13&root=cells&view=markup
I'll fix it up if I can. But I will wait till you read it.
>
> There are enough tools out there that work 80% of the time. It's the
> last 20% that typically hurt you when they are missing. Without an
> explanation whether you have thought about potential border cases or
> not, it's hard to tell whether one will ever run into a situation where
> they have painted oneself into a corner.
With a candy-ass attitude like that I can see why you avoid
applications: you just described what it is like writing programs when
we do not know what program to write (Graham).
I remember someone once saying "anybody can be an application
programmer". OK, this was a systems guy on a mainframe dissing
conventional COBOL business programming, but he was still wrong.
Applications are /nasty/.
>
> Again, the emphasis is on "explaining." "It worked for me most of the
> time, and if it doesn't work, I can easily fix things" is not very
> informative. (Read again: informative!)
Someone just told you about a tool that make programming substantially
easier and more fun (I should emphasize the latter more) and all you can
do is worry? Tsk, tsk.
Every new application of Cells leads to extensions and/or revisions to
Cells, and purely as an aside the way I know you are wrong about the
code is that for a couple of years or more all such refinements have
gone in painlessly, often by simply /removing/ a stricture.
So why does Cells keep evolving if it is so hot? Because it is so hot.
By which I mean, those of us working in dataflow have really tapped into
a rich vein, or broken thru to a new network of caves if you will. The
potential here is incredible, and in five years you will have your tail
between your legs publishng on dataflow, filling out the Road to Cells,
and admitting you were wrong again.
Btw, all flaming aside, you should when no one is looking take a look at
Cells (or computed-class if that makes you feel better). I would love to
be an academic and just play around all day with the paradigm, and given
the publish or perish pressure it seems like a fruitful, unexplored
area. ContextL has a nice real-world feel to it, but you have to admit
it is pretty boring.
>
>> By contrast, Steele did constraints as a pure exercise in what only
>> /seemed/ as if it would be cool to have when programming and paid no
>> attention to ease of programming, producing in the end something even
>> less programmable than Prolog.
>
>
> It's obvious that you misunderstand the goal of research. Research is
> about understanding the essential concepts, not about whether there are
> enough bells and whistles to make life easy for programmers. The goal of
> research is to explain, not to brag about.
Brings up the whole question of whether there /is/ a computer science.
You think Steele created an entire constraints programming language to
prove it was a terrible way to program? No, we cannot even give him
that: he thus contributed to ten-twenty years more delay in advancement
of the simpler linear dataflow paradigm they dismissed as trivial.
Good point, btw. It is trivial, why don't you get it? What they missed
as <puff chest> researchers is that the trivial pet trick made Actually
Programming computers insanely easier. And more fun.
>
>> How do you keep ContextL on track and easy to use without ever writing
>> applications?
>
>
> You should double-check your subconscious assumptions.
Ah, this reminds me of trying to get you to say what was wrong with
Cells. I will cut my losses this time on trying to get an answer.
>
> You have often said that a problem with the Lisp community is that
> people don't write enough applications and don't write enough libraries.
> But that's not true. Lispers write lots of applications and libraries,
> and are actually very successful at that. They are so successful at
> that, that they don't need to brag about how good they are in
> comp.lang.lisp.
>
> I mean, what the hell? Who cares about comp.lang.lisp?!? [1]
>
> That's why you couldn't deliver your rant at ECLM, because after a day
> of presentations about very impressive applications and libraries that
> are not only excellent, but actually pay several people's bills, it
> would have been very questionable to state that we don't have enough
> applications and libraries.
You are right except for "that's why". Or do you think I developed the
demo at lunch? Think, McFly. Think.
No, the reason is that Edi suggested I talk about Cells (well twist my
arm!) and he also said make it important. And I did take ECLM seriously.
> Especially from someone whose demo sucked
> big time.
You don't like spinning letters? I recall a gasp from the audience. :) I
should have stopped there.
>
> You seem to have lost touch with what's really going on out there.
>
And oh what a relief it is!
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
> You don't like spinning letters? I recall a gasp from the audience.
Ah yes, that sounds particularly interesting for real-world applications.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>> You don't like spinning letters? I recall a gasp from the audience.
>
>
> Ah yes, that sounds particularly interesting for real-world applications.
You are no fun.
How about the dataflow into, across, and back out of the RDF triple
store? You don't think more reliable real-world systems would arise from
that?
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
>
> Pascal Costanza wrote:
>> Ken Tilton wrote:
>>
>>> You don't like spinning letters? I recall a gasp from the audience.
>>
>>
>> Ah yes, that sounds particularly interesting for real-world applications.
>
> You are no fun.
>
> How about the dataflow into, across, and back out of the RDF triple
> store? You don't think more reliable real-world systems would arise from
> that?
(defvar *some-list* '(5 4 3 2 1))
(defvar *sum* (reduce #'+ *some-list*))
(defvar *length* (length *some-list*))
(defvar *avg* (/ *sum* *length*))
(push 6 *some-list*)
=> *sum* *length* *avg* ?
(push 7 *some-list*)
=> *sum* *length* *avg* ?
(push 8 *some-list*)
=> *sum* *length* *avg* ?
Especially: How long will this take? In each turn? What about very large
lists?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Ken Tilton
Subject: Cells, the Ultimate Glue! [was Costanza grinding some unknown axw]
Date:
Message-ID: <4844a7ac$0$11632$607ed4bc@cv.net>
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>
>>
>> Pascal Costanza wrote:
>>
>>> Ken Tilton wrote:
>>>
>>>> You don't like spinning letters? I recall a gasp from the audience.
>>>
>>>
>>>
>>> Ah yes, that sounds particularly interesting for real-world
>>> applications.
>>
>>
>> You are no fun.
>>
>> How about the dataflow into, across, and back out of the RDF triple
>> store? You don't think more reliable real-world systems would arise
>> from that?
>
>
> (defvar *some-list* '(5 4 3 2 1))
haha, you did not even notice the RDF bit did you?
>
> (defvar *sum* (reduce #'+ *some-list*))
> (defvar *length* (length *some-list*))
> (defvar *avg* (/ *sum* *length*))
>
> (push 6 *some-list*)
>
> => *sum* *length* *avg* ?
>
> (push 7 *some-list*)
>
> => *sum* *length* *avg* ?
>
> (push 8 *some-list*)
>
> => *sum* *length* *avg* ?
>
>
> Especially: How long will this take? In each turn? What about very large
> lists?
I see you have been drinking -- we are finding common ground at last! I
suggest you macroexpand push when you sober up, should help you with
your homework.
Btw, if you did not like the alphabet ferris wheel, how about the
Algebra application I demoed at ECLM?
http://www.theoryyalgebra.com/demo.html
Weren't you impressed when it reacted to a misguided but mathematically
consistent answer not by saying "wrong" but by saying "unusual"?
http://www.theoryyalgebra.com/demo-15.html
That was a nice touch, right? Can you imagine some porr kid already
confused doing something matematically valid and being told "wrong"?
Well, you are in higher education, you probably do not know anything
about teaching.
And what about the wysiwyg math editor? I use Cells for that. Granted,
nothing professional typeseting-wise like TeX -- I /do/ need to ship the
damn thing some decade -- but then TeX does not have a dynamic editor,
so there.
As for the subject, another reason I accepted Edi's invitation to talk
about Cells was that just before ECLM not one but two Cells noobs had
appeared on the scene (Andy Chambers with OpenAIR and Peter Hildebrandt
with everything from Cells-Gtk extensions to Cells-ODE) and it occurred
to me I was not wrong about the library (or something like it) being
Deeply Important...oh, I digress, I was explaining the message subject.
Looking at Peter's paper[1], I see Cells being used as glue two ways,
once to Gtk and once to ODE. He hit the glue trifecta if he used Cells
to glue OpenGL display lists to their Lisp-side dependencies by
guaranteeing that display lists get rebuilt automatically whenever
anything on the Lisp side changes that would affect the display list.
Andy meanwhile has Cells gluing a Lisp model to web browsers.
Automatic glue is nice -- it eliminates what is normally tedious,
bug-prone work -- but nothing sexy. otoh, Lisp having been just recently
thawed finds itself reborn into a world dominated by C and
Javascript-ready browsers, so if we want to Win Big With Lisp we are
looking at living effectively and painlessly as possible with a lot of
foreign libraries... thank god for Cells, eh?
kt
1. http://www.washbear-network.de/fritz/pub/thesis.pdf
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
+ Ken Tilton <···········@optonline.net>:
> Can you imagine some porr kid already confused doing something
> matematically valid and being told "wrong"?
> Well, you are in higher education, you probably do not know anything
> about teaching.
Ouch (I am in higher ed myself). But actually I think you missed your
target here: Not branding an unusual but correct procedure as "wrong"
has nothing to do with understanding about teaching and everything to do
with understanding the subject at hand. That is why you will often find
high school teachers, who do know about teaching but alas don't always
know the subject area well enough, making this mistake, while university
professors will rarely make it. I am sure we make lots of other mistakes
in our teaching, since most of us have never been taught how to teach,
but this is not one of them.
If your program is able to make the distinction between wrong and
unusual, that is excellent of course.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Harald Hanche-Olsen wrote:
> + Ken Tilton <···········@optonline.net>:
>
>
>>Can you imagine some porr kid already confused doing something
>>matematically valid and being told "wrong"?
>>Well, you are in higher education, you probably do not know anything
>>about teaching.
>
>
> Ouch (I am in higher ed myself). But actually I think you missed your
> target here: Not branding an unusual but correct procedure as "wrong"
> has nothing to do with understanding about teaching and everything to do
> with understanding the subject at hand. That is why you will often find
> high school teachers, who do know about teaching but alas don't always
> know the subject area well enough, making this mistake, while university
> professors will rarely make it.
You may be right there -- this might be the wrong example to grind my
anti-academia axe. :) kt
I am sure we make lots of other mistakes
> in our teaching, since most of us have never been taught how to teach,
> but this is not one of them.
>
> If your program is able to make the distinction between wrong and
> unusual, that is excellent of course.
>
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
From: Pascal Costanza
Subject: Re: Cells, the Ultimate Glue! [was Costanza grinding some unknown axw]
Date:
Message-ID: <6ak90aF37jjs3U1@mid.individual.net>
Ken Tilton wrote:
>
>
> Pascal Costanza wrote:
>> Ken Tilton wrote:
>>
>>>
>>>
>>> Pascal Costanza wrote:
>>>
>>>> Ken Tilton wrote:
>>>>
>>>>> You don't like spinning letters? I recall a gasp from the audience.
>>>>
>>>>
>>>>
>>>> Ah yes, that sounds particularly interesting for real-world
>>>> applications.
>>>
>>>
>>> You are no fun.
>>>
>>> How about the dataflow into, across, and back out of the RDF triple
>>> store? You don't think more reliable real-world systems would arise
>>> from that?
>>
>>
>> (defvar *some-list* '(5 4 3 2 1))
>
> haha, you did not even notice the RDF bit did you?
>
>>
>> (defvar *sum* (reduce #'+ *some-list*))
>> (defvar *length* (length *some-list*))
>> (defvar *avg* (/ *sum* *length*))
>>
>> (push 6 *some-list*)
>>
>> => *sum* *length* *avg* ?
>>
>> (push 7 *some-list*)
>>
>> => *sum* *length* *avg* ?
>>
>> (push 8 *some-list*)
>>
>> => *sum* *length* *avg* ?
>>
>>
>> Especially: How long will this take? In each turn? What about very
>> large lists?
>
> I see you have been drinking -- we are finding common ground at last! I
> suggest you macroexpand push when you sober up
You cannot abstract away from Common Lisp's definition for push?
My question is: If these were Cells-driven data structures, how would
this work (assuming that push is defined in such a way that it triggers
updates)?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Ken Tilton
Subject: Re: Cells, the Ultimate Glue! [was Costanza grinding some unknown axw]
Date:
Message-ID: <48453f51$0$25032$607ed4bc@cv.net>
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>
>>
>> Pascal Costanza wrote:
>>
>>> Ken Tilton wrote:
>>>
>>>>
>>>>
>>>> Pascal Costanza wrote:
>>>>
>>>>> Ken Tilton wrote:
>>>>>
>>>>>> You don't like spinning letters? I recall a gasp from the audience.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Ah yes, that sounds particularly interesting for real-world
>>>>> applications.
>>>>
>>>>
>>>>
>>>> You are no fun.
>>>>
>>>> How about the dataflow into, across, and back out of the RDF triple
>>>> store? You don't think more reliable real-world systems would arise
>>>> from that?
>>>
>>>
>>>
>>> (defvar *some-list* '(5 4 3 2 1))
>>
>>
>> haha, you did not even notice the RDF bit did you?
>>
>>>
>>> (defvar *sum* (reduce #'+ *some-list*))
>>> (defvar *length* (length *some-list*))
>>> (defvar *avg* (/ *sum* *length*))
>>>
>>> (push 6 *some-list*)
>>>
>>> => *sum* *length* *avg* ?
>>>
>>> (push 7 *some-list*)
>>>
>>> => *sum* *length* *avg* ?
>>>
>>> (push 8 *some-list*)
>>>
>>> => *sum* *length* *avg* ?
>>>
>>>
>>> Especially: How long will this take? In each turn? What about very
>>> large lists?
>>
>>
>> I see you have been drinking -- we are finding common ground at last!
>> I suggest you macroexpand push when you sober up
>
>
> You cannot abstract away from Common Lisp's definition for push?
>
> My question is: If these were Cells-driven data structures, how would
> this work (assuming that push is defined in such a way that it triggers
> updates)?
Oh, I was wondering if that is what you were getting at, but I saw no
sign or mention of Cells so ruled out the possibility.
Insufficient information, but... in the (only interesting) case where it
became a problem traversing the list after every change, how would you
handle it without Cells? Keep pre-cooked info along with the list? Avoid
recomputing after every change, or recompute after big changes or the
tenth change, whichever comes first? Do we need a general solution in
which multiple new items might be added at the same time? Perhaps to be
sort-merged, not just prepended?
The short answer: divide and conquer, as always. Nothing new here.
The other information missing from your question is, Why do you ask? As
we had just recently here on c.l.l, if the lists are so long that we do
not want to traverse them, do we really want to keep that data in a list?
Elsewhere I see you asking if Cells does not scale. Cells works at the
level of change, low enough that handing any such problem is just a case
of engineering. ie, It is low enough that it sees everything, so
anything can be accomplished with a little code and then it will be
accomplished as cleanly as possible and as efficiently as possible
(again, because it sits at such a low level in the state change (and
access) API).
As an example, I once had a Real World Problem* of something changing
(a) too often (b) in ways that did not matter, which is how synapses got
developed (to suppress propagation intelligently). It was not a perfect
solution because the loss of detail did turn out to matter (it was a
physics sim) but looking at discussions of physics engines I see the
same issue (how big a slice can we get away with before things start
passing thru walls?) so I do not feel too bad. In the end, Cells (being
built to handle change at the lowest level) has the best chance for
solving these problems elegantly, because it gives one a place to hang
the code that will perhaps tune the slice to circumstances -- the same
code anyone not using Cells might write, only now we just say:
(with-filter (<filter-name> <filter-arg-1>...)
(position ball))
kt
* Actually, no, it was not real world, it was a rare case of doing Cells
for its own sake. I did a pendulum simulation, by simulating the forces,
not using the law. It was not real world because I did not really have
to do a pendulum sim, I was just exploring how cool it was programming
with Cells. This was like week three in the history of Cells. So when
the slicing became a problem (insufficient granularity) I had no
ultimate functional requirements to guide a balancing of performance
against loss of information. k
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Pascal Costanza wrote:
> Ken Tilton wrote:
>>
>>
>> Pascal Costanza wrote:
>>> Ken Tilton wrote:
>>>
>>>> You don't like spinning letters? I recall a gasp from the audience.
>>>
>>>
>>> Ah yes, that sounds particularly interesting for real-world
>>> applications.
>>
>> You are no fun.
>>
>> How about the dataflow into, across, and back out of the RDF triple
>> store? You don't think more reliable real-world systems would arise
>> from that?
>
> (defvar *some-list* '(5 4 3 2 1))
>
> (defvar *sum* (reduce #'+ *some-list*))
> (defvar *length* (length *some-list*))
> (defvar *avg* (/ *sum* *length*))
>
> (push 6 *some-list*)
Modifying literal data? Hmmmm ...
>
> => *sum* *length* *avg* ?
>
> (push 7 *some-list*)
>
> => *sum* *length* *avg* ?
>
> (push 8 *some-list*)
>
> => *sum* *length* *avg* ?
>
>
> Especially: How long will this take? In each turn? What about very large
> lists?
>
>
> Pascal
>
Peter Hildebrandt wrote:
> Pascal Costanza wrote:
>
>> Ken Tilton wrote:
>>
>>>
>>>
>>> Pascal Costanza wrote:
>>>
>>>> Ken Tilton wrote:
>>>>
>>>>> You don't like spinning letters? I recall a gasp from the audience.
>>>>
>>>>
>>>>
>>>> Ah yes, that sounds particularly interesting for real-world
>>>> applications.
>>>
>>>
>>> You are no fun.
>>>
>>> How about the dataflow into, across, and back out of the RDF triple
>>> store? You don't think more reliable real-world systems would arise
>>> from that?
>>
>>
>> (defvar *some-list* '(5 4 3 2 1))
>>
>> (defvar *sum* (reduce #'+ *some-list*))
>> (defvar *length* (length *some-list*))
>> (defvar *avg* (/ *sum* *length*))
>>
>> (push 6 *some-list*)
>
>
> Modifying literal data? Hmmmm ...
That was my initial reaction, but push only needs to change the
symbol-value of *some-list* to the new cons created to hold the new
value -- it is not really altering the literal, tho it has that look
about it.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
> Peter Hildebrandt wrote:
>> Pascal Costanza wrote:
>>> (push 6 *some-list*)
>>
>>
>> Modifying literal data? Hmmmm ...
>
> That was my initial reaction, but push only needs to change the
> symbol-value of *some-list* to the new cons created to hold the new
> value -- it is not really altering the literal, tho it has that look
> about it.
Yep, I should start to think *before* I post.
Thx,
Peter
>
> kt
>
Peter Hildebrandt wrote:
> Pascal Costanza wrote:
>> Ken Tilton wrote:
>>>
>>>
>>> Pascal Costanza wrote:
>>>> Ken Tilton wrote:
>>>>
>>>>> You don't like spinning letters? I recall a gasp from the audience.
>>>>
>>>>
>>>> Ah yes, that sounds particularly interesting for real-world
>>>> applications.
>>>
>>> You are no fun.
>>>
>>> How about the dataflow into, across, and back out of the RDF triple
>>> store? You don't think more reliable real-world systems would arise
>>> from that?
>>
>
> CL-USER> (require 'cells)
> ; loading system definition from /home/fritz/.sbcl/systems/utils-kt.asd
> ; into #<PACKAGE "ASDF0">
> ; registering #<SYSTEM :UTILS-KT {AF15E99}> as UTILS-KT
> NIL
Ah, a real answer, that's something refreshing for a change. Thanks,
Ken. Ah, no, it's Peter. Thanks, Peter.
> CL-USER> (defpackage :testing (:use :cl :cells :utils-kt))
> #<PACKAGE "TESTING">
> CL-USER> (in-package :testing)
> #<PACKAGE "TESTING">
> TESTING> (defmd node () value)
> #<STANDARD-CLASS NODE>
> TESTING> (defvar *some-list* (make-instance 'node :value (c-in (list 5 4
> 3 2 1))))
> *SOME-LIST*
> TESTING> (defvar *sum* (make-instance 'node :value (c? (reduce #'+
> (value *some-list*)))))
> *SUM*
> TESTING> (defvar *length* (make-instance 'node :value (c? (length (value
> *some-list*)))))
> *LENGTH*
> TESTING> (defvar *avg* (make-instance 'node :value (c? (/ (value
> *sum*) (value *length*)))))
> *AVG*
> TESTING> (push 6 (value *some-list*))
> (6 5 4 3 2 1)
> TESTING> (defun vals () (list '*sum* (value *sum*) '*length* (value
> *length*) '*avg* (value *avg*)))
> VALS
>
> TESTING> (vals)
> (*SUM* 21 *LENGTH* 6 *AVG* 7/2)
Whenever *some-list* is changed, do the rules for *sum* and *length*
traverse the whole list over and over again? Or is there a mechanism to
specify how deltas are computed in a more efficient way? Or does Cells
do this automatically for you? That would be impressive.
That will be important once Cells goes for triple stores, because such
stores are primarily collections of large numbers of entries (otherwise
you could just use alists, plists or hash tables).
In other words: Does Cells scale, or is it indeed just for simple
applications?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Peter Hildebrandt wrote:
>
>> Pascal Costanza wrote:
>>
>>> Ken Tilton wrote:
>>>
>>>>
>>>>
>>>> Pascal Costanza wrote:
>>>>
>>>>> Ken Tilton wrote:
>>>>>
>>>>>> You don't like spinning letters? I recall a gasp from the audience.
>>>>>
>>>>>
>>>>>
>>>>> Ah yes, that sounds particularly interesting for real-world
>>>>> applications.
>>>>
>>>>
>>>> You are no fun.
>>>>
>>>> How about the dataflow into, across, and back out of the RDF triple
>>>> store? You don't think more reliable real-world systems would arise
>>>> from that?
>>>
>>>
>>
>> CL-USER> (require 'cells)
>> ; loading system definition from /home/fritz/.sbcl/systems/utils-kt.asd
>> ; into #<PACKAGE "ASDF0">
>> ; registering #<SYSTEM :UTILS-KT {AF15E99}> as UTILS-KT
>> NIL
>
>
> Ah, a real answer, that's something refreshing for a change. Thanks,
> Ken. Ah, no, it's Peter. Thanks, Peter.
>
>> CL-USER> (defpackage :testing (:use :cl :cells :utils-kt))
>> #<PACKAGE "TESTING">
>> CL-USER> (in-package :testing)
>> #<PACKAGE "TESTING">
>> TESTING> (defmd node () value)
>> #<STANDARD-CLASS NODE>
>
>
>> TESTING> (defvar *some-list* (make-instance 'node :value (c-in (list 5
>> 4 3 2 1))))
>> *SOME-LIST*
>
>
>> TESTING> (defvar *sum* (make-instance 'node :value (c? (reduce #'+
>> (value *some-list*)))))
>> *SUM*
>
>
>> TESTING> (defvar *length* (make-instance 'node :value (c? (length
>> (value *some-list*)))))
>> *LENGTH*
>
>
>> TESTING> (defvar *avg* (make-instance 'node :value (c? (/ (value
>> *sum*) (value *length*)))))
>> *AVG*
>
>
>> TESTING> (push 6 (value *some-list*))
>> (6 5 4 3 2 1)
>
>
>> TESTING> (defun vals () (list '*sum* (value *sum*) '*length* (value
>> *length*) '*avg* (value *avg*)))
>> VALS
>>
>> TESTING> (vals)
>> (*SUM* 21 *LENGTH* 6 *AVG* 7/2)
>
>
> Whenever *some-list* is changed, do the rules for *sum* and *length*
> traverse the whole list over and over again? Or is there a mechanism to
> specify how deltas are computed in a more efficient way? Or does Cells
> do this automatically for you? That would be impressive.
Simple engineering. Supporting only push and pop and simply typed in to
give rough ideas:
(defmd precomputed-list ()
data
(len (let (before)
(c? (b-if now (^data))
(+ .cache (if (eq before (cdr now)) 1 -1))
0)))))
(sum (let (before)
(c? (b-if now (^data))
(+ .cache (if (eq before (cdr now))
(car now) (- (car before))))
0)))))
(average (c? (if (zerop (^len)) 0 (/ (^sum) (^len))))))
I have played with off-the-shelf pre-defined list-aware synapses (which
would hide the above wiring) in the past but only for fun so (to beat a
drum) without a Real World Problem I quickly lost interest.
I would not call that automatic as much as "being in the right place at
the right time". Cells is an API for change, living just above
slot-value (just below it when I did a metaclass). So it has the
information needed when it comes time to optimize.
> That will be important once Cells goes for triple stores, because such
> stores are primarily collections of large numbers of entries (otherwise
> you could just use alists, plists or hash tables).
The trick often is to explode/expose change. Still in list context:
(defmd precomputed-list ()
(new-guys (c-in nil) :cell :ephemeral)
(chop-count (c-in nil) :cell :ephemeral)
(len (c? (+ (or .cache 0) (length (^new-guys)) (- (^chop-count))))
(list (c? (append (^new-guys)
(nthcdr (or (^chop-count) 0) .cache)))))
Sum and average as before. Note that one would get only one of new-guys
and chop-count in one atomic Cells change, but (I think) the rule above
handles that gracefully in one computation.
Now you see code like:
(setf (chop-count x) 5)
or:
(setf (new-guys x) (list 1 2 3))
>
> In other words: Does Cells scale, or is it indeed just for simple
> applications?
What part of 80kloc enterpise application supporting clinical drug trial
management including integration of Cells with AllegroStore did you
forget? And if you think this is simple:
http://www.theoryyalgebra.com/demo-20.html
...we need you to get to work on harnessing nuclear fusion.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
>
> Pascal Costanza wrote:
>
>> In other words: Does Cells scale, or is it indeed just for simple
>> applications?
>
>
> What part of 80kloc enterpise application supporting clinical drug trial
> management including integration of Cells with AllegroStore did you
> forget?
btw, longer but so code-y write-up here:
http://smuglispweeny.blogspot.com/2008/03/my-biggest-lisp-project.html
There was a way cool moment I have described before, perhaps here, when
I fed a page awkwardly into the scanner to kick off the
scan-recognize-validate-and-store sequence and when I viewed the results
I got a first ever failure to read /anything/. Stunned and wondering how
I had broken that code without coming near it I looked at the trace
output I always have leaking out of my apps and decided,
"Inconceivable." Recalling I had been a bit awkward with the feed I
decided to see if I had finally found one limit on the robustness of our
recognition component. So I fed the page back in and this time the trace
started showing the right kind of output and decided my guess was right.
Then I had an omigod moment. I had left the document viewer open to the
page I had just rescanned. The gui elements displaying each field got
their value to display by reading the database. Duh. But I had glued
dynamic Cells to persistent Cells. Because we never discarded any data,
the "current value" of a field was by convention the latest value stored
so the dependency of the GUI fiels was on /the set of values/ stored for
the field. The scanning logic was about to write out new values for each
field. Omigod. The scanning trickle (over on monitor two) ended so I
looked back at the form view on monitor one and watched the properly
scanned and recognized data Just Appear.
That was cool. Note that no code was written to do that, nor was the
scenario ever contemplated. Some code Just Wrote data to the database,
and some code Just Read the database. As a result, no user would have
ever called support to claim that they had just scanned in a page ten
times and it still did not work (they believed because they did not
think to exit the view and come back in). Or as Windows Explorer so
helpfully solves, put a "Refresh view" menu item in their applications.
A final note: this all worked /without/ the data integrity defined in
the document you refuse to read, back in the days of wild wild dataflow.
It took RoboCup to force that. Go figure.
As for Cells just being for simple applications, you and Xtophe have
that beautifully and precisely backwards. I know your religion prevents
you from reading the Cells Manifesto, but it is all in there. Look for
the bits where I compare and contrast with Brooks's No Silver Bullet
essays.... oh, no it isn't in there, not very grandly, just a sober
listing of one of Cells's advantages:
"Natural decomposition of overall application complexity into so many
simple rules and slot observers. "
Hmmm, actually that does meet The Kenny Standard for unsober grandiosity
if one understands why large applications are hard.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
> Pascal Costanza wrote:
>> Peter Hildebrandt wrote:
>>
>>> Pascal Costanza wrote:
>>>
>>>> Ken Tilton wrote:
>>>>>
>>>>> How about the dataflow into, across, and back out of the RDF triple
>>>>> store? You don't think more reliable real-world systems would arise
>>>>> from that?
>>>>
>>>
>>> CL-USER> (require 'cells)
>>> ; loading system definition from /home/fritz/.sbcl/systems/utils-kt.asd
>>> ; into #<PACKAGE "ASDF0">
>>> ; registering #<SYSTEM :UTILS-KT {AF15E99}> as UTILS-KT
>>> NIL
>>
>> Ah, a real answer, that's something refreshing for a change. Thanks,
>> Ken. Ah, no, it's Peter. Thanks, Peter.
>>
>>> CL-USER> (defpackage :testing (:use :cl :cells :utils-kt))
>>> #<PACKAGE "TESTING">
>>> CL-USER> (in-package :testing)
>>> #<PACKAGE "TESTING">
>>> TESTING> (defmd node () value)
>>> #<STANDARD-CLASS NODE>
>>
>>> TESTING> (defvar *some-list* (make-instance 'node :value (c-in (list
>>> 5 4 3 2 1))))
>>> *SOME-LIST*
>>
>>> TESTING> (defvar *sum* (make-instance 'node :value (c? (reduce #'+
>>> (value *some-list*)))))
>>> *SUM*
>>
>>> TESTING> (defvar *length* (make-instance 'node :value (c? (length
>>> (value *some-list*)))))
>>> *LENGTH*
>>
>>> TESTING> (defvar *avg* (make-instance 'node :value (c? (/ (value
>>> *sum*) (value *length*)))))
>>> *AVG*
>>
>>> TESTING> (push 6 (value *some-list*))
>>> (6 5 4 3 2 1)
>>
>>> TESTING> (defun vals () (list '*sum* (value *sum*) '*length* (value
>>> *length*) '*avg* (value *avg*)))
>>> VALS
>>>
>>> TESTING> (vals)
>>> (*SUM* 21 *LENGTH* 6 *AVG* 7/2)
>>
>> Whenever *some-list* is changed, do the rules for *sum* and *length*
>> traverse the whole list over and over again? Or is there a mechanism
>> to specify how deltas are computed in a more efficient way? Or does
>> Cells do this automatically for you? That would be impressive.
>
> Simple engineering. Supporting only push and pop and simply typed in to
> give rough ideas:
>
> (defmd precomputed-list ()
> data
> (len (let (before)
> (c? (b-if now (^data))
> (+ .cache (if (eq before (cdr now)) 1 -1))
> 0)))))
> (sum (let (before)
> (c? (b-if now (^data))
> (+ .cache (if (eq before (cdr now))
> (car now) (- (car before))))
> 0)))))
> (average (c? (if (zerop (^len)) 0 (/ (^sum) (^len))))))
>
> I have played with off-the-shelf pre-defined list-aware synapses (which
> would hide the above wiring) in the past but only for fun so (to beat a
> drum) without a Real World Problem I quickly lost interest.
>
> I would not call that automatic as much as "being in the right place at
> the right time". Cells is an API for change, living just above
> slot-value (just below it when I did a metaclass). So it has the
> information needed when it comes time to optimize.
I take this as a "No, Cells doesn't do this for you." (BTW, (if (eq
before (cdr now)) ...) is a good example why I don't trust your code.)
>> That will be important once Cells goes for triple stores, because such
>> stores are primarily collections of large numbers of entries
>> (otherwise you could just use alists, plists or hash tables).
>
> The trick often is to explode/expose change. Still in list context:
>
> (defmd precomputed-list ()
> (new-guys (c-in nil) :cell :ephemeral)
> (chop-count (c-in nil) :cell :ephemeral)
> (len (c? (+ (or .cache 0) (length (^new-guys)) (- (^chop-count))))
> (list (c? (append (^new-guys)
> (nthcdr (or (^chop-count) 0) .cache)))))
>
> Sum and average as before. Note that one would get only one of new-guys
> and chop-count in one atomic Cells change, but (I think) the rule above
> handles that gracefully in one computation.
>
> Now you see code like:
>
> (setf (chop-count x) 5)
>
> or:
>
> (setf (new-guys x) (list 1 2 3))
That looks better, but is not really convincing. You can do the same
thing in plain CLOS, and you have to write roughly the same logic.
(defclass list-container ()
((%elements :initarg :elements
:initform '()
:reader lc-elements)
(%length :initform 0
:reader lc-length)
(%sum :initform 0
:reader lc-sum)))
(defun lc-average (lc)
(/ (lc-sum lc) (lc-length lc)))
(defmethod shared-initialize :after
((lc list-container) slot-names &key elements)
(when elements
(with-slots (%length %sum) lc
(setf %length (length elements))
(setf %sum (reduce #'+ elements)))))
(defmethod add-notify ((lc list-container) element)
(with-slots (%length %sum) lc
(incf %length)
(incf %sum element)))
(defmethod remove-notify ((lc list-container) element)
(with-slots (%length %sum) lc
(decf %length)
(decf %sum element)))
(defmethod push/lc ((lc list-container) element)
(add-notify lc element)
(with-slots (%elements) lc
(push element %elements)))
(defmethod push-on-end/lc ((lc list-container) element)
(add-notify lc element)
(with-slots (%elements) lc
(setf %elements (nconc %elements (list element)))))
(defmethod pushnew/lc ((lc list-container) element)
(with-slots (%elements) lc
(unless (member element %elements)
(push/lc lc element))
%elements))
(defmethod pop/lc ((lc list-container))
(with-slots (%elements) lc
(when %elements
(let ((element (pop %elements)))
(remove-notify lc element)
element))))
(defmethod pop-from-end/lc ((lc list-container))
(with-slots (%elements) lc
(loop for (elm . more) on %elements
while more collect elm into new-elements
finally
(remove-notify lc elm)
(setf %elements new-elements)
(return elm))))
(defmethod remove/lc ((lc list-container) element)
(with-slots (%elements) lc
(loop for (elm . more) on %elements
if (eql elm element) do
(remove-notify lc elm)
(if more
(setf %elements (nconc new-elements more))
(setf %elements new-elements))
(loop-finish)
else collect elm into new-elements)
%elements))
It's a bit more verbose because CLOS is in general a bit more verbose,
plus my code is a bit more complete for illustration purposes.
The underlying assumption of dataflow approaches (like Cells) is that
most of the updates will lead to recomputations that are handled well by
the implicit update propagation mechanisms. As soon as the implicit
propagations don't handle specific kinds of recomputations well, you
have to be explicit again in your code, as the example above shows.
So for applications where most updates are simple enough or fit well in
the schemes anticipated by the dataflow abstractions, a dataflow
approach is a good fit. For applications where this is not the case,
it's not a good fit.
That's actually quite a trivial observation.
The fact that Cells seems to provide the hooks you need to plug in more
complex triggered computations apparently makes you forget that you're
not inside the dataflow paradigm anymore when you do that.
>> In other words: Does Cells scale, or is it indeed just for simple
>> applications?
>
> What part of 80kloc enterpise application supporting clinical drug trial
> management including integration of Cells with AllegroStore did you
> forget? And if you think this is simple:
>
> http://www.theoryyalgebra.com/demo-20.html
>
> ...we need you to get to work on harnessing nuclear fusion.
OK, I see. Back to handwaving again...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>
>> Pascal Costanza wrote:
>>
>>> Peter Hildebrandt wrote:
>>>
>>>> Pascal Costanza wrote:
>>>>
>>>>> Ken Tilton wrote:
>>>>>
>>>>>>
>>>>>> How about the dataflow into, across, and back out of the RDF
>>>>>> triple store? You don't think more reliable real-world systems
>>>>>> would arise from that?
>>>>>
>>>>>
>>>>
>>>> CL-USER> (require 'cells)
>>>> ; loading system definition from /home/fritz/.sbcl/systems/utils-kt.asd
>>>> ; into #<PACKAGE "ASDF0">
>>>> ; registering #<SYSTEM :UTILS-KT {AF15E99}> as UTILS-KT
>>>> NIL
>>>
>>>
>>> Ah, a real answer, that's something refreshing for a change. Thanks,
>>> Ken. Ah, no, it's Peter. Thanks, Peter.
>>>
>>>> CL-USER> (defpackage :testing (:use :cl :cells :utils-kt))
>>>> #<PACKAGE "TESTING">
>>>> CL-USER> (in-package :testing)
>>>> #<PACKAGE "TESTING">
>>>> TESTING> (defmd node () value)
>>>> #<STANDARD-CLASS NODE>
>>>
>>>
>>>> TESTING> (defvar *some-list* (make-instance 'node :value (c-in (list
>>>> 5 4 3 2 1))))
>>>> *SOME-LIST*
>>>
>>>
>>>> TESTING> (defvar *sum* (make-instance 'node :value (c? (reduce #'+
>>>> (value *some-list*)))))
>>>> *SUM*
>>>
>>>
>>>> TESTING> (defvar *length* (make-instance 'node :value (c? (length
>>>> (value *some-list*)))))
>>>> *LENGTH*
>>>
>>>
>>>> TESTING> (defvar *avg* (make-instance 'node :value (c? (/ (value
>>>> *sum*) (value *length*)))))
>>>> *AVG*
>>>
>>>
>>>> TESTING> (push 6 (value *some-list*))
>>>> (6 5 4 3 2 1)
>>>
>>>
>>>> TESTING> (defun vals () (list '*sum* (value *sum*) '*length* (value
>>>> *length*) '*avg* (value *avg*)))
>>>> VALS
>>>>
>>>> TESTING> (vals)
>>>> (*SUM* 21 *LENGTH* 6 *AVG* 7/2)
>>>
>>>
>>> Whenever *some-list* is changed, do the rules for *sum* and *length*
>>> traverse the whole list over and over again? Or is there a mechanism
>>> to specify how deltas are computed in a more efficient way? Or does
>>> Cells do this automatically for you? That would be impressive.
>>
>>
>> Simple engineering. Supporting only push and pop and simply typed in
>> to give rough ideas:
>>
>> (defmd precomputed-list ()
>> data
>> (len (let (before)
>> (c? (b-if now (^data))
>> (+ .cache (if (eq before (cdr now)) 1 -1))
>> 0)))))
>> (sum (let (before)
>> (c? (b-if now (^data))
>> (+ .cache (if (eq before (cdr now))
>> (car now) (- (car before))))
>> 0)))))
>> (average (c? (if (zerop (^len)) 0 (/ (^sum) (^len))))))
>>
>> I have played with off-the-shelf pre-defined list-aware synapses
>> (which would hide the above wiring) in the past but only for fun so
>> (to beat a drum) without a Real World Problem I quickly lost interest.
>>
>> I would not call that automatic as much as "being in the right place
>> at the right time". Cells is an API for change, living just above
>> slot-value (just below it when I did a metaclass). So it has the
>> information needed when it comes time to optimize.
>
>
> I take this as a "No, Cells doesn't do this for you." (BTW, (if (eq
> before (cdr now)) ...) is a good example why I don't trust your code.)
Well, you were the one who decided to base your evaluation of a
promising library on code that requires the extremes one by definition
goes to when optimizing. I think you did this in good faith, a good
example of why your instincts for programming are so bad. Your mind
dashed straight off to a stress-test and now that is all you can see.
>
>>> That will be important once Cells goes for triple stores, because
>>> such stores are primarily collections of large numbers of entries
>>> (otherwise you could just use alists, plists or hash tables).
>>
>>
>> The trick often is to explode/expose change. Still in list context:
>>
>> (defmd precomputed-list ()
>> (new-guys (c-in nil) :cell :ephemeral)
>> (chop-count (c-in nil) :cell :ephemeral)
>> (len (c? (+ (or .cache 0) (length (^new-guys)) (- (^chop-count))))
>> (list (c? (append (^new-guys)
>> (nthcdr (or (^chop-count) 0) .cache)))))
>>
>> Sum and average as before. Note that one would get only one of
>> new-guys and chop-count in one atomic Cells change, but (I think) the
>> rule above handles that gracefully in one computation.
>>
>> Now you see code like:
>>
>> (setf (chop-count x) 5)
>>
>> or:
>>
>> (setf (new-guys x) (list 1 2 3))
>
>
> That looks better, but is not really convincing. You can do the same
> thing in plain CLOS, and you have to write roughly the same logic.
Of course. Not the manifesto but other things I have written list
bottleneck setters (and of course CLOS let's us treat SETF as a
bottleneck by letting us adorn it with before/after/around to do extra
stuff) as prior art for Cells.
Peter Herth did LTk all through the miracle of CLOS, for example, so
there was no need to go through all this:
>
> (defclass list-container ()
> ((%elements :initarg :elements
> :initform '()
> :reader lc-elements)
> (%length :initform 0
> :reader lc-length)
> (%sum :initform 0
> :reader lc-sum)))
>
> (defun lc-average (lc)
> (/ (lc-sum lc) (lc-length lc)))
>
> (defmethod shared-initialize :after
> ((lc list-container) slot-names &key elements)
> (when elements
> (with-slots (%length %sum) lc
> (setf %length (length elements))
> (setf %sum (reduce #'+ elements)))))
>
> (defmethod add-notify ((lc list-container) element)
> (with-slots (%length %sum) lc
> (incf %length)
> (incf %sum element)))
>
> (defmethod remove-notify ((lc list-container) element)
> (with-slots (%length %sum) lc
> (decf %length)
> (decf %sum element)))
>
> (defmethod push/lc ((lc list-container) element)
> (add-notify lc element)
> (with-slots (%elements) lc
> (push element %elements)))
>
> (defmethod push-on-end/lc ((lc list-container) element)
> (add-notify lc element)
> (with-slots (%elements) lc
> (setf %elements (nconc %elements (list element)))))
>
> (defmethod pushnew/lc ((lc list-container) element)
> (with-slots (%elements) lc
> (unless (member element %elements)
> (push/lc lc element))
> %elements))
>
> (defmethod pop/lc ((lc list-container))
> (with-slots (%elements) lc
> (when %elements
> (let ((element (pop %elements)))
> (remove-notify lc element)
> element))))
>
> (defmethod pop-from-end/lc ((lc list-container))
> (with-slots (%elements) lc
> (loop for (elm . more) on %elements
> while more collect elm into new-elements
> finally
> (remove-notify lc elm)
> (setf %elements new-elements)
> (return elm))))
>
> (defmethod remove/lc ((lc list-container) element)
> (with-slots (%elements) lc
> (loop for (elm . more) on %elements
> if (eql elm element) do
> (remove-notify lc elm)
> (if more
> (setf %elements (nconc new-elements more))
> (setf %elements new-elements))
> (loop-finish)
> else collect elm into new-elements)
> %elements))
>
>
> It's a bit more verbose because CLOS is in general a bit more verbose,
> plus my code is a bit more complete for illustration purposes.
Great, super, that is one way to open code a deliberate stress test case
that gets nowhere near the reality of application development. You would
not be an academic by any chance, would you?
>
>
> The underlying assumption of dataflow approaches (like Cells) is that
> most of the updates will lead to recomputations ...
Actually I think it was Buddha (or T-Mobile) that discovered "It's all
connected." It was either one of the sutras or an ad campaign for
weekend calling, I forget.
Anyway, a lot of code does not need Cells. You may recall Tilton's Law:
"All X All the Time is Always Wrong".
> ...that are handled well by
> the implicit update propagation mechanisms. As soon as the implicit
> propagations don't handle specific kinds of recomputations well, you
> have to be explicit again in your code, as the example above shows.
No, that was an optimization problem, a list so long and changing so
often that (reduce #\+ ...) became intractable. I guess I am up to
300kloc of Cells code now and I have not run across that use case, but
feel free to base your evaluation on that. (I understand you have a deep
non-technological need to reject my work.)
>
> So for applications where most updates are simple enough or fit well in
> the schemes anticipated by the dataflow abstractions, a dataflow
> approach is a good fit.
Now you are making an intellectually dishonest leap from "lists short
enough to re-sum any time they change" to "simple applications". Bzzt!
Nice try, though.
What you are missing is that even in the stress-test case where
automatic dataflow would produce too much work, an optimization was
possible even without extending Cells and could have been hidden in a
macro (you should see the f-sensitivyty macro) to make it look slicker
still without extending Cells, and then the rest of the application
model built with Cells would just keep on chugging blissfully unimpacted
by the local chicanery demanded by an optimization problem.
Or do you not run into optimization problems working on those toy
problems academics like? Or when you do dismiss them as something for a
grad student to fix?
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
> Or do you not run into optimization problems working on those toy
> problems academics like? Or when you do dismiss them as something for a
> grad student to fix?
...and from handwaving mode back to insulting mode again.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>
>> Or do you not run into optimization problems working on those toy
>> problems academics like? Or when you do dismiss them as something for
>> a grad student to fix?
>
>
> ...and from handwaving mode back to insulting mode again.
Um, "idiot"? Graciously ignored by me about 3-4 times, never mind the
pre-ECLM explosion of profanity? And you want the high road on behavior?
But you are wise to duck my point about you having fixated on an
optimization problem. Had you continued in that vein I was going to ask
exactly how long these lists were such that (reduce '+ list) was a
performance issue (not that the Cells solution was not fine). I am
tempted to do a benchmark and see if it is at ten or a hundred million
(at which point I was going to ask you why you had more than a hundred
or so things in a list and in what application) but I really do need to
focus on ALgebra.
Face it, dude, you are for reasons I can but will not guess at publicly
out of consideration for you furious with me and have tried to exorcise
this anger by going personal. We learn a deep lesson from this by seeing
how unsatisfying that has been for you.
Erik was always right when he advised his adversaries to look into their
own hearts and not his to escape their pain. Others off-line have
complained to me that you are not usually like this. So ask yourself why
you are acting so out of character. Then ask yourself how you could
change your feelings without changing me. The next step will be
emancipation.
As an example of this, the reason I ignored until now your repeated
gratuitous bricks and stones was that I felt badly that my Usenet fun
and games had cut you so deeply.
If it makes you feel any better, there really is nothing personal going
on. This may not help, but what you took to be personal attacks was
never that, for you are clearly a fine, decent, sincere, and
well-meaning soul. I just authentically find absolutely all your
responses to newbies misguided, and I really do honestly think you have
become obsessed with CLOS as an end in itself. And now in this latest
exchange I see you fixating on a bizarre optimization use case and
ending up with a non-assessing assessment of an important library and
in good faith so we can add the "clearly not a working programmer"
objection to my list of honestly held concerns about your contributions
to c.l.l.
So there will be a consistency in my deplorings of your commentary here
on this Lisp forum arising not from anything personal, rather from the
earnestness of my convictions and your own consistency in forever (as I
see it) robotically helping newbies do crazy things because (as I see
it) you fail to grasp that silly questions arise from someone trying to
solve serious problems and misapplying a new complex tool like Lisp so
they need to be asked what they are doing, not pointed to obscure Lisp
features and tricks to help them continue down their ill-conceived newby
paths
I went thru something like this once with Dr. Weitz, who once lashed
into me here on c.l.l over one of my drumbeat put-downs of LW and
accused me of shilling for Franz. He graciously accepted my rejoinder
that, um, no, those were just my honest feelings about the two tools. It
may be tougher when you are the drum on which I am beating, but the
consolation is the same: the motivation is nothing but techno-professional.
hth, kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Rajappa Iyer wrote:
> Madhu <·······@meer.net> writes:
>
>
>>Take this to your blogs, thx
>
>
> Heh, whatever happened to "take this to email." ? :-)
>
> But yeah, what he said.
>
> rsi
Don't be silly, this is mostly solid software design talk interspersed
with enough flaming to avoid being as dull as you two.
Did you have a question on Cells?
:)
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
>
> Pascal Costanza wrote:
>> Ken Tilton wrote:
>>
>>>
>>> Or do you not run into optimization problems working on those toy
>>> problems academics like? Or when you do dismiss them as something for
>>> a grad student to fix?
>>
>>
>> ...and from handwaving mode back to insulting mode again.
>
> Um, "idiot"? Graciously ignored by me about 3-4 times, never mind the
> pre-ECLM explosion of profanity? And you want the high road on behavior?
Nevermind. I'm going to leave this group for a while. I can't take your
shit anymore.
If people want to discuss CLOS- and MOP-related stuff, I'm happy to
discuss them at the Closer mailing list.
Bye,
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>
>>
>> Pascal Costanza wrote:
>>
>>> Ken Tilton wrote:
>>>
>>>>
>>>> Or do you not run into optimization problems working on those toy
>>>> problems academics like? Or when you do dismiss them as something
>>>> for a grad student to fix?
>>>
>>>
>>>
>>> ...and from handwaving mode back to insulting mode again.
>>
>>
>> Um, "idiot"? Graciously ignored by me about 3-4 times, never mind the
>> pre-ECLM explosion of profanity? And you want the high road on behavior?
>
>
> Nevermind. I'm going to leave this group for a while.
Drama queen!
> I can't take your
> shit anymore.
Well, I went back looking for the post where you cursed me out and I
felt bad for harrassing you so I put you in my killfile and I never
found it but what I did find was you repeatedly coming at me ("Idiot"
being your drumbeat of choice) after someone quoted you saying Cells
code was so bad no one should use it -- I have to think that was a case
of you pining for abuse from The Kenny and hoping to get quoted and once
again draw my fire -- so nice try, but, bzzzt! I believe this is called
"bearding the lion" and in conclusion, ask not whose shit tolls for
thee, its yours. Hemingway. I think I have that right.
>
> If people want to discuss CLOS- and MOP-related stuff, I'm happy to
> discuss them at the Closer mailing list.
AspectL? ContextL? Those are Java ports, yes? To solve problems Java
has? Hmmm... I think you'll get more better papers out of Cells or
whatever you call your fork thereof (computed-class is taken). I have a
MOP-based implementation if you want to start from that.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
>
> Pascal Costanza wrote:
>> If people want to discuss CLOS- and MOP-related stuff, I'm happy to
>> discuss them at the Closer mailing list.
>
> AspectL? ContextL? Those are Java ports, yes? To solve problems Java
> has?
No. Try harder.
> Hmmm... I think you'll get more better papers out of Cells or
> whatever you call your fork thereof (computed-class is taken). I have a
> MOP-based implementation if you want to start from that.
Thanks, I'm doing fine. My libraries are used in production systems, my
users are very happy with those libraries, and both myself and my users
are actually making money with them.
Good luck with your Algebra system.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>
>>
>> Pascal Costanza wrote:
>
>
>>> If people want to discuss CLOS- and MOP-related stuff, I'm happy to
>>> discuss them at the Closer mailing list.
>>
>>
>> AspectL? ContextL? Those are Java ports, yes? To solve problems Java has?
>
>
> No. Try harder.
>
>> Hmmm... I think you'll get more better papers out of Cells or whatever
>> you call your fork thereof (computed-class is taken). I have a
>> MOP-based implementation if you want to start from that.
>
>
> Thanks, I'm doing fine. My libraries are used in production systems, my
> users are very happy with those libraries, and both myself and my users
> are actually making money with them.
Great! You are one up on me so far.
>
> Good luck with your Algebra system.
Thanks, over the hump and polishing for a pre-alpha,
pardon-our-appearance, dont-even-bother-with-bug-reports release Any
Week Now.(tm)
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
>
> Pascal Costanza wrote:
>> Ken Tilton wrote:
>>
>>>
>>>
>>> Pascal Costanza wrote:
>>
>>
>>>> If people want to discuss CLOS- and MOP-related stuff, I'm happy to
>>>> discuss them at the Closer mailing list.
>>>
>>>
>>> AspectL? ContextL? Those are Java ports, yes? To solve problems Java
>>> has?
>>
>>
>> No. Try harder.
>>
>>> Hmmm... I think you'll get more better papers out of Cells or
>>> whatever you call your fork thereof (computed-class is taken). I have
>>> a MOP-based implementation if you want to start from that.
>>
>>
>> Thanks, I'm doing fine. My libraries are used in production systems,
>> my users are very happy with those libraries, and both myself and my
>> users are actually making money with them.
>
> Great! You are one up on me so far.
>
>>
>> Good luck with your Algebra system.
>
> Thanks, over the hump and polishing for a pre-alpha,
> pardon-our-appearance, dont-even-bother-with-bug-reports release Any
> Week Now.(tm)
Have fun with the law suits because of using copyrighted material. ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>
>>
>> Pascal Costanza wrote:
>>
>>> Ken Tilton wrote:
>>>
>>>>
>>>>
>>>> Pascal Costanza wrote:
>>>
>>>
>>>
>>>>> If people want to discuss CLOS- and MOP-related stuff, I'm happy to
>>>>> discuss them at the Closer mailing list.
>>>>
>>>>
>>>>
>>>> AspectL? ContextL? Those are Java ports, yes? To solve problems Java
>>>> has?
>>>
>>>
>>>
>>> No. Try harder.
>>>
>>>> Hmmm... I think you'll get more better papers out of Cells or
>>>> whatever you call your fork thereof (computed-class is taken). I
>>>> have a MOP-based implementation if you want to start from that.
>>>
>>>
>>>
>>> Thanks, I'm doing fine. My libraries are used in production systems,
>>> my users are very happy with those libraries, and both myself and my
>>> users are actually making money with them.
>>
>>
>> Great! You are one up on me so far.
>>
>>>
>>> Good luck with your Algebra system.
>>
>>
>> Thanks, over the hump and polishing for a pre-alpha,
>> pardon-our-appearance, dont-even-bother-with-bug-reports release Any
>> Week Now.(tm)
>
>
> Have fun with the law suits because of using copyrighted material. ;)
>
Thanks for your concern, but...What part of "fair use" do you not
understand?! I am not competitive with their works, I am only using
small portions, and the bits are not essential to what I deliver.
If they insist I take out the bits from their IP and add more from
others or do my own sound effects. Hell, grown-ups at /ECLM/ had not
heard of 2001, I am sure this would be lost on 13-year olds:
http://www.theoryyalgebra.com/demo-15.html
Or maybe they like my other idea: go further and provide complete skins
free to download for co-marketing when new movies are coming out.
Eventually I will have a solid chunk of the teen market to deliver...
hmmm, maybe I /should/ make it free.
You're a business man, what do you think?
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
> Erik was always right when he advised his adversaries to look into their
> own hearts and not his to escape their pain. Others off-line have
> complained to me that you are not usually like this. So ask yourself why
> you are acting so out of character. Then ask yourself how you could
> change your feelings without changing me. The next step will be
> emancipation.
Yes, I understand that you changing is obviously not an option.
Do you have any idea how impudent it is what you're asking here?
> As an example of this, the reason I ignored until now your repeated
> gratuitous bricks and stones was that I felt badly that my Usenet fun
> and games had cut you so deeply.
Hint: Making fun of people, ridiculing them and being arrogant to them
is not nice. You wouldn't do that in real life, so why do you do this on
usenet? Because you feel safe?
You have no idea whatsoever what people went through in their lifes. You
have no idea what making fun of them and treating them in pejorative
ways can do to them. You have no idea what options they have and
especially don't have to change that. And now you're even trying to
become a teacher for personal change in life? You prick.
This is a technical forum. It's about Lisp. Discussions should be
technical exchanges about Lisp. Not about people and their betterment
(or what you consider betterment in your simplistic "philosophy").
> If it makes you feel any better, there really is nothing personal going
> on. This may not help, but what you took to be personal attacks was
> never that, for you are clearly a fine, decent, sincere, and
> well-meaning soul. I just authentically find absolutely all your
> responses to newbies misguided, and I really do honestly think you have
> become obsessed with CLOS as an end in itself.
I welcome you correcting misconceptions and helping find better
solutions to questions being asked. You're good at asking beyond the
obviously stated questions (but you suck and giving direct answers, btw).
However, this is almost never where you stop. You always have to poke
fun at those who you think have been giving "inferior" replies. Why?
Does that make you feel better about yourself? Arsehole.
> And now in this latest
> exchange I see you fixating on a bizarre optimization use case and
> ending up with a non-assessing assessment of an important library and in
> good faith so we can add the "clearly not a working programmer"
> objection to my list of honestly held concerns about your contributions
> to c.l.l.
You have no idea what you are talking about.
> So there will be a consistency in my deplorings of your commentary here
> on this Lisp forum arising not from anything personal, rather from the
> earnestness of my convictions and your own consistency in forever (as I
> see it) robotically helping newbies do crazy things because (as I see
> it) you fail to grasp that silly questions arise from someone trying to
> solve serious problems and misapplying a new complex tool like Lisp so
> they need to be asked what they are doing, not pointed to obscure Lisp
> features and tricks to help them continue down their ill-conceived newby
> paths.
I have already explained to you why I'm focusing on such replies
elsewhere. You're welcome to disagree with my approach, and you're
welcome to give what you think of as better answers. But I'm not going
to change. Deal with it.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>> Erik was always right when he advised his adversaries to look into
>> their own hearts and not his to escape their pain. Others off-line
>> have complained to me that you are not usually like this. So ask
>> yourself why you are acting so out of character. Then ask yourself how
>> you could change your feelings without changing me. The next step will
>> be emancipation.
>
>
> Yes, I understand that you changing is obviously not an option.
>
> Do you have any idea how impudent it is what you're asking here?
Absolutely. Ironic, eh?
>
>> As an example of this, the reason I ignored until now your repeated
>> gratuitous bricks and stones was that I felt badly that my Usenet fun
>> and games had cut you so deeply.
>
>
> Hint: Making fun of people, ridiculing them and being arrogant to them
> is not nice.
That's why I stopped when you cursed me out and put you in my killfile,
I realized I must have crossed a line somewhere, or that you were
over-sensitive, but it did not matter, I did not want to cause you
further discomfit/umbrage.
> You wouldn't do that in real life, so why do you do this on
> usenet? Because you feel safe?
You should see me at the local meetings. But there I do the same thing I
do here, deliberately chew the scenery and act outrageous so that only a
tedious, humorless yobbo would take it seriously.... I did it again,
didn't I? But it is funny how often yobbos confront me in real life
expecting to carry on the McCLIM Wars or something. Weird.
>
> You have no idea whatsoever what people went through in their lifes. You
> have no idea what making fun of them and treating them in pejorative
> ways can do to them. You have no idea what options they have and
> especially don't have to change that.
I know they are on Usenet and I can tell which ones have been on Usenet
a lot and are comfortable with The Usenet Way and that gets factored
into how I treat people /all the time/, so you are basically completely
wrong with that angle of attack. Nice try, though on the
holier-than-thou thing.
> And now you're even trying to
> become a teacher for personal change in life?
You do not want to learn from a "natural", you want to learn from
someone who succeeded only by studying the mechanics of some skill
sufficiently to overachieve.
> You prick.
Irrelevant. Dude, you were safely in my killfile, something I did purely
out of compassion for you. How did you get out? Thanks to something you
wrote that you knew had an excellent chance of reaching me and getting
my attention. If you did not think it through that far, there's your
problem. If you did, Heeeeeeeeeere's Kenny!!!
I said it before and I'll say it again, you are not going to learn
anything from this until you stop worrying about me and start
understanding how you contribute to everything that happens to you. This
is a general rule applying not just to The Kenny.
>
> This is a technical forum. It's about Lisp. Discussions should be
> technical exchanges about Lisp.
Please. This is Usenet. Too late for rules.
> Not about people and their betterment
> (or what you consider betterment in your simplistic "philosophy").
Telling me what not to talk about on Usenet is against the rules.
>
>> If it makes you feel any better, there really is nothing personal
>> going on. This may not help, but what you took to be personal attacks
>> was never that, for you are clearly a fine, decent, sincere, and
>> well-meaning soul. I just authentically find absolutely all your
>> responses to newbies misguided, and I really do honestly think you
>> have become obsessed with CLOS as an end in itself.
>
>
> I welcome you correcting misconceptions and helping find better
> solutions to questions being asked. You're good at asking beyond the
> obviously stated questions (but you suck and giving direct answers, btw).
Examples? Anyway, I happen also to be a teacher and take that seriously
as well. Give me a fish, teach me to fish, yadda yadda...
>
> However, this is almost never where you stop. You always have to poke
> fun at those who you think have been giving "inferior" replies. Why?
> Does that make you feel better about yourself? Arsehole.
I guess a blowjob is completely out of the question? Yes, you and almost
everyone else here do post the silliest help always trying to help
clueless noobs write the code they just happened to crash into first.
The fun will poke on.
>
>> And now in this latest exchange I see you fixating on a bizarre
>> optimization use case and ending up with a non-assessing assessment of
>> an important library and in good faith so we can add the "clearly not
>> a working programmer" objection to my list of honestly held concerns
>> about your contributions to c.l.l.
>
>
> You have no idea what you are talking about.
Yes, I am glad to hear elsewhere you also have a commerical angle going,
I stand corrected. As I said elsewhere, the libraries certainly are Real
World. Good luck with that stuff.
> I have already explained to you why I'm focusing on such replies
> elsewhere. You're welcome to disagree with my approach, and you're
> welcome to give what you think of as better answers. But I'm not going
> to change. Deal with it.
>
I put you in my killfile when I realized you had had enough of me. I am
in non-killfile mode these days, but it may not seem that way to you. :)
peace, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
>> I have played with off-the-shelf pre-defined list-aware synapses
>> (which would hide the above wiring) in the past but only for fun so
>> (to beat a drum) without a Real World Problem I quickly lost interest.
>>
>> I would not call that automatic as much as "being in the right place
>> at the right time". Cells is an API for change, living just above
>> slot-value (just below it when I did a metaclass). So it has the
>> information needed when it comes time to optimize.
>
>
> I take this as a "No, Cells doesn't do this for you."
By "this" do you mean "I would not call that automatic"? You have obtuse
turned up to eleven, don't you?
Here's a pop quiz for young programmers: what would be cooler, having
Cells extended to efficiently handle lists, or achieving the same by
having a rule close over a variable it can use to augment the
declarative thing with a little tracking over time of state from prior
invocations of the otherwise declarative rule?
Hint: the answer is the same as for whether it was cooler implementing
cells with a metaclass or with macrology.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
The post I'm responding to is three days old now because I thought the
misconceptions/misunderstandings were worth responding to.
On Jun 3, 10:23 pm, Pascal Costanza <····@p-cos.net> wrote:
> Ken Tilton wrote:
>
> > Pascal Costanza wrote:
> >> Peter Hildebrandt wrote:
>
> >>> Pascal Costanza wrote:
>
> >>>> Ken Tilton wrote:
Pascal Costanza wrote:
> >> Whenever *some-list* is changed, do the rules for *sum* and *length*
> >> traverse the whole list over and over again? Or is there a mechanism
> >> to specify how deltas are computed in a more efficient way? Or does
> >> Cells do this automatically for you? That would be impressive.
Yes, they get reevaluated again. In the very simple way of expressing
this in Cells, more or less the same computations happen as with a
simple functional formulation of the same. Cells is a sophisticated
extension to object orientation that brings a lot of the feel of
declarative and functional programming into the flow. But it doesn't
automatically fix your inefficient use of cons cells.
I said automatically, because there are all sorts of tricks you could
do here -- using carefully-placed laziness, smarter change-detection,
recomputation making use of previous values, etc. These things
sometimes have their place. Here though, if running down the lists
every time is unacceptably inefficient, you're probably using the
wrong data structure.
And that's where these sorts of systems shine.
Ken Tilton wrote:
> > Simple engineering. Supporting only push and pop and simply typed in to
> > give rough ideas:
>
> > (defmd precomputed-list ()
> > data
> > (len (let (before)
> > (c? (b-if now (^data))
> > (+ .cache (if (eq before (cdr now)) 1 -1))
> > 0)))))
> > (sum (let (before)
> > (c? (b-if now (^data))
> > (+ .cache (if (eq before (cdr now))
> > (car now) (- (car before))))
> > 0)))))
> > (average (c? (if (zerop (^len)) 0 (/ (^sum) (^len))))))
>
> > I have played with off-the-shelf pre-defined list-aware synapses (which
> > would hide the above wiring) in the past but only for fun so (to beat a
> > drum) without a Real World Problem I quickly lost interest.
And here is Ken falling into the trap he often criticizes others for
falling into. If you had a real problem where this came up, the
solution would probably be much simpler; not that the above wouldn't
work if you're really sold on conses. But this is something more like
what my code tends to look like:
(defmodel node ()
((next :initval (cv nil))
(len :initval (c? (if (^next)
(1+ (len (^next)))
1)))))
Or even:
(defmodel node ()
((parent :initval (cv nil))
(children :initval (cv nil))
(height :initval (c? (if (^children)
(1+ (apply #'max (height (^children))))
0)))
(depth :initval (c? (if (^parent) (1+ (depth (^parent))) 0))
(breadth :initval (c-formula (:lazy :until-asked)
(length (children (^parent))))))
Now you have parts of a tree that you can splice and dice and insert
and remove portions of, without worrying about maintaining all of your
invariants. They maintain themselves.
> I take this as a "No, Cells doesn't do this for you."
Right, it gives you powerful tools above and beyond what CLOS does to
make it easy to make your own correct data structures.
> (BTW, (if (eq before (cdr now)) ...) is a good example why I don't trust your code.)
?!?!?! really? Whatever the abbreviation is for (c-formula
(:lazy :until-asked) ...) is the reason I find Ken's code sometimes
hard to read. Code like the above is no more of a reason to distrust
someone's code than is the fact that they use recursion. *hint*
*hint*. This is just the dataflow version of recursion. A lot of
people fear it until they get the hang of thinking in those terms, but
that's just growing pains.
> That looks better, but is not really convincing. You can do the same
> thing in plain CLOS, and you have to write roughly the same logic.
What the hell?! You follow this statement with something like 50 times
the amount of code that Ken posted. Ugly, imperative, modification-
heavy code. Yes, of course you can do it by hand in CLOS. And it's a
huge amount of error prone work. The whole point of systems like Cells
is to give you easy, mostly functional, mostly declarative ways to
express efficient, correct propagation of change and maintenance of
invariants. That's the core, main value proposition. Hell, I can write
an equivalent program in elegant, plain Power PC assembler.
> The fact that Cells seems to provide the hooks you need to plug in more
> complex triggered computations apparently makes you forget that you're
> not inside the dataflow paradigm anymore when you do that.
No. When you *do* need to do that you're painfully aware of it. But
it's rare, and when you need to do it, you do so just long enough to
launch yourself back into the nice declarative world. But you haven't
even seen an example of that here, all you saw was the equivalent of a
couple ugly recursions. Bug whup.
> >> In other words: Does Cells scale, or is it indeed just for simple
> >> applications?
Yes. The whole point is that it scales, whereas managing the sam state
by hand does not.
Thomas F. Burdick wrote:
> The post I'm responding to is three days old now because I thought the
> misconceptions/misunderstandings were worth responding to.
>
> On Jun 3, 10:23 pm, Pascal Costanza <····@p-cos.net> wrote:
>
>>Ken Tilton wrote:
>>
>>
>>>Pascal Costanza wrote:
>>>
>>>>Peter Hildebrandt wrote:
>>
>>>>>Pascal Costanza wrote:
>>
>>>>>>Ken Tilton wrote:
>
>
> Pascal Costanza wrote:
>
>
>>>>Whenever *some-list* is changed, do the rules for *sum* and *length*
>>>>traverse the whole list over and over again? Or is there a mechanism
>>>>to specify how deltas are computed in a more efficient way? Or does
>>>>Cells do this automatically for you? That would be impressive.
>
>
> Yes, they get reevaluated again. In the very simple way of expressing
> this in Cells, more or less the same computations happen as with a
> simple functional formulation of the same. Cells is a sophisticated
> extension to object orientation that brings a lot of the feel of
> declarative and functional programming into the flow. But it doesn't
> automatically fix your inefficient use of cons cells.
>
> I said automatically, because there are all sorts of tricks you could
> do here -- using carefully-placed laziness, smarter change-detection,
> recomputation making use of previous values, etc. These things
> sometimes have their place. Here though, if running down the lists
> every time is unacceptably inefficient, you're probably using the
> wrong data structure.
>
> And that's where these sorts of systems shine.
>
> Ken Tilton wrote:
>
>
>>>Simple engineering. Supporting only push and pop and simply typed in to
>>>give rough ideas:
>>
>>>(defmd precomputed-list ()
>>> data
>>> (len (let (before)
>>> (c? (b-if now (^data))
>>> (+ .cache (if (eq before (cdr now)) 1 -1))
>>> 0)))))
>>> (sum (let (before)
>>> (c? (b-if now (^data))
>>> (+ .cache (if (eq before (cdr now))
>>> (car now) (- (car before))))
>>> 0)))))
>>> (average (c? (if (zerop (^len)) 0 (/ (^sum) (^len))))))
>>
>>>I have played with off-the-shelf pre-defined list-aware synapses (which
>>>would hide the above wiring) in the past but only for fun so (to beat a
>>>drum) without a Real World Problem I quickly lost interest.
>
>
> And here is Ken falling into the trap he often criticizes others for
> falling into. If you had a real problem where this came up, the
> solution would probably be much simpler; not that the above wouldn't
> work if you're really sold on conses. But this is something more like
> what my code tends to look like:
>
> (defmodel node ()
> ((next :initval (cv nil))
> (len :initval (c? (if (^next)
> (1+ (len (^next)))
> 1)))))
>
> Or even:
>
> (defmodel node ()
> ((parent :initval (cv nil))
> (children :initval (cv nil))
> (height :initval (c? (if (^children)
> (1+ (apply #'max (height (^children))))
> 0)))
> (depth :initval (c? (if (^parent) (1+ (depth (^parent))) 0))
> (breadth :initval (c-formula (:lazy :until-asked)
> (length (children (^parent))))))
>
> Now you have parts of a tree that you can splice and dice and insert
> and remove portions of, without worrying about maintaining all of your
> invariants. They maintain themselves.
>
>
>>I take this as a "No, Cells doesn't do this for you."
>
>
> Right, it gives you powerful tools above and beyond what CLOS does to
> make it easy to make your own correct data structures.
>
>
>>(BTW, (if (eq before (cdr now)) ...) is a good example why I don't trust your code.)
>
>
> ?!?!?! really? Whatever the abbreviation is for (c-formula
> (:lazy :until-asked) ...) is the reason I find Ken's code sometimes
> hard to read.
Do what I do (with my own code): control-alt-.
I believe lazy until asked is c_?, the mnemonic being "lying down at
first, then responsive to change". c?_ is then "lazy once asked", tho I
am sure that goes without explaining.
I might have that backwards.
> Code like the above is no more of a reason to distrust
> someone's code than is the fact that they use recursion. *hint*
> *hint*. This is just the dataflow version of recursion. A lot of
> people fear it until they get the hang of thinking in those terms, but
> that's just growing pains.
I belatedly realized that an issue here was indeed the unusual code (and
mindset) the declarative paradigm sometimes demands of us. In some cases
it does make me think harder in return for the benefits of being
declarative, but that only makes it more fun (in small doses).
>
>
>>That looks better, but is not really convincing. You can do the same
>>thing in plain CLOS, and you have to write roughly the same logic.
>
>
> What the hell?! You follow this statement with something like 50 times
> the amount of code that Ken posted. Ugly, imperative, modification-
> heavy code. Yes, of course you can do it by hand in CLOS. And it's a
> huge amount of error prone work. The whole point of systems like Cells
> is to give you easy, mostly functional, mostly declarative ways to
> express efficient, correct propagation of change and maintenance of
> invariants. That's the core, main value proposition. Hell, I can write
> an equivalent program in elegant, plain Power PC assembler.
>
>
>>The fact that Cells seems to provide the hooks you need to plug in more
>>complex triggered computations apparently makes you forget that you're
>>not inside the dataflow paradigm anymore when you do that.
>
>
> No. When you *do* need to do that you're painfully aware of it. But
> it's rare, and when you need to do it, you do so just long enough to
> launch yourself back into the nice declarative world. But you haven't
> even seen an example of that here, all you saw was the equivalent of a
> couple ugly recursions. Bug whup.
I should talk about how the Algebra solver works someday cuz it is the
kinda thing that does not seem declarative on the face of it. And no
change is involved! Solutions get computed and boom that is it. Not sure
why I used Cells--I recall not being sure about doing so. It still led
to a clean decomposition of the larger problem, but most code does that.
Anyway in the end I had this omigod moment when for some reason in
mid-solution I decided I wanted to take an intermediate expression and
reduce it to simplest form (using of course the same problem-solving
logic).
I groaned at the task I anticipated of carving out from the solution
engine a little standalone solver and set to work, examining my code to
see where the hell I actually invoked the solver. Turns out I never did,
it was an OO/declarative kinda thing:
(answer (make-instance 'problem
:instructions 'factor
:statement (mmx "x^2-1")))
=> "(x+1)(x-1)"
That was cool.
The alternative would have been procedural code building up the same
data structures that emerge during the solution of a problem. Over here
is the code building up the data, over here is the data with values just
sitting there and I wonder what code put them there. Ah, maybe that is
it. In this case the advantage is just that it is declarative, so behind
every value is a rule I know produced it.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Thomas F. Burdick wrote:
> The post I'm responding to is three days old now because I thought the
> misconceptions/misunderstandings were worth responding to.
>
> On Jun 3, 10:23 pm, Pascal Costanza <····@p-cos.net> wrote:
>> Ken Tilton wrote:
>>
>>> Pascal Costanza wrote:
>>>> Peter Hildebrandt wrote:
>>>>> Pascal Costanza wrote:
>>>>>> Ken Tilton wrote:
>
> Pascal Costanza wrote:
>
>>>> Whenever *some-list* is changed, do the rules for *sum* and *length*
>>>> traverse the whole list over and over again? Or is there a mechanism
>>>> to specify how deltas are computed in a more efficient way? Or does
>>>> Cells do this automatically for you? That would be impressive.
>
> Yes, they get reevaluated again. In the very simple way of expressing
> this in Cells, more or less the same computations happen as with a
> simple functional formulation of the same. Cells is a sophisticated
> extension to object orientation that brings a lot of the feel of
> declarative and functional programming into the flow. But it doesn't
> automatically fix your inefficient use of cons cells.
Yep, I figured so.
> I said automatically, because there are all sorts of tricks you could
> do here -- using carefully-placed laziness, smarter change-detection,
> recomputation making use of previous values, etc. These things
> sometimes have their place. Here though, if running down the lists
> every time is unacceptably inefficient, you're probably using the
> wrong data structure.
Maybe.
> Ken Tilton wrote:
>
>>> Simple engineering. Supporting only push and pop and simply typed in to
>>> give rough ideas:
>>> (defmd precomputed-list ()
>>> data
>>> (len (let (before)
>>> (c? (b-if now (^data))
>>> (+ .cache (if (eq before (cdr now)) 1 -1))
>>> 0)))))
>>> (sum (let (before)
>>> (c? (b-if now (^data))
>>> (+ .cache (if (eq before (cdr now))
>>> (car now) (- (car before))))
>>> 0)))))
>>> (average (c? (if (zerop (^len)) 0 (/ (^sum) (^len))))))
>>> I have played with off-the-shelf pre-defined list-aware synapses (which
>>> would hide the above wiring) in the past but only for fun so (to beat a
>>> drum) without a Real World Problem I quickly lost interest.
>
> And here is Ken falling into the trap he often criticizes others for
> falling into. If you had a real problem where this came up, the
> solution would probably be much simpler; not that the above wouldn't
> work if you're really sold on conses. But this is something more like
> what my code tends to look like:
>
> (defmodel node ()
> ((next :initval (cv nil))
> (len :initval (c? (if (^next)
> (1+ (len (^next)))
> 1)))))
>
> Or even:
>
> (defmodel node ()
> ((parent :initval (cv nil))
> (children :initval (cv nil))
> (height :initval (c? (if (^children)
> (1+ (apply #'max (height (^children))))
> 0)))
> (depth :initval (c? (if (^parent) (1+ (depth (^parent))) 0))
> (breadth :initval (c-formula (:lazy :until-asked)
> (length (children (^parent))))))
>
> Now you have parts of a tree that you can splice and dice and insert
> and remove portions of, without worrying about maintaining all of your
> invariants. They maintain themselves.
>
>> I take this as a "No, Cells doesn't do this for you."
>
> Right, it gives you powerful tools above and beyond what CLOS does to
> make it easy to make your own correct data structures.
>
>> (BTW, (if (eq before (cdr now)) ...) is a good example why I don't trust your code.)
>
> ?!?!?! really? Whatever the abbreviation is for (c-formula
> (:lazy :until-asked) ...) is the reason I find Ken's code sometimes
> hard to read. Code like the above is no more of a reason to distrust
> someone's code than is the fact that they use recursion. *hint*
> *hint*. This is just the dataflow version of recursion. A lot of
> people fear it until they get the hang of thinking in those terms, but
> that's just growing pains.
My problem is not with the recursion. My problem is with the way he
tries to detect whether someone called push or pop. This will work only
for those two operations. If more list-modifying operations are added,
this will probably break.
This kind of ad hoc code is what causes my mistrust.
>> That looks better, but is not really convincing. You can do the same
>> thing in plain CLOS, and you have to write roughly the same logic.
>
> What the hell?! You follow this statement with something like 50 times
> the amount of code that Ken posted. Ugly, imperative, modification-
> heavy code. Yes, of course you can do it by hand in CLOS. And it's a
> huge amount of error prone work. The whole point of systems like Cells
> is to give you easy, mostly functional, mostly declarative ways to
> express efficient, correct propagation of change and maintenance of
> invariants. That's the core, main value proposition. Hell, I can write
> an equivalent program in elegant, plain Power PC assembler.
My CLOS code was quite different from Kenny's code, and wasn't an
attempt to replicate his solution exactly. The reason is that I have
written that in parallel to his reply, before I saw his solution. One
reason why my code is much longer is that it already has a hook to add
more list-manipulating operations, so it should in principle be more
robust in that regard (but without extensive testing, you never know, of
course).
The important part, though, is that the necessary logic to make updating
the lists efficient is more or less the same in Kenny's, mine and your
solution. There is no real way around that, it seems. The dataflow
approach doesn't seem to provide a more natural way to deal with such a
situation. It actually requires you to adapt your solution to the
language constructs provided, not the other way around how it should be
(and what seemingly works well with simpler data structures in Cells).
>> The fact that Cells seems to provide the hooks you need to plug in more
>> complex triggered computations apparently makes you forget that you're
>> not inside the dataflow paradigm anymore when you do that.
>
> No. When you *do* need to do that you're painfully aware of it. But
> it's rare, and when you need to do it, you do so just long enough to
> launch yourself back into the nice declarative world. But you haven't
> even seen an example of that here, all you saw was the equivalent of a
> couple ugly recursions. Bug whup.
I already said this in a previous posting in this thread. The assumption
is that most of the time, you don't have to poke around with the
internal details of dataflow, but that it just "automagically" works. Sure.
>>>> In other words: Does Cells scale, or is it indeed just for simple
>>>> applications?
>
> Yes. The whole point is that it scales, whereas managing the sam state
> by hand does not.
Kenny has suggested the use of Cells with RDF several times. Triplet
stores are, as far as I understand it, large collections of data. (If
they weren't large, they wouldn't make much sense, would they?) In
certain applications, having statistics about large amounts of data is
pretty essential. I'm questioning that something like Cells is a good
solution there.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Jun 10, 3:37 am, Pascal Costanza <····@p-cos.net> wrote:
> Thomas F. Burdick wrote:
> > The post I'm responding to is three days old now because I thought the
> > misconceptions/misunderstandings were worth responding to.
>
> > On Jun 3, 10:23 pm, Pascal Costanza <····@p-cos.net> wrote:
> >> Ken Tilton wrote:
>
> >>> Pascal Costanza wrote:
> >>>> Peter Hildebrandt wrote:
> >>>>> Pascal Costanza wrote:
> >>>>>> Ken Tilton wrote:
>
> > Pascal Costanza wrote:
>
> >>>> Whenever *some-list* is changed, do the rules for *sum* and *length*
> >>>> traverse the whole list over and over again? Or is there a mechanism
> >>>> to specify how deltas are computed in a more efficient way? Or does
> >>>> Cells do this automatically for you? That would be impressive.
>
> > Yes, they get reevaluated again. In the very simple way of expressing
> > this in Cells, more or less the same computations happen as with a
> > simple functional formulation of the same. Cells is a sophisticated
> > extension to object orientation that brings a lot of the feel of
> > declarative and functional programming into the flow. But it doesn't
> > automatically fix your inefficient use of cons cells.
>
> Yep, I figured so.
>
> > I said automatically, because there are all sorts of tricks you could
> > do here -- using carefully-placed laziness, smarter change-detection,
> > recomputation making use of previous values, etc. These things
> > sometimes have their place. Here though, if running down the lists
> > every time is unacceptably inefficient, you're probably using the
> > wrong data structure.
>
> Maybe.
>
>
>
> > Ken Tilton wrote:
>
> >>> Simple engineering. Supporting only push and pop and simply typed in to
> >>> give rough ideas:
> >>> (defmd precomputed-list ()
> >>> data
> >>> (len (let (before)
> >>> (c? (b-if now (^data))
> >>> (+ .cache (if (eq before (cdr now)) 1 -1))
> >>> 0)))))
> >>> (sum (let (before)
> >>> (c? (b-if now (^data))
> >>> (+ .cache (if (eq before (cdr now))
> >>> (car now) (- (car before))))
> >>> 0)))))
> >>> (average (c? (if (zerop (^len)) 0 (/ (^sum) (^len))))))
> >>> I have played with off-the-shelf pre-defined list-aware synapses (which
> >>> would hide the above wiring) in the past but only for fun so (to beat a
> >>> drum) without a Real World Problem I quickly lost interest.
>
> > And here is Ken falling into the trap he often criticizes others for
> > falling into. If you had a real problem where this came up, the
> > solution would probably be much simpler; not that the above wouldn't
> > work if you're really sold on conses. But this is something more like
> > what my code tends to look like:
>
> > (defmodel node ()
> > ((next :initval (cv nil))
> > (len :initval (c? (if (^next)
> > (1+ (len (^next)))
> > 1)))))
>
> > Or even:
>
> > (defmodel node ()
> > ((parent :initval (cv nil))
> > (children :initval (cv nil))
> > (height :initval (c? (if (^children)
> > (1+ (apply #'max (height (^children))))
> > 0)))
> > (depth :initval (c? (if (^parent) (1+ (depth (^parent))) 0))
> > (breadth :initval (c-formula (:lazy :until-asked)
> > (length (children (^parent))))))
>
> > Now you have parts of a tree that you can splice and dice and insert
> > and remove portions of, without worrying about maintaining all of your
> > invariants. They maintain themselves.
>
> >> I take this as a "No, Cells doesn't do this for you."
>
> > Right, it gives you powerful tools above and beyond what CLOS does to
> > make it easy to make your own correct data structures.
>
> >> (BTW, (if (eq before (cdr now)) ...) is a good example why I don't trust your code.)
>
> > ?!?!?! really? Whatever the abbreviation is for (c-formula
> > (:lazy :until-asked) ...) is the reason I find Ken's code sometimes
> > hard to read. Code like the above is no more of a reason to distrust
> > someone's code than is the fact that they use recursion. *hint*
> > *hint*. This is just the dataflow version of recursion. A lot of
> > people fear it until they get the hang of thinking in those terms, but
> > that's just growing pains.
>
> My problem is not with the recursion. My problem is with the way he
> tries to detect whether someone called push or pop. This will work only
> for those two operations. If more list-modifying operations are added,
> this will probably break.
>
> This kind of ad hoc code is what causes my mistrust.
>
> >> That looks better, but is not really convincing. You can do the same
> >> thing in plain CLOS, and you have to write roughly the same logic.
>
> > What the hell?! You follow this statement with something like 50 times
> > the amount of code that Ken posted. Ugly, imperative, modification-
> > heavy code. Yes, of course you can do it by hand in CLOS. And it's a
> > huge amount of error prone work. The whole point of systems like Cells
> > is to give you easy, mostly functional, mostly declarative ways to
> > express efficient, correct propagation of change and maintenance of
> > invariants. That's the core, main value proposition. Hell, I can write
> > an equivalent program in elegant, plain Power PC assembler.
>
> My CLOS code was quite different from Kenny's code, and wasn't an
> attempt to replicate his solution exactly. The reason is that I have
> written that in parallel to his reply, before I saw his solution. One
> reason why my code is much longer is that it already has a hook to add
> more list-manipulating operations, so it should in principle be more
> robust in that regard (but without extensive testing, you never know, of
> course).
>
> The important part, though, is that the necessary logic to make updating
> the lists efficient is more or less the same in Kenny's, mine and your
> solution. There is no real way around that, it seems. The dataflow
> approach doesn't seem to provide a more natural way to deal with such a
> situation. It actually requires you to adapt your solution to the
> language constructs provided, not the other way around how it should be
> (and what seemingly works well with simpler data structures in Cells).
>
> >> The fact that Cells seems to provide the hooks you need to plug in more
> >> complex triggered computations apparently makes you forget that you're
> >> not inside the dataflow paradigm anymore when you do that.
>
> > No. When you *do* need to do that you're painfully aware of it. But
> > it's rare, and when you need to do it, you do so just long enough to
> > launch yourself back into the nice declarative world. But you haven't
> > even seen an example of that here, all you saw was the equivalent of a
> > couple ugly recursions. Bug whup.
>
> I already said this in a previous posting in this thread. The assumption
> is that most of the time, you don't have to poke around with the
> internal details of dataflow, but that it just "automagically" works. Sure.
>
> >>>> In other words: Does Cells scale, or is it indeed just for simple
> >>>> applications?
>
> > Yes. The whole point is that it scales, whereas managing the sam state
> > by hand does not.
>
> Kenny has suggested the use of Cells with RDF several times. Triplet
> stores are, as far as I understand it, large collections of data. (If
> they weren't large, they wouldn't make much sense, would they?) In
> certain applications, having statistics about large amounts of data is
> pretty essential. I'm questioning that something like Cells is a good
> solution there.
>
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
Pascal, there is often something new to learn from your cll posts, so
please don't go away. It's good to have you back.
agt
Pascal Costanza wrote:
> Thomas F. Burdick wrote:
>
>> The post I'm responding to is three days old now because I thought the
>> misconceptions/misunderstandings were worth responding to.
>>
>> On Jun 3, 10:23 pm, Pascal Costanza <····@p-cos.net> wrote:
>>
>>> Ken Tilton wrote:
>>>
>>>> Pascal Costanza wrote:
>>>>
>>>>> Peter Hildebrandt wrote:
>>>>>
>>>>>> Pascal Costanza wrote:
>>>>>>
>>>>>>> Ken Tilton wrote:
>>
>>
>> Pascal Costanza wrote:
>>
>>>>> Whenever *some-list* is changed, do the rules for *sum* and *length*
>>>>> traverse the whole list over and over again? Or is there a mechanism
>>>>> to specify how deltas are computed in a more efficient way? Or does
>>>>> Cells do this automatically for you? That would be impressive.
>>
>>
>> Yes, they get reevaluated again. In the very simple way of expressing
>> this in Cells, more or less the same computations happen as with a
>> simple functional formulation of the same. Cells is a sophisticated
>> extension to object orientation that brings a lot of the feel of
>> declarative and functional programming into the flow. But it doesn't
>> automatically fix your inefficient use of cons cells.
>
>
> Yep, I figured so.
>
>> I said automatically, because there are all sorts of tricks you could
>> do here -- using carefully-placed laziness, smarter change-detection,
>> recomputation making use of previous values, etc. These things
>> sometimes have their place. Here though, if running down the lists
>> every time is unacceptably inefficient, you're probably using the
>> wrong data structure.
>
>
> Maybe.
I am starting to wonder what is going on here. I am no PhD smart
OlogN-savvy kinda guy, but isn't there something a tad ineluctable about
the runtime cost of some of these deals? What would Cells or OpenGL or a
new kind of tennis racquet be able to do about that? And why were you
looking for it in Cells, which does something else?
>
>> Ken Tilton wrote:
>>
>>>> Simple engineering. Supporting only push and pop and simply typed in to
>>>> give rough ideas:
>>>> (defmd precomputed-list ()
>>>> data
>>>> (len (let (before)
>>>> (c? (b-if now (^data))
>>>> (+ .cache (if (eq before (cdr now)) 1 -1))
>>>> 0)))))
>>>> (sum (let (before)
>>>> (c? (b-if now (^data))
>>>> (+ .cache (if (eq before (cdr now))
>>>> (car now) (- (car before))))
>>>> 0)))))
>>>> (average (c? (if (zerop (^len)) 0 (/ (^sum) (^len))))))
>>>> I have played with off-the-shelf pre-defined list-aware synapses (which
>>>> would hide the above wiring) in the past but only for fun so (to beat a
>>>> drum) without a Real World Problem I quickly lost interest.
>>
>>
>> And here is Ken falling into the trap he often criticizes others for
>> falling into. If you had a real problem where this came up, the
>> solution would probably be much simpler; not that the above wouldn't
>> work if you're really sold on conses. But this is something more like
>> what my code tends to look like:
>>
>> (defmodel node ()
>> ((next :initval (cv nil))
>> (len :initval (c? (if (^next)
>> (1+ (len (^next)))
>> 1)))))
>>
>> Or even:
>>
>> (defmodel node ()
>> ((parent :initval (cv nil))
>> (children :initval (cv nil))
>> (height :initval (c? (if (^children)
>> (1+ (apply #'max (height (^children))))
>> 0)))
>> (depth :initval (c? (if (^parent) (1+ (depth (^parent))) 0))
>> (breadth :initval (c-formula (:lazy :until-asked)
>> (length (children (^parent))))))
>>
>> Now you have parts of a tree that you can splice and dice and insert
>> and remove portions of, without worrying about maintaining all of your
>> invariants. They maintain themselves.
>>
>>> I take this as a "No, Cells doesn't do this for you."
>>
>>
>> Right, it gives you powerful tools above and beyond what CLOS does to
>> make it easy to make your own correct data structures.
>>
>>> (BTW, (if (eq before (cdr now)) ...) is a good example why I don't
>>> trust your code.)
>>
>>
>> ?!?!?! really? Whatever the abbreviation is for (c-formula
>> (:lazy :until-asked) ...) is the reason I find Ken's code sometimes
>> hard to read. Code like the above is no more of a reason to distrust
>> someone's code than is the fact that they use recursion. *hint*
>> *hint*. This is just the dataflow version of recursion. A lot of
>> people fear it until they get the hang of thinking in those terms, but
>> that's just growing pains.
>
>
> My problem is not with the recursion. My problem is with the way he
> tries to detect whether someone called push or pop. This will work only
> for those two operations.
In other words, "this will work". It was not much a spec (did not even
include "pop", I threw that in out of boredom) so I took the liberty of
handling only the spec (and filling in any missing pieces I liked). It
was just a badly-confused question orthogonal to what Cells does.
If more list-modifying operations are added,
> this will probably break.
>
> This kind of ad hoc code is what causes my mistrust.
Silly questions get silly code. This was really a non-question, because
it was presented without indicating what problem was being solved.
Without knowing that, one does not know the bounds and constraints on
what code can be written. This is why I always ask noobs what they are
really trying to do when I see scary questions, and I suppose you
thinking this was a good question is why you do not.
>
>>> That looks better, but is not really convincing. You can do the same
>>> thing in plain CLOS, and you have to write roughly the same logic.
>>
>>
>> What the hell?! You follow this statement with something like 50 times
>> the amount of code that Ken posted. Ugly, imperative, modification-
>> heavy code. Yes, of course you can do it by hand in CLOS. And it's a
>> huge amount of error prone work. The whole point of systems like Cells
>> is to give you easy, mostly functional, mostly declarative ways to
>> express efficient, correct propagation of change and maintenance of
>> invariants. That's the core, main value proposition. Hell, I can write
>> an equivalent program in elegant, plain Power PC assembler.
>
>
> My CLOS code was quite different from Kenny's code, and wasn't an
> attempt to replicate his solution exactly. The reason is that I have
> written that in parallel to his reply, before I saw his solution. One
> reason why my code is much longer is that it already has a hook to add
> more list-manipulating operations, so it should in principle be more
> robust in that regard (but without extensive testing, you never know, of
> course).
>
> The important part, though, is that the necessary logic to make updating
> the lists efficient is more or less the same in Kenny's, mine and your
> solution. There is no real way around that, it seems.
The light beckons. Thanks for wasting all our time.
> The dataflow
> approach doesn't seem to provide a more natural way to deal with such a
> situation. It actually requires you to adapt your solution to the
> language constructs provided, not the other way around how it should be
> (and what seemingly works well with simpler data structures in Cells).
>
>>> The fact that Cells seems to provide the hooks you need to plug in more
>>> complex triggered computations apparently makes you forget that you're
>>> not inside the dataflow paradigm anymore when you do that.
>>
>>
>> No. When you *do* need to do that you're painfully aware of it. But
>> it's rare, and when you need to do it, you do so just long enough to
>> launch yourself back into the nice declarative world. But you haven't
>> even seen an example of that here, all you saw was the equivalent of a
>> couple ugly recursions. Bug whup.
>
>
> I already said this in a previous posting in this thread. The assumption
> is that most of the time, you don't have to poke around with the
> internal details of dataflow, but that it just "automagically" works. Sure.
>
>>>>> In other words: Does Cells scale, or is it indeed just for simple
>>>>> applications?
>>
>>
>> Yes. The whole point is that it scales, whereas managing the sam state
>> by hand does not.
>
>
> Kenny has suggested the use of Cells with RDF several times. Triplet
> stores are, as far as I understand it, large collections of data. (If
> they weren't large, they wouldn't make much sense, would they?)
Yes they would. You have not listened to my beach video. First few
minutes, I explain why RDF is The Lisp Way of representations. The
Conventional Wisdom is confused. It is like thinking Lisp is for AI.
/Exactly/ like that. Clue: the guy who came up with RDF also came up
with RDB and thinks RDF is better. He is not wrong.
> In
> certain applications, having statistics about large amounts of data is
> pretty essential. I'm questioning that something like Cells is a good
> solution there.
It is perfect for that. Now that we all know that large amounts of data
have a processing cost from which you can run but not hide, the question
becomes how best to cut corners. Cells, sitting at the nexus of change
to data, gives one the ideal framework to hang ones optimizations. Very
early on I did so-called "synapses", local (to another Cell's rule)
anonymous (mediating an arbitrary subform of said rule) Cells which can
be used to modulate either the rate or semantics of the "flow" of data
from the arbitrary subform. If some dependency changes too often
(forcing excessive recomputation) and one sees one can recompute on
every fifth change or only when the emerging value has changed in some
way from the last time one propagated, fuck, use a synapse and yer done.
Right in the middle of the too-often-running-too-slow-computing Cell
rule, and magically it will not compute so often but you /will/ have
complete control over what gets skipped. One can even have the synapse
tune itself over time -- maybe I do not worry about the football
position too much when it is fifty yards away and worry more when it is
five meters a way. The synapse can express that by changing its own
sensitivity as the absolute number being reported decreases. One can go
higher order and increase the sensitvity if one sees the distance
/decreasing/ rapidly. etc etc etc.... The key, as I said at ECLM, is
that Cells is simply a library for change, the most fundamental concept
of all. So it is in a good place to do all sorts of cool things.
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton <·········@gmail.com> wrote:
+---------------
| http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?rev=1.13&root=cells&view=markup
+---------------
Call me stupid, but isn't there a bug in the first example?
(make-instance 'menu-item
:label "Cut"
:enabled (c? (bwhen (f (focus *window*))
(and (typep focus 'text-widget)
(selection-range focus)))))
Shouldn't those last two occurences of FOCUS be F instead?
(make-instance 'menu-item
:label "Cut"
:enabled (c? (bwhen (f (focus *window*))
(and (typep f 'text-widget)
(selection-range f)))))
Or am I misunderstanding BWHEN? [I thought
it was sort of a BIND + WHEN or LET1 + WHEN.]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Ken Tilton <·········@gmail.com> wrote:
> +---------------
> | http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?rev=1.13&root=cells&view=markup
> +---------------
>
> Call me stupid, but isn't there a bug in the first example?
>
> (make-instance 'menu-item
> :label "Cut"
> :enabled (c? (bwhen (f (focus *window*))
> (and (typep focus 'text-widget)
> (selection-range focus)))))
>
> Shouldn't those last two occurences of FOCUS be F instead?
Yep. Thx, kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
> From: Ken Tilton <···········@optonline.net>
> Here is another date:
> "My desire for an algebraic list processing language for artificial
> intelligence work on the IBM 704 computer arose in the summer of 1956
..
> That might be better considered the date of conception ...
That's not really a date of conception. It's more like a date of
intent. Like when you start looking for a girlfriend in second
grade, with some vague idea of someday marrying her and starting a
family, with no idea how penises and vaginas actually work, and
definitely no method to use them yet, not like years later when you
knock her up and a baby is *really* conceived. For conception of
Lisp, we need the final key idea that got the ball rolling, that
made the result nearly inevitable, barring a drastic change of
plans such as an abortion (funding was cut off and principle
investigator got eliminated) or miscarriage (the idea turned out to
be totally wrong and work had to start from scratch with a new idea
which might take years or decades to occur).
I read about somebody putting together the idea of parenthesized
notation for expressing lists with the idea of passing such a list
(with first element the name of a function) to some sort of
interpretor that simply did a table lookup on that first element
and called itself recursively (or emulated such) on the rest of the
elements and then finally called that looked-up function with those
evaluated args. When did that key idea of putting together those
two key concepts cause somebody to *start* actual work on such an
interpretor?
> Oops. Howard, I'm afraid we'll have to put the champagne on ice**:
> "I wrote the first implimenation of a LISP interpreter on the IBM
> 704 at MIT in early in 1959. I hand-compiled John McCarthy's
> "Universal LISP Function"."
Is that ULF what we now call "EVAL"? If so, when did McCarthy first
come up with that idea in clear enough form that the ball started
rolling? That might be analagous to the couple getting "hitched"
and *starting* to seriously do things that would shortly result in
conception. (For hack value, we might even celebrate the 50th
anniversary of the "marriage" of s-expressions for linked-lists
with putting the function in the first-element position i.e. the
left part of the first pair.)
IMO, Lisp deserves more than just a day of celebration, maybe a
whole year. (Sorta like the bicentennial celebration of the events
that led to the USA being formed, including Boston Tea Party, Stamp
Act, Declaration of Independence, Articles of Confederation, and
finally the Constitution, not to mention defeating the British at
Yorktown somewhere along the way. I seem to recall a whole year of
celebration occurred, with multiple parties celebrating each
specific event, right?) We should catch up with celebrating events
that happened more than 50 years ago, presumably including
McCarthy's description of the "Universal LISP Function", then make
announcements of each new event-plus-50-years as it approaches. Did
anybody involved in this keep a diary or journal or lab notebook or
appointment calendar any other document that gave day-by-day clues
as to what might have been happening, that could jog memories as to
how daily events related to the conception and gestation milestones
(such as first kicking and first ultrasound and first "showing")
and birth of Lisp? After birth (crude working LISP interpretor on
704), maybe "first breath" could be when the *second* person tried
it and found that it actually worked, causing word to start getting
around that it was **available** for use already.
So will anybody volunteer to put together a calendar of
50th-anniversary dates and post it on a Web page for reference?
> http://www.iwriteiam.nl/HaCAR_CDR.html
Because of an unfortunate temporary lapse of inspiration, we couldn't
think of any other names for the 2 pointers in a list node than
"address" and "decrement", so we called the functions CAR for
"Contents of Address of Register" and CDR for "Contents of Decrement
of Register".
Actually that's better than Contents of Left part of Register and
Contents of Right part of Register, given that I read somewhere in
these transcripts that for efficiency the left/right are actually
reversed compared to how we draw them in diagrams, and even if
left/right had been correct (not reversed) on some implementation,
it'd be a shame if the terminology locked us into left/right
implemetation.
Now a possibly better name would have been:
Contents of Left part of Cell (CLC)
Contents of Right part of Cell (CRC)
for working with symmetric binary trees, with aliases:
Down Pointer (DP)
Right Pointer (RP)
for working with linked lists that use the same basic two-part
cell. Did the 704 assembler support single-word macros such that
CLC and DP would convert to CAR and the other two would convert to
CDR of the 704 instruction set?
Alternately, instead of Down Pointer, have Contents of Down part of
Cell (CDC), and then always use CRC for the right pointer
regardless of whether it's in a symmetric tree or a linked list.
That means one less macro is needed, so the vacuum tube computer
takes a few seconds less time to process the macro declarations at
the top of the source file.
No, better take the extra time by using two completely different
sets of names, so that anyone looking at the code can *see* at a
glance from just one instruction whether the intention of the
binary cell is to be part of a symmetric binary tree or part of a
linked list where down and right parts have assymmetric purposes.
After several months and giving a few classes in LISP, we realized
that "first" and "rest" were better names, and we (John McCarthy, I
and some of the rest of the AI Project) tried to get people to use
them instead.
I think that was actually wrong, if these binary cells were
intended to be used not just for linked lists
(where "first" and "rest" are appropriate terms),
but also for symmetric binary trees
(where "first" and "rest" are flat out wrong-headed, basically
lying to the reader about the intention/usage, causing the code to
be more inscrutable, like Humpty Dumpty in Lewis Carrol's book who
deliberately used words in misleading ways on the excuse of giving
the person control over the words instead of vice versa, with no
consideration for the listener who was more accustomed to the
ordinary meanings of the words).
Alas, it was too late! We couldn't make it stick at all. So we have
CAR and CDR.
Good, at least for an intention-neutral basic name, which can be
mapped from various aliases as might be invented to express
intention. For linked lists we now have FIRST and REST as aliases
(and unfortuately LAST which really should be called LAST[-]CELL,
then LAST could be defined as the CAR of the LAST[-]CELL,
analagous to NTHCDR and NTH which return cell (or run off end)
and element respectively; LAST[-]CELL isntead of LAST[-]CDR to
emphasize that the result is guaranteed to be a cell whereas
NTHCDR may return a cell or not depending on whether it ran off
the end of the list).
For using the same CAR+CDR cells to build symmetric binary trees,
maybe LEFT and RIGHT would be good aliases if nobody can think of
anything better. It's good that the built-in names were
intention-neutral, so that we had 30-50 years to ponder and debate
the best aliases for specific intentions.
[-] means the hyphen is optional. I'm undecided which way would be best.
LAST[-]CONS would be an alternate name of course.
Four choices to choose from!! Which would y'all prefer?
(Well five choices if you allow the misleading ANSI-CL name "LAST".)
Of course there's the problem that given an empty list, the result
is NIL i.e. () which is not a CONS cell. Still calling the function
LAST is a common source of confusion. Maybe the idea can be that
LAST[-][CONS|CELL] returns the last CONS cell if one is available,
otherwise returns boolean false i.e. NIL to indicate failure, which
by chance/design happens to be the empty list you wanted anyway.
Side remark: The convention in Lisp for failure, such as FIND that
can't find anything, POSITION that can't return a position/index,
is to return NIL, thus many functions are extra-boolean, NIL for
failure, otherwise the proper result. The convention in Java seems
to be to throw a exception in such cases. It's a whole
philosophical viewpoint which standard is best. The Java way means
the programmer *must* take care to catch failure cases, as a
requirement of the language (otherwise your application does the
equivalent of an ABEND, printing a backtrace and quitting). The
Lisp way means that lots of such failure cases can slip through
unnoticed until some other part of the code errors out with
NONNUMERIC ARGUMENT NIL IN <some arithmetic function>, several layers
of code away from where the NIL return value failed to get
defaulted to a reasonable value.
(setq ix2 (position-if #'char-is-delmim str :start ix1))
(setq word (subseq ix1 ix2)) ;Works fine even if POSITION-IF ran off end
(when (<= ix2 (length str)) ...) ;Signals non-num arg error if ran off end
Correct first-line code would have been:
(setq ix2 (or (position-if #'char-is-delmim str :start ix1) (length str)))
The advantage of Lisp in this regard is more-rapid prototyping.
You can write a single line of code, and test it for both success
and failure cases, without needing to first wrap an exception
handler around it.
If we had it to do all over again, like ANSI Very Common Lisp 2010,
maybe we should have a WARNING type of exception which the
interpretator always catches very gently to let the user know that
an exception handler should be wrapped around the code before it's
embedded into a larger piece of code, but for now it'll supply the
value of *DEFAULT-FAILURE-RETURN-VALUE* (which defaults to NIL) as
the return value of the line of code that failed.
Am I the only one who gets stumped by this once a year?:
(typecase (make-instance 'mx-greater-eql)
(mx-greater 'mx-less)
(mx-greater-eql 'mx-less-eql)
(mx-less 'mx-greater)
(mx-less-eql 'mx-greater-eql))
-> 'mx-less
Hunh? The inverse of >= is <= and that's what my code says!...
Doh! Took me thirty minutes to figure out -- left as an exercise for
noobs -- albeit while watching the Yankees win and the Pistons lose.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton <···········@optonline.net> writes:
> Am I the only one who gets stumped by this once a year?:
>
> (typecase (make-instance 'mx-greater-eql)
> (mx-greater 'mx-less)
> (mx-greater-eql 'mx-less-eql)
> (mx-less 'mx-greater)
> (mx-less-eql 'mx-greater-eql))
> -> 'mx-less
>
> Hunh? The inverse of >= is <= and that's what my code says!...
>
> Doh! Took me thirty minutes to figure out -- left as an exercise for
> noobs -- albeit while watching the Yankees win and the Pistons lose.
More OO:
(defgeneric mx-not (mx-comparator)
(:method ((self mx-greater-eql)) 'mx-less)
(:method ((self mx-greater)) 'mx-less-eql)
(:method ((self mx-less-eql)) 'mx-greater)
(:method ((self mx-less)) 'mx-greater-eql))
(defmethod mx-not ((self mx-eql)) 'mx-not-eql)
(defmethod mx-not ((self mx-not-eql)) 'mx-eql)
More data oriented:
(defvar *mx-classes* '((mx-less mx-greater-eql) (mx-less-eql mx-greater)))
(defun the-other (x pair) (first (remove x pair)))
(defun mx-not (mx-comparator)
(the-other mx-comparator (find mx-comparator *mx-classes*)))
(push '(mx-eql mx-not-eql) *mx-classes*)
;; Code not tested, caveat emptor.
--
__Pascal Bourguignon__
howard yeh <······@gmail.com> writes:
> I just realized.
>
> Wikipedia: "Lisp was invented by John McCarthy in 1958..."
>
> On which day should I open the champagne and party?
MIT held a 30th anniversary celebration in late November, 1989.
http://groups.google.com/group/comp.lang.scheme/msg/4286ffcd59058f6d
Zach
I suppose one could say that "first publication" of lisp is sort of
like saying "i am pregnant" without having given birth yet. First
implementation seems a closer analogy.
"November 28 through December 1 1989."
Next year? Do we agree on this? I wouldn't like it if 2000 years from
now people would say, nope, Lisp was ACTUALLY born on 4 A.L. (After
Lisp), and NOT on November 28th.
Well, we've got a year to buy all the booze we need.
On May 31, 4:08 am, Zach Beane <····@xach.com> wrote:
> howard yeh <······@gmail.com> writes:
> > I just realized.
>
> > Wikipedia: "Lisp was invented by John McCarthy in 1958..."
>
> > On which day should I open the champagne and party?
>
> MIT held a 30th anniversary celebration in late November, 1989.
>
> http://groups.google.com/group/comp.lang.scheme/msg/4286ffcd59058f6d
>
> Zach
In article
<····································@w5g2000prd.googlegroups.com>,
howard yeh <······@gmail.com> wrote:
> I suppose one could say that "first publication" of lisp is sort of
> like saying "i am pregnant" without having given birth yet. First
> implementation seems a closer analogy.
>
> "November 28 through December 1 1989."
>
> Next year? Do we agree on this? I wouldn't like it if 2000 years from
> now people would say, nope, Lisp was ACTUALLY born on 4 A.L. (After
> Lisp), and NOT on November 28th.
Half serious: Lisp has been discovered, not invented.
Then the date of the first steps on the new continent counts. ;-)
>
> Well, we've got a year to buy all the booze we need.
>
> On May 31, 4:08�am, Zach Beane <····@xach.com> wrote:
> > howard yeh <······@gmail.com> writes:
> > > I just realized.
> >
> > > Wikipedia: "Lisp was invented by John McCarthy in 1958..."
> >
> > > On which day should I open the champagne and party?
> >
> > MIT held a 30th anniversary celebration in late November, 1989.
> >
> > http://groups.google.com/group/comp.lang.scheme/msg/4286ffcd59058f6d
> >
> > Zach
--
http://lispm.dyndns.org/
howard yeh wrote:
> I suppose one could say that "first publication" of lisp is sort of
> like saying "i am pregnant" without having given birth yet. First
> implementation seems a closer analogy.
Depends. Is it the idea that counts, or is it a concrete implementation?
It can't be the latter because, well, Lisp 1.0 is no longer in use for
decades. So if we want to celebrate the 50th anniversary of Lisp, I
think we actually want to celebrate the set of ideas that made Lisp a
successful design principle for a wide variety of languages and dialects.
But I guess that won't ring through to the anti-intellectual mindset of
certain people around here. (If you can't execute it on your private
laptop, it doesn't exist? Bah, how silly is that? Seriously!)
Anyway, why don't we just party both this and next year?!? Who cares
about the exact date...? ;-)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On May 31, 11:30 am, Pascal Costanza <····@p-cos.net> wrote:
> howard yeh wrote:
> > I suppose one could say that "first publication" of lisp is sort of
> > like saying "i am pregnant" without having given birth yet. First
> > implementation seems a closer analogy.
>
> Depends. Is it the idea that counts, or is it a concrete implementation?
> It can't be the latter because, well, Lisp 1.0 is no longer in use for
> decades. So if we want to celebrate the 50th anniversary of Lisp, I
> think we actually want to celebrate the set of ideas that made Lisp a
> successful design principle for a wide variety of languages and dialects.
>
Let me continue my silly analogy. I was born a baby, but the person I
am now is not using the body of the baby at time of birth. But the
actual delivery of that original bundle of flesh still marks the
precise date of birth.
But point taken about the set of ideas that make Lisp great is worth
celebrating.
However, when we celebrate Christmas, it's not the set of abstract
Christian ideas, but the actual person born in the manger. When we
celebrate Lisp, we don't want to talk about the "abstract" ideas, or
when the spirit entered into the fetus. We want to actual dropping
onto the laptop.
I feel like a sophist. Enough silliness :)
>
> Anyway, why don't we just party both this and next year?!? Who cares
> about the exact date...? ;-)
We the anti-intellectuals care.
howard yeh wrote:
> On May 31, 11:30 am, Pascal Costanza <····@p-cos.net> wrote:
>> howard yeh wrote:
>>> I suppose one could say that "first publication" of lisp is sort of
>>> like saying "i am pregnant" without having given birth yet. First
>>> implementation seems a closer analogy.
>> Depends. Is it the idea that counts, or is it a concrete implementation?
>> It can't be the latter because, well, Lisp 1.0 is no longer in use for
>> decades. So if we want to celebrate the 50th anniversary of Lisp, I
>> think we actually want to celebrate the set of ideas that made Lisp a
>> successful design principle for a wide variety of languages and dialects.
>
> Let me continue my silly analogy. I was born a baby, but the person I
> am now is not using the body of the baby at time of birth. But the
> actual delivery of that original bundle of flesh still marks the
> precise date of birth.
What about the date when you were conceived? Is that not important? ;)
> But point taken about the set of ideas that make Lisp great is worth
> celebrating.
>
> However, when we celebrate Christmas, it's not the set of abstract
> Christian ideas, but the actual person born in the manger.
Nope, can't be, because we don't know the exact date of birth of Jesus
Christ, and it was probably not December 25. See
http://en.wikipedia.org/wiki/Christmas#Pre-Christian_origins and
http://en.wikipedia.org/wiki/Nativity_of_Jesus#Date_of_birth
> When we celebrate Lisp, we don't want to talk about the "abstract"
> ideas, or when the spirit entered into the fetus. We want to actual
> dropping onto the laptop.
So which Lisp are you going to celebrate? Common Lisp? Scheme? Dylan?
ISLISP? EuLisp? MacLisp? Interlisp? Standard Lisp? ...
> I feel like a sophist. Enough silliness :)
>
>> Anyway, why don't we just party both this and next year?!? Who cares
>> about the exact date...? ;-)
>
> We the anti-intellectuals care.
Hear, hear! :)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
howard yeh wrote:
> I just realized.
>
> Wikipedia: "Lisp was invented by John McCarthy in 1958..."
>
> On which day should I open the champagne and party?
We'll do something at the International Lisp Conference
next spring, although we're not sure what yet.