First-class functions, check.
Closures, check.
eval, check.
Dynamic, check.
Null as false, check, tho they are differentiable if you hit the = key
enough times.
Parentheses, not so much.
Macros, oops.
But we had an ILC talk one year anwsering the subject in the affirmative.
Questions? Comments?
On 22 ÑÎ×, 19:04, Kenneth Tilton <·········@gmail.com> wrote:
> First-class functions, check.
> Closures, check.
> eval, check.
> Dynamic, check.
> Null as false, check, tho they are differentiable if you hit the = key
> enough times.
> Parentheses, not so much.
> Macros, oops.
>
> But we had an ILC talk one year anwsering the subject in the affirmative.
>
> Questions? Comments?
Not quite. It's not even quite functional: functions don't return
value of the last expression (unless explicitly instructed by
return). ;)
On 22 Gen, 18:04, Kenneth Tilton <·········@gmail.com> wrote:
> Questions? Comments?
In real-men real-world projects, just use Parenscript.
So JavaScript will be nothing but a simple meta language:
Parenscript will compile to JavaScript which will compile to object
code (in some browser of today / every browser of tomorrow?).
Paul
On Thu, 22 Jan 2009 12:04:29 -0500, Kenneth Tilton wrote:
> Questions? Comments?
Why is the question interesting?
In the narrow sense, Lisp is a well-defined family (CL, Scheme, ELisp,
etc), with distinguishing characteristics, most prominently
S-expressions and macros -- of course the two are closely related. JS
is clearly not Lisp in that sense.
When people ask the "is X Lisp" question, they usually use a broader
sense (like your laundry list of features). Of course, all depends on
the particular definition. So to me the question is a bit pointless,
and my impression is that it is always asked with some particular
purpose in mind (eg to show that X is a good language because it is
almost Lisp, etc).
Tamas
Tamas K Papp wrote:
> On Thu, 22 Jan 2009 12:04:29 -0500, Kenneth Tilton wrote:
>
>> Questions? Comments?
>
> Why is the question interesting?
That is a metaquestion. No metaquestions allowed under Obama. Note that
this is a metametaanswer, it's like minus signs, ya got two ya ain't got
any. With me so far?
>
> In the narrow sense, Lisp is a well-defined family (CL, Scheme, ELisp,
> etc), with distinguishing characteristics, most prominently
> S-expressions and macros -- of course the two are closely related. JS
> is clearly not Lisp in that sense.
Fence builder! Neither then, based on the sexprs, is Dylan. Bzzt.
>
> When people ask the "is X Lisp" question, they usually use a broader
> sense (like your laundry list of features). Of course, all depends on
> the particular definition. So to me the question is a bit pointless,
> and my impression is that it is always asked with some particular
> purpose in mind (eg to show that X is a good language because it is
> almost Lisp, etc).
You smoked me out. Google SoC is starting up, I was wondering if we
could sucker those LispNYC winos into a JS project.
kt
On Thu, 22 Jan 2009 14:32:37 -0500, Kenneth Tilton wrote:
> Tamas K Papp wrote:
>> On Thu, 22 Jan 2009 12:04:29 -0500, Kenneth Tilton wrote:
>>
>>> Questions? Comments?
>>
>> Why is the question interesting?
>
> That is a metaquestion. No metaquestions allowed under Obama. Note that
> this is a metametaanswer, it's like minus signs, ya got two ya ain't got
> any. With me so far?
You tellin' me that I can't ask metaquestions? Yes, I can!
>> In the narrow sense, Lisp is a well-defined family (CL, Scheme, ELisp,
>> etc), with distinguishing characteristics, most prominently
>> S-expressions and macros -- of course the two are closely related. JS
>> is clearly not Lisp in that sense.
>
> Fence builder! Neither then, based on the sexprs, is Dylan. Bzzt.
Which Dylan? As long as it mapped into sexps, it may have been a
Lisp, after it lost that ability, it no longer was.
>> When people ask the "is X Lisp" question, they usually use a broader
>> sense (like your laundry list of features). Of course, all depends on
>> the particular definition. So to me the question is a bit pointless,
>> and my impression is that it is always asked with some particular
>> purpose in mind (eg to show that X is a good language because it is
>> almost Lisp, etc).
>
> You smoked me out. Google SoC is starting up, I was wondering if we
> could sucker those LispNYC winos into a JS project.
Haha. But I am actually interested in why people care about whether
language X is Lisp (in the broader sense) or not. It seems that the
ability to claim that language X "is a Lisp" is valued because it
gives a certain pedigree to a language, as if Lisp was some ideal that
one is supposed to attain. But Lisp is here -- why not simply use
it instead of X?
Tamas
Tamas K Papp wrote:
> On Thu, 22 Jan 2009 14:32:37 -0500, Kenneth Tilton wrote:
>
>> Tamas K Papp wrote:
>>> On Thu, 22 Jan 2009 12:04:29 -0500, Kenneth Tilton wrote:
>>>
>>>> Questions? Comments?
>>> Why is the question interesting?
>> That is a metaquestion. No metaquestions allowed under Obama. Note that
>> this is a metametaanswer, it's like minus signs, ya got two ya ain't got
>> any. With me so far?
>
> You tellin' me that I can't ask metaquestions? Yes, I can!
>
>>> In the narrow sense, Lisp is a well-defined family (CL, Scheme, ELisp,
>>> etc), with distinguishing characteristics, most prominently
>>> S-expressions and macros -- of course the two are closely related. JS
>>> is clearly not Lisp in that sense.
>> Fence builder! Neither then, based on the sexprs, is Dylan. Bzzt.
>
> Which Dylan? As long as it mapped into sexps, it may have been a
> Lisp, after it lost that ability, it no longer was.
>
>>> When people ask the "is X Lisp" question, they usually use a broader
>>> sense (like your laundry list of features). Of course, all depends on
>>> the particular definition. So to me the question is a bit pointless,
>>> and my impression is that it is always asked with some particular
>>> purpose in mind (eg to show that X is a good language because it is
>>> almost Lisp, etc).
>> You smoked me out. Google SoC is starting up, I was wondering if we
>> could sucker those LispNYC winos into a JS project.
>
> Haha. But I am actually interested in why people care about whether
> language X is Lisp (in the broader sense) or not. It seems that the
> ability to claim that language X "is a Lisp" is valued because it
> gives a certain pedigree to a language, as if Lisp was some ideal that
> one is supposed to attain. But Lisp is here -- why not simply use
> it instead of X?
Simple, assuming the audience knows X. If they can be reassured X is
Lisp they do not need to learn Lisp. See Norvig's essay on Python as
Lisp. The entire Google enterprise breathed a huge sigh of relief.
hth,kth
From: Robert Maas
Subject: Domain specific Turing/Lisp tests please (was: Is Javascript a Lisp?)
Date:
Message-ID: <REM-2009jan29-004@Yahoo.Com>
> > But Lisp is here -- why not simply use it instead of X?
> From: Kenneth Tilton <·········@gmail.com>
> Simple, assuming the audience knows X. If they can be reassured X is
> Lisp they do not need to learn Lisp.
Then we need to **prove** that no other language is a Lisp, so that
they will have one less excuse not to learn Lisp.
How to do that?
We need to propose test suites that can't be done easily or in
straightforward "just do it" code by any language except Lisp.
No fair defining the task explicitly as a call to internal Lisp
functions such as SET or REMPROP. No fair even defining the task to
require a specific data-type such as SYMBOL or linked-list or EQ
hash table.
These must be domain-specific task specifications that on the face
of it say *nothing* specific about Lisp-specific functions or
datatypes, but in fact can be easily accomplished *only* with Lisp.
And these must be at least vaguely practical tasks, rather than
theoretical A.I. such as general problem solver or advice taker or
Turing-test passer or natural language translation/understanding etc.
These must be tasks where a human already *knows* precisely how to
accomplish the task, but it would take a million man-years (and a
gazillion mistakes in the final result) without a computer doing
most of the computational labor.
Smart systems, including those that automatically train/adapt
themselves from given training data, with a well-defined
training/tuning procedure (including a well-defined
genetic/annealing algorithm stated in the specification) would be
acceptable, however.
Anyone who can think of a good such task, post followup (I've
amended the Subject field to make it easy to find this sub-thread).
Side remark: In 1988 I was sorta-living-with a gal (Jean Conner)
who let me talk her into going together to a SigGraph meeting in
San Francisco. At the meeting somebody said that a computer will
never be able to train itself from natural-world information,
specifically to create pleasing or attractive artwork, that
computers always need to be explicitly programmed how to perform
tasks, and human artists will always be required to create
pleasing/attractive art work.
On the way back home I told Jean that I believe that was incorrect,
and proposed a simple test case of what should be possible: Have a
pair of carbonated beverage machines side by side, offering
different brands (Coke/Pepsi for example), and have one of them
controlled by a computer that changed the visual image on the front
of the machine (such as by a cluster of flatpanel displays, which
didn't exist then but I knew someday it *would*) to try to draw
potential customers closer to it (to increase the chance they'll
buy something from this machine), and away from the other machine
(to decrease the chance they'll buy something from the *other*
machine and then no longer be thirsty for something from *this*
machine), using as feedback a sensor that tells when people are
near that machine and when they are near the other machine and when
they walk away from both, using something like a genetic algorithm
to eliminate unattractive images but replicate attractive images
and super-replicate any images that result in an actual sale.
She then insisted that could never work, no computer program could
ever use such feedback to automatically learn how to better attract
customers. Now over 20 years later who was right, the speaker at
SigGraph saying never (and Jean agreeing), or Robert Maas saying it
*is* feasible and *will* eventually be accomplished??
Has anybody set up the hardware like that and then tried to code
the genetic attract-customer algorithms, or is this still a
futuristic pipedream over 20 years after I first proposed it?
Alternate idea: Compose musical melodies to attract customer to
this machine and compose horrible noise whenever somebody goes near
the other machine, and adjust volume level to attract new customers
from far away but not overwealm/deafen them when they draw near.
But I suspect *this* experiment would be judged "too easy" and
hence not a fair test of automatic-smart systems. So back to the
original (1988) idea.
New idea I thought of right now: Has anybody tried the same idea on
Web pages (which didn't exist in 1988, hence my not thinking of
this idea back then), i.e. using genetic algorithms to
automatically change/adapt the layout of the Web page or the images
on it or the color of text or background image etc. to better
attract users and get them to come back, using login IDs or
somesuch to match the page view users saw the first time with that
same user returning later? Or alternately using genetic algorithms
to make Web page layout more efficient, by timing how long it takes
users to find what they want on the Web page and rewarding layouts
whereby they get their task done most quickly? (Or more perversely,
deliberately making navigation as difficult as possible so that
users need to spend more time looking all over the page to find
what they want and thus see the advertisements longer? Even more
perversely, users accidently click on ads because they are so
confused by the poor page layout?)
Related slightly: HotOrNot has a new deviousness: Right between the
two places you must pass the mouse between when choosing whom to
consider meeting, there's a region of the screen with active
JavaScript function such that whenever you just pass the mouse over
that region it expands an advertisement to fill the whole screen,
so the only way to avoid that ad is to run the mouse all the way
**around** that region. Once you have that full-screen ad, it takes
quite some effort to shrink it again so that you can continue
browsing people to meet, so it's a *royal*pain*.
(Caveat: Whenever mouse is over that part of the screen, a
countdown 3 2 1 0 starts to run, at a cadence faster than than 1
per second, and when it reaches zero the advertisement expands. So
if you pass the mouse very quickly over there, it never reaches
zero. But the countdown is very quick, and the boundaries are so
close to where your mouse needs to be back and forth, that it's
really common to drift the mouse just a quarter of inch from where
it needed to be without noticing you've done so, and by the time
you notice it's too late to avoid the ad filling the screen.)
········································@MaasInfo.Org (Robert Maas) writes:
> Has anybody set up the hardware like that and then tried to code
> the genetic attract-customer algorithms, or is this still a
> futuristic pipedream over 20 years after I first proposed it?
AFAIK, there's no such hardware developed yet. But as you've
constated, nowadays we have all the pieces to do it. This is your
opportunity to become rich. Write the software, make a demo, get some
venture capital to setup a couple of prototype machines, make a real
life demo to pepsi or cocacola people showing them how they could
increase their sales with your machine. Cash the check.
--
__Pascal Bourguignon__
On 29 Jan, 13:34, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> ········································@MaasInfo.Org (Robert Maas) writes:
> > Has anybody set up the hardware like that and then tried to code
> > the genetic attract-customer algorithms, or is this still a
> > futuristic pipedream over 20 years after I first proposed it?
>
> AFAIK, there's no such hardware developed yet.
flatscreens on vending machines (beware broken link)
http://www.neatorama.com/2009/02/04/samsung-touchscreen-vending-machine/
notworking vending machines:
http://findarticles.com/p/articles/mi_m0IGV/is_5_3/ai_74940254
> But as you've
> constated, nowadays we have all the pieces to do it. This is your
> opportunity to become rich. Write the software, make a demo, get some
> venture capital to setup a couple of prototype machines, make a real
> life demo to pepsi or cocacola people showing them how they could
> increase their sales with your machine. Cash the check.
> flatscreens on vending machines (beware broken link)
> http://www.neatorama.com/2009/02/04/samsung-touchscreen-vending-machine/
This is a waste of money - for christsake, it's just a vending machine -
not entertainment - besides people would tend to stay more at it, and
look at it (trying to be an advertising machine)?
Reminds of the failed fully electronic mouse trap... There is no need
for certain things to be more complex than needed...
"Dimiter \"malkia\" Stanev" <······@mac.com> writes:
>> flatscreens on vending machines (beware broken link)
>> http://www.neatorama.com/2009/02/04/samsung-touchscreen-vending-machine/
>
> This is a waste of money - for christsake, it's just a vending machine
> -
> not entertainment - besides people would tend to stay more at it, and
> look at it (trying to be an advertising machine)?
>
> Reminds of the failed fully electronic mouse trap... There is no need
> for certain things to be more complex than needed...
The next step would be this kind of vending machine:
http://tinyurl.com/c7gbq4
"Come here buy from me, or else..."
--
__Pascal Bourguignon__
> http://tinyurl.com/c7gbq4
> "Come here buy from me, or else..."
>
Imagine the following scene: "Nice couple making sex in bed, in the mean
time gangsters intruding the house, starting killing"... Scene clears...
Minute later, an announcer comes out and says: "Now this might happen to
you, if you still use Lisp! Switch to..." (you know what)
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: Domain specific Turing/Lisp tests please
Date:
Message-ID: <REM-2009apr15-004@Yahoo.Com>
> From: "Dimiter \"malkia\" Stanev" <······@mac.com>
> Imagine the following scene: "Nice couple making sex in bed, in
> the mean time gangsters intruding the house, starting killing"...
> Scene clears... Minute later, an announcer comes out and says: "Now
> this might happen to you, if you still use Lisp! Switch to..." (you
> know what)
Two 80-year-old men, each retired from software programming, are
lamenting about how great their sexual life used to be and how it's
degraded. Still, like George Burns, they have recently found
younger wives.
C programmer: "Two months ago the most beautiful young woman fell
in love with me and started giving me great sex. It's so sad."
Lisp programmer: "Same thing happened to me, but I see nothing sad
about it. What's your problem?"
C programmer: "I can't remember where I live. I haven't seen my
wife since a week after we met, when I went out to buy some beer
and got lost on the way back home."
Lisp programmer: "I think I know your problem: Memory leak."
C programmer: "Oh, is that what my daddy kept warning me about? I
completely forgot. I should have paid more attention when he told
me to use whatchamacallit instead of C. Too late now."
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: Domain specific Turing/Lisp tests please
Date:
Message-ID: <REM-2009apr15-003@Yahoo.Com>
> From: ····@informatimago.com (Pascal J. Bourguignon)
> The next step would be this kind of vending machine:
> http://tinyurl.com/c7gbq4
"Come here buy from me, or else..."
That redirects to:
<http://allthingsmike.com/CulturalBlender/robots/robocop.jpg>
which is a walking weapons-toting robot, like from a sci-fi
invasion-from-space movie. Somehow I don't think any soft-drink
manufacturer/vendor would be able to afford the liability insurance
to run one of those things.
It occurs to me that even my original idea of a mere visual
attraction, if carried into full commercial production, may need
some limit to protect against one customer becoming so addicted to
the display that he/she purchases and consumes enough beverage to
achieve toxicity or tummy-bursting or other fatal result. However
with just the scientific/enginerring proof of concept, I see no
danger worth worrying about, providing the machine doesn't distract
drivers on a nearby road. But the distract-driver type of sign
already is in common use, such as along Bayshore Freeway (US-101)
near Great America, and the danger has been discussed in public
forums, so I expect guidelines to be in place before my proposed
device becomes a driver-distraction hazard. Perhaps a variation of
my idea might be useful: Have a drive-through site for the
vending machine, with attractive display visible from road enough
to get the driver to turn off the highway at a well-marked exit to
get to the drive-through to get a better view and purchase the
beverage. Done properly, this would be analagous to traditional
highway directions to get to popular drive-in and drive-through
restaurants such as A&W or MacDonalds or Denny's, as well as
gasoline stations along major highways, and Las Vegas casinos. The
trick would be to show enough of a preview of the attraction
visible from the highway to show the driver this isn't just any
ordinary drive-in or drive-through but a new one with special
visual attractions far beyond the norm. Come to think of it,
porn/nudity might be the best type of attractor. The teaser along
the highway could be the first part of a strip, with a promise for
the full strip over *there* at the drive-through, maybe with some
extra *after* purchase. Or the teaser could be a computer-generated
cartoon animation of the strip, with actual nude-human video of
partial strip at the drive-through before purchase and full strip
as the reward after purchase of beverage. To provide selection
feedback *after* purchase, to improve the post-purchase video, the
post-purchase video could advance down the driveway where the
driver has to continue driving (very slowly) to see it all, but
with instructions to "stop here and block traffic if you feel you
were ripped off and want to ruin our future sales".
Note that my original idea was for attracting foot traffic, such as
two or more vending machines outside a supermarket for quick
purchases before entering store or after leaving or while just
walking by, rather than attracting drivers off a highway. That
visually distracting display along Bayshore Freeway got me
sidetracked for a while.
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: Domain specific Turing/Lisp tests please
Date:
Message-ID: <REM-2009apr15-002@Yahoo.Com>
> > flatscreens on vending machines (beware broken link)
> > http://www.neatorama.com/2009/02/04/samsung-touchscreen-vending-machine/
> From: "Dimiter \"malkia\" Stanev" <······@mac.com>
> This is a waste of money - for ******, it's just a vending
> machine - not entertainment - besides people would tend to stay
> more at it, and look at it (trying to be an advertising machine)?
IMO it depends entirely on how the flat screen on the machine is
used. Per my original 1988 idea, Darwinian evolution would direct
the display specifically toward whatever sells the most beverage,
regardless of any entertainment or other value we might ascribe to
the system. By definition, if the evolution "works", it increases
sales compared to no-evolved machine. The question is whether we
can devise a sufficiently flexible yet stable evolutionary
mechanism such that natural selection will direct evolution
rapidly-enough towards increase in sales to pay back investment.
But more basically, any significant increase in sales would be a
"proof of concept" even if it doesn't yet pay back the investment.
> Reminds of the failed fully electronic mouse trap... There is no
> need for certain things to be more complex than needed...
Again, it depends on the full implementation. IMO a ceiling-mounted
video-camera plus laser-cannon device that identified all moving
objects in a room and shot the laser beam to first blind then kill
any unwanted rodent (mouse, rat, etc.) or insect (cockroach, ant,
silverfish, fly, mosquito, etc.) would be an interesting idea to
try developing for possible practical use.
On Wed, 15 Apr 2009 10:55:00 -0700, Robert Maas, http://tinyurl.com/uh3t
wrote:
> Again, it depends on the full implementation. IMO a ceiling-mounted
> video-camera plus laser-cannon device that identified all moving objects
> in a room and shot the laser beam to first blind then kill any unwanted
> rodent (mouse, rat, etc.) or insect (cockroach, ant, silverfish, fly,
> mosquito, etc.) would be an interesting idea to try developing for
> possible practical use.
Or a pool filled with angry sharks with lasers attached to their
heads. The possibilities are endless.
Tamas
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: Domain specific Turing/Lisp tests please
Date:
Message-ID: <REM-2009apr15-001@Yahoo.Com>
(Re my idea for vending machine as demonstrating my thesis that
it's possible for a computer program to adapt directly to the
environment to become more and more fit)
> From: ····················@hotmail.com
> flatscreens on vending machines (beware broken link)
> http://www.neatorama.com/2009/02/04/samsung-touchscreen-vending-machine/
That's a discussion about the vending machine in a "blog", but no
actual info about it. When I click on the link that says "Samsung
Touchscreen Vending Machine", it just takes me back to the same
place I already was. Do you know where to find any actual info
about the vending machine, such as a photo of it?
There's one place that says: [YouTube - Link]
which is supposed to go to:
<http://www.youtube.com/watch?v=q19uhAjtuk0&eurl=http://www.cooldesignideasblog.net/?p=1671&feature=player_embedded>
but when I click that link, browser says:
Internet Explorer cannot display the webpage
"Samsung debuted these touch screen vending machines at CES. The machine features a large
screen that shows animations and interactive menus and is also equipped with WiFi to send
a signal to owners when product is running low. The machines should arrive at your local mall
in 2010."
That one paragraph is the *only* actual information available on or from that Web page.
In particular there's not even one image of the new machine.
The rest of that Web page is full of advertisements. This is a crappy Web site!!
> notworking vending machines:
> http://findarticles.com/p/articles/mi_m0IGV/is_5_3/ai_74940254
That's another near-crappy Web site.
Much of the good information is hidden behind a pop-up that says:
"As a valued visitor to BNET, your feedback is very important to us.
Please help us by answering a very brief survey.
It should take less than 3 minutes to complete.
Your input will help us improve BNET and better meet your needs.
Your responses will be kept confidential and anonymous.
Best regards,
The BNET Team
To take the survey, click below:
Take survey (opens in a new window)
No thanks. (Click to close this invitation.)
Technical problems? Contact us"
The only innovation here is that payment can be via electronic
funds transfer over cell-phone as well as by physical coins. This
has nothing to do with my idea for Darwinian evolution of
"attractive" vending machines.
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: Domain specific Turing/Lisp tests please
Date:
Message-ID: <REM-2009mar12-006@Yahoo.Com>
> > Has anybody set up the hardware like that and then tried to code
> > the genetic attract-customer algorithms, or is this still a
> > futuristic pipedream over 20 years after I first proposed it?
> From: ····@informatimago.com (Pascal J. Bourguignon)
> AFAIK, there's no such hardware developed yet. But as you've
> constated, nowadays we have all the pieces to do it.
Not exactly. I don't have access to any vending machine or other
displayable object in public place where attraction of potential
customers to the device/object would be meaningful.
> This is your opportunity to become rich. Write the software,
> make a demo,
I can't think of any meaningful demo that would be possible without
a public-displayable object like a vending machine.
> get some venture capital
* Easier said than done, cha cha cha *
> to setup a couple of prototype machines, make a real life demo to
> pepsi or cocacola people showing them how they could increase their
> sales with your machine. Cash the check.
Without any venture capital, that's pie in the sky.
If you can think of any meaningful way a "demo" could be set up as
a Web application, tell me, and I'l reconsider my first response
above. Meanwhile, I'm very busy brainstorming all by myself and
desperately trying to find one or two additional people to join me
in brainstorming towards <TinyURL.Com/NewEco> which seems very
urgent at this time of economic crisis.
·············@rem.intarweb.org (Robert Maas, http://tinyurl.com/uh3t) writes:
>> to setup a couple of prototype machines, make a real life demo to
>> pepsi or cocacola people showing them how they could increase their
>> sales with your machine. Cash the check.
>
> Without any venture capital, that's pie in the sky.
>
> If you can think of any meaningful way a "demo" could be set up as
> a Web application, tell me, and I'l reconsider my first response
> above.
You only need to add a webcam to your current hardware. Don't you
have a computer with USB? A cheap USB webcam can be bought for less
than $10.
> Meanwhile, I'm very busy brainstorming all by myself and
> desperately trying to find one or two additional people to join me
> in brainstorming towards <TinyURL.Com/NewEco> which seems very
> urgent at this time of economic crisis.
Perhaps you should concentrate on solving YOUR problems before trying
to solve other people's.
--
__Pascal Bourguignon__
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: Domain specific Turing/Lisp tests please
Date:
Message-ID: <REM-2009apr15-005@Yahoo.Com>
> From: ····@informatimago.com (Pascal J. Bourguignon)
> >> to setup a couple of prototype machines, make a real life demo to
> >> pepsi or cocacola people showing them how they could increase their
> >> sales with your machine. Cash the check.
> > Without any venture capital, that's pie in the sky.
> > If you can think of any meaningful way a "demo" could be set up as
> > a Web application, tell me, and I'l reconsider my first response
> > above.
> You only need to add a webcam to your current hardware.
I don't quite understand how adding a WebCam to my Macintosh
Performa sitting in my tiny room on the third floor of an apartment
complex will emulate a vending machine that is attracting street
traffic to purchase more beverage.
> Don't you have a computer with USB?
(not (havep (person "Robert Maas") (system "computer" "USB"))) => T
> A cheap USB webcam can be bought for less than $10.
Do you know where (in Sunnyvale) I can get a (used but still
working) laptop computer with (working) USB port (and working modem
and working diskette drive) for less than $10?
Alternately do you know where I can get, for less than $10, an
adaptor that plugs into a SCSI port (EIA 25-pin female connector on
device at end of SCSI chain from computer, male plug on adaptor) to
provide a USB port?
> > Meanwhile, I'm very busy brainstorming all by myself and
> > desperately trying to find one or two additional people to join me
> > in brainstorming towards <TinyURL.Com/NewEco> which seems very
> > urgent at this time of economic crisis.
> Perhaps you should concentrate on solving YOUR problems before trying
> to solve other people's.
You're missing the point of a "cooperative", whereby people work
together to help each other. Since I don't have the money to pay
myself a wage to do work for myself, there's no way I can get out
of poverty all by myself. Only by getting others to cooperate with
me can I get out of poverty. Whether others have money and can
simply pay me to work for them, or like me they don't have money
but can join me to form a new kind of economic system where money
isn't needed to hire others, either way it takes other people to
help me get out of poverty. If you have any money beyond what's
needed for basic necessities to stay alive, perhaps you would hire
me to work for you? I'm currently specializing in WebServer
applications, but I'm flexible if you can think of some other kind
of work I can do that would be useful to you.
·············@rem.intarweb.org (Robert Maas, http://tinyurl.com/uh3t) writes:
>> From: ····@informatimago.com (Pascal J. Bourguignon)
>> >> to setup a couple of prototype machines, make a real life demo to
>> >> pepsi or cocacola people showing them how they could increase their
>> >> sales with your machine. Cash the check.
>> > Without any venture capital, that's pie in the sky.
>> > If you can think of any meaningful way a "demo" could be set up as
>> > a Web application, tell me, and I'l reconsider my first response
>> > above.
>> You only need to add a webcam to your current hardware.
>
> I don't quite understand how adding a WebCam to my Macintosh
> Performa sitting in my tiny room on the third floor of an apartment
> complex will emulate a vending machine that is attracting street
> traffic to purchase more beverage.
It might motivate *you* to purchage more beverage.
Anyways, there are already such screens installed in parisian metro:
http://blogs.ionis-group.com/iseg/national/actualites/2009/03/le_panneau_publicitaire_intell.html
It makes a lot of noise, because people don't like to be "watched" by
their ads.
> You're missing the point of a "cooperative", whereby people work
> together to help each other. Since I don't have the money to pay
> myself a wage to do work for myself, there's no way I can get out
> of poverty all by myself.
You are missing the point of working for oneself.
Take a sheet of paper and draw six columns:
| myself || myself as employer|| myself as worker |
| credit debit || credit debit || credit debit |
| | || | || | |
| | || | || | |
| | || | || | |
| | || | || | |
Now, let's say you work for yourself eight hours, ad $100/hour. You
must debit yourself as employer $800, and credit yourself as worker
$800.
| myself || myself as employer|| myself as worker |
| credit debit || credit debit || credit debit |
| | || | || | |
| | || | $800.00|| $800.00| |
| | || | || | |
| | || | || | |
But where does the money from yourself as employer come? From
yourself! So to equilibrate the accounts, you must also credit
yourself as employer from yourself:
| myself || myself as employer|| myself as worker |
| credit debit || credit debit || credit debit |
| | || | || | |
| | $800.00|| $800.00| $800.00|| $800.00| |
| | || | || | |
| | || | || | |
And where does this money you give to yourself as an employer come
from? Well, from yourself as a worker! So finally you have:
| myself || myself as employer|| myself as worker |
| credit debit || credit debit || credit debit |
| | || | || | |
| $800.00| $800.00|| $800.00| $800.00|| $800.00| $800.00|
| | || | || | |
| | || | || | |
All accounts are equilibrated, and you have worked 8 hours, and you
have financed this work.
Now of course, since this is all by yourself, don't try to talk about
it to your tax man, he would want to take his share of added value and
yourself as worker revenue, and you would end more indebted and
enslaved. But if you can keep your mouth shut, you can work for
yourself all you want.
Notice that eventually, yourself as employer should have exploited
yourself as worker enough to be left with something saleable to
others, and make big profits! You won't be happy because yourself as
worker will still be as poor as Job, but at least yourself as employer
will be rich.
No, just joking. Of course the money yourself as worker gave to
yourself to finance yourself as employer should give yourself as
worker shares to your self enteprise, so yourself as worker would
eventually be majoritary share holder, and get all the dividends from
the profit yourself as employer does!
--
__Pascal Bourguignon__
> From: Kenneth Tilton <·········@gmail.com>
> I was wondering if we could sucker those LispNYC winos into a JS project.
LispNYC are complete losers. Last March I heard about their Summer
project for mentors, and I offered to be a mentor. I needed to
provide LispNYC with my e-mail address, so I made up a new address
nobody else knew about and used that address to contact LispNYC.
They promptly gave that brand-new unique e-mail address to
CareerBuilder, which flooded me with spam before I got even one
message from LispNYC about my mentoring offer. I advise you never
to have anything to do with LispNYC until they disassociate
themselves from CareerBuilder.
mentor1 0 0 4 7 2008-05-10 03:18 ···················@spamgourmet.com
CareerBuilder stole this adderess from the summer mentoring program
where I applied to become a mentor, and proceeded to flood it with
spam on 2008.May.09,10,15, thereby consuming all three message slots
that I had allowed for the mentor program.
(Note that I allowed 4, instead of the usual 3, messages at this
address, because I thought the mentoring program was important, and
I had no idea that CareerBuilder would steal this address and flood
it with spam. After they hit the limit of 4, they sent 7 more spam
to the same address, or maybe LispNYC was one of those seven
discarded messages after the address was disabled.)
See also:
careerbuilder1 0 0 3 106 2008-05-09 01:02
··························@spamgourmet.com I tried to apply for a
job that had been advertised through CareerBuilder, but CareerBuilder
intercepted this address and used it to flood me with spam on
2008.May.09,10,15, thereby consuming all three message slots allowed
for employer responses.
(Note that after they filled the three slots, they proceeded to
flood it with an additional one hundred and six spam, all of which
SpamGourmet simply discarded.)
cb514 0 0 2 0 2008-05-14 19:33 ·················@spamgourmet.com
Stopping Career Builder spam. CB harvested address intended for
employer only 2008.May.14.
That wasn't too bad. They sent only two spam before I disabled the
address, and they didn't spam that address again. But still I lost
my chance to get a response from the employer. In the future, if I
suspect any chance whatsoever that an employer might be affiliated
with CareerBuilder, I won't provide a reply e-mail address at all,
but will instead point them to my Turing test:
<http://rem.intarweb.org/FirCon/tur1.html>
Then I'll give a different SpamGourmet disposable address to each
person who passes the Turing test, keeping active any address that
gets direct contact from employers, but disabling any e-mail
address spammed by CareerBuilder. (But most likely CareerBuilder
harvests e-mail addresses automatically, so there'd be no human
looking at my original e-mail to see the URL for the Turing test,
and they spam automatically too so even if a human saw the URL
he/she wouldn't spend the time to take the Turing test.)
Before I got on SpamGourmet, my Yahoo! Mail address suffered over a
hundred spam from CareerBuilder. Here's a partial report showing
the first six months of their spam:
<http://www.rawbw.com/~rem/NewPub/CareerBuilderSpam/cbs.html>
I checked that old Yahoo!Mail account I haven't used since I got on
SpamGourmet, and I see the CareerBuilder spam folder now contains a
total of 284 messages. Most likely every last one of them is spam,
but it's not worth my energy to look at them to see if just maybe
there might be a non-spam, or even an apology, amidst all the
spam. Someday maybe I'll write a script that scans that folder and
posts every last one of them to news.admin.net-abuse.sightings, but
at the moment I'm more interested in spending my energy setting up
a new barter-based "cooperative/economy" whereby *anyone* can be an
employer and consequently there will be enough paying (barter) jobs
for *anyone* who is willing to work in exchange for credit that can
later be used to purchase services somebody else might provide.
Robert Maas wrote:
>> From: Kenneth Tilton <·········@gmail.com>
>> I was wondering if we could sucker those LispNYC winos into a JS project.
>
> LispNYC are complete losers.
The word is "lushes".
> I needed to
> provide LispNYC with my e-mail address, so I made up a new address
> nobody else knew about and used that address to contact LispNYC.
> They promptly gave that brand-new unique e-mail address to
> CareerBuilder, which flooded me with spam before I got even one
> message from LispNYC about my mentoring offer. I advise you never
> to have anything to do with LispNYC until they disassociate
> themselves from CareerBuilder.
So the idea is that as long as one stays away from LispNYC they will not
get spam? Hmmm.
Do what everyone else does, get a gmail account and forward it to your
super-secret ISP email address, let Google eat the spam.
too easy?
kt
Kenneth Tilton <·········@gmail.com> writes:
> Robert Maas wrote:
>>> From: Kenneth Tilton <·········@gmail.com>
>>> I was wondering if we could sucker those LispNYC winos into a JS project.
>> LispNYC are complete losers.
>
> The word is "lushes".
>
>> I needed to
>> provide LispNYC with my e-mail address, so I made up a new address
>> nobody else knew about and used that address to contact LispNYC.
>> They promptly gave that brand-new unique e-mail address to
>> CareerBuilder, which flooded me with spam before I got even one
>> message from LispNYC about my mentoring offer. I advise you never
>> to have anything to do with LispNYC until they disassociate
>> themselves from CareerBuilder.
>
> So the idea is that as long as one stays away from LispNYC they will
> not get spam? Hmmm.
>
> Do what everyone else does, get a gmail account and forward it to your
> super-secret ISP email address, let Google eat the spam.
>
> too easy?
Not mentionning that a career is really the only thing Robert needs...
--
__Pascal Bourguignon__
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: Is Javascript a Lisp?
Date:
Message-ID: <REM-2009mar12-007@Yahoo.Com>
> From: ····@informatimago.com (Pascal J. Bourguignon)
> Not mentionning that a career is really the only thing Robert needs...
Well, I also need a girlfriend, or else nothing else is worth living for.
If you can help me with either, please do.
Robert Maas, http://tinyurl.com/uh3t wrote:
>> From: ····@informatimago.com (Pascal J. Bourguignon)
>> Not mentionning that a career is really the only thing Robert needs...
>
> Well, I also need a girlfriend, or else nothing else is worth living for.
> If you can help me with either, please do.
What do sailboats and girlfirends have in common?
kt
On Thu, 12 Mar 2009 04:42:16 -0400, Kenneth Tilton
<·········@gmail.com> wrote:
>Robert Maas, http://tinyurl.com/uh3t wrote:
>>> From: ····@informatimago.com (Pascal J. Bourguignon)
>>> Not mentionning that a career is really the only thing Robert needs...
>>
>> Well, I also need a girlfriend, or else nothing else is worth living for.
>> If you can help me with either, please do.
>
>What do sailboats and girlfirends have in common?
>
>kt
Both are something you shovel money into 8)
George Neuner wrote:
> On Thu, 12 Mar 2009 04:42:16 -0400, Kenneth Tilton
> <·········@gmail.com> wrote:
>
>> Robert Maas, http://tinyurl.com/uh3t wrote:
>>>> From: ····@informatimago.com (Pascal J. Bourguignon)
>>>> Not mentionning that a career is really the only thing Robert needs...
>>> Well, I also need a girlfriend, or else nothing else is worth living for.
>>> If you can help me with either, please do.
>> What do sailboats and girlfirends have in common?
>>
>> kt
>
> Both are something you shovel money into 8)
OK, what /two/ things?
#2: The two happiest days in a man's life are when he gets one and gets
rid of one.
kenny
Kenneth Tilton wrote:
> George Neuner wrote:
> > On Thu, 12 Mar 2009 04:42:16 -0400, Kenneth Tilton
> > <·········@gmail.com> wrote:
> >
> >> Robert Maas, http://tinyurl.com/uh3t wrote:
> >>>> From: ····@informatimago.com (Pascal J. Bourguignon)
> >>>> Not mentionning that a career is really the only thing Robert needs...
> >>> Well, I also need a girlfriend, or else nothing else is worth living for.
> >>> If you can help me with either, please do.
> >> What do sailboats and girlfirends have in common?
> > >
> >> kt
> >
> > Both are something you shovel money into 8)
>
> OK, what /two/ things?
>
> #2: The two happiest days in a man's life are when he gets one and gets
> rid of one.
>
> kenny
ATONEMENT
Two women in heaven claimed one Man newly arrived.
``I was his wife,'' said one.
``I, his sweetheart,'' said the other.
St. Peter said to the Man: ``Go down to the Other Place---you
have suffered enough.''
--- Ambrose Bierce
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: Is Javascript a Lisp?
Date:
Message-ID: <REM-2009apr15-006@Yahoo.Com>
> From: Kenneth Tilton <·········@gmail.com>
> What do sailboats and girlfirends [sic] have in common?
Dave Poole had both, before he committed suicide.
Kenneth Tilton wrote:
> First-class functions, check.
> Closures, check.
> eval, check.
> Dynamic, check.
> Null as false, check, tho they are differentiable if you hit the = key
> enough times.
> Parentheses, not so much.
> Macros, oops.
>
> But we had an ILC talk one year anwsering the subject in the affirmative.
>
> Questions? Comments?
Javascript is too popular and useful to be considered a Lisp.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Jan 22, 6:04 pm, Kenneth Tilton <·········@gmail.com> wrote:
> First-class functions, check.
> Closures, check.
> eval, check.
> Dynamic, check.
> Null as false, check, tho they are differentiable if you hit the = key
> enough times.
> Parentheses, not so much.
> Macros, oops.
>
> But we had an ILC talk one year anwsering the subject in the affirmative.
>
> Questions? Comments?
s-expression, Nope. So no it's not.
bobi
On 23 Jan., 10:36, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Jan 22, 6:04 pm, Kenneth Tilton <·········@gmail.com> wrote:> First-class functions, check.
> > Closures, check.
> > eval, check.
> > Dynamic, check.
> > Null as false, check, tho they are differentiable if you hit the = key
> > enough times.
> > Parentheses, not so much.
> > Macros, oops.
>
> > But we had an ILC talk one year anwsering the subject in the affirmative.
>
> > Questions? Comments?
>
> s-expression, Nope. So no it's not.
>
> bobi
"Standard Lisp":
FEXPR PROCEDURE AND(U);
BEGIN
IF NULL U THEN RETURN NIL;
LOOP: IF NULL CDR U THEN RETURN EVAL CAR U
ELSE IF NULL EVAL CAR U THEN RETURN NIL;
U := CDR U;
GO LOOP
END;
EXPR PROCEDURE MEMQ(A, B);
IF NULL B THEN NIL
ELSE IF A EQ CAR B THEN B
ELSE MEMQ(A, CDR B);
"LOGO":
to factorial :number
if :number = 1 [output 1]
output :number * factorial :number - 1
end
Both are Lisp dialects, I'd say.
On Jan 23, 11:05 am, ·······@corporate-world.lisp.de"
<······@corporate-world.lisp.de> wrote:
> On 23 Jan., 10:36, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
>
>
>
>
> > On Jan 22, 6:04 pm, Kenneth Tilton <·········@gmail.com> wrote:> First-class functions, check.
> > > Closures, check.
> > > eval, check.
> > > Dynamic, check.
> > > Null as false, check, tho they are differentiable if you hit the = key
> > > enough times.
> > > Parentheses, not so much.
> > > Macros, oops.
>
> > > But we had an ILC talk one year anwsering the subject in the affirmative.
>
> > > Questions? Comments?
>
> > s-expression, Nope. So no it's not.
>
> > bobi
>
> "Standard Lisp":
>
> FEXPR PROCEDURE AND(U);
> BEGIN
> IF NULL U THEN RETURN NIL;
> LOOP: IF NULL CDR U THEN RETURN EVAL CAR U
> ELSE IF NULL EVAL CAR U THEN RETURN NIL;
> U := CDR U;
> GO LOOP
> END;
>
> EXPR PROCEDURE MEMQ(A, B);
> IF NULL B THEN NIL
> ELSE IF A EQ CAR B THEN B
> ELSE MEMQ(A, CDR B);
>
> "LOGO":
>
> to factorial :number
> if :number = 1 [output 1]
> output :number * factorial :number - 1
> end
>
> Both are Lisp dialects, I'd say.
I disagree. No s-expressions no lisp. That's my opinion.
bobi
On 23 Jan., 11:50, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Jan 23, 11:05 am, ·······@corporate-world.lisp.de"
>
> <······@corporate-world.lisp.de> wrote:
> > On 23 Jan., 10:36, Slobodan Blazeski <·················@gmail.com>
> > wrote:
>
> > > On Jan 22, 6:04 pm, Kenneth Tilton <·········@gmail.com> wrote:> First-class functions, check.
> > > > Closures, check.
> > > > eval, check.
> > > > Dynamic, check.
> > > > Null as false, check, tho they are differentiable if you hit the = key
> > > > enough times.
> > > > Parentheses, not so much.
> > > > Macros, oops.
>
> > > > But we had an ILC talk one year anwsering the subject in the affirmative.
>
> > > > Questions? Comments?
>
> > > s-expression, Nope. So no it's not.
>
> > > bobi
>
> > "Standard Lisp":
>
> > FEXPR PROCEDURE AND(U);
> > BEGIN
> > IF NULL U THEN RETURN NIL;
> > LOOP: IF NULL CDR U THEN RETURN EVAL CAR U
> > ELSE IF NULL EVAL CAR U THEN RETURN NIL;
> > U := CDR U;
> > GO LOOP
> > END;
>
> > EXPR PROCEDURE MEMQ(A, B);
> > IF NULL B THEN NIL
> > ELSE IF A EQ CAR B THEN B
> > ELSE MEMQ(A, CDR B);
>
> > "LOGO":
>
> > to factorial :number
> > if :number = 1 [output 1]
> > output :number * factorial :number - 1
> > end
>
> > Both are Lisp dialects, I'd say.
>
> I disagree. No s-expressions no lisp. That's my opinion.
It must be hard for you to read Allen's classic book Anatomy of Lisp
without seeing it using s-expression syntax.
For me it is not necessary to have s-expressions as a surface
syntax to write useful Lisp programs. I like s-expressions,
but I can write code in Lisp dialects that don't
use s-expressions as their (primary) syntax for
programs.
Slobodan Blazeski <·················@gmail.com> writes:
> On Jan 23, 11:05�am, ·······@corporate-world.lisp.de"
> <······@corporate-world.lisp.de> wrote:
>> "Standard Lisp":
>>
>> FEXPR PROCEDURE AND(U);
>> BEGIN
>> � IF NULL U THEN RETURN NIL;
>> LOOP: IF NULL CDR U THEN RETURN EVAL CAR U
>> � � � � ELSE IF NULL EVAL CAR U THEN RETURN NIL;
>> � � U := CDR U;
>> � � GO LOOP
>> END;
>>
>> EXPR PROCEDURE MEMQ(A, B);
>> � IF NULL B THEN NIL
>> � � ELSE IF A EQ CAR B THEN B
>> � � ELSE MEMQ(A, CDR B);
>>
>> "LOGO":
>>
>> to factorial :number
>> if :number = 1 [output 1]
>> output :number * factorial :number - 1
>> end
>>
>> Both are Lisp dialects, I'd say.
> I disagree. No s-expressions no lisp. That's my opinion.
I agree with Bobi:
(read-from-string "
EXPR PROCEDURE MEMQ(A, B);
IF NULL B THEN NIL
ELSE IF A EQ CAR B THEN B
ELSE MEMQ(A, CDR B);
")
--> EXPR ;
6
unless the READ function in that language returns something else?
--
__Pascal Bourguignon__
> > "Standard Lisp":
> > FEXPR PROCEDURE AND(U);
> > BEGIN
> > =A0 IF NULL U THEN RETURN NIL;
> > LOOP: IF NULL CDR U THEN RETURN EVAL CAR U
> > =A0 =A0 =A0 =A0 ELSE IF NULL EVAL CAR U THEN RETURN NIL;
> > =A0 =A0 U :=3D CDR U;
> > =A0 =A0 GO LOOP
> > END;
(The original contained non-USASCII characters which I can't copy
and paste here, hence the =A0 representations of non-USASCII bytes
that the Unix program 'more' generates. Note that Standard Lisp
didn't support non-USASCII text, so the above example by the
two-previous poster was mangled from anything that would have been
understood by Standard Lisp. But when I viewed it in lynx, the
high-order bits were simply discarded, and so I didn't notice it
had actually been mangled until I printed it to terminal using
'more'.)
> From: Slobodan Blazeski <·················@gmail.com>
> No s-expressions no lisp. That's my opinion.
I disagree with you. The key to Lisp isn't the syntax per se, it's
the way the REP works. Linear (text) syntax is first parsed into a
nested list structure. Next that nested-list structure is either
recursively interpreted directly, or it's compiled into some
machine or intermediate language, such as bytecode, and that is
then CPU-executed or emulated, to produce a new nested-list
structure. Finally that new nested-list structure is converted to
linear (text) form and printed out (either by co-routing the
conversion and printing, or by first converting to a string then
piping that string to output, doesn't matter which way it's done).
(Lisp macros introduce an extra step after parsing but before
interpretation or compiling+executing, and multiple value returns
complicate the final print-result step. But this doesn't negate the
basic REP design.)
Furthermore each of the three main steps can be independently used.
For example, you can parse source-code syntax then not compile or
execute it but instead traverse it to glean various types of
information such as a list of functions called which aren't
defined.
(mapcar #'glean-functions-called
(load-file-by-method "foo.lisp" :ALLREADS))
Or you can run software that directly generates internal
nested-list structure without reading from text input, and then
proceed to interpret it and then just store the result without
converting to linear form.
(progn (setq myresult
(eval (funcall (database-get-function-name mykey)
(database-get-first-arg mykey)
(database-get-second-arg mykey))))
(values))
Or you can directly generate a nested-list and just serialize+print it.
(let* ((ut (get-universal-time))
(datestr (format-date ut '(:yyyy :mmm :dd)))
(filnam (format nil "debtlist-~A-new.dat" datestr))
)
(with-open-file (ochan filnam :direction :output :representation :utf8)
(format "~S~%"
(loop for customerkey in customers-with-current-debts
collect (list customerkey
(database-get-family-name customerkey)
(database-get-given-name customerkey)
(database-get-amount-owed customerkey)
)
)
)))
Standard Lisp does the REP just like I described above
(except it doesn't have keyword symbols or the LOOP macro or lots
of other CL interals, so the specific examples above wouldn't
work as given, but could be adapted easily),
so it's a true "Lisp".
(Note that SL has option of either s-expression or Reduce/RLISP
syntax independently for both input and output, so it's actually a
Lisp plus more!! But an RLISP package could be loaded into *any*
Lisp so that's not a big deal except that the RLISP package was
included in the system as delivered from Utah before it was
replaced by PSL i.e. Portable Standard Lisp.)
I don't know whether the normal operation of Logo is REP or not, so
I can't say whether it's a true "Lisp" or not. Java most assuredly
is *not* a true "Lisp", ditto C and C++ and Forth. (Of course
list-processing, including REP, could be emulated within any
general purpose programming language, relatively easily within Java
or Forth, not so easily within C or C++, and if users then
abandoned using the underlying system directly and shifted to using
the emulated Lisp for all their application programming, then that
emulation would be a true "Lisp".)
Note that a crucial sub-primitive of EVAL is APPLY. Most EVALs are
implemented in terms of APPLY, but I can imagine a version of EVAL
that was implemented directly without bothering to first define
APPLY separately, so I don't require APPLY for a programming
language to qualify as a true "Lisp". Without an explicit APPLY
available, all the code normally used to define APPLY would surely
be embedded as a sub-form within the definition of EVAL, right? And
APPLY really is separately useful in many cirumstaces, so it makes
sense that nobody in their right mind, except as a hack, would
bother to define EVAL without first defining APPLY as a explicit
and accessible function and then call it from the definition of
EVAL.
········································@MaasInfo.Org (Robert Maas) writes:
>> > "Standard Lisp":
>> > FEXPR PROCEDURE AND(U);
>> > BEGIN
>> > =A0 IF NULL U THEN RETURN NIL;
>> > LOOP: IF NULL CDR U THEN RETURN EVAL CAR U
>> > =A0 =A0 =A0 =A0 ELSE IF NULL EVAL CAR U THEN RETURN NIL;
>> > =A0 =A0 U :=3D CDR U;
>> > =A0 =A0 GO LOOP
>> > END;
> (The original contained non-USASCII characters which I can't copy
> and paste here, hence the =A0 representations of non-USASCII bytes
> that the Unix program 'more' generates.
This is wrong. The original didn't contain (at least at this place)
non-USASCII characters. It's the response that did substitute
original spaces characters by unbreakable spaces in ISO-8859-1.
--
__Pascal Bourguignon__
From: Robert Maas
Subject: The *essence* of a "Lisp" (was: Is Javascript a Lisp?)
Date:
Message-ID: <REM-2009jan30-001@Yahoo.Com>
(following up my own posting because while waking up from a nap I
realized something more essential than what I previously posted:)
> From: ········································@MaasInfo.Org (Robert Maas)
> The key to Lisp isn't the syntax per se, it's the way the REP
> works. Linear (text) syntax is first parsed into a nested list
> structure. Next that nested-list structure is either recursively
> interpreted directly, or it's compiled into some machine or
> intermediate language, such as bytecode, and that is then
> CPU-executed or emulated, to produce a new nested-list structure.
> Finally that new nested-list structure is converted to linear
> (text) form and printed out (either by co-routing the conversion
> and printing, or by first converting to a string then piping that
> string to output, doesn't matter which way it's done).
(remarks about macros and multiple values snipped)
> Furthermore each of the three main steps can be independently used.
(examples of how to use each part separately snipped)
There's another way of looking at this: EVAL is the only key part
of a "Lisp". READ and PRINT are nothing but convenient ways for
users to build the nested-list that is passed to EVAL and later
view the result from EVAL. I pointed out before that it doesn't
matter whether s-expressions or m-expressions (or XML) are the
syntax that is parsed by READ and generated by PRINT, it's only how
EVAL works that's key. APPLY the first element of the toplevel list
to the recursively EVALuated sub-lists given by the rest of the
toplevel list. (Special cases for non-lists at any level,
specifically that symbols EVALuate to the contents of their VALUE
cells, and every other atom EVALuates to itself.)
Whereas most other languages are defined in terms of their text
syntax, Lisp is defined in terms of its nested-list (special case
for atoms) abstract-internal representation. Thus, for example, we
define the semantics of a call to = not by saying "openParens
equalSign whitespace firstParameter whitespace secondParameter
closeParens", but by saying "a list of three elements whose first
element is the symbol named "=" and the other two elements are the
parameters", then the rest of the definition is the same either
way, "tests whether the first and second parameter are numbers with
the same value, returning the symbol T if they are and the symbol
NIL if they aren't". Thus it would be possible to implement a
"Lisp" that didn't use READ and PRINT at all, but instead of READ
used some entirely different tool for users to enter nested lists
and pass a pointer to the toplevel list to EVAL, and then instead
of PRINT used yet another tool to somehow inspect/view the nested
list that was implied by the return value of EVAL. In fact my
proposed "no syntax" or "syntax-free" Web-based software-development
system would use HTML forms to specify the types and details of
each data object going into both test data and source "code", and
display nested lists (both verified input data and results from
EVAL) as box-and-arrow diagrams similar to those shown here:
<http://www.rawbw.com/~rem/AsciiArt/LispDiagrams.html>
But I thought of a sorta perverse alternative to either traditional
READ and PRINT (and m-expr or JavaScript or PHP variations) or my
proposed box-and-arrow editor+displayer, namely relational database
tables. Each fixed-size basic unit of a Lisp object would be a
single row of a database table, where the primary key for that row
was used as the machine reference to that object, and the other
fields in that same row contained either references to other rows
that contained other parts of the Lisp object, or primitive machine
data such as numbers or UniCode points. Furthermore, a sort of
BiBop ("big bag of pages", used by MacLisp at MIT) storage
management system would be used whereby each table contains only a
single primitive sub-type of data, thus each table can have exactly
the fields needed to represent the parts used by that type of
sub-object with no fields wasted, and each table has a different
number of fields ("columns") per its needs. A Lisp "reference"
(a.k.a. "pointer" or "handle") as passed around to/from EVAL and
other functions would then be a pair: <TableName, UniqueIdWithinThatTable>.
One additional table would contain the meta-data, namely one row
for each primitive sub-object data-type, containing as fields the
name of the corresponding BiBop table for that data-type, the
print-name of that data-type, and internal data needed to generate
appropriate code for performing various primitive operations upon
this particular data type.
Example of a possible implementation:
TableName Fields
ConsCell ID CarTableName CarID CdrTableName CdrID
SmallInteger ID Value
IEEE-SingleFloat ID Value
IEEE-DoubleFloat ID Value
BigInteger ID NChunks FirstChunkID LastChunkID
BigIntegerChunk ID ChunkValue NextID
Character ID UniCodePoint
ShortString ID Length ChunkOfAtMost256UniCodePoints
LongString ID NChunks FirstChunkID LastChunkID
Symbol ID PrintNameShortStringID ValueTableName ValueID PropTableName PropID ...
To shorten the number of characters in SQL queries, to reduce
required bandwidth between the Lisp engine and the RDBS datastore
server, probably very short aliases, possible single characters or
two-digit integers, would be used instead of the long
self-documentating names shown above.
The way you'd use this replacement for REP would be as follows:
-R- Generate SQL for building all the sub-objects and linking them
together into a whole nested-list object and getting back the
<TableName, ID> to pass to EVAL;
-E- Passing that <TableName, ID> to EVAL and getting back
multiple-value returns via a reference to a result set, each
element of which is one <TableName, ID> corresponding to one
returned value;
-P- Generate SQL to explore the result set and somehow show the user
what Lisp object is implied by each return-value result-set.
Exactly what tools are used for -R- and -P- is at the discretion of
the user. If the user wants to write something that parses
s-expressions or m-expresions or XML, that's his/her option. More
interesting would be a true graphical drawing/display tool or
building or viewing box-and-arrow diagrams directly without ever
dealing with text-string serializations. But in any case RDBS BiBop
tables are the underlying datastore and SQL is the actual
build/explore mechanism for that datastore.
So would *you* accept such a system as a "Lisp" if EVAL in this
system had exactly the same nestedList-to-nestedList
abstract-semantics as it does in CL?
From: Kaz Kylheku
Subject: Re: The *essence* of a "Lisp" (was: Is Javascript a Lisp?)
Date:
Message-ID: <20090205145220.689@gmail.com>
On 2009-01-30, ········································@MaasInfo.Org (Robert
Maas) <http> wrote:
> (following up my own posting because while waking up from a nap I
> realized something more essential than what I previously posted:)
>> From: ········································@MaasInfo.Org (Robert Maas)
>> The key to Lisp isn't the syntax per se, it's the way the REP
>> works. Linear (text) syntax is first parsed into a nested list
>> structure. Next that nested-list structure is either recursively
>> interpreted directly, or it's compiled into some machine or
>> intermediate language, such as bytecode, and that is then
>> CPU-executed or emulated, to produce a new nested-list structure.
>> Finally that new nested-list structure is converted to linear
>> (text) form and printed out (either by co-routing the conversion
>> and printing, or by first converting to a string then piping that
>> string to output, doesn't matter which way it's done).
> (remarks about macros and multiple values snipped)
>> Furthermore each of the three main steps can be independently used.
> (examples of how to use each part separately snipped)
>
> There's another way of looking at this: EVAL is the only key part
> of a "Lisp". READ and PRINT are nothing but convenient ways for
> users to build the nested-list that is passed to EVAL and later
> view the result from EVAL.
The key part of Lisp is the extensive library for managing the dynamic data
structures (including the I/O routines for serializing and deserializing data
from the text). Subsumed in this key part is the memory management stategy,
such as garbage collection.
Before you can even think about implementing eval, you have to have all that
stuff in place.
EVAL is an afterthought: Hey look, this data structure can represent code, and
its written notation can be used as a source language for programming, that
doesn't actually suck. It's not hard to write EVAL once you have the other
pieces in place.
You can write programs before you have EVAL, becuase you can just write them in
the same language in which you implemented all of the other pieces, like
assembly language or C.
I worked on a project once that grew a Lisp-like C++ library. A lot of work was
being done with that library, from within C++, before EVAL was ever written,
including things like pattern matching, processes communicating complex
commands to each other over sockets, program configuration stored as S-exps,
etc.
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: The *essence* of a "Lisp" (was: Is Javascript a Lisp?)
Date:
Message-ID: <REM-2009mar07-005@Yahoo.Com>
>> The key to Lisp isn't the syntax per se, it's the way the REP
>> works. ...
> From: Kaz Kylheku <········@gmail.com>
> The key part of Lisp is the extensive library for managing the
> dynamic data structures (including the I/O routines for
> serializing and deserializing data from the text).
Hmm, there's some value in your way of looking at. I suppose once
you have the serializing and deserializing, as well as all the
utilities for doing things with symbols (most notably present in
Lisp but not other languages) and other (more commonly implemented)
data objects, it's sorta trivial (using knowledge of internal
function linkage mechanism) to implement APPLY, after which it *is*
trivial to also implement EVAL.
But Java also has a nice library for managing dynamic data
structures, and has a way to serialize and deserialize data <=>
text, no Lisp-like symbols but it should be relatively easy to
define a Java Class that has a value cell and function cell and
property list etc. Then as I say above it'd be relatively trivial
to implement APPLY and EVAL. So does that mean Java is just as good
as Lisp per your criterion?
> Subsumed in this key part is the memory management stategy, such
> as garbage collection.
Yeah "such as" is an important caveat. Mark-and-collect GC isn't
necessary at all. For some environments reference count or
never-reclaim-until-program-ends would be usable. Even hybrid
systems (reference count for everything except symbols and CLOS
objects, mark-and-collect of uninterned symbols and CLOS
objects only when reference count can't reclaim enough
memory, manually unintern interned symbols if you are ever
done with them but better always use uninterned symbols
for anything you will ever want disposed before program
ends)
would be workable for some environments. You just need to decide
what your decision is, document it, and implement it consistently.
> Before you can even think about implementing eval, you have to
> have all that stuff in place.
Well, as McCarthy showed in his just-before-Lisp paper, and as the
very first Lisp implementation proved in practice, there really
isn't a lot of stuff absolutely needed before implementing APPLY,
hence EVAL also, if you don't mind that CONS cells and small
integers and symbols are the only data types, with characters
emulated as intentional datatype of small integers within an I/O
library, likewise for any other data type you want to emulate.
Someday if I ever find time maybe I'll implement reference-count
Lisp in Forth, as I described a few weeks ago (every time a Lisp
pointer is duplicated on the stack, its RC is incremented, and
every time a Lisp pointer is discarded from the stack, its RC is
decremented and tested for zero, making it trivial to avoid RC-leak
bugs). I could even cheat by not implementing symbols as an
internal data type, instead if the CAR of a CONS cell is a special
value, then it means the CDR is the slots of an intentional-symbol-type
rather than an ordinary list. Integers could be symmetric -127 to
+127, with -128 disallowed in arithmetic, used instead as the
CAR-of-symbol tag. How's that for a nifty hack? Or -128 could be
CAR-of-intentional-extension tag, with the CADR being a dispatch
index into table of various intentional types, and the CDDR being
the list of slots of whatever intentional type is being
represented? Yeah, that's more flexible, I like it!
> EVAL is an afterthought: Hey look, this data structure can
> represent code, and its written notation can be used as a source
> language for programming, that doesn't actually suck.
It's a damn good afterthought! Instead of having to keep function
and parameter list separate, or even worse having to keep function
and each parameter as separate, with no way to write APPLY at all,
only APPLY0 and APPLY1 and APPLY2 etc. as special cases, you can
bundle function and arglist into a single list. Then instead of
taking 2 or N separate inputs to produce one output, you always
take 1 bundled-input to produce one output (ignoring the
complication of multiple-value returns). If you really do want each
input provided separately, you can use APPLY or FUNCALL, but in
most cases EVAL is what you want to do to transform one expression
into its "value". As a bonue, it nicely unifies function calls and
variable lookups (as well as macro-form expansion too!!). How can
anybody who has seen EVAL ever want to do without it??
> It's not hard to write EVAL once you have the other pieces in place.
If you have APPLY, I agree EVAL is trivial.
If you don't have APPLY already, um... you need to know the API for
function calls really good, to write APPLY, after which EVAL is trivial.
> You can write programs before you have EVAL, becuase you can just
> write them in the same language in which you implemented all of the
> other pieces, like s/assembly language or C/Forth/.
Agreed, if you're willing to suffer writing Forth syntax and being
ultra careful never to pop too many or too few items off the stack
before trying to return to your caller. Defining formal Lisp-like
functions that have declared #parameters or formal spec for
optional or keyword parameters is a big win compared to Forth
calling conventions that are totally unsafe even for experts.
Thus the shortest route to increased productivity may be to
implement formal Lisp functions with formal spec for parameters
enforced by the runtime, and then to CONS-up linked lists to pass
to APPLY, and then "one small step for a man" to write EVAL and
"voila" who ever needs to write another line of Forth?
······@corporate-world.lisp.de wrote:
> On 23 Jan., 10:36, Slobodan Blazeski <·················@gmail.com>
> wrote:
>> On Jan 22, 6:04 pm, Kenneth Tilton <·········@gmail.com> wrote:> First-class functions, check.
>>> Closures, check.
>>> eval, check.
>>> Dynamic, check.
>>> Null as false, check, tho they are differentiable if you hit the = key
>>> enough times.
>>> Parentheses, not so much.
>>> Macros, oops.
>>> But we had an ILC talk one year anwsering the subject in the affirmative.
>>> Questions? Comments?
>> s-expression, Nope. So no it's not.
>>
>> bobi
>
> "Standard Lisp":
>
> FEXPR PROCEDURE AND(U);
> BEGIN
> IF NULL U THEN RETURN NIL;
> LOOP: IF NULL CDR U THEN RETURN EVAL CAR U
> ELSE IF NULL EVAL CAR U THEN RETURN NIL;
> U := CDR U;
> GO LOOP
> END;
>
> EXPR PROCEDURE MEMQ(A, B);
> IF NULL B THEN NIL
> ELSE IF A EQ CAR B THEN B
> ELSE MEMQ(A, CDR B);
>
>
> "LOGO":
>
> to factorial :number
> if :number = 1 [output 1]
> output :number * factorial :number - 1
> end
>
>
> Both are Lisp dialects, I'd say.
>
Yep, I forgot about Logo.
kt
I don't know JavaScript, but I think JavaScript will be a lisp when
you write json<->javascript
conversion and define quasiquotation under json (or one is here
already?) Why not you, Kenneth?
... but this will be a rather slow lisp. Another member of python/perl/
php family.
On Jan 23, 4:05 am, ·······@corporate-world.lisp.de" <······@corporate-
world.lisp.de> wrote:
> "LOGO":
>
> to factorial :number
> if :number = 1 [output 1]
> output :number * factorial :number - 1
> end
OCaml:
let rec fac = function
0 -> 1
| n -> n * fac (n - 1)
·········@yahoo.com schrieb:
> On Jan 23, 4:05 am, ·······@corporate-world.lisp.de" <······@corporate-
> world.lisp.de> wrote:
>
>> "LOGO":
>>
>> to factorial :number
>> if :number = 1 [output 1]
>> output :number * factorial :number - 1
>> end
>
>
> OCaml:
>
> let rec fac = function
> 0 -> 1
> | n -> n * fac (n - 1)
Btw, is that OCaml code potentially safe from stack overflows?
In the last days there was some talk about tail recursion.
Although it is not really needed. Here a solution in Lisp:
(def facs (lazy-cat [1] (map * facs (iterate inc 1))))
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Jan 30, 1:55 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> ·········@yahoo.com schrieb:
>
>
>
> > On Jan 23, 4:05 am, ·······@corporate-world.lisp.de" <······@corporate-
> > world.lisp.de> wrote:
>
> >> "LOGO":
>
> >> to factorial :number
> >> if :number = 1 [output 1]
> >> output :number * factorial :number - 1
> >> end
>
> > OCaml:
>
> > let rec fac = function
> > 0 -> 1
> > | n -> n * fac (n - 1)
>
> Btw, is that OCaml code potentially safe from stack overflows?
You get hit by other problems first.
Objective Caml version 3.10.0
# let rec factorial = function
0 -> 1
| n -> n * factorial (n - 1)
;;
val factorial : int -> int = <fun>
# factorial 13;;
- : int = -215430144
#
Cheers
--
Marco
> In the last days there was some talk about tail recursion.
> Although it is not really needed. Here a solution in Lisp:
>
> (def facs (lazy-cat [1] (map * facs (iterate inc 1))))
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
On Jan 28, 2:51 pm, ·········@yahoo.com wrote:
> On Jan 23, 4:05 am, ·······@corporate-world.lisp.de" <······@corporate-
>
> world.lisp.de> wrote:
> > "LOGO":
>
> > to factorial :number
> > if :number = 1 [output 1]
> > output :number * factorial :number - 1
> > end
>
> OCaml:
>
> let rec fac = function
> 0 -> 1
> | n -> n * fac (n - 1)
For bignums:
#load "nums.cma"
open Num
(* "rec" for recursive *)
let rec factorial = function
Int 1 -> Int 1
| n -> mult_num n (factorial (pred_num n));;
print_endline (string_of_num (factorial (Int 333)))
······@corporate-world.lisp.de wrote:
> On 23 Jan., 10:36, Slobodan Blazeski <·················@gmail.com>
> wrote:
> > On Jan 22, 6:04�pm, Kenneth Tilton <·········@gmail.com> wrote:>
> > First-class functions, check.
> > > Closures, check.
> > > eval, check.
> > > Dynamic, check.
> > > Null as false, check, tho they are differentiable if you hit the
> > > = key enough times.
> > > Parentheses, not so much.
> > > Macros, oops.
> >
> > > But we had an ILC talk one year anwsering the subject in the
> > > affirmative.
> >
> > > Questions? Comments?
> >
> > s-expression, Nope. So no it's not.
> >
> > bobi
>
> "Standard Lisp":
>
> FEXPR PROCEDURE AND(U);
> BEGIN
> IF NULL U THEN RETURN NIL;
> LOOP: IF NULL CDR U THEN RETURN EVAL CAR U
> ELSE IF NULL EVAL CAR U THEN RETURN NIL;
> U := CDR U;
> GO LOOP
> END;
>
> EXPR PROCEDURE MEMQ(A, B);
> IF NULL B THEN NIL
> ELSE IF A EQ CAR B THEN B
> ELSE MEMQ(A, CDR B);
>
>
> "LOGO":
>
> to factorial :number
> if :number = 1 [output 1]
> output :number * factorial :number - 1
> end
>
>
> Both are Lisp dialects, I'd say.
Reduce:
1: procedure fac n; for i:=1:n product i;
fac
2: fac 33;
8683317618811886495518194401280000000
On Jan 31, 5:40 am, "William James" <·········@yahoo.com> wrote:
> ······@corporate-world.lisp.de wrote:
> > On 23 Jan., 10:36, Slobodan Blazeski <·················@gmail.com>
> > wrote:
> > > On Jan 22, 6:04 pm, Kenneth Tilton <·········@gmail.com> wrote:>
> > > First-class functions, check.
> > > > Closures, check.
> > > > eval, check.
> > > > Dynamic, check.
> > > > Null as false, check, tho they are differentiable if you hit the
> > > > = key enough times.
> > > > Parentheses, not so much.
> > > > Macros, oops.
>
> > > > But we had an ILC talk one year anwsering the subject in the
> > > > affirmative.
>
> > > > Questions? Comments?
>
> > > s-expression, Nope. So no it's not.
>
> > > bobi
>
> > "Standard Lisp":
>
> > FEXPR PROCEDURE AND(U);
> > BEGIN
> > IF NULL U THEN RETURN NIL;
> > LOOP: IF NULL CDR U THEN RETURN EVAL CAR U
> > ELSE IF NULL EVAL CAR U THEN RETURN NIL;
> > U := CDR U;
> > GO LOOP
> > END;
>
> > EXPR PROCEDURE MEMQ(A, B);
> > IF NULL B THEN NIL
> > ELSE IF A EQ CAR B THEN B
> > ELSE MEMQ(A, CDR B);
>
> > "LOGO":
>
> > to factorial :number
> > if :number = 1 [output 1]
> > output :number * factorial :number - 1
> > end
>
> > Both are Lisp dialects, I'd say.
>
> Reduce:
>
> 1: procedure fac n; for i:=1:n product i;
>
> fac
>
> 2: fac 33;
>
> 8683317618811886495518194401280000000
Yet another Greenspunning by the Ruby creators.... :)
Cheers
--
Marco
In article
<····································@e1g2000pra.googlegroups.com>,
Marco Antoniotti <·······@gmail.com> wrote:
> > Reduce:
> >
> > 1: procedure fac n; for i:=1:n product i;
> >
> > fac
> >
> > 2: fac 33;
> >
> > 8683317618811886495518194401280000000
>
> Yet another Greenspunning by the Ruby creators.... :)
REDUCE is a computer algebra system written in
Standard Lisp with algebraic syntax, which it also uses.
>
> Cheers
> --
> Marco
--
http://lispm.dyndns.org/
On Jan 31, 2:05 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@e1g2000pra.googlegroups.com>,
> Marco Antoniotti <·······@gmail.com> wrote:
>
> > > Reduce:
>
> > > 1: procedure fac n; for i:=1:n product i;
>
> > > fac
>
> > > 2: fac 33;
>
> > > 8683317618811886495518194401280000000
>
> > Yet another Greenspunning by the Ruby creators.... :)
>
> REDUCE is a computer algebra system written in
> Standard Lisp with algebraic syntax, which it also uses.
>
>
>
> > Cheers
> > --
> > Marco
>
> --http://lispm.dyndns.org/
Ooops. I jumped the gun!
But does our Ruby friend know about Reduce (and Macsyma/Maxima)?
Cheers
--
Marco
Slobodan Blazeski wrote:
> On Jan 22, 6:04 pm, Kenneth Tilton <·········@gmail.com> wrote:
>> First-class functions, check.
>> Closures, check.
>> eval, check.
>> Dynamic, check.
>> Null as false, check, tho they are differentiable if you hit the = key
>> enough times.
>> Parentheses, not so much.
>> Macros, oops.
>>
>> But we had an ILC talk one year anwsering the subject in the affirmative.
>>
>> Questions? Comments?
> s-expression, Nope. So no it's not.
Dylan. Bzzzzzt!
Lisp's inventor wanted m-exprs. Bzzzzzzzzzzzzzzzzzzzzzzzzzzzzt!
Otherwise, I agree.
kt
On Jan 23, 2:59 pm, Kenneth Tilton <·········@gmail.com> wrote:
> Slobodan Blazeski wrote:
> > On Jan 22, 6:04 pm, Kenneth Tilton <·········@gmail.com> wrote:
> >> First-class functions, check.
> >> Closures, check.
> >> eval, check.
> >> Dynamic, check.
> >> Null as false, check, tho they are differentiable if you hit the = key
> >> enough times.
> >> Parentheses, not so much.
> >> Macros, oops.
>
> >> But we had an ILC talk one year anwsering the subject in the affirmative.
>
> >> Questions? Comments?
> > s-expression, Nope. So no it's not.
>
> Dylan. Bzzzzzt!
The first s-expressions based Dylan was actually quite good.
So let's put it this way. There was some people wanting to replace s-
expressions with something more primitive ooops conventional. But they
all failed so s-expressions are de facto standard among lispy
languages. I know that's probably not a perfect divider but we have
to draw line somewhere, else someone will suggest to accept Python,
Ruby or whatever language that ripped some features from lisp and
claim being a part of the family. And if all those mainstream coder
start to hang here will have to loose our reasons to be smug.
How does http://touchyfeelylispweenie.blogspot.com sounds ? So keep
the infidels from the sacred city.
> Lisp's inventor wanted m-exprs. Bzzzzzzzzzzzzzzzzzzzzzzzzzzzzt!
You shall not make wrongful use of the name of the Lord your God, for
the Lord will not acquit anyone who misuses his name.
I know that you're god but than McCarthy is a meta god.
> Otherwise, I agree.
I'm glad.
bobi
On Jan 22, 12:04 pm, Kenneth Tilton <·········@gmail.com> wrote:
> First-class functions, check.
> Closures, check.
> eval, check.
> Dynamic, check.
> Null as false, check, tho they are differentiable if you hit the = key
> enough times.
> Parentheses, not so much.
> Macros, oops.
>
> But we had an ILC talk one year anwsering the subject in the affirmative.
>
> Questions? Comments?
Java-script is a macro-language for xml.