From: David Cohen
Subject: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <2282daa3.0111261533.7c7a56d2@posting.google.com>
For those of you, like myself, who were wondering what Paul Graham
(author of "ANSI Lisp" and "On Lisp") has been up to lately, the
answer is: he's been devising a new Lisp dialect called "Arc".

If you are interested in examining a possible direction for the future
of Lisp, you might want to check these out:

Quick intro:
http://www.paulgraham.com/paulgraham/arc

Arc material presented at LL1, the Lightweight Languages conference
at MIT on Nov. 17 (long):
http://www.paulgraham.com/paulgraham/arcll1.html

And, for those generally interested in what LL1 was about:
http://ll1.mit.edu/

Enjoy.
__
DC

From: Frank A. Adrian
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <GPFM7.1115$302.330042@news.uswest.net>
David Cohen wrote:

> For those of you, like myself, who were wondering what Paul Graham
> (author of "ANSI Lisp" and "On Lisp") has been up to lately, the
> answer is: he's been devising a new Lisp dialect called "Arc".
> 
> If you are interested in examining a possible direction for the future
> of Lisp, you might want to check these out:
> 
> Quick intro:
> http://www.paulgraham.com/paulgraham/arc
> 
> Arc material presented at LL1, the Lightweight Languages conference
> at MIT on Nov. 17 (long):
> http://www.paulgraham.com/paulgraham/arcll1.html
> 
> And, for those generally interested in what LL1 was about:
> http://ll1.mit.edu/

My take on Arc:

Arc is interesting from the standpoint of
        (a) targeting a niche need;
        (b) having a small core;
        (c) some of its linguistic features;
        (d) simplifying CL.

But...

Arc is also good enough to fragment the Lisp community yet again.
Arc is still too foreign (and has too many parens) to convince the unwashed 
masses to convert.

All in all...

It is sad that the discussions on subsetting and minimal cores (and on 
Common Lisp, in general) have stagnated to the point where people feel that 
the only option they have that would allow `a Lisp-like language to succeed 
is to fragment the community once again.

In the end...

It will probably do as well as Dylan.

The oracle has spoken...

faa
From: Kenny Tilton
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C033361.21B0E1E9@nyc.rr.com>
"Frank A. Adrian" wrote:
> 
> David Cohen wrote:
> > If you are interested in examining a possible direction for the future
> > of Lisp, you might want to check these out:
> >
> > Quick intro:
> > http://www.paulgraham.com/paulgraham/arc
> >
> My take on Arc:
> 
...
> In the end...
> 
> It will probably do as well as Dylan.
> 
> The oracle has spoken...

the oracle is not wrong. 

ok, PG sees Python and Perl take off outta nowhere and thinks, aha!
that's the trick.

well, god bless him, but what a waste of energy. what we need is a lisp
plug-in for IE and NS.

can that be done?

kenny
clinisys
From: Vebjorn Ljosa
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <cy3ofloeioi.fsf@ljosa.com>
* Kenny Tilton <·······@nyc.rr.com>
| 
| well, god bless him, but what a waste of energy. what we need is a lisp
| plug-in for IE and NS.
| 
| can that be done?

Allegro CL has that already.  I think it only works on Windows, and
not with IE 5.5 or newer.  See <URL:http://www.franz.com/support/
documentation/5.0.1/doc/cl/plugin.htm> and <URL:http://www.franz.com/
support/documentation/6.1/doc/plugin.htm>.

-- 
Vebjorn Ljosa
From: Kenny Tilton
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C036F8C.DF95F57F@nyc.rr.com>
Vebjorn Ljosa wrote:
> 
> * Kenny Tilton <·······@nyc.rr.com>
> |
> | well, god bless him, but what a waste of energy. what we need is a lisp
> | plug-in for IE and NS.
> |
> | can that be done?
> 
> Allegro CL has that already.  I think it only works on Windows, and
> not with IE 5.5 or newer.  

Nice to see something in this direction, tho of course comprehensive
IE/NS support on Win32 is a minimum requirement, and it would be wrong
to leave out the Mac. Could some eager Open Source type convert CMUCL to
a plug-in?

btw, how scary is a browser plug-in that can execute any OS function
including deleting files?! That is really unacceptable if we want
everyone to install it.

kenny
clinisys
From: Coby Beck
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <qkVM7.126660$Yb.33373164@typhoon.tampabay.rr.com>
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
······················@nyc.rr.com...
> Vebjorn Ljosa wrote:
> >
> > * Kenny Tilton <·······@nyc.rr.com>
> > |
> > | well, god bless him, but what a waste of energy. what we need is a lisp
> > | plug-in for IE and NS.
> > |
> > | can that be done?
> >
> > Allegro CL has that already.  I think it only works on Windows, and
> > not with IE 5.5 or newer.
>
> Nice to see something in this direction, tho of course comprehensive
> IE/NS support on Win32 is a minimum requirement, and it would be wrong
> to leave out the Mac. Could some eager Open Source type convert CMUCL to
> a plug-in?
>
> btw, how scary is a browser plug-in that can execute any OS function
> including deleting files?! That is really unacceptable if we want
> everyone to install it.
>

I believe MS Outlook allows any received email the same functionality!  ;-)

--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
From: Kenny Tilton
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C0431AB.B08EAF6F@nyc.rr.com>
Coby Beck wrote:
> 
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> ······················@nyc.rr.com...
> > btw, how scary is a browser plug-in that can execute any OS function
> > including deleting files?! That is really unacceptable if we want
> > everyone to install it.
> >
> 
> I believe MS Outlook allows any received email the same functionality!  ;-)
> 

<rofl>
From: IsraelRT
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <olpe0uoau58odr63kjc1kqa5e6m1el69d7@4ax.com>
On 27 Nov 2001 00:12:29 -0800, Vebjorn Ljosa <·····@ljosa.com> wrote:

>* Kenny Tilton <·······@nyc.rr.com>
>| 
>| well, god bless him, but what a waste of energy. what we need is a lisp
>| plug-in for IE and NS.
>| 
>| can that be done?

And will it be used ?

>Allegro CL has that already. 

I guess that it is not being used.
From: Carl Shapiro
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <ouy1yikibjg.fsf@panix3.panix.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> well, god bless him, but what a waste of energy. what we need is a lisp
> plug-in for IE and NS.
> 
> can that be done?

Lisp browser plugins have been around for quite some time.  It is
really super easy to write one especially if you can deliver your Lisp
image as a DLL.  Franz has such a thing, and I have seen some sort of
CLISP-based Lisp browser plugin from SRI.
From: Kenny Tilton
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C03A4E1.42B21FCF@nyc.rr.com>
Carl Shapiro wrote:
> 
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> > well, god bless him, but what a waste of energy. what we need is a lisp
> > plug-in for IE and NS.
> >
> > can that be done?
> 
> Lisp browser plugins have been around for quite some time.  It is
> really super easy to write one especially if you can deliver your Lisp
> image as a DLL.  Franz has such a thing, and I have seen some sort of
> CLISP-based Lisp browser plugin from SRI.

I followed the link to the Franz plug-in info, looked limited to just
NS. Anyway, so the idea is a CL dll and a small amount of Java to...
well, I know so little about these things I'll just shut up. But I do
wonder why the Franz approach is browser and browser-version specific.

I have been hot for producing Lisp-driven Web pages for a while, and
Graham I /think/ was suggesting a role like this for Arc as the killer
app necessary to win over lotsa programmers.... but either I am the only
one interested in such a beast or there is an easier way I am missing.

kenny
clinisys
From: Daniel Barlow
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <87d724za7s.fsf@noetbook.telent.net>
Kenny Tilton <·······@nyc.rr.com> writes:

> well, god bless him, but what a waste of energy. what we need is a lisp
> plug-in for IE and NS.

What on earth for?  Even java died a death on the client side.


-dan

-- 

  http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources 
From: Kenny Tilton
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C039E72.5B244DD2@nyc.rr.com>
Daniel Barlow wrote:
> 
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> > well, god bless him, but what a waste of energy. what we need is a lisp
> > plug-in for IE and NS.
> 
> What on earth for?  Even java died a death on the client side.

OK, educate me. This Web stuff is new to me. How can I get a cool
Lisp-driven, highly-interactive session running mostly on the client
side--one that can be stumbled onto via Google? ie, easily reach a large
audience?

OK, they can DL the entire app, right? That is not a terrible solution.
I just kinda like the transparency offered by a browser plugin so they
just stay in the browser.

btw, if this is what you mean: i am not thinking this helps CL grow, I
just want to some fun stuff on the Web in CL. I gather Kawa might be an
alternative: Scheme-like compiled to Java?

kenny
clinisys
From: Daniel Barlow
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <871yikz2jh.fsf@noetbook.telent.net>
Kenny Tilton <·······@nyc.rr.com> writes:

> OK, they can DL the entire app, right? That is not a terrible solution.
> I just kinda like the transparency offered by a browser plugin so they
> just stay in the browser.

OK, it's a reasonable thing to want to do, but I still don't think
it's a particularly compelling one.  People are happy to download
special-purpose clients for instant messaging, napster, ····@home,
playing DVDs, etc etc.  Come up with an application they already want
to use, and they'll jump through whatever hoops are necessary - and
probably won't care too much about the implementation language either.

You also have far fewer browser compatibility issues if you deliver a
standalone app ...

> btw, if this is what you mean: i am not thinking this helps CL grow, I

Fair enough then, I agree with you ;-)

> just want to some fun stuff on the Web in CL. I gather Kawa might be an
> alternative: Scheme-like compiled to Java?

I wrote an applet in Kawa once, actually.  Problem was that (at the
time; this was several years ago and Kawa has probably improved since)
I had to jar up an awful lot of Kawa along with it; few people are
going to have the patience to download a 500k applet over a 28.8 modem.

If I needed to produce more applets I'd certainly look at it again,
but with any luck that wont be necessary.


-dan

-- 

  http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources 
From: Kenny Tilton
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C03B871.AD1C9141@nyc.rr.com>
Daniel Barlow wrote:

> I wrote an applet in Kawa once, actually.  Problem was that (at the
> time; this was several years ago and Kawa has probably improved since)
> I had to jar up an awful lot of Kawa along with it; few people are
> going to have the patience to download a 500k applet over a 28.8 modem.
> 

OK, but that's where the plug-in comes in, they DL once for all <g> Lisp
Web applications.

Unless it is like Real Player and I am asked to download a new better
version for every frikkin page I come to.

kenny
clinisys
From: ········@acm.org
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <a1YM7.13258$Vm5.2042063@news20.bellglobal.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> Daniel Barlow wrote:
> > I wrote an applet in Kawa once, actually.  Problem was that (at
> > the time; this was several years ago and Kawa has probably
> > improved since) I had to jar up an awful lot of Kawa along with
> > it; few people are going to have the patience to download a 500k
> > applet over a 28.8 modem.

> OK, but that's where the plug-in comes in, they DL once for all <g>
> Lisp Web applications.

If it's a "Lisp Runner" application, then I need only download it once
for all the "Lisp Apps" that I'd download that use that "Runner."
-- 
(reverse (concatenate 'string ·············@" "enworbbc"))
http://www.cbbrowne.com/info/wp.html
"I think it would be totally inappropriate for me to even contemplate
what I am thinking about."  -- Don Mazankowski
From: ········@acm.org
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <J%XM7.7033$Ju6.1812937@news20.bellglobal.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> I just kinda like the transparency offered by a browser plugin so
> they just stay in the browser.

I _hate_ the "transparency" offered by browser plugins; they make the
application as fragile as the combination of:
  - P(Browser Crash), combined with
  - P(Plugin Crash), combined with
  - P(Plugin Infrastructure Crash), combined with
  - P(Plugin Application Crash).

All of these are non-zero, and even if Bayes' Theorem can't be used to
legitimately multiply them, as the components are _not_ independent,
it is still manifestly obvious that plugin-based applications are a
whopping lot Not Reliable.

If I trust the application enough that I'd be prepared to run it in my
browser, thereby giving it the ability to crash the browser and
whatever other browser-related activity might be ongoing, I'm surely
trusting enough to let it run as its own separate application...
-- 
(reverse (concatenate 'string ····················@" "454aa"))
http://www.cbbrowne.com/info/lisp.html
"Feel free to  contact me (flames about my english  and the useless of
this driver will be redirected to /dev/null, oh no, it's full...)"
-- Michael Beck, describing the PC-speaker sound device
From: Kenny Tilton
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C047B4B.83671B8D@nyc.rr.com>
········@acm.org wrote:
> 
> Kenny Tilton <·······@nyc.rr.com> writes:
> > I just kinda like the transparency offered by a browser plugin so
> > they just stay in the browser.
> 
> I _hate_ the "transparency" offered by browser plugins; they make the
> application as fragile as the combination of:
>   - P(Browser Crash), combined with
>   - P(Plugin Crash), combined with
>   - P(Plugin Infrastructure Crash), combined with
>   - P(Plugin Application Crash).
> 
> All of these are non-zero, and even if Bayes' Theorem can't be used to
> legitimately multiply them, as the components are _not_ independent,
> it is still manifestly obvious that plugin-based applications are a
> whopping lot Not Reliable.

Two things. First, you are not wrong. I think WWW stands for the Wild
Wild West. And I have long considered it a good measure of how great is
the Web that we (I?) love it in spite of that.

Second, I just made this up, but maybe a Web-based version becomes a
free demo/sample for a standalone DL version offered for sale? As it is
I was preparing animated GIFs to show off a neat optics simulation I
offered from a different enterprise.

I am talking about educational apps or games here, not heavy-duty stuff
where a crash is a major bummer.

kenny
clinisys
From: lin8080
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C0454D2.D8D3EB26@freenet.de>
Kenny Tilton schrieb:

> btw, if this is what you mean: i am not thinking this helps CL grow, I
> just want to some fun stuff on the Web in CL. I gather Kawa might be an
> alternative: Scheme-like compiled to Java?


Example:

[1] 
create an nice search-button-icon. Place it as a plug-in in the browsers
menu bar. The user can see his plug-in every time he surf around.

[2]
by clicking on this nice icon, a *small* window opens, one single line
is enough, waiting for the usual search engine stuff, two or three
words, and a big OK button at the end of that single nice bordered line.
Oh, may be you add a "?" button and, of course some short-cut keys.

[3]
call up any search-engine that may do the job. This is what the user can
specify in one of these endless popup cards with realy 1000 + 1 options,
so users can talk about their way to manage this plug-in for best
results.

[3A]
while searching with unkown time show the user some quick bytes flying
through the input line. The user can see: it works.

[4]
offer the user the complete search result, may be found 3mio entries, if
possible in 2 *small* text lines, and ask him for some more precision,
if necessary. This way the user can think: aha, intelligent. Search
again on available search-engines. And look out for only seconds until
the user see the next action.

[5]
format a search-report in a futuristic but useful, clear manner and let
the user download his report with a big download button. This is
something new, because the user can read this report offline and choose
his next url(s). And the user can collect such reports like his private
knowledge base.

[6]
do not forget a nice simple logo, CL or something, on evry report side.
This remind the user to his new plug-in and make him think: aha, fine.

[7]
prepare the next plug-in. The user might want to edit his report.

stefan
From: Eric Moss
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C03D721.D209F91A@alltel.net>
Kenny Tilton wrote:

> well, god bless him, but what a waste of energy. what we need is a lisp
> plug-in for IE and NS.

That would be fantastic--if only I knew enough to do such a thing.
Yet-another-new-language won't get us any new functionality, but a lisp
plugin would do that in spades.

I hear M$ is working on making plugins impossible--yet another way of
locking people into their way of browsing. Ick.

Eric
From: Marc Battyani
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <0FC4B6F0904A1568.17F76575FCA51B98.B9AA6CE5235B1EAB@lp.airnews.net>
"Eric Moss" <········@alltel.net> wrote in message
······················@alltel.net...
> Kenny Tilton wrote:
>
> > well, god bless him, but what a waste of energy. what we need is a lisp
> > plug-in for IE and NS.
>
> That would be fantastic--if only I knew enough to do such a thing.
> Yet-another-new-language won't get us any new functionality, but a lisp
> plugin would do that in spades.

It's rather easy to do. You just need to do a what M$ calls a "Script
Engine". But it would probably take some time if you want to FLI enough
functions to be interesting.

Just look at :
http://msdn.microsoft.com/library/en-us/script56/html/engines.asp?frame=true

Then you can put <script langage="Common-Lisp"> Lisp code </Script> in your
HTML pages.

You can have a look at how it has been done for Python and Haskell and some
others.

Marc
From: Fernando Rodr�guez
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <mvr60ukkv3d8g1jbg3e625j1efa7dc4obb@4ax.com>
On Tue, 27 Nov 2001 06:29:24 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:


>ok, PG sees Python and Perl take off outta nowhere and thinks, aha!
>that's the trick.
>
>well, god bless him, but what a waste of energy. what we need is a lisp
>plug-in for IE and NS.
>
>can that be done?

CormanLisp is already a COM server, so integrating it with IE shouldn't be too
difficult.

Why do you think we need this? O:-)



--
Fernando Rodr�guez
frr at wanadoo dot es
--
From: Kenny Tilton
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C03A03E.9C3C34C6@nyc.rr.com>
"Fernando Rodr�guez" wrote:

> 
> CormanLisp is already a COM server, so integrating it with IE shouldn't be too
> difficult.

Interesting.

> 
> Why do you think we need this? O:-)
> 

What are the alternatives for delivering complex interactive
applications via the Web running mostly client-side for performance? I
am thinking Java, Kawa, Flash...other?

kenny
clinisys
From: Fernando Rodr�guez
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <rlb70u8vsmgrukjurbo0ju46mr02rejjnb@4ax.com>
On Tue, 27 Nov 2001 14:13:52 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:


>> Why do you think we need this? O:-)
>> 
>
>What are the alternatives for delivering complex interactive
>applications via the Web running mostly client-side for performance? I
>am thinking Java, Kawa, Flash...other?

You can write the core of your app in CL and a GUI with Java. You may also
have the customer download a reasonably small CL compiler such as Corman Lisp
that downloads fasl files or even source files from a server as needed. 
 You could also wait for Arc's first release, since this seems to be what they
are aiming at. :-)




--
Fernando Rodr�guez
frr at wanadoo dot es
--
From: Kenny Tilton
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C03B702.1BC74A9@nyc.rr.com>
"Fernando Rodr�guez" wrote:
> 
> You can write the core of your app in CL and a GUI with Java.

Yikes, the interface is the fun part. (I know, most people think of a
Lisp expert system or some such doing the interesting bit behind the
scenes, but I want to do insanely great 3d stuff.) Anyway....

...thx to all for all the input, sounds like when I get the time there
will be some way or other to have my way with the Web. And I will
definitely keep an eye on Arc.

kenny
clinisys
From: Brian P Templeton
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <87d71z3c4r.fsf@tunes.org>
I'm sure it would be quite easy to make a CL plug-in for Closure ;).

I know very little about MS products, but as for Mozilla (probably
Netscape too) on Unix, plug-ins are shared libraries, and are probably
documented in the developer information at
<URL:http://www.mozilla.org/>. For Mozilla and Netscape on MS-Windows,
plug-ins are probably implemented as DLLs.

-- 
BPT <···@tunes.org>	    		/"\ ASCII Ribbon Campaign
backronym for Linux:			\ / No HTML or RTF in mail
	Linux Is Not Unix			 X  No MS-Word in mail
Meme plague ;)   --------->		/ \ Respect Open Standards
From: Carl Shapiro
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <ouyvgfwgwr2.fsf@panix3.panix.com>
"Frank A. Adrian" <·······@qwest.net> writes:

> Arc is interesting from the standpoint of

[...]

>         (d) simplifying CL.

It's a mid-life crisis Lisp.
From: ···············@telia.com
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3c037a44.3620466@vulkan.euv-frankfurt-o.de>
On Mon, 26 Nov 2001 21:52:18 -0800, "Frank A. Adrian"
<·······@qwest.net> wrote:

I too fail to see what is so much better with Arc, lacking the
analysis that lead to this idea of "a new Lisp dialect". 

>All in all...
>
>It is sad that the discussions on subsetting and minimal cores (and on 
>Common Lisp, in general) have stagnated to the point where people feel that 
>the only option they have that would allow `a Lisp-like language to succeed 
>is to fragment the community once again.
>

