Paul Graham describes his new Lisp dialect, "Arc"
David Cohen
(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
Frank A. Adrian
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
Kenny Tilton
"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
Vebjorn Ljosa
|
| 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
Kenny Tilton
Vebjorn Ljosa wrote:
>
> * Kenny Tilton <kti...@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
Daniel Barlow
> 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
lars.r....@telia.com
<fad...@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
Fernando Rodríguez
>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
--
Carl Shapiro
> 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.
Carl Shapiro
> Arc is interesting from the standpoint of
[...]
> (d) simplifying CL.
It's a mid-life crisis Lisp.
Kenny Tilton
Daniel Barlow wrote:
>
> Kenny Tilton <kti...@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
Kenny Tilton
"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
Kenny Tilton
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
Dorai Sitaram
> (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
Frank A. Adrian
> 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
Daniel Barlow
> 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, SETI@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.
Fernando Rodríguez
>> 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. :-)
Kenny Tilton
"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
Kenny Tilton
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
Eric Moss
> 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
Marc Battyani
"Eric Moss" <eric...@alltel.net> wrote in message
news:3C03D721...@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
Coby Beck
"Kenny Tilton" <kti...@nyc.rr.com> wrote in message
news:3C036F8C...@nyc.rr.com...
I believe MS Outlook allows any received email the same functionality! ;-)
--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
Kenny Tilton
Coby Beck wrote:
>
> "Kenny Tilton" <kti...@nyc.rr.com> wrote in message
> news:3C036F8C...@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>
cbbr...@acm.org
> 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 "ac.notelrac.teneerf@" "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
cbbr...@acm.org
> 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 "moc.enworbbc@" "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
lin8080
> 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
Kenny Tilton
cbbr...@acm.org wrote:
>
> Kenny Tilton <kti...@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
Drew McDermott
> 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
Thomas F. Burdick
> 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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Carl Shapiro
> 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.
Kenny Tilton
"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
Thomas F. Burdick
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?
Kent M Pitman
> Carl Shapiro <csha...@panix.com> writes:
>
> > t...@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.
Thomas F. Burdick
> t...@monsoon.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Carl Shapiro <csha...@panix.com> writes:
> >
> > > t...@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.
Carl Shapiro
> 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.
Kent M Pitman
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
Kent M Pitman
> Kent M Pitman <pit...@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.
Dorai Sitaram
Thomas F. Burdick <t...@monsoon.OCF.Berkeley.EDU> wrote:
>coh...@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
Marco Antoniotti
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'.
Hannu Koivisto
> 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
Rahul Jain
> 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 -=- mailto: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.
Thomas F. Burdick
> 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.
Marco Antoniotti
t...@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Marco Antoniotti <mar...@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?
Bruce Hoult
<mar...@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
Erik Naggum
| 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.
Dave Morse
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)
Dave Morse
>
> 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))
Bruce Hoult
<dm-...@bomberlan.net> wrote:
Hmm. I'm looking at the package-nicknames entry in the hyperspec. How
am I supposed to tell that you can setf it?
-- Bruce
cbbr...@acm.org
> * 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 "gro.mca@" "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.)
Pierre R. Mai
> 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 <pm...@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
Kent M Pitman
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.
Dave Morse
> Bruce Hoult <br...@hoult.org> writes:
>
>
>>In article <3C06D038...@bomberlan.net>, Dave Morse
>><dm-...@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.
Pierre R. Mai
> 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
> > 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.
Thomas F. Burdick
> t...@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.
Erik Naggum
| 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.
Ed L Cashin
> * cbbr...@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:
eca...@terry.uga.edu http://integrit.sourceforge.net/
Note: If you want me to send you email, don't munge your address.
Erik Naggum
| 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?
Marc Spitzer
> Erik Naggum <er...@naggum.net> writes:
>
>> * cbbr...@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
Ian Wild
>
> 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?
Tim Bradshaw
>
> 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
Janne Rinta-Mänty
> 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
cbbr...@acm.org
.. And what _other_ result would you have been expecting than for a
pile of html files to go away?
--
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://www.cbbrowne.com/info/languages.html
"The wrath of Holloway is nothing compared to the wrath of Moon."
-- Fred Drenckhahn
Dave Bakhash
> 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
Tim Bradshaw
>
> 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
Erik Naggum
> $ public_html
> $ rm *.html
| .. 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?
Coby Beck
<cbbr...@acm.org> wrote in message
news:7rLN7.24385$cC5.2...@news20.bellglobal.com...
> tfb+g...@tfeb.org (Tim Bradshaw) writes:
> > cbbr...@acm.org wrote in message
news:<ZWAN7.21576$cC5.2...@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")
Tim Bradshaw
> 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
cbbr...@acm.org
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.
Kent M Pitman
> tfb+g...@tfeb.org (Tim Bradshaw) writes:
> > cbbr...@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 ....
Thomas F. Burdick
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 ...).
Daniel Barlow
> 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
Carl Shapiro
[...]
> 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!
Marco Antoniotti
Carl Shapiro <csha...@panix.com> 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)
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'.
Carl Shapiro
> 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.
Bruce Hoult
<csha...@panix.com> wrote:
In Arc? It's not shorthand for dotted pairs, but for function
application.
-- Bruce
Thomas F. Burdick
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>
Ed L Cashin
Yeah, I've never had the problem even though I always called my test
programs "test".
Raffael Cavallaro
> 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
IsraelRT
>* Kenny Tilton <kti...@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.
Brian P Templeton
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 <b...@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
Thomas F. Burdick
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...
Robert Monfera
> [...] 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
Kenny Tilton
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
Doug Alcorn
> 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 (mailto:do...@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.
Thomas F. Burdick
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.
Tim Bradshaw
>
> Maybe clever people tend to be _able_ to, but being clever,
> we don't.
That's wisdom you mean there, I think.
--tim
Tim Bradshaw
>
> 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
Paul Graham
> 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
Andras Simon
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
Robert Monfera
> Robert Monfera <mon...@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
Robert Monfera
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
Kent M Pitman
> 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.
Christian Lynbech
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: christia...@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
glauber
> 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
Janos Blazi
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! ==-----
Kenny Tilton
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
cbbr...@acm.org
> 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 "moc.enworbbc@" "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."
Robert Monfera
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
Thaddeus L Olczyk
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.)