Ahem, cough cough.

At this point I remember your and cbbrowne's somewhat acid comments
about LispOS-builders. Vapour and YALI were mentioned.  :)

I can see nothing wrong in implementing a chosen subset of a larger
languge such as CL. The implementor would do it for a specific purpose
of course. But doing it strictly within CL seems almost impossible.
The standard was not written to make such implementations easy.

To quote from the Arc page:

"If you just made a Lisp that could talk to the OS and had powerful
string libraries, I think it would more than hold its own. We're
hoping to do more than that though."

Now, how does one interpret _that_? 

Naughty naughty,
Lars
From: Frank A. Adrian
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <TcOM7.3251$_06.83990@news.uswest.net>
···············@telia.com wrote:

> Ahem, cough cough.
> 
> At this point I remember your and cbbrowne's somewhat acid comments
> about LispOS-builders. Vapour and YALI were mentioned.  :)

Because it focuses on a place where the "bang for the buck" is less than in 
clearing out the weeds in the language.  It also isn't as fragmenting as 
starting from the current language and making sure that the current 
language can be built from the initial subset.

Besides, who thinks that consistency is always a virtue :-)...

faa
From: Dorai Sitaram
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <9u08p6$cnl$1@news.gte.com>
In article <·····················@news.uswest.net>,
Frank A. Adrian <·······@qwest.net> wrote:
>Arc is interesting from the standpoint of
>        (a) targeting a niche need;
>        (b) having a small core;
>        (c) some of its linguistic features;
>        (d) simplifying CL.
>
>But...
>
>Arc is also good enough to fragment the Lisp community yet again.
>Arc is still too foreign (and has too many parens) to convince the unwashed 
>masses to convert.
>
>All in all...
>
>It is sad that the discussions on subsetting and minimal cores (and on 
>Common Lisp, in general) have stagnated to the point where people feel that 
>the only option they have that would allow `a Lisp-like language to succeed 
>is to fragment the community once again.

I had the good luck to hear Paul speak at the LL1.  In
the very first paragraph he implied that Arc wasn't
intended to convert or be backward-compatible,
because that would hamstring the design process too
much.  He did say he wanted to reduce parens, not to
lure the parenphobic, but to be minimalistic.   

Fragmentation isn't as bad as it sounds, really.  A
family of languages that uses s-expressions ipso facto
cannot have insurmountable backward- or
cross-compatibility problems, so letting 1K flowers
bloom isn't at all deadly.  Source-to-source
transformations to Common Lisp are easy enough, and
there is no demand for source-to-source transformations
from Common Lisp.  That's why Common Lisp and Scheme
continue to interact behind the scenes so well. 

--d
From: Thomas F. Burdick
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <xcvu1vek219.fsf@monsoon.OCF.Berkeley.EDU>
······@mindspring.com (David Cohen) writes:

> For those of you, like myself, who were wondering what Paul Graham
> (author of "ANSI Lisp" and "On Lisp") has been up to lately, the
> answer is: he's been devising a new Lisp dialect called "Arc".
> 
> If you are interested in examining a possible direction for the future
> of Lisp, you might want to check these out:
> 
> Quick intro:
> http://www.paulgraham.com/paulgraham/arc

Wow, I have to say, this really makes me thankful for Common Lisp.
This looks like it's going to be a horrid dialect.  It's a Lisp-1, but
it looks like he's trying to make the trade-off worth it, because he's
doing some cute things with that first position of a form that you
couldn't do in a Lisp-2.  On the other hand, I don't understand the
desire for crippled iteration constructs and object system.  I'm
amazed that someone who's worked with Common Lisp couldn't see the
benefit of multiple inheritance and multiple dispatch.  Sure, you can
do most things without them -- but he's claiming that the language is
designed for advanced users, and I'm pretty sure most advanced OO
programers can make good use of MI and especially multiple dispatch.

The wacky iteration constructs are particularly puzzling.  I think of
DO in much the same way I think of TAGBODY -- it's a good thing to
have around, is perfectly appropriate for machine consumption and
generation, but I don't want to see it.  But dear god, I'm glad it's
there!  I don't understand why he's not doing something more like
Series, particularly since it seems he values code-walking macros. That
would be a cool language feature, making code-walking macros easy to
write -- so I wonder why he's not taking advantage of it?

What's up with only being able to collect *or* sum in an iteration,
not both?  What's up with no mention of multiple values?  A couple
things in there (get returns the value of *fail* if it can't find
something in a hash/alist, for example, instead of two values) look
like hacks around the lack of multiple values.

Maybe it'll improve, but it looks like it's headed in a perfectly
horrid direction.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Carl Shapiro
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <ouyvgfuo5b4.fsf@panix3.panix.com>
···@monsoon.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> Wow, I have to say, this really makes me thankful for Common Lisp.
> This looks like it's going to be a horrid dialect.  It's a Lisp-1, but
> it looks like he's trying to make the trade-off worth it, because he's
> doing some cute things with that first position of a form that you
> couldn't do in a Lisp-2.

At least one of those "cute" things, the ability to funcall an array,
is basically old news and has been done before on Lisps that do not
unify their function and variable name spaces.  For example, this
feature existed on both Maclisp and Zetalisp.  It is not so clear that
the other "cute" feature, the overloading hair, is anything which
mandates the conflation of name spaces either.
From: Thomas F. Burdick
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <xcvu1vejq4v.fsf@monsoon.OCF.Berkeley.EDU>
Carl Shapiro <········@panix.com> writes:

> ···@monsoon.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> 
> > Wow, I have to say, this really makes me thankful for Common Lisp.
> > This looks like it's going to be a horrid dialect.  It's a Lisp-1, but
> > it looks like he's trying to make the trade-off worth it, because he's
> > doing some cute things with that first position of a form that you
> > couldn't do in a Lisp-2.
> 
> At least one of those "cute" things, the ability to funcall an array,
> is basically old news and has been done before on Lisps that do not
> unify their function and variable name spaces.  For example, this
> feature existed on both Maclisp and Zetalisp.  It is not so clear that
> the other "cute" feature, the overloading hair, is anything which
> mandates the conflation of name spaces either.

Hmm, I knew it had been done before, but I didn't know it had been
done in a Lisp-2.  How could that work?

  (defun foo (x) (* x 10))
  (let ((foo (vector 0 1 2 3 4 5 6 7 8 9)))
    (foo 5))

Would this return 5 or 50?

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Kent M Pitman
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <sfwwv0anx21.fsf@shell01.TheWorld.com>
···@monsoon.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> Carl Shapiro <········@panix.com> writes:
> 
> > ···@monsoon.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > 
> > > Wow, I have to say, this really makes me thankful for Common Lisp.
> > > This looks like it's going to be a horrid dialect.  It's a Lisp-1, but
> > > it looks like he's trying to make the trade-off worth it, because he's
> > > doing some cute things with that first position of a form that you
> > > couldn't do in a Lisp-2.
> > 
> > At least one of those "cute" things, the ability to funcall an array,
> > is basically old news and has been done before on Lisps that do not
> > unify their function and variable name spaces.  For example, this
> > feature existed on both Maclisp and Zetalisp.  It is not so clear that
> > the other "cute" feature, the overloading hair, is anything which
> > mandates the conflation of name spaces either.
> 
> Hmm, I knew it had been done before, but I didn't know it had been
> done in a Lisp-2.  How could that work?
> 
>   (defun foo (x) (* x 10))
>   (let ((foo (vector 0 1 2 3 4 5 6 7 8 9)))
>     (foo 5))
> 
> Would this return 5 or 50?

In Maclisp, an array was secretly also a kind of function.  If you di

(ARRAY FOO 5000)

this made FOO  a named array (that is, it put the array on the ARRAY
property of FOO).  If you did (FOO 3) it would access element 3 of that
array.  You had to use ARRAYCALL to access an array not declared in this way.

Were there a CL analog, it would presumably be the ability to setf the
function cell to an array or else the ability to do
 (alet ((foo 5000 :element-type 'bit))
   ...)

but we didn't.

You can, however, probably implement this as a macro.
From: Thomas F. Burdick
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <xcvlmgqjope.fsf@monsoon.OCF.Berkeley.EDU>
Kent M Pitman <······@world.std.com> writes:

> ···@monsoon.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> 
> > Carl Shapiro <········@panix.com> writes:
> > 
> > > ···@monsoon.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > > 
> > > > Wow, I have to say, this really makes me thankful for Common Lisp.
> > > > This looks like it's going to be a horrid dialect.  It's a Lisp-1, but
> > > > it looks like he's trying to make the trade-off worth it, because he's
> > > > doing some cute things with that first position of a form that you
> > > > couldn't do in a Lisp-2.
> > > 
> > > At least one of those "cute" things, the ability to funcall an array,
> > > is basically old news and has been done before on Lisps that do not
> > > unify their function and variable name spaces.  For example, this
> > > feature existed on both Maclisp and Zetalisp.  It is not so clear that
> > > the other "cute" feature, the overloading hair, is anything which
> > > mandates the conflation of name spaces either.
> > 
> > Hmm, I knew it had been done before, but I didn't know it had been
> > done in a Lisp-2.  How could that work?
> > 
> >   (defun foo (x) (* x 10))
> >   (let ((foo (vector 0 1 2 3 4 5 6 7 8 9)))
> >     (foo 5))
> > 
> > Would this return 5 or 50?
> 
> In Maclisp, an array was secretly also a kind of function.  If you di[d]
> 
> (ARRAY FOO 5000)
> 
> this made FOO  a named array (that is, it put the array on the ARRAY
> property of FOO).  If you did (FOO 3) it would access element 3 of that
> array.  You had to use ARRAYCALL to access an array not declared in this way.

Okay, so if I did something like:

  (DEFUN TENTH (ARRAY)
    (ARRAYCALL ARRAY 9))

how would I call it?  Like (TENTH #'FOO) or like (TENTH FOO)?  That
is, was the array also the variable's value?  If so, it seems like it
would turn into a Lisp-1 for the purposes of array variables (which
might be Carl's point about it not requiring a Lisp-1 -- because you
can temporarily make a Lisp-2 a Lisp-1 for certain variables; I
actually do this for my collection macro, and quite like it).

> Were there a CL analog, it would presumably be the ability to setf the
> function cell to an array or else the ability to do
>  (alet ((foo 5000 :element-type 'bit))
>    ...)
> 
> but we didn't.
> 
> You can, however, probably implement this as a macro.

Yeah, that'd be easy enough, but probably not worth the confusion it'd
cause to any poor soul trying to read your code, unless it was alread
rather non-CL-like.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Kent M Pitman
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <sfwlmgqgoqf.fsf@shell01.TheWorld.com>
···@monsoon.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> Kent M Pitman <······@world.std.com> writes:
>
> > In Maclisp, an array was secretly also a kind of function.  If you di[d]
> > 
> > (ARRAY FOO 5000)
> > 
> > this made FOO  a named array (that is, it put the array on the ARRAY
> > property of FOO).  If you did (FOO 3) it would access element 3 of that
> > array.  You had to use ARRAYCALL to access an array not declared in 
> > this way.
>
> Okay, so if I did something like:
> 
>   (DEFUN TENTH (ARRAY)
>     (ARRAYCALL ARRAY 9))

That's what you did with an unnamed array, not a named array.

> how would I call it?  Like (TENTH #'FOO) or like (TENTH FOO)?  

 (TENTH (GET 'FOO 'ARRAY))

if you had set up to call with arraycall.  But I'm pretty sure you
could also do:

 (DEFUN TENTH (FN) (FUNCALL FN 9))
 (TENTH 'FOO)

You need to understand that there was no function cell.  FUNCALL scanned
the plist for any of a zillion properties (hence the importance of 
GET-PROPERTIES at the time CL was spec'd out).  It might seem slow, but if
the call was compiled, various caching schemes (some flushable, some
not) were possible so that the long lookup was not done over and over.
The long lookup would, of course, be done in the variable case of
FUNCALL of a variable since the value of the variable might fluctuate.

> That
> is, was the array also the variable's value?

No.  You could use *ARRAY to get the effect of make-array, but ARRAY did
effectively (SETF (GET 'FOO 'ARRAY) (*ARRAY ...)).  Except there was no
SETF for most of MACLISP's life, so mostly you'd have described it with
PUTPROP isntead.

> If so, it seems like it
> would turn into a Lisp-1 for the purposes of array variables (which
> might be Carl's point about it not requiring a Lisp-1 -- because you
> can temporarily make a Lisp-2 a Lisp-1 for certain variables; I
> actually do this for my collection macro, and quite like it).

No. MACLISP was tried and true LISP2.

> > Were there a CL analog, it would presumably be the ability to setf the
> > function cell to an array or else the ability to do
> >  (alet ((foo 5000 :element-type 'bit))
> >    ...)
> > 
> > but we didn't.
> > 
> > You can, however, probably implement this as a macro.
> 
> Yeah, that'd be easy enough, but probably not worth the confusion it'd
> cause to any poor soul trying to read your code, unless it was alread
> rather non-CL-like.

For a one-shot thing, yeah.  But maybe not for an application heavy on
arrays.  As with most macros, it depends on circumstance what's going to
work.  Certainly I've never found myself missing anything like this.
But I use arrays (other than strings) hardly ever--mostly only subprimitively
for implementing buffers/stacks.  There are some good uses for arrays, just
mostly not the things I find myself doing.
From: Marco Antoniotti
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <y6cu1vdeg6u.fsf@octagon.mrl.nyu.edu>
As I understand it, the problem here is not only relative to arrays,
but to "table" access as a whole.  The problem is that in other
languages you can do

	table[something]

ans be able to retrieve whatever is stored in the location keyed by
<something>.  Hence the problem of defining something liks this in
Lisp notation create contortions (which AFAIU were "solved" in
Maclisp, earlier dialects and Lisp-1) about the meaning of the
notation

	(table something)

(where <table> is an array, an alist or a hash table).

I think this is not a good way to frame the problem.  After all these
other languages do syntactically differentiate function application.

	table(something)

is (where <table> is a function) different from

	table[something]

If we wanted to go Perlish we could aways define something like

(defgeneric [] (table &rest keys))

(defmethod []  ((a array) &rest keys) (apply #'aref a keys))
(defmethod [] ((a hash-table) &rest keys) (gethash (first a) a))

Which is almost what the ASSOCIATION functions you (KMP) posted some
time ago.

It does not solve the problem, but it unifies "table" lookup.

Note that there is another "table" like package floating around by
Peter Norvig.

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.
From: Thomas F. Burdick
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <xcvr8qhfi0e.fsf@conquest.OCF.Berkeley.EDU>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> As I understand it, the problem here is not only relative to arrays,
> but to "table" access as a whole.  The problem is that in other
> languages you can do
> 
> 	table[something]
> 
> ans be able to retrieve whatever is stored in the location keyed by
> <something>.  Hence the problem of defining something liks this in
> Lisp notation create contortions (which AFAIU were "solved" in
> Maclisp, earlier dialects and Lisp-1) about the meaning of the
> notation
> 
> 	(table something)
> 
> (where <table> is an array, an alist or a hash table).
> 
> I think this is not a good way to frame the problem.  After all these
> other languages do syntactically differentiate function application.
> 
> 	table(something)

Whether it's a good idea or a bad one, I think depends on how you're
viewing your tables.  A lot of languages *do* make the two look very
different, but should they?  It's nice that if I just want to deal
with sequences, and not think about exactly what kind, I can.  If I
decide to change from a list of characters to a string, I don't need
to change my consuming code.  Well, what if I want to change from
using a function that computes results to looking them up in a table?
Functions and tables aren't really different from the consumer's point
of view.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Dave Morse
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C06CFB6.7050600@bomberlan.net>
Re: similar looking invokes for funcall and aref


It becomes implementation dependant whether alpha-char-p is a function 
or a constant array.  ;)

(alpha-char-p 32) => NIL
(alpha-char-p 97) => T
alpha-char-p      => 
#b000000000000000000000000000000000000000000000000000000000000000000111111111111111111111111...
                   OR
                   #<function @0A00F43>

(yes, I'm hand-waving with the char-code conversion)
From: Marco Antoniotti
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <y6coflltgyp.fsf@octagon.mrl.nyu.edu>
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> Marco Antoniotti <·······@cs.nyu.edu> writes:
> 
> > As I understand it, the problem here is not only relative to arrays,
> > but to "table" access as a whole.  The problem is that in other
> > languages you can do
> > 
> > 	table[something]
> > 
	...
> 
> Whether it's a good idea or a bad one, I think depends on how you're
> viewing your tables.  A lot of languages *do* make the two look very
> different, but should they?  It's nice that if I just want to deal
> with sequences, and not think about exactly what kind, I can.  If I
> decide to change from a list of characters to a string, I don't need
> to change my consuming code.  Well, what if I want to change from
> using a function that computes results to looking them up in a table?
> Functions and tables aren't really different from the consumer's point
> of view.

I believe it is a trade off.  In Ada95 if you see something like

	foo(42)

you may be looking either at a function call or at an array index
(alas, not to a hash table lookup).

But yes, all in all you are right.  In CL we are stuck with a
separation that allows for clarity and efficiency (there I said the
E-word :) ) in many other cases.

All in all, I would just settel for some macrology unifying array and
hash-table references, but then again, why bother?

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.
From: Thomas F. Burdick
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <xcvadx5gdi2.fsf@conquest.OCF.Berkeley.EDU>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Whether it's a good idea or a bad one, I think depends on how you're
> > viewing your tables.  A lot of languages *do* make the two look very
> > different, but should they?  It's nice that if I just want to deal
> > with sequences, and not think about exactly what kind, I can.  If I
> > decide to change from a list of characters to a string, I don't need
> > to change my consuming code.  Well, what if I want to change from
> > using a function that computes results to looking them up in a table?
> > Functions and tables aren't really different from the consumer's point
> > of view.
> 
> I believe it is a trade off.  In Ada95 if you see something like
> 
> 	foo(42)
> 
> you may be looking either at a function call or at an array index
> (alas, not to a hash table lookup).
> 
> But yes, all in all you are right.  In CL we are stuck with a
> separation that allows for clarity and efficiency (there I said the
> E-word :) ) in many other cases.

I don't think it would actually be an efficiency problem.  If FLET[*]
bound the function value of a variable to an arbitrary value, and
there was some way of associating a FUNCALL-like function for types,
you could do something like:

  (flet ((table (make-array ...))
         (fn (lambda (x) ...)))
    (fn 'foo)
    (table 10))

Now, presumably CMUCL would be able to figure out that TABLE and FN
are an array and a function, and would compile in the specific
machinery, not the generic check-and-dispatch.  Lesser compilers would
probably require type declarations :-).  All in all, I don't think
it's any different than normal type issues.

> All in all, I would just settel for some macrology unifying array and
> hash-table references, but then again, why bother?

I have a generic function REF:

  (defgeneric ref (thing &rest subscripts))

This should theoretically be a really handy thing, allowing me to use
hash tables, a-lists, arrays, etc, uniformly.  I say theoretically,
because I always forget to remember it.  If I could only remember it's
there, I think I'd enjoy using it.

As to "why bother", I think I agree with Kent that if you're using a
lot of arrays, this would be worth the bother.  And the fact that I
didn't think of that shows that I haven't been doing scientific
computations for a while :-(

[*] My fictional FLET would make it a little more difficult to create
a local function, but there'd still be LABELS.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Bruce Hoult
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <bruce-936604.11093430112001@news.paradise.net.nz>
In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti 
<·······@cs.nyu.edu> wrote:

> As I understand it, the problem here is not only relative to arrays,
> but to "table" access as a whole.  The problem is that in other
> languages you can do
> 
> 	table[something]
> 
> ans be able to retrieve whatever is stored in the location keyed by
> <something>.  Hence the problem of defining something liks this in
> Lisp notation create contortions (which AFAIU were "solved" in
> Maclisp, earlier dialects and Lisp-1) about the meaning of the
> notation
> 
> 	(table something)
> 
> (where <table> is an array, an alist or a hash table).
> 
> I think this is not a good way to frame the problem.  After all these
> other languages do syntactically differentiate function application.
> 
> 	table(something)
> 
> is (where <table> is a function) different from
> 
> 	table[something]

FORTRAN and BASIC don't.


I think that data structure lookup and function application should be 
differentiated from each other, of only because the data structure 
lookup denotes a "place" that you can setf, while the function 
application doesn't.

-- Bruce
From: Dave Morse
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C06D038.5050701@bomberlan.net>
Bruce Hoult wrote:


> 
> I think that data structure lookup and function application should be 
> differentiated from each other, of only because the data structure 
> lookup denotes a "place" that you can setf, while the function 
> application doesn't.
> 


You're right most of the time, but of course some function calls are 
invertible:

e.g. (package-nicknames foo)
<---> (setf (package-nicknames foo) '(fo))
From: Bruce Hoult
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <bruce-F3A88D.14050230112001@news.paradise.net.nz>
In article <················@bomberlan.net>, Dave Morse 
<······@bomberlan.net> wrote:

> Bruce Hoult wrote:
> 
> > I think that data structure lookup and function application should be 
> > differentiated from each other, of only because the data structure 
> > lookup denotes a "place" that you can setf, while the function 
> > application doesn't.
> 
> You're right most of the time, but of course some function calls are 
> invertible:
> 
> e.g. (package-nicknames foo)
> <---> (setf (package-nicknames foo) '(fo))

Hmm.  I'm looking at the package-nicknames entry in the hyperspec.  How 
am I supposed to tell that you can setf it?

-- Bruce
From: Kent M Pitman
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <sfwy9kpf393.fsf@shell01.TheWorld.com>
Bruce Hoult <·····@hoult.org> writes:

> In article <················@bomberlan.net>, Dave Morse 
> <······@bomberlan.net> wrote:
> 
> > Bruce Hoult wrote:
> > 
> > > I think that data structure lookup and function application should be 
> > > differentiated from each other, of only because the data structure 
> > > lookup denotes a "place" that you can setf, while the function 
> > > application doesn't.
> > 
> > You're right most of the time, but of course some function calls are 
> > invertible:
> > 
> > e.g. (package-nicknames foo)
> > <---> (setf (package-nicknames foo) '(fo))
> 
> Hmm.  I'm looking at the package-nicknames entry in the hyperspec.  How 
> am I supposed to tell that you can setf it?

You can't (portably).  it would say "Accessor" instead of "Function"
at the top of the entry if you could SETF it.  I think it's not
conforming for an implementation to extend this to allow SETF, btw,
though I didn't check to be sure.  That would be enumerated in the concepts
section of the package chapter.

You have to use RENAME-PACKAGE to change the package nicknames, which
means giving it a bunch of args you probably don't care about.
From: Dave Morse
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C06E87B.20908@bomberlan.net>
Kent M Pitman wrote:

> Bruce Hoult <·····@hoult.org> writes:
> 
> 
>>In article <················@bomberlan.net>, Dave Morse 
>><······@bomberlan.net> wrote:
>>
>>
>>>Bruce Hoult wrote:
>>>
>>>
>>>>I think that data structure lookup and function application should be 
>>>>differentiated from each other, of only because the data structure 
>>>>lookup denotes a "place" that you can setf, while the function 
>>>>application doesn't.
>>>>
>>>You're right most of the time, but of course some function calls are 
>>>invertible:
>>>
>>>e.g. (package-nicknames foo)
>>><---> (setf (package-nicknames foo) '(fo))
>>>
>>Hmm.  I'm looking at the package-nicknames entry in the hyperspec.  How 
>>am I supposed to tell that you can setf it?
>>



Doh, I didn't actually bother to check my facts.  Please replace 
package-nicknames in the above example with something else invertible, 
for example: get.  Sorry.
From: Pierre R. Mai
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <87k7w9vy8c.fsf@orion.bln.pmsf.de>
Bruce Hoult <·····@hoult.org> writes:

> > You're right most of the time, but of course some function calls are 
> > invertible:
> > 
> > e.g. (package-nicknames foo)
> > <---> (setf (package-nicknames foo) '(fo))
> 
> Hmm.  I'm looking at the package-nicknames entry in the hyperspec.  How 
> am I supposed to tell that you can setf it?

You aren't, because you can't.  Bad or non-portable example on the OPs
part.

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Pierre R. Mai
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <87wv09vz8h.fsf@orion.bln.pmsf.de>
Bruce Hoult <·····@hoult.org> writes:

> I think that data structure lookup and function application should be 
> differentiated from each other, of only because the data structure 
> lookup denotes a "place" that you can setf, while the function 
> application doesn't.

Not necessarily.  Random function application forms can be valid
places, if you so define them through setf functions or setf
expansions.

Of course in order to change the future value of that function, you
will have to mutate some "real" data structure at some point, but
that is not actually relevant to the question at hand, it seems to
me, because it isn't apparent to the user.

We have no problem conflating slot accessors and "normal" methods, and
accessor GFs and normal methods.  Doing the same with arrays and
functions isn't all that different, though there are some problems to
overcome of integrating that idea with CL.

Whether it would be worth it, I can't answer.  That said, I find that
in situations where I would switch between function and table, one or
both of the following are true:

a) It is obvious from the start that this particular lookup merits its
   own abstraction, hence I'll use a function or macro to encapsulate
   and name the lookup anyway.
b) If I started out with a function, transparently changing that
   function to internally use a table is no problem.

Transparently changing a table lookup to a function is a problem, but
that is far more seldom the case, at least for me.  Of course I've
been influenced by the absence of the discussed feature for most of my
life, so my experience may not be very indicative.

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Paul Graham
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <4f52f844.0112031141.23589de@posting.google.com>
> I think that data structure lookup and function application should be 
> differentiated from each other, of only because the data structure 
> lookup denotes a "place" that you can setf, while the function 
> application doesn't.
> 

You can write a setf expander for any expression, not just one
that refers to a place, and there are cases in which you might
want to do it  You might do it as a way of memoizing a function,
for example.  

--pg
From: Andras Simon
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <vcdk7w4rmrn.fsf@russell.math.bme.hu>
····@bugbear.com (Paul Graham) writes:

> > I think that data structure lookup and function application should be 
> > differentiated from each other, of only because the data structure 
> > lookup denotes a "place" that you can setf, while the function 
> > application doesn't.
> > 
> 
> You can write a setf expander for any expression, not just one
> that refers to a place, and there are cases in which you might
> want to do it  You might do it as a way of memoizing a function,
> for example.  

Great! One more reason to stick to CL. (Another is that Amazon
doesn't list books called On Arc and ANSI Arc yet :-)

Andras
> 
> --pg
From: Carl Shapiro
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <ouyheremco4.fsf@panix3.panix.com>
Kent M Pitman <······@world.std.com> writes:

> this made FOO  a named array (that is, it put the array on the ARRAY
> property of FOO).  If you did (FOO 3) it would access element 3 of that
> array.  You had to use ARRAYCALL to access an array not declared in this way.

As you probably know, Zetalisp defined ARRAYCALL as a macro which
expanded out into a vanilla FUNCALL.

One thing I have been wondering is what's supposed to be passed in as
the first argument to ARRAYCALL?  It is always ignored in Zetalisp.
From: Kent M Pitman
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <sfwoflmgp7g.fsf@shell01.TheWorld.com>
Carl Shapiro <········@panix.com> writes:

> Kent M Pitman <······@world.std.com> writes:
> 
> > this made FOO  a named array (that is, it put the array on the ARRAY
> > property of FOO).  If you did (FOO 3) it would access element 3 of that
> > array.  You had to use ARRAYCALL to access an array not declared in this way.
> 
> As you probably know, Zetalisp defined ARRAYCALL as a macro which
> expanded out into a vanilla FUNCALL.
> 
> One thing I have been wondering is what's supposed to be passed in as
> the first argument to ARRAYCALL?  It is always ignored in Zetalisp.

The first argument was a type, effectively the element type of the array,
though it was not called that.  I think it was not evaluated. If memory 
serves, it was:

 (ARRAYCALL T FOO 1 2) for general arrays
 (ARRAYCALL NIL FOO 1 2) for weak-pointer general arrays
 (ARRAYCALL FLONUM FOO 1 2) for FLONUM arrays
 (ARRAYCALL FIXNUM FOO 1 2) for FIXNUM arrays
From: Kenny Tilton
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C0575C6.C190FA41@nyc.rr.com>
"Thomas F. Burdick" wrote:
> 
>  but he's claiming that the language is
> designed for advanced users, and I'm pretty sure most advanced OO
> programers can make good use of MI and ...

And he even cited his expert test audience as explicitly pooh-poohing
MI. I think my mouth has hanging open when I saw that. I obviously have
no idea how other programmers think, and must remember that next time I
talk to one. :)

kenny
clinisys
From: Dorai Sitaram
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <9u5gjm$fns$1@news.gte.com>
In article <···············@monsoon.OCF.Berkeley.EDU>,
Thomas F. Burdick <···@monsoon.OCF.Berkeley.EDU> wrote:
>······@mindspring.com (David Cohen) writes:
>
>> Quick intro:
>> http://www.paulgraham.com/paulgraham/arc
>
>It's a Lisp-1, but
>it looks like he's trying to make the trade-off worth it, because he's
>doing some cute things with that first position of a form that you
>couldn't do in a Lisp-2. 

I liked that part too.  Before I had access to Unix
command-line editing, I have often written out a
directory name without a "cd" in front of it, and in
the course of correction, wondered why it wouldn't just
cd anyway as there was no competing semantic (as
in a Lisp1 application with a non-procedure-or-macro at
the car).  I think there was even a freeware shell for
OS/2 that did this, but no mainstream Unix seems to
have adopted this tactic.  I wonder why, given Unix's
fondness for short commands. 

--d 
From: Rahul Jain
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <87vgft8kk0.fsf@photino.sid.rice.edu>
····@goldshoe.gte.com (Dorai Sitaram) writes:


> I have often written out a directory name without a "cd" in front of
> it, and in the course of correction, wondered why it wouldn't just
> cd anyway [...]  but no mainstream Unix seems to have adopted this
> tactic.

zsh allows this behavior as an option, and it runs on basically all
unices. I suppose it's not a mainstream shell, if that's what you
meant.

-- 
-> -/-                       - Rahul Jain -                       -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ·················@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   Version 11.423.999.220020101.23.50110101.042
   (c)1996-2000, All rights reserved. Disclaimer available upon request.
From: Hannu Koivisto
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <87k7w9twd6.fsf@lynx.ionific.com>
····@goldshoe.gte.com (Dorai Sitaram) writes:

> command-line editing, I have often written out a
> directory name without a "cd" in front of it, and in
> the course of correction, wondered why it wouldn't just
> cd anyway as there was no competing semantic (as
> in a Lisp1 application with a non-procedure-or-macro at
> the car).  I think there was even a freeware shell for
> OS/2 that did this, but no mainstream Unix seems to
> have adopted this tactic.  I wonder why, given Unix's
> fondness for short commands. 

FWIW, you can have that behaviour in zsh (the only Unix shell I
consider tolerable for interactive use) with autocd option.

-- 
Hannu
From: Erik Naggum
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3216067088226825@naggum.net>
* Dorai Sitaram
| I liked that part too.  Before I had access to Unix command-line editing,
| I have often written out a directory name without a "cd" in front of it,
| and in the course of correction, wondered why it wouldn't just cd anyway
| as there was no competing semantic (as in a Lisp1 application with a
| non-procedure-or-macro at the car).  I think there was even a freeware
| shell for OS/2 that did this, but no mainstream Unix seems to have
| adopted this tactic.  I wonder why, given Unix's fondness for short
| commands.

  Because users should be able to run newly installed programs that have
  the same name as an existing directory, or be able to name directories
  the same as existing commands without accidentally running programs that
  may be seriously damaging.  Microsoft would have done something like this
  because it allows so much mischief to be done to other users.  It is not
  unlike the seriously dangerous habit of having "." first in PATH.  Even
  when "." is last, mischief is certainly possible with common typos.  I
  have seen a lot of software installation scripts and even makefiles that
  depend on "." in PATH, which I fix to remove that problem.  Some people
  seem not to recognize that search lists and large namespaces constitute a
  problem when they build new software packages and _know_ they need to run
  a local version of a particular program.  To me, it is the annoying Y2K
  problem all over again, where people simply fail to provide the computer
  with information they have but think the computer should intuit, somehow,
  as if they were people.

///
-- 
  The past is not more important than the future, despite what your culture
  has taught you.  Your future observations, conclusions, and beliefs are
  more important to you than those in your past ever will be.  The world is
  changing so fast the balance between the past and the future has shifted.
From: ········@acm.org
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <ZWAN7.21576$cC5.2579900@news20.bellglobal.com>
Erik Naggum <····@naggum.net> writes:
> * Dorai Sitaram
> | I liked that part too.  Before I had access to Unix command-line
> | editing, I have often written out a directory name without a "cd"
> | in front of it, and in the course of correction, wondered why it
> | wouldn't just cd anyway as there was no competing semantic (as in
> | a Lisp1 application with a non-procedure-or-macro at the car).  I
> | think there was even a freeware shell for OS/2 that did this, but
> | no mainstream Unix seems to have adopted this tactic.  I wonder
> | why, given Unix's fondness for short commands.

> Because users should be able to run newly installed programs that
> have the same name as an existing directory, or be able to name
> directories the same as existing commands without accidentally
> running programs that may be seriously damaging.

This is NOT a case where there's significant chance of anything
"seriously damaging."

All we're talking about is the possibility of typing in:

% public_html

and having the shell figure out that:
  - Since there aren't any programs in $PATH by that name, and
  - Since there _is_ a directory under $PWD called public_html,
it would be slick to transform that into:

% cd public_html

There certainly are misfeatures out there that could result in "severe
mischief," adding in the _possibility_ of "Oh, my stars!  We went to a
subdirectory!  Oh, the humanity..." does not seem like massive
disaster.
-- 
(reverse (concatenate 'string ········@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/unix.html
Actually, typing random strings in the Finder does the equivalent of
filename completion.  (Discussion in comp.os.linux.misc  on the
intuitiveness of commands: file completion vs. the Mac Finder.)
From: Pierre R. Mai
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <87g06xvxy0.fsf@orion.bln.pmsf.de>
········@acm.org writes:

> There certainly are misfeatures out there that could result in "severe
> mischief," adding in the _possibility_ of "Oh, my stars!  We went to a
> subdirectory!  Oh, the humanity..." does not seem like massive
> disaster.

What if there is a public_html binary in the path[1]?  Your common
Unix/Linux system contains several thousand binaries in the default
path directories.  People will _not_ remember them all, and invoking
some random command (even if you do it without arguments), when you
were expecting a cd is not a good thing.

Throw in the usual common typing mistakes, including spaces where they
shouldn't be, and things start to look even worse.

And now add some other common stupidities, like having directories in
your path that are not solely under the control of people you trust
(i.e. root on Unix machines), and we are nearly entering Microsoft
Outlook teritory.

Regs, Pierre.

Footnotes: 
[1]  All the more likely for some of the more common directory names.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Erik Naggum
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3216079463684556@naggum.net>
* ········@acm.org
| This is NOT a case where there's significant chance of anything
| "seriously damaging."

  Are you kidding me?

| All we're talking about is the possibility of typing in:
| 
| % public_html
| 
| and having the shell figure out that:
|   - Since there aren't any programs in $PATH by that name, and
|   - Since there _is_ a directory under $PWD called public_html,
| it would be slick to transform that into:
| % cd public_html

  What if this was the case yesterday, but today, somebody put a program in
  one of the directories in PATH named "public_html" which did something
  that you did not want at all?

| There certainly are misfeatures out there that could result in "severe
| mischief," adding in the _possibility_ of "Oh, my stars!  We went to a
| subdirectory!  Oh, the humanity..." does not seem like massive disaster.

  If you want to achieve system security, you have to stop ridiculing the
  professional paranoia that security people have to engage in.

///
-- 
  The past is not more important than the future, despite what your culture
  has taught you.  Your future observations, conclusions, and beliefs are
  more important to you than those in your past ever will be.  The world is
  changing so fast the balance between the past and the future has shifted.
From: Ed L Cashin
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <m3y9kozu52.fsf@terry.uga.edu>
Erik Naggum <····@naggum.net> writes:

> * ········@acm.org
...
> | All we're talking about is the possibility of typing in:
> | 
> | % public_html
> | 
> | and having the shell figure out that:
> |   - Since there aren't any programs in $PATH by that name, and
> |   - Since there _is_ a directory under $PWD called public_html,
> | it would be slick to transform that into:
> | % cd public_html
> 
>   What if this was the case yesterday, but today, somebody put a program in
>   one of the directories in PATH named "public_html" which did something
>   that you did not want at all?

If they can change binaries that are in your path, then your system is
toast anyway.  

The main problem I see with the feature is that you might name a
directory something like "reboot" or some other no-argument command
that does something you don't want.

-- 
--Ed Cashin                     integrit file-verification system:
  ·······@terry.uga.edu         http://integrit.sourceforge.net/

    Note: If you want me to send you email, don't munge your address.
From: Erik Naggum
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3216088979694745@naggum.net>
* Ed L Cashin
| If they can change binaries that are in your path, then your system is
| toast anyway.  

  Huh?  Are you guys for real?

  Systems are upgraded by their system administrator, new software packages
  are installed by the system administrator, sanctioned or even requested
  by their owners and/or users.  There is no security breech here at all!
  It is the _normal_ operation that is a threat to the stupid design to
  conflate directory names with executable names.

  No wonder people design software with built-in security flaws when you
  guys cannot even read a description of the problem.

| The main problem I see with the feature is that you might name a
| directory something like "reboot" or some other no-argument command that
| does something you don't want.

  Since I already covered this case (sans examples, because examples cause
  even worse reading comprehension), you are just annoying me with Dylan-
  freak-like reading comprehension problems, right?

///
-- 
  The past is not more important than the future, despite what your culture
  has taught you.  Your future observations, conclusions, and beliefs are
  more important to you than those in your past ever will be.  The world is
  changing so fast the balance between the past and the future has shifted.
From: Marc Spitzer
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <slrna0ehmm.2bea.marc@oscar.eng.cv.net>
In article <··············@terry.uga.edu>, Ed L Cashin wrote:
> Erik Naggum <····@naggum.net> writes:
> 
>> * ········@acm.org
> ...
>> | All we're talking about is the possibility of typing in:
>> | 
>> | % public_html
>> | 
>> | and having the shell figure out that:
>> |   - Since there aren't any programs in $PATH by that name, and
>> |   - Since there _is_ a directory under $PWD called public_html,
>> | it would be slick to transform that into:
>> | % cd public_html
>> 
>>   What if this was the case yesterday, but today, somebody put a program in
>>   one of the directories in PATH named "public_html" which did something
>>   that you did not want at all?
> 
> If they can change binaries that are in your path, then your system is
> toast anyway.  
> 
> The main problem I see with the feature is that you might name a
> directory something like "reboot" or some other no-argument command
> that does something you don't want.

A rough gage of security on a unix system is:
security = 1/convenience
And you seem to want a large value for convenience.  Here is a simple
example of why your idea needs to be reconsidered IMO.  I have a
directory called partitions or formats and as uid 0(aka root, but not
limited to root).  I type formats(or partitions) but the s does not
take so instead of changing directories in invoke the command.  Now it
depends on the unix you are on and what else you typed before you
realized you screwed up how badly you have just fucked your self and
your employer.  

You are also setting your self up for name clashes down the road.  And
realy unhappy management when the users who you support do the EXACT
SAME THING they did yesterday but now they have given you a reason to
finally see if your backup policy is as good as you thought it was.
If you were an SysAdmin that installed such a potentially distructive
piece of software, solely because some users wanted it, you probably
would not work there by the end of the day that the problem happened
if I had anything to do with it.  

Some tmes good admin is as simple as saying "no way in hell is that
going on my systems", good security also.

marc 


> 
> -- 
> --Ed Cashin                     integrit file-verification system:
>   ·······@terry.uga.edu         http://integrit.sourceforge.net/
> 
>     Note: If you want me to send you email, don't munge your address.
From: Ian Wild
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C074B9A.F63A5470@cfmu.eurocontrol.int>
Ed L Cashin wrote:
> 
> The main problem I see with the feature is that you might name a
> directory something like "reboot" or some other no-argument command
> that does something you don't want.

How many people still write programs called "test" and
scratch their heads in puzzlement?
From: Tim Bradshaw
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <fbc0f5d1.0111300826.3d220663@posting.google.com>
Ian Wild <···@cfmu.eurocontrol.int> wrote in message news:<·················@cfmu.eurocontrol.int>...
> 
> How many people still write programs called "test" and
> scratch their heads in puzzlement?

Heh.  This was the first mistake I ever made on Unix.  I *still* call
all my test programs `ts' because of this.  Even though I haven't had
. in my path for 15 years or something, so I'd have to say ./test
anyway...

--tim
From: Ed L Cashin
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <m3oflir2ib.fsf@terry.uga.edu>
··········@tfeb.org (Tim Bradshaw) writes:

> Ian Wild <···@cfmu.eurocontrol.int> wrote in message news:<·················@cfmu.eurocontrol.int>...
> > 
> > How many people still write programs called "test" and
> > scratch their heads in puzzlement?
> 
> Heh.  This was the first mistake I ever made on Unix.  I *still* call
> all my test programs `ts' because of this.  Even though I haven't had
> . in my path for 15 years or something, so I'd have to say ./test
> anyway...

Yeah, I've never had the problem even though I always called my test
programs "test".  

-- 
--Ed Cashin                     integrit file-verification system:
  ·······@terry.uga.edu         http://integrit.sourceforge.net/

    Note: If you want me to send you email, don't munge your address.
From: Janne Rinta-Mänty
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <xknsnaw1ln3.fsf@lepoluoto.cs.Helsinki.FI>
Ian Wild 2001-11-30T09:00:18Z:
> How many people still write programs called "test" and scratch their
> heads in puzzlement?

Not me, but recently I did

(defstruct something
  ;; ...
  p)

and scratched my head for a few minutes.

-- 
Janne Rinta-M�nty
From: Tim Bradshaw
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <fbc0f5d1.0111300423.7e22d84a@posting.google.com>
········@acm.org wrote in message news:<·······················@news20.bellglobal.com>...
> 
> There certainly are misfeatures out there that could result in "severe
> mischief," adding in the _possibility_ of "Oh, my stars!  We went to a
> subdirectory!  Oh, the humanity..." does not seem like massive
> disaster.


$ public_html
$ rm *.html
From: ········@acm.org
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <7rLN7.24385$cC5.2818807@news20.bellglobal.com>
··········@tfeb.org (Tim Bradshaw) writes:
> ········@acm.org wrote in message news:<·······················@news20.bellglobal.com>...
> > There certainly are misfeatures out there that could result in "severe
> > mischief," adding in the _possibility_ of "Oh, my stars!  We went to a
> > subdirectory!  Oh, the humanity..." does not seem like massive
> > disaster.
> 
> $ public_html
> $ rm *.html

.. And what _other_ result would you have been expecting than for a
pile of html files to go away?
-- 
(reverse (concatenate 'string ·············@" "sirhc"))
http://www.cbbrowne.com/info/languages.html
"The wrath of Holloway is nothing compared to the wrath of Moon."
-- Fred Drenckhahn
From: Tim Bradshaw
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <fbc0f5d1.0111301122.5293435c@posting.google.com>
········@acm.org wrote in message news:<7rLN7.24385$> 
> .. And what _other_ result would you have been expecting than for a
> pile of html files to go away?


I was expecting a different pile to go away.  In particular I was not
expecting the ones in my public_html directory to go away.  I care
about which files I delete.

--tim
From: ········@acm.org
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <fpSN7.19909$Ju6.3415693@news20.bellglobal.com>
··········@tfeb.org (Tim Bradshaw) writes:
> ········@acm.org wrote in message news:<7rLN7.24385$> 
> > .. And what _other_ result would you have been expecting than for a
> > pile of html files to go away?
> 
> I was expecting a different pile to go away.  In particular I was not
> expecting the ones in my public_html directory to go away.  I care
> about which files I delete.

And you typed "public_html" first because...
-- 
(concatenate 'string "chris" ·@cbbrowne.com")
http://www.cbbrowne.com/info/lsf.html
Black holes are where God divided by zero.
From: Kent M Pitman
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <sfwoflk6j70.fsf@shell01.TheWorld.com>
········@acm.org writes:

> ··········@tfeb.org (Tim Bradshaw) writes:
> > ········@acm.org wrote in message news:<7rLN7.24385$> 
> > > .. And what _other_ result would you have been expecting than for a
> > > pile of html files to go away?
> > 
> > I was expecting a different pile to go away.  In particular I was not
> > expecting the ones in my public_html directory to go away.  I care
> > about which files I delete.
> 
> And you typed "public_html" first because...

Actually, it wasn't public_html that was typed.  It was just p* and it
accidentally expanded to just one item, so was taken as if public_html
was typed... or perhaps he meant to type ls public_html but made a typo...
or perhaps it was a paste-o ... or perhaps completion was used and
he typed p<TAB><ENTER> without realizing the context, getting a completely
different item than intended ... or ....
From: Thomas F. Burdick
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <xcv7ks7yhif.fsf@whirlwind.OCF.Berkeley.EDU>
Kent M Pitman <······@world.std.com> writes:

> ········@acm.org writes:
> 
> > ··········@tfeb.org (Tim Bradshaw) writes:
> > > ········@acm.org wrote in message news:<7rLN7.24385$> 
> > > > .. And what _other_ result would you have been expecting than for a
> > > > pile of html files to go away?
> > > 
> > > I was expecting a different pile to go away.  In particular I was not
> > > expecting the ones in my public_html directory to go away.  I care
> > > about which files I delete.
> > 
> > And you typed "public_html" first because...
> 
> Actually, it wasn't public_html that was typed.  It was just p* and it
> accidentally expanded to just one item, so was taken as if public_html
> was typed... or perhaps he meant to type ls public_html but made a typo...
> or perhaps it was a paste-o ... or perhaps completion was used and
> he typed p<TAB><ENTER> without realizing the context, getting a completely
> different item than intended ... or ....

Of course, some of these (particularly the paste-o) are possible
without that aweful misfeature.  Which is why I consider it a safety
issue to have at least the current working directory in the shell
prompt, if not the entire path to it (which I always use for root).
Ob Lisp: I really like how CLISP puts the name of the current package
in the prompt.  I use ILISP, so even using CMUCL, it's on the mode
line, but I think that was a good design choice on the part of CLISP.
Yuck, imagine if typing a symbol at the toplevel, if it had no value
as a variable, but there was a package of the same name, was the same
as typing (in-package ...).

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Daniel Barlow
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <878zcnwz6g.fsf@noetbook.telent.net>
···@whirlwind.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> Ob Lisp: I really like how CLISP puts the name of the current package
> in the prompt.  I use ILISP, so even using CMUCL, it's on the mode
> line, but I think that was a good design choice on the part of CLISP.

In CMUCL, you can set *prompt* to a function that returns any string
of your choice.  See http://ww.telent.net/cliki/CMUCL%20Hints for
a tip courtesy of Paul Foley that uses this to get the current package
into the prompt.


-dan

-- 

  http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources 
From: Christian Lynbech
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <ofd71v5rvd.fsf@chl.ted.dk.eu.ericsson.se>
>>>>> "Thomas" == Thomas F Burdick <···@whirlwind.OCF.Berkeley.EDU> writes:

Thomas> Yuck, imagine if typing a symbol at the toplevel, if it had no value
Thomas> as a variable, but there was a package of the same name, was the same
Thomas> as typing (in-package ...).

The application I am working on started out in Guile Scheme. We had
our own REPL, which resided along with most of the aplication code in
the main user module.

Our REPL both supported some special syntax as well as allowing
general scheme expressions to be evaluated. However, some care was
needed. If you changed the current module to be something else than
the user module, you could be in trouble. If `eval' wasn't visible in
the other module, the REPL would stop working and you would be unable
to change back since you could not evaluate anything! Restarting the
application was the only solution.

Taught me a lesson or two on the virtues of the CL package system.


------------------------+-----------------------------------------------------
Christian Lynbech       | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244    | email: ·················@ted.ericsson.dk
Fax:   +45 8938 5101    | web:   www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - ·······@hal.com (Michael A. Petonic)
From: Tim Bradshaw
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <fbc0f5d1.0112030534.3cd48c2b@posting.google.com>
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> 
> Actually, it wasn't public_html that was typed.  It was just p* and it
> accidentally expanded to just one item, so was taken as if public_html
> was typed... or perhaps he meant to type ls public_html but made a typo...
> or perhaps it was a paste-o ... or perhaps completion was used and
> he typed p<TAB><ENTER> without realizing the context, getting a completely
> different item than intended ... or ....

Yes, one of those.  Probably it was meant to be publish_html or
something and I typed public<TAB> (that C should have been S).

I think the underlying message about this stuff is this: 

    Don't make the current directory special for commands.

Years ago practically everyone had . somewhere in their path, thus
meaning that you could pick up random commands depending on whatever
happened to be in the current directory.  Even before that people
often had . *first* in their path, which is even worse.  It is
convenient, of course, because you don't have to type all this
./command rubbish, but sometimes too much convenience is not worth the
pain. I have no idea what the majority of people do now (and in fact
my `practically everyone' above is based simply on my experience), but
I kind of hope that they've worked out that . *anywhere* in the path
is not a good thing: certainly no default setup on machines I run has
. in the path anywhere.  If you want to be able to shadow commands you
do it by having a $HOME/bin and putting the shadows in *there*.

This magic cd thing is just another case of this - The command you
type has meaning which depends on exactly which directory you happen
to be in at the time, and that's not a good thing to do on Unix
machines.  (Note, as an aside, I *would* be happy with ./public_html
doing a cd, I think).

--tim
From: Brian P Templeton
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <87666yyfsh.fsf@tunes.org>
··········@tfeb.org (Tim Bradshaw) writes:

[...]
> This magic cd thing is just another case of this - The command you
> type has meaning which depends on exactly which directory you happen
> to be in at the time, and that's not a good thing to do on Unix
> machines.  (Note, as an aside, I *would* be happy with ./public_html
> doing a cd, I think).
> 
········@#&$ pwd
~/www
········@#&$ ls
junk1.html spam.html old.html public_html/ publish_html* 
                [User decides to publish his WWW site]
········@#&$ ./pub<TAB>
          [User decides to get rid of those junk HTML files]
········@#&$ rm *.html

-- 
BPT <···@tunes.org>	    		/"\ ASCII Ribbon Campaign
backronym for Linux:			\ / No HTML or RTF in mail
	Linux Is Not Unix			 X  No MS-Word in mail
Meme plague ;)   --------->		/ \ Respect Open Standards
From: Erik Naggum
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3216128325597674@naggum.net>
* Tim Bradshaw
> $ public_html
> $ rm *.html

* ········@acm.org
| .. And what _other_ result would you have been expecting than for a
| pile of html files to go away?

  A different pile of html files?

///
-- 
  The past is not more important than the future, despite what your culture
  has taught you.  Your future observations, conclusions, and beliefs are
  more important to you than those in your past ever will be.  The world is
  changing so fast the balance between the past and the future has shifted.
From: Coby Beck
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <FLPN7.147681$Yb.37789240@typhoon.tampabay.rr.com>
<········@acm.org> wrote in message
····························@news20.bellglobal.com...
> ··········@tfeb.org (Tim Bradshaw) writes:
> > ········@acm.org wrote in message
news:<·······················@news20.bellglobal.com>...
> > > There certainly are misfeatures out there that could result in "severe
> > > mischief," adding in the _possibility_ of "Oh, my stars!  We went to a
> > > subdirectory!  Oh, the humanity..." does not seem like massive
> > > disaster.
> >
> > $ public_html
> > $ rm *.html
>
> .. And what _other_ result would you have been expecting than for a
> pile of html files to go away?
> --

and one pile is as good as the next, eh?  :-/
--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
From: Raffael Cavallaro
Subject: Paul Graham and OO
Date: 
Message-ID: <aeb7ff58.0112012115.744fce42@posting.google.com>
···@monsoon.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@monsoon.OCF.Berkeley.EDU>...
> I'm
> amazed that someone who's worked with Common Lisp couldn't see the
> benefit of multiple inheritance and multiple dispatch.  Sure, you can
> do most things without them -- but he's claiming that the language is
> designed for advanced users, and I'm pretty sure most advanced OO
> programers can make good use of MI and especially multiple dispatch.

Paul Graham has always been at best lukewarm with regard to OO
programming. Here's a quote from ANSI Common Lisp, p. 178, and the
associated note which is on p. 408. Graham is discussing CLOS here:

"If the program was written carefully to begin with, we can make all
these types of modifications without even looking at the rest of the
code.*"

* note, p. 408 "Let's play that back one more time: _we can make all
these types of modifications without even looking at the rest of the
code_. This idea may sound alarmingly familiar to some readers. It is
the recipie for spaghetti code.
The object-oriented model makes it easy to build up programs by
accretion. What this often means in practice, is that it provides a
structured way to write spaghetti code. This is not necessarily bad,
but it is not entirely good either. A lot of code in the real world is
spaghetti code, and this is probably not going to change soon. For
programs that would have ended up as spaghetti anyway, the
oject-oriented model is good: they will at least be structured
spaghetti. But for programs that might otherwise have avoided this
fate, object oriented abstractions could be more dangerous than
useful."

Raf
From: Thomas F. Burdick
Subject: Re: Paul Graham and OO
Date: 
Message-ID: <xcvr8qd8594.fsf@famine.OCF.Berkeley.EDU>
·······@mediaone.net (Raffael Cavallaro) writes:

> ···@monsoon.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@monsoon.OCF.Berkeley.EDU>...
> > I'm
> > amazed that someone who's worked with Common Lisp couldn't see the
> > benefit of multiple inheritance and multiple dispatch.  Sure, you can
> > do most things without them -- but he's claiming that the language is
> > designed for advanced users, and I'm pretty sure most advanced OO
> > programers can make good use of MI and especially multiple dispatch.
> 
> Paul Graham has always been at best lukewarm with regard to OO
> programming. Here's a quote from ANSI Common Lisp, p. 178, and the
> associated note which is on p. 408. Graham is discussing CLOS here:
> 
> "If the program was written carefully to begin with, we can make all
> these types of modifications without even looking at the rest of the
> code.*"
> 
> * note, p. 408 "Let's play that back one more time: _we can make all
> these types of modifications without even looking at the rest of the
> code_. This idea may sound alarmingly familiar to some readers. It is
> the recipie for spaghetti code.
> The object-oriented model makes it easy to build up programs by
> accretion. What this often means in practice, is that it provides a
> structured way to write spaghetti code. This is not necessarily bad,
> but it is not entirely good either. A lot of code in the real world is
> spaghetti code, and this is probably not going to change soon. For
> programs that would have ended up as spaghetti anyway, the
> oject-oriented model is good: they will at least be structured
> spaghetti. But for programs that might otherwise have avoided this
> fate, object oriented abstractions could be more dangerous than
> useful."

Yeah, I was aware of this quote, and I completely agree with the
sentiment.  My view on OOP is that it's a powerful technique where
it's appropriate.  And, like all powerful techniques, it can be a
horrible thing when used inappropriately, particularly by clever
people, who tend to be able to dig remarkably deep holes for
themselves when trying to dig back out.  So, I may have been
projecting my views onto him, particularly since if he's designing a
language for experts, presumably experts should be wise enough to know
when to avoid OOP.  Then again, he *is* including an object system, so
I'm still confused...

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Robert Monfera
Subject: Re: Paul Graham and OO
Date: 
Message-ID: <3C0AF55E.802@fisec.com>
Thomas F. Burdick wrote:

> [...] it can be a horrible thing when used inappropriately, 

> particularly by clever people, who tend to be able to dig 

> remarkably deep holes for themselves [...]


Maybe clever people tend to be _able_ to, but being clever,
we don't.

Robert
From: Thomas F. Burdick
Subject: Re: Paul Graham and OO
Date: 
Message-ID: <xcvelmc9adc.fsf@famine.OCF.Berkeley.EDU>
Robert Monfera <·······@fisec.com> writes:

> Thomas F. Burdick wrote:
> 
> > [...] it can be a horrible thing when used inappropriately,
> 
> > particularly by clever people, who tend to be able to dig
> 
> > remarkably deep holes for themselves [...]
> 
> 
> Maybe clever people tend to be _able_ to, but being clever,
> we don't.

You *never* dig yourself into a hole?  I don't believe a word of it.
I learned a long time ago to check to see if I'm digging my own grave,
and hopefully to catch myself while I'm still only knee-deep, but the
only people I've ever seen who claim to never dig down, always seem to
be saying so from the center of the earth.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Robert Monfera
Subject: OT Re: Paul Graham and OO
Date: 
Message-ID: <3C0C3DB7.6030709@fisec.com>
Thomas F. Burdick wrote:

> Robert Monfera <·······@fisec.com> writes:
> 
> 
>>Thomas F. Burdick wrote:
>>
>>
>>>[...] it can be a horrible thing when used inappropriately,
>>>
>>>particularly by clever people, who tend to be able to dig
>>>
>>>remarkably deep holes for themselves [...]
>>>
>>
>>Maybe clever people tend to be _able_ to, but being clever,
>>we don't.
>>
> 
> You *never* dig yourself into a hole?  I don't believe a word of it.


If I say I don't drink or go to church it does not necessarily mean I 
*never* do.  I responded to your "tend to".


> I learned a long time ago to check to see if I'm digging my own grave,
> and hopefully to catch myself while I'm still only knee-deep, 


Mind your step!

> but the
> only people I've ever seen who claim to never dig down, always seem to
> be saying so from the center of the earth.


Then you must either be near them or hallucinate :-)

Robert
From: Tim Bradshaw
Subject: Re: Paul Graham and OO
Date: 
Message-ID: <fbc0f5d1.0112030255.5715803d@posting.google.com>
Robert Monfera <·······@fisec.com> wrote in message news:<············@fisec.com>...
> 
> Maybe clever people tend to be _able_ to, but being clever,
> we don't.

That's wisdom you mean there, I think.

--tim
From: Robert Monfera
Subject: Re: Paul Graham and OO
Date: 
Message-ID: <3C0C4631.7050203@fisec.com>
What I mean is that if somebody isn't capable of solving a problem OOP 
is beneficial for within reasonable time _with_ OOP, then he will 
probably not be capable of solving that problem _sans_ OOP within 
reasonable time.  Thus it is not fair to criticize OOP on the basis that 
it allows one to shoot himself in the foot in new ways.

OO myths I sometimes react to:
  - it is mainly for GUI work (luckily this is a dying breed)
  - its use should be minimized to avoid pitfalls
  - it makes code harder to read
  - choose the right tool for the job (looking the other way,
    wishing OOP were not it)
  - you can either program in OOP style or functional style
  - one who doesn't grok OOP can put together an equivalent
    solution just as rapidly

Robert

Tim Bradshaw wrote:

>>Maybe clever people tend to be _able_ to, but being clever,
>>we don't.
>>
> 
> That's wisdom you mean there, I think.
From: Kent M Pitman
Subject: Re: Paul Graham and OO
Date: 
Message-ID: <sfwwv0339id.fsf@shell01.TheWorld.com>
Robert Monfera <·······@fisec.com> writes:

> OO myths I sometimes react to:
>   - it is mainly for GUI work (luckily this is a dying breed)

Heh.  I remember when the Lisp Machine's "New Error System" (the Flavor-based,
object-oriented precursor to the CL Error System) came along and someone said:

"Finally a second use for flavors."  [For many, the first and only use that
had been out for years was for window system programming.]

It's funny how good ideas can take a while to understand how to use in 
general-purpose situations.
From: Kenny Tilton
Subject: Re: Paul Graham and OO
Date: 
Message-ID: <3C0AFB19.CE3BE0B8@nyc.rr.com>
I am not clever enough to get OO right by staring at it, so I just start
someplace reasonable and let the spaghetti develop until it becomes
unbearable, then I shake things up. Rinse. repeat. I wait as long as I
can so as many exceptional cases as possible can inform my redesign.

Indeed, i have a couple of class sub-hierarchies on Death Row over here
just waiting for the last straw.

kenny
clinisys

Robert Monfera wrote:
> 
> Thomas F. Burdick wrote:
> 
> > [...] it can be a horrible thing when used inappropriately,
> 
> > particularly by clever people, who tend to be able to dig
> 
> > remarkably deep holes for themselves [...]
> 
> Maybe clever people tend to be _able_ to, but being clever,
> we don't.
> 
> Robert
From: Doug Alcorn
Subject: Re: Paul Graham and OO
Date: 
Message-ID: <87u1v87wfo.fsf@localhost.localdomain>
Kenny Tilton <·······@nyc.rr.com> writes:

> Indeed, i have a couple of class sub-hierarchies on Death Row over here
> just waiting for the last straw.

This is a wonderful expression of feelings I have about some of the
code I maintain.
-- 
 (__) Doug Alcorn (···········@lathi.net http://www.lathi.net)
 oo / PGP 02B3 1E26 BCF2 9AAF 93F1  61D7 450C B264 3E63 D543
 |_/  If you're a capitalist and you have the best goods and they're
      free, you don't have to proselytize, you just have to wait. 
From: Drew McDermott
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C05501F.7A20B919@yale.edu>
David Cohen wrote:

> For those of you, like myself, who were wondering what Paul Graham
> (author of "ANSI Lisp" and "On Lisp") has been up to lately, the
> answer is: he's been devising a new Lisp dialect called "Arc".
>

Based on a cursory reading of the Arc proposal, I don't understand what
problem he's solving.  Getting rid of parentheses and/or adding infix
syntax to Lisp seems pointless.  It makes the expert programmers' life
harder (by making to harder to write code walkers and macros), and won't
fool the C-crowd, whose attachment to C syntax, no matter what the
underlying semantics, borders on the insane.

    -- Drew McDermott
From: Dave Bakhash
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <c29snawjkfb.fsf@biohazard-cafe.mit.edu>
······@mindspring.com (David Cohen) writes:

> For those of you, like myself, who were wondering what Paul Graham
> (author of "ANSI Lisp" and "On Lisp") has been up to lately, the
> answer is: he's been devising a new Lisp dialect called "Arc".

I havn't read the whole thing, but I've read enough.  This ain't no
good.

In fact, I am in shock after reading some of the things in there:

-------------- example --------------

14. Strings Work Like Lists


> (car "abc")   
\a
> (cons \a "bc")
"abc"

Contagion as with ints and floats


  > (+ "abc" '(d e))
  (\a \b \c D E)



Should we allow nonchars in strings? 

-------------- end here --------------

Who wants this?  _why_ would anyone want this?

Someone compared this in some way to Dylan.  But one thing that Dylan
did at least try to preserve was sensibility.  I don't think that Arc is
going anywhere, anytime.  The emphasis on abbreviation and some C-like
loop macros won't get anyone using this thing, and it doesn't matter who
wrote it.  I can't believe that this language is supposed to embody
"What programmers _secretly_ want".  Since when have programmers been
secretive?

writing x.y instead of (x . y) or whatever is _not_ what people want.
It almost seems as if Arc was designed by someone who wanted to make a
Lispy Perl, and even me, being one of the few Lisp guys who also likes
and uses Perl, I just can't see Arc as having value.

dave
From: Carl Shapiro
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <ouy8zcnzdg8.fsf@panix3.panix.com>
Dave Bakhash <·····@alum.mit.edu> writes:

[...]

> writing x.y instead of (x . y) or whatever is _not_ what people want.

Wait just a second, is 1.2 now a cons?  Or perhaps just a float?
Maybe it's a symbol!  Who knows?  After all, this is a language
designed for the "good" programmers!
From: Marco Antoniotti
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <y6cn112bys8.fsf@octagon.mrl.nyu.edu>
Carl Shapiro <········@panix.com> writes:

> Dave Bakhash <·····@alum.mit.edu> writes:
> 
> [...]
> 
> > writing x.y instead of (x . y) or whatever is _not_ what people want.
> 
> Wait just a second, is 1.2 now a cons?  Or perhaps just a float?
> Maybe it's a symbol!  Who knows?  After all, this is a language
> designed for the "good" programmers!

1.2 is a FLOAT.  The rules are very simple.  That is because in CL
spaces are meaningful as separators (something we should all be
gratuful for) and - to some extent - because you do not have infix
operators)

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.
From: Carl Shapiro
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <ouybshig546.fsf@panix3.panix.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> 1.2 is a FLOAT.  The rules are very simple.  That is because in CL
> spaces are meaningful as separators (something we should all be
> gratuful for) and - to some extent - because you do not have infix
> operators)

In Common Lisp, certainly!  But, this new-fangled something.something
syntax as short hand for dotted pairs (thankfully) isn't part of
Common Lisp.  As such, you cannot necessarily use Common Lisp's rules
to disambiguate the expression.
From: Thomas F. Burdick
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <xcvzo52oaew.fsf@famine.OCF.Berkeley.EDU>
Carl Shapiro <········@panix.com> writes:

> Marco Antoniotti <·······@cs.nyu.edu> writes:
> 
> > 1.2 is a FLOAT.  The rules are very simple.  That is because in CL
> > spaces are meaningful as separators (something we should all be
> > gratuful for) and - to some extent - because you do not have infix
> > operators)
> 
> In Common Lisp, certainly!  But, this new-fangled something.something
> syntax as short hand for dotted pairs (thankfully) isn't part of
> Common Lisp.  As such, you cannot necessarily use Common Lisp's rules
> to disambiguate the expression.

And, what with it being intended for experts, it should be obvious to
anyone "good" enough to use the language what is going on.  Sort of
like with C -- if you *can't* read that mess of syntax easily, you
obviously aren't "good" enough for the language.

</irony>

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Bruce Hoult
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <bruce-72D67C.09573902122001@news.paradise.net.nz>
In article <···············@panix3.panix.com>, Carl Shapiro 
<········@panix.com> wrote:

> Marco Antoniotti <·······@cs.nyu.edu> writes:
> 
> > 1.2 is a FLOAT.  The rules are very simple.  That is because in CL
> > spaces are meaningful as separators (something we should all be
> > gratuful for) and - to some extent - because you do not have infix
> > operators)
> 
> In Common Lisp, certainly!  But, this new-fangled something.something
> syntax as short hand for dotted pairs (thankfully) isn't part of
> Common Lisp.  As such, you cannot necessarily use Common Lisp's rules
> to disambiguate the expression

In Arc?  It's not shorthand for dotted pairs, but for function 
application.

-- Bruce
From: Janos Blazi
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3c0d0ef9_3@news.newsgroups.com>
It looks to me as though Mr Graham  were joking and we should not take Arc
too seriously. Maybe he simply wanted to enjoy the outrage in this NG.

J.B.




-----=  Posted via Newsfeeds.Com, Uncensored Usenet News  =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
 Check out our new Unlimited Server. No Download or Time Limits!
-----==  Over 80,000 Newsgroups - 19 Different Servers!  ==-----
From: Kenny Tilton
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C0D1732.756B0152@nyc.rr.com>
Janos Blazi wrote:
> 
> It looks to me as though Mr Graham  were joking and we should not take Arc
> too seriously. Maybe he simply wanted to enjoy the outrage in this NG.
> 

I had the same thought.

Does he say anywhere where the name came from? "arc" looks like an infix
"car".

kenny
clinisys
From: Phil Fraering,,,
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <m9aku9.s31.ln@127.0.0.1>
Kenny Tilton <·······@nyc.rr.com> writes:



>Janos Blazi wrote:
>> 
>> It looks to me as though Mr Graham  were joking and we should not take Arc
>> too seriously. Maybe he simply wanted to enjoy the outrage in this NG.
>> 

>I had the same thought.

>Does he say anywhere where the name came from? "arc" looks like an infix
>"car".

I can already see where he'll have to scale Arc back. If only because
the resulting language would be named Arc-light.

Phil

-- 
Phil Fraering
···@globalreach.net
From: ········@acm.org
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <dK8P7.7669$V12.1542368@news20.bellglobal.com>
"Janos Blazi" <······@hotmail.com> writes:
> It looks to me as though Mr Graham were joking and we should not
> take Arc too seriously. Maybe he simply wanted to enjoy the outrage
> in this NG.

If Graham spent a lot of time otherwise trolling around
comp.lang.lisp, that might make sense.  He doesn't, so it doesn't.

The things in the "spec" so far certainly seem consistent with the
"feel" of his other writings (e.g. - CL books, discussions of
Yahoo!Store activities), so it seems unlikely to be a pure joke.

Actually, the way I'd think it plausible for Arc to actually come into
existance would be for Graham to pick some existing Lisp
implementation (whether CL, Scheme, or something else might not
matter) and build it atop that.
-- 
(reverse (concatenate 'string ·············@" "sirhc"))
http://www.ntlug.org/~cbbrowne/lisp.html
Appendium to  the Rules  of the  Evil Overlord #1:  "I will  not build
excessively integrated  security-and-HVAC systems. They  may be Really
Cool, but are far too vulnerable to breakdowns."
From: Robert Monfera
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C0D78F0.4080702@fisec.com>
Does someone know why high-profile lispers either frequent c.l.l. or 
write Lisp books, but rarely both?  Maybe it's purely statistics - 
seeing that only a small portion of lispers post here, it's just 
unlikely that those few writers would be c.l.l. regulars.  But then 
again, writing a book often derives from a strong commitment to spread 
the word.  Maybe they write CL out of themselves and fill the void with 
arc, python, aspect-orinented programming or simply pull a Steele. 
Kent, no rush with that book :-)

Robert

········@acm.org wrote:

> If Graham spent a lot of time otherwise trolling around
> comp.lang.lisp, that might make sense.  He doesn't, so it doesn't.
From: Thaddeus L Olczyk
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3c0e8e3c.499633421@nntp.interaccess.com>
On Wed, 05 Dec 2001 01:32:09 GMT, Robert Monfera <·······@fisec.com>
wrote:

>Does someone know why high-profile lispers either frequent c.l.l. or 
>write Lisp books, but rarely both?
1) Richard Gabriell ( I know I spelled it wrong ) does neither.
2) In most news groups the people who post who are authors tend to

    be schlock writers. Corba in 21 days, C++ for dummies. Object 
   Oriented Programming Released. So I don't think you'll see many
    high-profile author post hear. Their books are just too high 
    quality :)
    Actually to be serious about it, in other newsgroups it's a 
    problem for me because I always want to say something like 
    " you don't know what you are talking about, you're just a 
    schlock writer " and eventually do triggering a flame war. (   
   sigh.)
From: Gareth McCaughan
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <slrna0th5o.16dt.Gareth.McCaughan@g.local>
Thaddeus L Olczyk wrote:

> On Wed, 05 Dec 2001 01:32:09 GMT, Robert Monfera <·······@fisec.com>
> wrote:
> 
> >Does someone know why high-profile lispers either frequent c.l.l. or 
> >write Lisp books, but rarely both?
> 1) Richard Gabriell ( I know I spelled it wrong ) does neither.

An interesting response, since Richard Gabriel

  - has written a book (more than one, even)

and

  - has posted to c.l.l several times over the last couple of weeks.

It's true that he hasn't written any high-profile books about Lisp
and that he isn't a regular in c.l.l, but still...

-- 
Gareth McCaughan  ················@pobox.com
.sig under construc
From: Pierre R. Mai
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <874rn53uzg.fsf@orion.bln.pmsf.de>
················@pobox.com (Gareth McCaughan) writes:

> Thaddeus L Olczyk wrote:
> 
> > On Wed, 05 Dec 2001 01:32:09 GMT, Robert Monfera <·······@fisec.com>
> > wrote:
> > 
> > >Does someone know why high-profile lispers either frequent c.l.l. or 
> > >write Lisp books, but rarely both?
> > 1) Richard Gabriell ( I know I spelled it wrong ) does neither.
> 
> An interesting response, since Richard Gabriel
> 
>   - has written a book (more than one, even)
> 
> and
> 
>   - has posted to c.l.l several times over the last couple of weeks.
> 
> It's true that he hasn't written any high-profile books about Lisp
> and that he isn't a regular in c.l.l, but still...

Don't know if this counts as "high-profile", but at the time, his book
"Performance and Evaluation of Lisp Systems" (MIT Press, 1985), did
receive some attention...

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Tim Bradshaw
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <fbc0f5d1.0112050519.7f3285ad@posting.google.com>
Robert Monfera <·······@fisec.com> wrote in message news:<················@fisec.com>...

> Does someone know why high-profile lispers either frequent c.l.l. or 
> write Lisp books, but rarely both?  

lack of a cloning machine and the fixed number of hours per day would
seem to explain a lot.  In particular why of the four possibilities
(books, cll, neither, both) the last is less plausible than the
others.

Damn, I knew Lisp should have had a generic COPY function, this would
have solved this problem so easily.  That must be why C++ does so much
better...

--tim
From: Robert Monfera
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <3C0EB738.6020402@fisec.com>
Tim Bradshaw wrote:

> lack of a cloning machine and the fixed number of hours per day would
> seem to explain a lot.


Are you sure about the former?
From: Kent M Pitman
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <sfwitbmuiqp.fsf@shell01.TheWorld.com>
Robert Monfera <·······@fisec.com> writes:

> Does someone know why high-profile lispers either frequent c.l.l. or 
> write Lisp books, but rarely both?

Break it down by case and it's easier to see.  Most people probably fall 
into more than one case, but in each case, the answer is clear and the sum
of all the cases is the result you say:

 - some people are social, others are not.  bookwriting is not a social
   acitivity. newsgroups are.

 - some people write books for money.  newsgroups don't pay money.  yet.
   the shift in the economy is troublesome.  looks like there are going 
   to be things we're used to having free that might cost money.  i'm not
   excited about that, but if money does start transacting, i hope some
   flows to the content producers and not just to the content hosters.

 - some people are just busy and can't afford to do all possible forms
   of public interaction. they are forced to choose.

 - books reach different audiences than newsgroups.   people make choices
   about this.  some people don't want their remarks interactively dissected.
   some people want to reach people who don't newsgroup. etc.

 - books are enduring.  the jury's still out on newsgroups.  certainly
   dejanews/google has been spotty 

 - some people prefer the prestige of a book.
   
 - it might be that if you write a book first, newsgroups feel like slumming
   it. i don't know.  i haven't been there.  on the reverse, writing for
   newsgroups consumes time that could go into books. it's a value judgment
   whether that risk is worth taking.  i judge it to be so.  others' mileage
   clearly varies.  maybe i won't get a book out, but at least i'll have been
   heard.  maybe if i tried to write a book, i'd get hit by a car before 
   i finished and never have done either.

 - books require research/editing/publication.  some people have a stomach
   for that.  i think books have traditionally locked out some people with
   things to say, and that newsgroups give a voice to such people.  nowadays,
   i feel a shift in the world to be more informal, perhaps due to the
   internet.  but traditionally, academic book publishers have had a very 
   snobby kind of ivory tower sense to them.  i've often felt the skill of
   "having an idea" was distinct from the skill of "doing documented research"
   but often the traditional publishing media require academic books to ahve
   a certain look.  i know i used to write a lot of published papers, but they
   took months to crank out.  and for all they might have had something to
   say, this newsgroup gives me a forum to say probably hundreds of times as
   many things as i might have ever gotten to say in published papers.
   some of them half-baked? sure.  but others with more patience for papers
   can then still build on what i have to say and formalize it.  better
   throughput overall.  but that's just what works for me.  the modality
   people like to work in is a personal choice.

> Maybe it's purely statistics - 

I doubt it.  IMO it's surely structural / non-accidental.

> seeing that only a small portion of lispers post here, it's just 
> unlikely that those few writers would be c.l.l. regulars.  But then 
> again, writing a book often derives from a strong commitment to spread 
> the word.  Maybe they write CL out of themselves and fill the void with 
> arc, python, aspect-orinented programming or simply pull a Steele. 
> Kent, no rush with that book :-)

Heh...
From: Bill Clementson
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <yxBP7.912$ER5.108898@rwcrnsc52>
Kent M Pitman <······@world.std.com> writes:

> Robert Monfera <·······@fisec.com> writes:
>
> > Does someone know why high-profile lispers either frequent c.l.l. or
> > write Lisp books, but rarely both?

Although it seems to be rare, some people have managed to convert newsgroup
participation into income. For example, Jeni Tennison is quite a prolific
poster on the XSL List group and she has recently released a book (XSLT and
XPath On The Edge) based (in large part) on material that she had posted to
the newsgroup. She also maintained a lot of her postings on her web site:
http://www.jenitennison.com/xslt/
prior to the publication of the book so that she continued to get feedback
on her postings even after the initial newsgroup postings.

I'm not suggesting that this approach might be a formula for success;
however, I (for one) would love to see something similar done either
individually or collaboratively by some of the high content/quality
posters on this list.

>  - books are enduring.  the jury's still out on newsgroups.  certainly
>    dejanews/google has been spotty

There is so much good material posted on comp.lang.lisp, it seems a waste
to have it just pile up in the Google archives. Not sure what the copyright
issues are though :-(

>  - books require research/editing/publication.  some people have a stomach
>    for that.  i think books have traditionally locked out some people with
>    things to say, and that newsgroups give a voice to such people.
nowadays,
>    i feel a shift in the world to be more informal, perhaps due to the
>    internet.  but traditionally, academic book publishers have had a very
>    snobby kind of ivory tower sense to them.  i've often felt the skill of
>    "having an idea" was distinct from the skill of "doing documented
research"

I think both can be valuable in book format; unfortunately, the barriers to
publication can mean that "formulas" that have worked in the past are copied
by
prospective authors.

BTW Kent, you mentioned that you might have a book in the works - any
advance hints on what & when?

bc
From: glauber
Subject: Re: Paul Graham describes his new Lisp dialect, "Arc"
Date: 
Message-ID: <892f97d1.0112040808.644d3938@posting.google.com>
······@mindspring.com (David Cohen) wrote in message news:<····························@posting.google.com>...
> For those of you, like myself, who were wondering what Paul Graham
> (author of "ANSI Lisp" and "On Lisp") has been up to lately, the
> answer is: he's been devising a new Lisp dialect called "Arc".

Wow! it's hard to understand why.

If he's looking for a simpler Lisp, Scheme is already there.
If he's looking for something with fewer ()s, then there's Dylan,
Perl, Python...
I can't see how this new language will be able to survive, but
hopefully it will express a handful of great ideas that will then be
able to survive somewhere else.

g