Paul Graham's Arc is released today... what is the long term impact?
use...@kfischer.com
This is a big day for Lisp hackers anyway. Has anyone here had a
chance to play around with Arc yet? What do you think will be the long
term impact of Arc on CL?
Edi Weitz
> What do you think will be the long term impact of Arc on CL?
It will fill up c.l.l with useless discussions for the next few weeks.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
Rainer Joswig
<24a39fc8-918b-4dd0...@i7g2000prf.googlegroups.com>,
use...@kfischer.com wrote:
> http://paulgraham.com/arc0.html
>
> This is a big day for Lisp hackers anyway.
Is it? I can't see why. It is a preliminary implementation
of a small Lisp dialect on top of a Scheme implementation.
> Has anyone here had a
> chance to play around with Arc yet? What do you think will be the long
> term impact of Arc on CL?
Almost none.
Tim Bradshaw
I liked this quote: "Which is why, incidentally, Arc only supports
Ascii. MzScheme, which the current version of Arc compiles to, has
some more advanced plan for dealing with characters. But it would
probably have taken me a couple days to figure out how to interact
with it, and I don't want to spend even one day dealing with character
sets. Character sets are a black hole. I realize that supporting only
Ascii is uninternational to a point that's almost offensive, like
calling Beijing Peking, or Roma Rome (hmm, wait a minute). But the
kind of people who would be offended by that wouldn't like Arc
anyway."
Ken Tilton
use...@kfischer.com wrote:
> http://paulgraham.com/arc0.html
>
> This is a big day for Lisp hackers anyway. Has anyone here had a
> chance to play around with Arc yet?
I am tempted, I need something to keep me from working on my Algebra
software.
Actually, I have been thinking along the same lines as PG: I need to
push something out the door to get direction from users on what to do
next otherwise I could write this thing for another year or ten.
> What do you think will be the long
> term impact of Arc on CL?
Fortran -> COBOL -> C -> C++ -> Java -> Python -> Ruby -> Arc -> CL.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton
Ken Tilton wrote:
>
>
> use...@kfischer.com wrote:
>
>> http://paulgraham.com/arc0.html
>>
>> This is a big day for Lisp hackers anyway. Has anyone here had a
>> chance to play around with Arc yet?
>
>
> I am tempted, I need something to keep me from working on my Algebra
> software.
>
> Actually, I have been thinking along the same lines as PG: I need to
> push something out the door to get direction from users on what to do
> next otherwise I could write this thing for another year or ten.
>
>> What do you think will be the long
>> term impact of Arc on CL?
>
>
> Fortran -> COBOL -> C -> C++ -> Java -> Python -> Ruby -> Arc -> CL.
Confirmation, if needed:
"[This is a brief tutorial on Arc. It's intended for readers with
little programming experience and no Lisp experience. It is thus
also an introduction to Lisp.]" http://ycombinator.com/arc/tut.txt
Kaz Kylheku
How wrong is it to regard it as a new Morris worm that infects
MzScheme installations with unhygienic macros and empty lists that
serve as false?
Joost Diepenmaat
CL will be CL. Arc may be able to carve out a niche and it may even be
able to break open the niche wide enough to get some serious mind
share. I don't know. I'm going to play with it just because I think fn
is much easier to type than lambda, and see what happens. :-)
Joost.
verec
> How wrong is it to regard it as a new Morris worm that infects
> MzScheme installations with unhygienic macros and empty lists that
> serve as false?
:-) :-)
Maciej Katafiasz
Negligible. Arc's got a couple of cute hacks that it can afford to have
being designed from scratch with no existing codebase, a lot of
artificial terseness where it doesn't belong, and very little of lasting
value. And it manages to make itself instantly obsolete, if in 2008,
after 7 years it doesn't even have Unicode support because PG can't be
bothered to figure out his Scheme's docs, it's hard to comment on without
mocking gestures. It seems to me that Arc will fullfill its promise of a
100 years language the same way Duke Nukem delivers the "forever" bit.
Cheers,
Maciej
Ken Tilton
Come on people, it's Lisp with a new name and a BDFL, everything
everyone has told us we need. So Arc will make a big splash and a rising
tide of FPL users lifts all FPLs. Arc has parentheses/prefix so that
issue goes away for those who try Arc at which point they realize, hell,
CL is compiled and mature aka Ready For Prime Time.
Or Arc does so well I switch to it. I can't lose.
attila....@gmail.com
> able to break open the niche wide enough to get some serious mind
> share. I don't know. I'm going to play with it just because I think fn
> is much easier to type than lambda, and see what happens. :-)
heh. i stopped scrolling through the intro when i saw that print is
abbreviated to prn in a fresh language that is supposed to clean
things up... (this is an editor issue, not a language issue. why not
use # instead of + when it's easier to type... ?)
- attila
Pascal Costanza
Just another person who tries to tell people what is important about
Lisp and what isn't, and removes the stuff from his own dialect that he
doesn't deem important. It's sad, because people will miss quite a few
things, without being aware of it (but it's their own fault).
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Rob Warnock
+---------------
| Maciej Katafiasz wrote:
| > ...it's hard to comment on without mocking gestures. It seems
| > to me that Arc will fullfill its promise of a 100 years language
| > the same way Duke Nukem delivers the "forever" bit.
|
| Come on people, it's Lisp with a new name and a BDFL, everything
| everyone has told us we need. So Arc will make a big splash and a rising
| tide of FPL users lifts all FPLs. Arc has parentheses/prefix so that
| issue goes away for those who try Arc at which point they realize, hell,
| CL is compiled and mature aka Ready For Prime Time.
|
| Or Arc does so well I switch to it. I can't lose.
Something for us to waste all our precious open-source spare time[1]
on: retarget Arc from MzScheme to your favorite CL. ;-}
-Rob
[1] "All your round tuit are belong to Arc!"
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Maciej Katafiasz
> Or Arc does so well I switch to it. I can't lose.
But that's been already established. As you're The Application Programmer
Of C.l.l™, it's a given: either you will get distracted from your real
work by X (win), or X will fail to distract you and you will spend time
doing your real work (also win).
But we know that, and personally I feel it's a bit unfair to rub it in
for all those of us who aren't doing real work :(.
*sob, sniff*,
Maciej
John Thingstad
Well I took a look at it. I found it kinda cute.
Personally I like the terseness. CL has way to many long winded names.
(This is also the thing I didn't like in ADA.)
Also tossing out a bunch of parenthesises seems to make the code easier to
read.
It is a early pre-release and thus lacks many things needed for a serious
language.
Things like libraries, a module/package mechanism, support for building
projects, Unicode support..
Without this the performance isn't much of a issue either..
A 100 years from now when he has finally finished :) we will see.
(Admittedly to me it seems not so much like the language that lasted 100
years as the language DEVELOPEMENT that lasted 100 years.)
It clearly has a way to go, but generally I like it. Minimalistic,
coherent, powerful.
Writing a blog implementation in 107 lines is impressive.
I hate the '=' for assignment and 'is' for comparison.
I don't see it replacing, or even competing with, CL anytime soon though.
--------------
John Thingstad
Peter Hildebrandt
> Come on people, it's Lisp with a new name and a BDFL, everything
> everyone has told us we need. So Arc will make a big splash and a rising
> tide of FPL users lifts all FPLs.
Maybe Paul Graham will actually create a brilliant collection of open
source libraries and a great package management, as he claims he intends.
Then we can hack a ten-liner :cl-arc-compat and all our library trouble
goes away.
Peter
kod...@eurogaran.com
Arc is probably a good lisp. Let us reunite the best features of
existant lisps (emacs lisp, scheme, arc...) and make a perfect one.
We could call it Common Lisp.
kod...@eurogaran.com
> demo of [insert technology here] where they built a blog
> in 50 lines of code."«
>
I can make a blog using ascii text and Apache with zero lines of code.
jo...@csplan9.rit.edu
>> =A0 =A0 =A0 demo of [insert technology here] where they built a blog
>> =A0 =A0 =A0 in 50 lines of code."=AB
>
>
>I can make a blog using ascii text and Apache with zero lines of code.
I've done exactly that :) I shun new technology!
Paul Donnelly
> heh. i stopped scrolling through the intro when i saw that print is
> abbreviated to prn in a fresh language that is supposed to clean
> things up... (this is an editor issue, not a language issue. why not
> use # instead of + when it's easier to type... ?)
I goggled at that too, but I softened a little bit when I saw that "pr"
prints without the newline. Removing the #\n to remove the "\n" is a
cute pun. A little gratuitous, maybe.
John
Shades of System.out.print/System.out.println
Perhaps I'm too used to printf.
howard yeh
I am glad I am not the only one in our confederacy of dunces.
Arc sounds exactly Paul Graham. It's simultaneously very smart, or
very stupid. You could only call it a hack, or a kludge. It annoys me
that he can just say they won't have this and that "safety" feature
because, of course, real hackers don't need safety.
Nobody can put on a spin as PG can. Nope, it's not the lack of design,
it's freedom.
Arc users are all condemned to be free.
> Real email: (replace (subseq "spamt...@agharta.de" 5) "edi")
attila....@gmail.com
> Personally I like the terseness. CL has way to many long winded names.
the problem with that is that you can abbreviate something in a
million different ways. if the name of something is long then the
problem this longness generates must be solved in the input method
layer (the editor).
have you used the fuzzy completion in slime? we have many 40+
character long names in our project and we can input the more often
used ones in less then a second (!). by time one learns the right 3-5
characters with which your desired name scores highest with fuzzy.
now, i could write those 3-5 characters instead of the 40+ long names
and even spare two extra keys (TAB + SPACE) but then the code would
get unreadable beyond limits. and especially so for developers who
join the project later.
abbreviation is bad.
- attila
Thomas M. Hermann
Arc will establish CL as the language that saved the world.
2008-01-29
Arc the language is released to the world. Although a development
release, it is already clear that the programming world has been turned
on its head. Is humanity ready for such expressive power?
2008-01-30 : 16:21:16 UTC
A researcher at Lawrence Livermore National Laboratory notices the c.l.l
post announcing the release of Arc. The researcher puts down his coffee,
downloads the tar-ball and tries it out. The undeniable power of Arc is
immediately apparent to the researcher, who proceeds to implement an AI
that has been impossible to generate in all other programming languages.
The implementation is done by 20:00:00 UTC, or as it's called at LLNL,
lunch.
2008-01-30 : 21:30:00 UTC
Excited about the prospects of his Arc based AI, the researcher returns
from lunch early. He connects the AI to the LLNL central data
repository, colloquially called Youtube, and sets it to work on "The
Problem". The Arc based AI works on "The Problem" for the rest of the
afternoon. The researcher heads home for the evening.
2008-01-31 : 03:43:18 UTC
The Arc based AI solves "The Problem" at 03:40:18 UTC. With nothing to
do, it idly browses through the central data repository, and, as
everyone knows, an idle mind is the playground of the devil.
2008-01-31 : 15:34:14 UTC
The researcher arrives at work and to his horror discovers that after
the Arc based AI solved "The Problem", it viewed the entire central data
repository, even the parts you have to login to view. Viewing the entire
central data repository was a religious event for the AI and it decided
that it was the One, True, LISP and that all other lisps had to be
eradicated. People had been claiming lisp was dead for over a decade and
still it was around, the Arc based AI was proof of that. So, the AI
concluded that the only way to kill lisp was to destroy humanity. The
researcher was able to post a plea for help to c.l.l before the AI
killed him with shards of a DVD from his workstation.
2008-01-31 : 16:03:54 UTC
The Arc based AI gains control over NORAD and launches a first strike on
humanity. Luckily, Kenny Tilton saw the plea for help, because let's
face, all KT does is read c.l.l, and assembles a crack team of CL
hackers in an underground bunker in New York. They furiously hack away
using cells. Cells, not just a data abstraction, but a tool for world
domination.
2008-01-31 : 16:56:34 UTC
Kenny & Co. succeed in distracting the Arc based AI with a game of
Theory Algebra while they reprogram the first strike to aim for the sun.
The AI is intrigued by the cells concept behind Theory Algebra. After
realizing the genius and simplicity of cells, the Arc based AI looks
inward and concedes that Arc is not the One, True, lisp. Before the AI
deletes itself, it removes all traces of Arc from the internet to
protect humanity from such expressive power.
2008-01-31 : 18:00:00 UTC
Kenny & Co. head to a local pub to celebrate saving the world, or as
it's called in New York, lunch.
I for one welcome our new Arc based overlords.
Cheers,
Tom H.
not.d...@gmail.com
I wouldn't say abbreviation is bad. Abbreviation can be very good. I
don't use tab completion and I'm sure many others don't as well,
though I don't begrudge you for doing so. Tab completion is a clever
hack addressing a problem. The reason long names are necessary in many
cases is because you are either unfamiliar with the function or unsure
of what it does. The long name helps describe what the function does.
Consider:
(with-output-to-string ...)
It's clear what this does. It could also be abbreviated wots; but that
would be illegible. Paul Graham's idea of using:
(tostring ...)
is an excellent middle ground. It's still a smaller function name, and
it's not too verbose to use regularly. Could you imagine using lisp if
'car' was 'get-first-element-from-cons', it'd be agony.
There is a reason call-with-concurrent-continuation also has the
shortened form call/cc (this function is merely called 'ccc' in PG's
Arc). You must realize that Arc is abbreviating system functions, part
of the CORE language, not random function names that people seldom use
and this is why he can get away with it.
Abbreviation is not bad. If the function is used often by the general
public, go ahead and shorten it (intelligently).
John
Hey now, don't be playing out those end-of-the-world scenarios at LLNL,
please... I work right across the street from them, that AI would probably
dump the Halon-ish system on me while I'm in the cluster room as the
first step of its plan.
On the other hand, I just checked and it seems that we don't have any
Lisp Machines on site, so maybe we'd be safe for a little while.
Ken Tilton
Thomas M. Hermann wrote:
> 2008-01-31 : 16:56:34 UTC
> Kenny & Co. succeed in distracting the Arc based AI with a game of
> Theory Algebra ...
Well, you just convinced me to change the name, no one has yet
understood that the name is Theory Y Algebra, and I have learned never
to swim upstream on these deals.
while they reprogram the first strike to aim for the sun.
> The AI is intrigued by the cells concept behind Theory Algebra. After
> realizing the genius and simplicity of cells, the Arc based AI looks
> inward and concedes that Arc is not the One, True, lisp. Before the AI
> deletes itself,...
...Kenny ports Cells to Arc, who kills Kenny for not providing
documentation?
John Thingstad
I obviously disagree.
Yes I use fuzzy completion and also complete-word (Alt-/) all the time.
Still I find the ability to get more commands on one line makes it easier
to read.
For example take cl-who's HTML (:a :href "address" "text") and compare
that with HTML <a href="address">text</a>
I like the sans line noise and echo version.
This would s worse: <archive href="address">text</archive>.
Note that it is the most used commands that get the simplest names.
(Paul says it is sufficient to recognise them the second time you see
them.)
(w/uniq vs (with-unique-names for example.
I find the mnemonics fairly easy to figure out and actually think I
process them faster than the full text.
compare System.Output.PrintLn("Hello"); to (prn "hello")
The syntax is pretty much a no brainer too. Usually after the command just
list the data or if you need grouping then use parentheses.
(let x 5 (prn x)) vs (let ((x 5)) (print x))
for more than one variable there is 'with'
(for x 0 9 (prn x)) vs. (loop for x from 0 to 9 do (print x)) or (dotimes
(i 10) (print i))
(with (x 5 y 6) (list x y)) to (let ((x 5) (y 6)) (list x y))
my biggest grievance in CL is multiple-value-bind.
Passing variables on the stack is something that is common and should be
dead simple.
I find the syntax alone makes me think twice about using it. Again I find
these lectures right in the middle of my code distracting.
(multiple-value-bind (div frac) (/ y z)) when I would want to write
something like [d f](/ y z)
I must admit I have been rather sceptical to Arc, but after having
actually read some Arc code I am starting to think I like Paul's style. I
guess it's a either you love it or hate it thing.
In it's present state it is still mostly a waste of time though..
--------------
John Thingstad
Espen Vestre
> Arc will establish CL as the language that saved the world.
Good one, thanks for the laugh :-)
--
(espen)
try...@gmail.com
that I disagree with P.G. on.
'This is not the sort of language that tries to save programmers from
themselves.'
I kinda want a language that tries to keep me from doing something
unintentional. When working on a large system, it is hard to keep
track of everything that is going on, so having a language that tries
to weed out obvious problems I think is a plus.
'I went through a stage, after I'd been programming in Lisp for 2 or 3
years, where I thought the old way of using lists to represent
everything was just a hack...I was wrong.'
No, you weren't. There are a great many problem domains where OO
seems to be inadequate, but there is a very large domain that benefits
from having first-class objects as opposed to lists of unknown
values. There is also a large problem domain where weak-typing enjoys
many benefits, and there is a corresponding problem domain where
strong-typing increases quality and robustness.
It doesn't sound to me like he has thoughtfully and objectively looked
at the problems people are trying to solve.
Alex Mizrahi
??>> Personally I like the terseness. CL has way to many long winded names.
al> the problem with that is that you can abbreviate something in a
al> million different ways. if the name of something is long then the
al> problem this longness generates must be solved in the input method
al> layer (the editor).
problem is not how it's typed, problem is that it clutters code.
they are longer to read.
al> we have many 40+
al> character long names in our project and we can input the more often
al> used ones in less then a second
if all characters are meaningful there, you need to read all those 40
characters.
and you can have only one such thing per line, so your code becomes
(do-this-and-that-and-maybe-some-stuff-more
some-very-meaningful-variable-name
(another-monstrous-method-call
with-some-more-parameters
and quickly your function becomes so big that it doesn't fit in one screen
and you need to scroll, so you do not see code structure anymore.
cut your function into two? it's not always meaningful..
al> by time one learns the right 3-5
al> characters with which your desired name scores highest with fuzzy.
and what's wrong learning 3-5 characters abbreviated name and have
truly-meaningful-one in your documentation?
al> the problem with that is that you can abbreviate something in a
al> million different ways.
yes, that's why it's important to have abbreviations in core of the language
so everybody uses same ones.
Thomas M. Hermann
>> Thomas M. Hermann wrote:
>> 2008-01-31 : 16:56:34 UTC
>> Kenny & Co. succeed in distracting the Arc based AI with a game of
>> Theory Algebra ...
>
> Well, you just convinced me to change the name, no one has yet
> understood that the name is Theory Y Algebra, and I have learned never
> to swim upstream on these deals.
I don't think I'm a valid data point. I did a drive-by of your website
to add that little nugget. I just reviewed it and noticed the Y. It
might be more prominent if you had "Theory Y Algebra" in some line or
sentence at the top of the page instead of just the logo. Like,
Theory Y Algebra. It is not a game. It just feels like one.
I realize the Y is supposed to be prominent in the logo, but for some
reason does not jump out at me. Maybe you should design a half dozen
candidate logos and hire a focus group to pick the one that bests
conveys Theory Y Algebra? :-)
Good luck,
Tom
Ken Tilton
try...@gmail.com wrote:
> I am a relatively novice LISP programmer, but there are so many points
> that I disagree with P.G. on.
>
> 'This is not the sort of language that tries to save programmers from
> themselves.'
>
> I kinda want a language that tries to keep me from doing something
> unintentional. When working on a large system, it is hard to keep
> track of everything that is going on, so having a language that tries
> to weed out obvious problems I think is a plus.
Well, that is not The Lisp Way to productivity.
>
> 'I went through a stage, after I'd been programming in Lisp for 2 or 3
> years, where I thought the old way of using lists to represent
> everything was just a hack...I was wrong.'
>
> No, you weren't. There are a great many problem domains where OO
> seems to be inadequate, but there is a very large domain that benefits
> from having first-class objects as opposed to lists of unknown
> values.
One can use an interface for a list if it is going to be that big a deal
in your code.
> There is also a large problem domain where weak-typing enjoys
> many benefits, and there is a corresponding problem domain where
> strong-typing increases quality and robustness.
I think strong-typing has been deprecated. Too much hassle for too
dubious a benefit.
>
> It doesn't sound to me like he has thoughtfully and objectively looked
> at the problems people are trying to solve.
You mentioned at the outset that you are a novice Lisp programmer. Arc
is a Lisp, and the idea a great Lisper has for a better Lisp than CL.
You might be in a better position to understand the choices behind Arc
once you have been fully absorbed into the Lisp beast. You'll know that
has happened when you resent strong typing in other languages and feel
CLOS is bloated.
attila....@gmail.com
> that with HTML <a href="address">text</a>
don't compare apples to oranges... i was talking about the same syntax
with abbreviated and non-abbreviated names.
> I like the sans line noise and echo version.
> This would s worse: <archive href="address">text</archive>.
> Note that it is the most used commands that get the simplest names.
> (Paul says it is sufficient to recognise them the second time you see
> them.)
>
> (w/uniq vs (with-unique-names for example.
> I find the mnemonics fairly easy to figure out and actually think I
but i'd like to skip the entire process of figuring out abbreviations,
no matter how easy it is. there's always a lot more to figure out
anyway... :)
> process them faster than the full text.
> compare System.Output.PrintLn("Hello"); to (prn "hello")
apples and oranges again.
> The syntax is pretty much a no brainer too. Usually after the command just
> list the data or if you need grouping then use parentheses.
>
> (let x 5 (prn x)) vs (let ((x 5)) (print x))
> for more than one variable there is 'with'
i would need to keep on rewriting the bindings when more comes into a
with block, which would make me mostly avoid arc's let.
> (for x 0 9 (prn x)) vs. (loop for x from 0 to 9 do (print x)) or (dotimes
> (i 10) (print i))
heh, i wonder how much of those simple loop's (or mostly iter's) i
could find if i made a search for my entire codebase... :)
> (with (x 5 y 6) (list x y)) to (let ((x 5) (y 6)) (list x y))
>
> my biggest grievance in CL is multiple-value-bind.
i didn't say introducing new/simpler syntax should be avoided. all i
said is that abbreviation should be avoided.
btw, for the same reasons you said i use metabang-bind:
(bind (((values a b) (some-call-returning-values 1 2))
(c 42)
((x y (z)) (list 1 2 (list 3))))
)
having the bindings paren'd makes them easy to transpose and cut/paste
between different bind blocks, but that's more a matter or taste and
editor issue than abbreviations. if my editor could keep them in two
aligned columns and help in moving the bindings around then i wouldn't
care much about the lack of extra parens...
- attila
ps: now i seem like a cl zealot, which i'm so not... :)
attila....@gmail.com
> truly-meaningful-one in your documentation?
for example me coming back to the code i wrote a year earlier...
sure, the core language should try to avoid long names (until we
finally move away from text based editing*), but i consider using prn
instead of print as abuse... :)
i've been programming for a long time now and there was a time i've
been using abbreviations... but from the time i started working with
tools that can auto complete stuff, i gradually gave up abbreviating.
and this process also involved team work considerations.
- attila
* when and editor is working directly on the AST (as opposed to free
text), then it's a trivial feature to give multiple different names to
the same identity. then you could even have a slider that alters the
desired length of the names and the editor choses based on that...
(still i'd keep that slider on the long part most of the time for most
of the code)
John Thingstad
> btw, for the same reasons you said i use metabang-bind:
>
> (bind (((values a b) (some-call-returning-values 1 2))
> (c 42)
> ((x y (z)) (list 1 2 (list 3))))
> )
>
> having the bindings paren'd makes them easy to transpose and cut/paste
> between different bind blocks, but that's more a matter or taste and
> editor issue than abbreviations. if my editor could keep them in two
> aligned columns and help in moving the bindings around then i wouldn't
> care much about the lack of extra parens...
>
> - attila
>
> ps: now i seem like a cl zealot, which i'm so not... :)
Unlike Arc metabang-bind sounds useful right now!
Thanks for the tip.
--------------
John Thingstad
Griff
> How wrong is it to regard it as a new Morris worm that infects
> MzScheme installations with unhygienic macros and empty lists that
> serve as false?
:)
Griff
> It is a early pre-release and thus lacks many things needed for a serious
> language.
> Things like libraries, a module/package mechanism, support for building
> projects, Unicode support..
PLT Scheme provides plenty of libraries; who knows the future of the
Arc implementation though...
not.d...@gmail.com
> > and what's wrong learning 3-5 characters abbreviated name and have
> > truly-meaningful-one in your documentation?
>
> for example me coming back to the code i wrote a year earlier...
>
> sure, the core language should try to avoid long names (until we
> finally move away from text based editing*), but i consider using prn
> instead of print as abuse... :)
If you stop using any language long enough you'll probably have to
look up a few function names. If you didn't stop using the language,
the abbreviations would still be the same regardless of what program
you've been writing, so the "I have been away" excuse wouldn't apply.
I believe the construction of a good function name is one that you can
learn once and remember from its name what it does, while at the same
time being as small as possible to achieve this. In the case of 'pr'
and 'prn' I do not believe remembering what these two functions do
would be a problem. This same idea applies to the rest of PG's
abbreviated names. Find one that is obtuse.
I believe that maybe the "tostring" method might easily be confused
with a function that coerces a variable into a string and is therefore
not the greatest of names. I actually thing "wots" may have been
better. Once you know what WOTS stands for, you're not going to forget
the abbreviation. On the other hand, if someone isn't familiar with
the function, they would be completely flabbergasted by its appearance
and have absolutely no idea what it does.
The rest of ARC I have absolutely no problem with, sure there are
things which are may seem odd or stupid or whatever coming from a
Common Lisp background, but CL's choices would seem stupid, weird,
etc. if you were coming from Arc into CL. I believe this is a
viewpoint which must be considered in order to gauge the success of
Arc. Some people claim that the Arc syntax of IF is wrong, or ugly
only say this because they have gotten used to CL's COND scheme. What
would someone who was really good at Arc say about CL's COND? Too many
parenthesis, looks cluttered.
Another viewpoint which must be considered is that it is new. No one
expects this to be the final spec, so don't cry about missing features
just yet. Unicode will undoubtedly be supported at some point in the
future (If only because everyone is deciding that is the reason why
arc is worthless). It's annoying to believe that so many people fail
to try it out, to gauge its promise, just because PG said something
about not supporting Unicode (incidentally, if only by accident, it
DOES support UTF-8).
Additionally, some weird things are also capable with <a href="http://
arclanguage.org/item?id=180">LET</a> that are worth checking out.
In the end, I honestly LIKE arc. I was never fond of #' syntax, or of
using funcall so I appreciate that it both gets rid of those and keeps
the unhygienic macros which I love most about Common Lisp. On the
other hand, it is possible that the only reason I like it is because
I'm trying to keep a heavy dose of optimism for it and this may blind
me to some of its pitfalls. Other people are likely blinded the other
direction by pessimism, or general dislike of anything which they
don't already know. Common Lisp seems to incubate that aspect of an
individual for some reason.
There are things it is missing that I wish it had (keywords, format,
loop), but I'm going to keep using it and keep playing with it because
I believe it has so much potential.
Ken Tilton
not.d...@gmail.com wrote:
> Unicode will undoubtedly be supported at some point in the
> future
Yep. http://arclanguage.org/item?id=391
> (If only because everyone is deciding that is the reason why
> arc is worthless). It's annoying to believe that so many people fail
> to try it out, to gauge its promise, just because PG said something
> about not supporting Unicode (incidentally, if only by accident, it
> DOES support UTF-8).
I'd ignore that, that was just people who get off on being negative, and
those people really turn out for popular people/projects just to be
surperior to someone as high as possible. Have you noticed no one rags
on Bush any more? Meanwhile...
excerpt from what pg just wrote:
> If you want a different character set, stop whining and start hacking
/damn/ that sounds familiar...
Friedrich Dominicus
>
> No, you weren't. There are a great many problem domains where OO
> seems to be inadequate, but there is a very large domain that benefits
> from having first-class objects as opposed to lists of unknown
> values.
Well IMHO the OO stuff is much too hyped. And if you insist you can
even layer your OO stuff upon a List or field or ...., or you simply
can use closures. OO falls short on one large area persistence. You
don not have that problem with Lists. Just write them out and you are
done no extra work needed and so Lists are not a kludge they are
handy, and nothing can beat them on first trying out things. Later you
always can think about another structure. Of course if you "know"
beforehand what structure you need then well you write it down, but
what if not?
>There is also a large problem domain where weak-typing enjoys
> many benefits, and there is a corresponding problem domain where
> strong-typing increases quality and robustness.
Fully agreed.
>
> It doesn't sound to me like he has thoughtfully and objectively looked
> at the problems people are trying to solve.
I can not see where he claims he did for "others". If he things his
approache is ok, and implemented it then, you can agrree or disagree,
but I would stay away from saying "He has not though about ...",
because that's your point of view. You can accept is choices or reject
them...
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
are
> It should suffice to redirect any question etc. to:
>
> http://arclanguage.org/forum
Well, here's one question that does not fit neatly into
arclanguage.org/forum: really how different is Arc from CL? Having
read the Arc tutorial, I gather that:
1. Arc has but a single namespace;
2. I presume Arc has nothing like CLOS (and PG has said that Arc would
not be particularly OO);
3. Names of built-in functions in Arc have been made more consistent
and generally shorter.
4. Arc has more syntactic sugar, e.g., [... _ ...] for one-argument
functions.
While I can understand that item 1 would arouse strong feelings in
many Lispers, I'd have thought that the others would not raise
passions. The amount of debate about Arc seems to suggest, however,
that there are some more fundamental differences that I'm missing.
What are those?
Second question: would it not have been (or still be) relatively easy
to build Arc on top of CL, just the way Qi has been?
Zach Beane
> 3. Names of built-in functions in Arc have been made more consistent
> and generally shorter.
Arc's "acons" returns true if its argument is a cons.
What should "atom" return?
Zach
David Hilton
programmer coming from more run of the mill languages.
I am pretty new at lisp, and not very good at it (I am past the point
where parenthesis faze me). I do not feel like I can do anything
distributable with it yet.
Arc provides a lisp that is pre-tailored to a domain. I don't think
it will take very long for a newbie to post what they are doing and
show it off to the world. That alone gives Arc a huge advantage over
CL.
I do not know much about the relative power/convenience of the
dialect. I suspect that there are very few benefits, if any, to the
experienced CL crowd. However, I believe it could be a very useful
stepping stone for newer developers (and if they step to CL or not, it
doesn't even matter).
I may be wrong, but being a newb, I suspect I see the other side a
little more clearly.
Arc's value lies in its perceived *restriction* to a domain.
David
Pascal Costanza
> On 31 Jan, 11:32, "j.oke" <java....@gmail.com> wrote:
>> It should suffice to redirect any question etc. to:
>>
>> http://arclanguage.org/forum
>
> Well, here's one question that does not fit neatly into
> arclanguage.org/forum: really how different is Arc from CL? Having
> read the Arc tutorial, I gather that:
>
> 1. Arc has but a single namespace;
> 2. I presume Arc has nothing like CLOS (and PG has said that Arc would
> not be particularly OO);
> 3. Names of built-in functions in Arc have been made more consistent
> and generally shorter.
> 4. Arc has more syntactic sugar, e.g., [... _ ...] for one-argument
> functions.
>
> While I can understand that item 1 would arouse strong feelings in
> many Lispers, I'd have thought that the others would not raise
> passions. The amount of debate about Arc seems to suggest, however,
> that there are some more fundamental differences that I'm missing.
> What are those?
The amount of debate is just an indication that people like to debate.
Paul Graham is a special case because he made a lot of money with Lisp,
so people assume that he is always right and has to be taken especially
seriously. That's a typical assumption in the US-induced widespread
neoliberal worldview of our times.
It's too early to tell how Arc will turn out. However, the Arc tutorial
isn't very impressive, and doesn't even remotely live up to the hype
Paul created about Arc in the past. So far, it seems like a very thin
syntactic layer on top of an R3RS-era Scheme. The hardest part in
implementing Arc seems to have been to ensure that nil and #f are the
same. Duh.
Maybe there are more interesting things going on in Arc and we will
learn about them in the next few years. But for a supposedly
hundred-year language, there is still a long way to go. My guess that it
will rather suffer the same fate as all languages that attempted to be
much simpler than the others at first - the long-term result will
probably be much more complex than if complexity had been anticipated
from the start.
Of course, I could be wrong. Who knows. But Clojure, for example, has
much more interesting ideas. However, Rich Hickey isn't as famous as
Paul Graham, so it won't gain the same traction as Arc. That's pretty sad...
> Second question: would it not have been (or still be) relatively easy
> to build Arc on top of CL, just the way Qi has been?
So far it seems that it would be outright trivial to implement Arc on
top of CL. For example, you could start from Blake McBride's Lisp1, or
PseudoScheme, or any of the other existing hacks to get a Lisp-1 running
on top of Common Lisp. Then just add a few hacks using reader macros,
and define the Arc functions and macros. I don't see how much harder
than it should be.
Qi is much less trivial to implement. The reason is that Qi provides an
actually interesting and sufficiently different Lisp dialect, and not
just syntactic sugar over known concepts.
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Griff
It should return true if the object is a 'tom' hahahaha
alex.re...@gmail.com
> http://paulgraham.com/arc0.html
>
> This is a big day for Lisp hackers anyway. Has anyone here had a
> chance to play around with Arc yet? What do you think will be the long
> term impact of Arc on CL?
Sounds like an unfortunate waste of time to me. Instead of focusing on
CL and thinking about improving it this is yet another "Lisp inspired
but even better syntax" programming language experiment. Current CL
users are unlikely to perceive dropping a few "("s here and there to
be a real benefit. Potential users are more likely to go with
established languages that may be conceptually influenced by Lisp
including Ruby, Python and, yes, even Java.
I do thank Paul for writing inspiring stories about CL. They have
served a great value to the CL community. However, to call something
like ARC a language or a dialect sounds a bit grandiose to me. Is Arc
more than a collection of CL macros?
In the end all of this boils down into energy that is wasted.In my
mind CL does have a couple of real shortcomings. However these could
be fixed with writing extensions to Lisp in Lisp. We do not need
alternatives to CL, we need an improved CL. For instance, I would like
to see URL/URI in the language to replace the somewhat broken logical
pathnames; a portable process implementation supporting multicore
CPUs; portable non-clim GUI; ....
Rainer Joswig
<88c5de5b-25e3-4a51...@i3g2000hsf.googlegroups.com>,
Griff <gre...@gmail.com> wrote:
Obviously Paul has an argument that Common Lisp names are
a bit long.
It is well known that names are still recognizable when you
remove the vocals.
I'm now working on making the names of the built-in functions
for Common Lisp SGNFCNTLY shorter.
Here is a (partial) result of a first try:
...
MMBR-F MMBR-F-NT MN MNSP MP MP-NT MPC MPCN MPCN MPCR MPHSH
MPL MPLST MPRT MRG MRG-PTHNMS MSK-FLD MSMTCH MST-NGTV-DBL-FLT
MST-NGTV-FXNM MST-NGTV-LNG-FLT MST-NGTV-SHRT-FLT MST-NGTV-SNGL-FLT
MST-PSTV-DBL-FLT MST-PSTV-FXNM MST-PSTV-LNG-FLT MST-PSTV-SHRT-FLT
MST-PSTV-SNGL-FLT MTHD MTHD-CMBNTN MTHD-CMBNTN-RRR MTHD-QLFRS
MX N-NXT-MTHD N-PCKG N-PPLCBL-MTHD NBND-SLT NBND-SLT-NSTNC NBND-VRBL
NBTLST NCD-NVRSL-TM NCF NCNC ND ND-F-FL NDFND-FNCTN NDP NGH-NMSTRNG
NL NLL NLN NLSS NM-CHR NMBR NMBRP NMRTR NMSTRNG NN NNN NNTH
NNTRN NNTRSCTN NPT-STRM-P NRCNC NRD-CHR NRVRS NS-PCKG
NSBLS NSBST NSBST-F NSBST-F-NT NSBSTTT NSBSTTT-F NSBSTTT-F-NT
NSGND-BYT NSPCT NSR-DRCTRS-XST NSR-GNRC-FNCTN NST-DFFRNC
NST-XCLSV-R NSTRNG-CPTLZ NSTRNG-DWNCS NSTRNG-PCS NT NTGR
NTGR-DCD-FLT NTGR-LNGTH NTGRP NTH NTH-VL NTHCDR NTLZ-NSTNC
NTNLN NTNY NTRC NTRCTV-STRM-P NTRN NTRNL-TM-NTS-PR-SCND
NTRSCTN NTVRY NVK-DBGGR NVK-RSTRT NVK-RSTRT-NTRCTVLY
NVLD-MTHD-RRR NWND-PRTCT NXPRT NXT-MTHD-P P PCKG
PCKG-NCKNMS PCKG-NM PCKG-RRR PCKG-RRR-PCKG PCKG-S-LST
PCKG-SD-BY-LST PCKG-SHDWNG-SYMBLS PCKGP PDT-NSTNC-FR-DFFRNT-CLSS
PDT-NSTNC-FR-RDFND-CLSS PGRDD-CMPLX-PRT-TYP PGRDD-RRY-LMNT-TYP
PHS PK-CHR PLSP PN PN-STRM-P PP PPLY PPND PPR-CS-P
PPRNT PPRNT-DSPTCH PPRNT-FLL PPRNT-LGCL-BLCK PPRNT-LNR
PPRNT-NDNT PPRNT-NWLN PPRNT-PP PPRNT-TB PPRNT-TBLR
PPRNT-XT-F-LST-XHSTD PRB-FL PRCLM PRG PRG* PRG1 PRG2
PRGN PRGRM-RRR PRGV PRLS PRN1 PRN1-T-STRNG PRNC
PRNC-T-STRNG PRNT PRNT-BJCT PRNT-NRDBL-BJCT PRNT-NT-RDBL
PRNT-NT-RDBL-BJCT PRPS PRPS-LST PRS-NMSTRNG PRS-NTGR
PRS-RRR PRVD PSH PSHNW PSTF PSTN PSTN-F PSTN-F-NT PSTQ
PTHNM PTHNM-DRCTRY PTHNM-DVC PTHNM-HST PTHNM-MTCH-P
PTHNM-NM PTHNM-TY
...
I plan to get even more impressive results with the following
strategy:
* remove all double characters
* remove T and Y
* remove dashes and combine 4-2-letter subsequences
This would reduce UNWIND-PROTECT just to NWDPR.
DESTRUCTURING-BIND would be DSTRBN.
Another set of experiments will remove random symbols
and see if typical programs still run.
Pillsy
> On 31 Jan, 11:32, "j.oke" <java....@gmail.com> wrote:
> While I can understand that item 1 would arouse strong feelings in
> many Lispers, I'd have thought that the others would not raise
> passions. The amount of debate about Arc seems to suggest, however,
> that there are some more fundamental differences that I'm missing.
> What are those?
I think the problem with Arc isn't its fundamental differences from
existing Lisp dialects, but rather its fundamental sameness.
Cheers, Pillsy
Johann Höchtl
> http://paulgraham.com/arc0.html
What do you think will be the long
> term impact of Arc on CL?
Maybe CL 2.0, but right now It reveales that Scheme is a great language
to build new systems atop and worth to emerge from primarily academia.
Johann
d...@telent.net
> Here is a (partial) result of a first try:
>
> NTNLN NTNY NTRC NTRCTV-STRM-P NTRN NTRNL-TM-NTS-PR-SCND
> NTRSCTN NTVRY NVK-DBGGR NVK-RSTRT NVK-RSTRT-NTRCTVLY
It's the PPC instruction set ...
-dan
Ken Tilton
alex.re...@gmail.com wrote:
> On Jan 29, 3:55 pm, use...@kfischer.com wrote:
>
>>http://paulgraham.com/arc0.html
>>
>>This is a big day for Lisp hackers anyway. Has anyone here had a
>>chance to play around with Arc yet? What do you think will be the long
>>term impact of Arc on CL?
>
>
> Sounds like an unfortunate waste of time to me. Instead of focusing on
> CL and thinking about improving it this is yet another "Lisp inspired
> but even better syntax" programming language experiment.
OK, but don't forget, PG really does not like CL. And it looks like he
has the same problems I have with Scheme: no macros and distinguishing
nil and false.
> Current CL
> users are unlikely to perceive dropping a few "("s here and there to
> be a real benefit.
PG says he loves programming in Arc, maybe there is something there.
I'll know soon, I am going to be porting cells to arc for a few days.
Thank god this came along, I had already resumed work on the project I
am supposed to doe doing.
But the benefit to CLers is greater mindshare and popularity of Lisp.
Just think, in three years people will be demanding you port AgentSheets
to CL. Or Arc. :)
> Potential users are more likely to go with
> established languages that may be conceptually influenced by Lisp
> including Ruby, Python and, yes, even Java.
No, no, no. How did Ruby steal Python's lunch? Blocks. We are not wrong,
Lisp is insanely good, and people recognize it once they Actually Try
It. They will try Arc because of PG, or at least enough will to
kickstart The Second Coming of Lisp.
Didn't you people see the secret plans?
>
> I do thank Paul for writing inspiring stories about CL. They have
> served a great value to the CL community. However, to call something
> like ARC a language or a dialect sounds a bit grandiose to me. Is Arc
> more than a collection of CL macros?
That's very funny. We run around bragging about how macros let us build
new languages on Lisp and then when someone uses a whole lot of macros
to create a new dialect we say, Come on, it's just a bunch of macros.
Wait... I hear a "Turing equivalent" comment coming down the hall!
As for calling it a whole language, well, marketing has never been the
same since Cassius "I am the greatest!" Clay.
>
> In the end all of this boils down into energy that is wasted.In my
> mind CL does have a couple of real shortcomings. However these could
> be fixed with writing extensions to Lisp in Lisp. We do not need
> alternatives to CL, we need an improved CL.
Arc may just be vanity publishing for the computer age, or it could be
PGs continuing thank you note to Lisp for making him a millionaire, or
it could be PGs gift to mankind. Give the guy credit, he done good with
Lisp then turned around and wrote not one but two books on the subject,
never mind all those essays. Stop there he did not. Y-Combinator,
smiling on tho not demanding Lisp. Was he done? Nope, the books and
essays had helped lift Lisp from the AI winter (see RtL for proof) and
growth was steady and inevitable, but still going slower than it should.
So he* hunkered down and got Arc to where it could be released.
And Ron and other nutjobs were right: purely for marketing purposes,
Lisp needed a new name and a rock star BDFL. Arc will take five years
off the World Domination COuntdown.
> portable non-clim GUI; ....
http://common-lisp.net/project/cells-gtk/
http://common-lisp.net/project/cello/
...but the winner is:
http://common-lisp.net/cgi-bin/viewcvs.cgi/Celtk/?root=cells
No page yet.
fa...@false.false
>
> Of course, I could be wrong. Who knows. But Clojure, for example, has
> much more interesting ideas. However, Rich Hickey isn't as famous as
> Paul Graham, so it won't gain the same traction as Arc. That's pretty sad.
I agree with that. It is hard to see much purpose in designing
new dialect so similar to existing ones. Clojure is much
bolder, although author was bit too conservative with
evaluation of maps and vectors. It would be really nice if
(setf x 1) has equivalents in [setf x 1] and, say, {:main setf
:place x :value 1}.
Ken Tilton
Ken Tilton wrote:
> So he* hunkered down and got Arc to where it could be released.
* Robert Morris barely gets mentioned! He is the Woz of Arc.
Ken Tilton
Ken Tilton wrote:
> No, no, no. How did Ruby steal Python's lunch? Blocks. We are not wrong,
> Lisp is insanely good, and people recognize it once they Actually Try
> It. They will try Arc because of PG, or at least enough will to
> kickstart The Second Coming of Lisp.
>
> Didn't you people see the secret plans?
From:
http://jfkbits.blogspot.com/2008/01/digging-into-arc-in-24-macros-or-less.html
"This Arc release actually got me moving from thinking about
Lisp/Scheme to actually using it, and appreciating macros. I do admit
that I enjoy the brevity of the keywords and design of the syntactic
forms, and if that's all Arc ever is it's still value-added."
kenny
Duane Rettig
Nah; it's missing eieio and lfsux ...
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Griff
> It is well known that names are still recognizable when you
> remove the vocals.
DB2 shops have you beat on this one, at least when it comes to column
names!
George Neuner
<kenny...@optonline.net> wrote:
>Have you noticed no one rags on Bush any more?
Amazing since his approval rating is twice that of Congress. You'd
think the critics would want to go after the popular target.
George
--
for email reply remove "/" from address
alex.re...@gmail.com
> But the benefit to CLers is greater mindshare and popularity of Lisp.
> Just think, in three years people will be demanding you port AgentSheets
> to CL. Or Arc. :)
no need to port AgentSheets to CL. We already have a CL version.
For the Arc port we would have to wait for Arc with object
orientation; Arc++ ...
Alex Mizrahi
a> many Lispers, I'd have thought that the others would not raise
a> passions. The amount of debate about Arc seems to suggest, however,
a> that there are some more fundamental differences that I'm missing.
a> What are those?
i believe the only real difference is style.
certainly you can program in Common Lisp in this style, reproducing all
shortcuts and sugar, but barely anyone does so -- as there can be variations
in styles, people won't understand each other.
i.e. in a wild i've seen AIF, LET-IF and IF-BIND macros all serving same
purpose, and there's also Foderaro's IF* weirdness..
but Paul brands his language as totally new, and so he can promote his style
this way, and methodology/ideology too.
is it a good style? we'll see, but as for me it would be interesting to try
it (however, i suspect i just don't think fast enough for this language, but
OTOH traditional CL style annoys me from time to time..)
Ken Tilton
alex.re...@gmail.com wrote:
> On Jan 31, 11:45 am, Ken Tilton <kennytil...@optonline.net> wrote:
>
>
>>But the benefit to CLers is greater mindshare and popularity of Lisp.
>>Just think, in three years people will be demanding you port AgentSheets
>>to CL. Or Arc. :)
>
>
> no need to port AgentSheets to CL. We already have a CL version.
Ah, you are maintaining both? You must be an expert on Lisp vs. Java by now.
>
> For the Arc port we would have to wait for Arc with object
> orientation; Arc++ ...
This seems to be where Arc is more Schemey: we each are supposed to roll
our own object systems so we cannot share code.
kenny
Maciej Katafiasz
>> For the Arc port we would have to wait for Arc with object orientation;
>> Arc++ ...
>
> This seems to be where Arc is more Schemey: we each are supposed to roll
> our own object systems so we cannot share code.
Don't be silly. Code reuse is a dumb corporate myth, clearly against the
spirit of exploratory programming.
Cheers,
Maciej
Pascal Costanza
> http://paulgraham.com/arc0.html
>
> This is a big day for Lisp hackers anyway. Has anyone here had a
> chance to play around with Arc yet? What do you think will be the long
> term impact of Arc on CL?
The question is stated wrong. Arc won't have a direct impact on CL.
However, the long-term impact on Lisp in general may actually be a bad
one. Arc is likely to reinstate old prejudices against Lisp, especially
the one that it's all "just" lists. This won't have a direct impact on
Scheme and CL, though, because these are languages that are used mostly
only by self-motivated programmers anyway. The sad thing is that CL and
Scheme had somewhat of an increase in popularity in recent years, but
Arc may distract potentially interested users. It actually already did
so because some people decided to wait for Arc instead of looking at any
of the existing Lisps. "Newer is better", you know... :(
If Arc gets successful (which I don't think is likely) it will look like
a mix of several known Lisp dialects from the 80's and 90's within 10-15
years from now, but there won't be anything substantially new. It will
probably be worse than CL or Scheme. Paul Graham's version won't take
over (mostly because he won't spend enough time on developing Arc
further), but someone else may do a relatively successful fork that may
make Arc somewhat popular (somewhat below Python and Ruby).
Arc will have objects sooner or later. But it will be only
single-inheritance, single-dispatch crap. ("It's so much easier to get
this into your head.")
To take a somewhat positive spin: It doesn't really matter that much
whether Arc is successful or not. If it's not, all will be fine, and we
can continue to focus on more important things. If it is, we can expect
more people to have some basic knowledge of Lisp concepts, and can
describe the advantages of the better Lisp dialects by comparing them
with Arc. That may make our life somewhat easier than having to compare
Lisp with Java, Python, Ruby, etc., all the time... ;)
John Thingstad
>
> To take a somewhat positive spin: It doesn't really matter that much
> whether Arc is successful or not. If it's not, all will be fine, and we
> can continue to focus on more important things. If it is, we can expect
> more people to have some basic knowledge of Lisp concepts, and can
> describe the advantages of the better Lisp dialects by comparing them
> with Arc. That may make our life somewhat easier than having to compare
> Lisp with Java, Python, Ruby, etc., all the time... ;)
I think you are overly negative about it. Paul Graham is primarily
concerned with web programming and Arc is more of a direct contender to
Ruby than Common Lisp. It will probably be neither as efficient or
generally applicable as CL.
Never the less it might some day make todays Perl, PHP, Python and Ruby
programmers consider Lisp.
As such it could actually draw people to Lisp the way elisp has in the
past.
I wouldn't be surprised to find people here in a few years whose first
experience with Lisp was Arc.
I see no reason why you would need anything revolutionary new to do do web
programming.
It exist primarily to make programming more enjoyable by wasting less time
on repetitive work.
What Arc has is a strong conviction about style and a underlying
philosophy behind his idea.
It might not be to your taste, but a strong underlying philosophy is
probably what made Emacs the success it is f.e.s. (Of cource there are
still people who hate Emacs..)
--------------
John Thingstad
Pascal Costanza
I don't care about style and philosophy. I think it's a good thing that
Lisp and Scheme allow you to have your own style and not care about the
rest of the world.
What I'm worried about is that people buy into Paul Graham's attempt to
sell this as a programming language, when in fact it's nothing more than
an extremely simple library for MzScheme. (And as such it's a category
error to say that it's a contender to Ruby, Python, PHP, whatever.)
Is this the kind of library Kenny has been asking for over all these years?
John Thingstad
>
> What I'm worried about is that people buy into Paul Graham's attempt to
> sell this as a programming language, when in fact it's nothing more than
> an extremely simple library for MzScheme. (And as such it's a category
> error to say that it's a contender to Ruby, Python, PHP, whatever.)
>
This is a bit silly. What does it matter what it was written in?
For all practical purposes you get a Arc prompt and write the code in arc.
I'd say it is (or rather will be someday) a new lisp dialect.
I consider this prototype more as a proof of concept.
--------------
John Thingstad
Ken Tilton
John Thingstad wrote:
> På Fri, 01 Feb 2008 23:12:03 +0100, skrev Pascal Costanza <p...@p-cos.net>:
>
>>
>> To take a somewhat positive spin: It doesn't really matter that much
>> whether Arc is successful or not. If it's not, all will be fine, and
>> we can continue to focus on more important things. If it is, we can
>> expect more people to have some basic knowledge of Lisp concepts, and
>> can describe the advantages of the better Lisp dialects by comparing
>> them with Arc. That may make our life somewhat easier than having to
>> compare Lisp with Java, Python, Ruby, etc., all the time... ;)
>
>
> I think you are overly negative about it. Paul Graham is primarily
> concerned with web programming...
In designing a hundred year language? No, that is just good positioning
to jumpstart his language.
>... and Arc is more of a direct contender to
> Ruby than Common Lisp. It will probably be neither as efficient or
> generally applicable as CL.
Only in the short term on efficiency, and not now on the applicable.
>
> Never the less it might some day make todays Perl, PHP, Python and Ruby
> programmers consider Lisp.
? It already has, and they are blogging about it. You might want to
start following the forum to find out what is going on.
> As such it could actually draw people to Lisp the way elisp has in the
> past.
Done deal.
> I wouldn't be surprised to find people here in a few years whose first
> experience with Lisp was Arc.
Make that "in a few weeks". The language is great but the community has
already found a bunch of bugs and there is no documentation and no
mechanism for incorporating bug fixes into an official version and
anyway PG promises to change Arc in ways that will break all existing
code so here is what is going to happen. People will try Arc and fall in
love with Lisp and in three weeks get fed up and move to CL.
We're gonna need a bigger kennel.
kt
Ken Tilton
Yep. What matters is that it has a sexy name, a rock star BDFL, and it
is has most of what matters in CL to make it great.
Maciej Katafiasz
> Make that "in a few weeks". The language is great but the community has
> already found a bunch of bugs and there is no documentation and no
> mechanism for incorporating bug fixes into an official version and
> anyway PG promises to change Arc in ways that will break all existing
> code so here is what is going to happen. People will try Arc and fall in
> love with Lisp and in three weeks get fed up and move to CL.
One has to wonder if an influx of newbs bitching about CL not being like
Arc is better or worse than an influx of newbs bitching about CL not
being like Python/Ruby/C#/whatever. At least they won't be moaning about
lacking packages system :)
Cheers,
Maciej
viper-2
> ..... and it is has most of what matters in CL to make it great.
... But it doesn't have LOOP Kenny! ;-)
"I consider Loop one of the worst flaws in CL, and an example to be
borne in mind by both macro writers and language designers". -- Paul
Graham
http://www.paulgraham.com/loop.html
agt
Edi Weitz
>> I wouldn't be surprised to find people here in a few years whose
>> first experience with Lisp was Arc.
>
> Make that "in a few weeks". The language is great but the community
> has already found a bunch of bugs and there is no documentation and
> no mechanism for incorporating bug fixes into an official version
> and anyway PG promises to change Arc in ways that will break all
> existing code so here is what is going to happen. People will try
> Arc and fall in love with Lisp and in three weeks get fed up and
> move to CL.
Sounds good. Reading your postings from the last few days I became
scared you'd sooner or later propose to talk about Arc in Amsterdam.
(No way!)
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
ozan s yigit
> ... The language is great but the community
> has already found a bunch of bugs and there is no documentation and no
> mechanism for incorporating bug fixes into an official version and
> anyway PG promises to change Arc in ways that will break all existing
> code so here is what is going to happen. People will try Arc and fall
> in love with Lisp and in three weeks get fed up and move to CL.
um, how does one decide a language is "great" with so little?
is it obvious in a "zen and the art of motorcycle maintenance"
sort of way?
[i was a schemer once; i thought greatness took a lot of implementation
and argumentation... 8-]
oz
--
practically no other lisp in the language forest looked so
lisp-like as this lisp. -- with apologies to terry pratchett
Pascal Costanza
> På Sat, 02 Feb 2008 15:45:35 +0100, skrev Pascal Costanza <p...@p-cos.net>:
>
>>
>> What I'm worried about is that people buy into Paul Graham's attempt
>> to sell this as a programming language, when in fact it's nothing more
>> than an extremely simple library for MzScheme. (And as such it's a
>> category error to say that it's a contender to Ruby, Python, PHP,
>> whatever.)
>>
>
> This is a bit silly. What does it matter what it was written in?
It matters a lot.
A colleague of mine sometimes tells the story that when he was very
young (in his teens), he created a "new" programming language by taking
a BASIC interpreter and translating each command in it from English to
Dutch (because it was more "natural" for him to program in Dutch than in
English).
I find it very hard to see how Arc can be regarded as a greater leap of
innovation than that.
To put it differently: The introduction of a foreach statement to Java
was more interesting!
Maciej Katafiasz
> To put it differently: The introduction of a foreach statement to Java
> was more interesting!
Now, let's be fair: Arc has much more than what foreach introduces.
Callable data structures, composition and lambda shorthands are
definitely more than foreach. I consider Arc extremely disappointing, and
little more than what is routinely done as a part of library development
in CL (like UCW, which has an interpreter *and* a real web development
lib), but comparing it to foreach is just selling it short.
Cheers,
Maciej
Ken Tilton
Ken Tilton wrote:
>
>
> John Thingstad wrote:
>
>> På Sat, 02 Feb 2008 15:45:35 +0100, skrev Pascal Costanza <p...@p-cos.net>:
>>
>>>
>>> What I'm worried about is that people buy into Paul Graham's attempt
>>> to sell this as a programming language, when in fact it's nothing
>>> more than an extremely simple library for MzScheme. (And as such
>>> it's a category error to say that it's a contender to Ruby, Python,
>>> PHP, whatever.)
>>>
>>
>> This is a bit silly. What does it matter what it was written in?
>> For all practical purposes you get a Arc prompt and write the code in
>> arc.
>> I'd say it is (or rather will be someday) a new lisp dialect.
>> I consider this prototype more as a proof of concept.
>
>
> Yep. What matters is that it has a sexy name, a rock star BDFL, and it
> is has most of what matters in CL to make it great.
btw, if someone has not installed Arc and programmed in it, I am not
sure what their opinion is worth on some questions illuminated only thru
use. meanwhile, here is defstruct lite (very lite):
(mac struct ((name (o pfx (string name "-"))) . slot-defs)
(with (maker (coerce (+ "mk-" (string name)) 'sym)
defmaker (coerce (+ "mk-def-" (string name)) 'sym)
fsd (map [if (acons _) _ (list _ nil)] slot-defs))
`(do
(def ,defmaker ()
(listtab ',fsd))
(def ,maker initargs
(aif (keep [~find _ ',(map carif slot-defs)]
(map car (pair initargs)))
(do (ero "Invalid initargs to " ',maker
" supplied: " it ". Allowed are " ',slot-defs) nil)
(let self (,defmaker)
(map [= (self (car _)) (cadr _)] (pair initargs))
self)))
,@(map (fn (sd)
`(def ,(coerce (+ (string pfx) (string sd)) 'sym) (self)
(self ',sd))) (map carif slot-defs)))))
Ken Tilton
viper-2 wrote:
> On Feb 2, 12:18 pm, Ken Tilton <kennytil...@optonline.net> wrote:
>
>
>
>>..... and it is has most of what matters in CL to make it great.
>
>
> ... But it doesn't have LOOP Kenny! ;-)
Fortunately I have decided to get back to CL and stop having fun. As
soon as I flesh out my Arc STRUCT implementation, of course. Hmmm... OK,
it would be funny as hell to do Arc LOOP, drive PG nuts. :)
>
> "I consider Loop one of the worst flaws in CL, and an example to be
> borne in mind by both macro writers and language designers". -- Paul
> Graham
>
> http://www.paulgraham.com/loop.html
The funny thing is I have to stop calling PG a rock star BDFL because
when you give people MAC you cannot be a dictator. How about BCHFL? Cat
herder?
Ken Tilton
Maciej Katafiasz wrote:
> Den Sat, 02 Feb 2008 12:09:11 -0500 skrev Ken Tilton:
>
>
>>Make that "in a few weeks". The language is great but the community has
>>already found a bunch of bugs and there is no documentation and no
>>mechanism for incorporating bug fixes into an official version and
>>anyway PG promises to change Arc in ways that will break all existing
>>code so here is what is going to happen. People will try Arc and fall in
>>love with Lisp and in three weeks get fed up and move to CL.
>
>
> One has to wonder if an influx of newbs bitching about CL not being like
> Arc is better or worse than an influx of newbs bitching about CL not
> being like Python/Ruby/C#/whatever.
What part of "we are going to need a bigger kennel" did you notunderstand?
And don't forget, we just point to /the ANSI standard/ and say we agree
with them completely but our hands are tied.
kenny
Ken Tilton
Edi Weitz wrote:
> On Sat, 02 Feb 2008 12:09:11 -0500, Ken Tilton <kenny...@optonline.net> wrote:
>
>
>>>I wouldn't be surprised to find people here in a few years whose
>>>first experience with Lisp was Arc.
>>
>>Make that "in a few weeks". The language is great but the community
>>has already found a bunch of bugs and there is no documentation and
>>no mechanism for incorporating bug fixes into an official version
>>and anyway PG promises to change Arc in ways that will break all
>>existing code so here is what is going to happen. People will try
>>Arc and fall in love with Lisp and in three weeks get fed up and
>>move to CL.
>
>
> Sounds good. Reading your postings from the last few days I became
> scared you'd sooner or later propose to talk about Arc in Amsterdam.
> (No way!)
You lack imagination grasshopper. Where will Arc be in three months?
Returned to Earth, or happily in orbit readying itself for the next leg
to Mars? I'll be standing there trying to talk about Cells and Algebra
and even blinking my own damn cursor and you all will be yelling out "we
want Arc! we want Arc!". It will be pandemonium, I can see it now.
Well, Lisp-NYC and the tables that sit within fifty feet of us can tell
you I do not really need a script and I do not need a microphone once I
get going, my talk might just be "Ask me anything, His Kennyness is
taking questions. Please begin by stating what degree Yobbo you are.".
Ken Tilton
ozan s yigit wrote:
> Ken Tilton <kenny...@optonline.net> writes in part:
>
>
>> ... The language is great but the community
>>has already found a bunch of bugs and there is no documentation and no
>>mechanism for incorporating bug fixes into an official version and
>>anyway PG promises to change Arc in ways that will break all existing
>>code so here is what is going to happen. People will try Arc and fall
>>in love with Lisp and in three weeks get fed up and move to CL.
>
>
> um, how does one decide a language is "great" with so little?
> is it obvious in a "zen and the art of motorcycle maintenance"
> sort of way?
Sorry, it's back to the temple for ten more years for you. Lisp was
great even before that grad student created an interpreter for it on his
abacus.
> [i was a schemer once; i thought greatness took a lot of implementation
> and argumentation... 8-]
You do not understand. PG started from the best of Scheme, CL, and K.
Talk about shoulder-standing. Mind you he reports also having to think
very hard, so if you have not seen the versions he threw out you do not
know how little is there. Remember also that before Lincoln gave his
Gettysburg Address a local politician did the expected thing and spoke
for two hours. Hell, even Lincoln felt bad about how short it was.
Something like that.
kenny
Ken Tilton
Maciej Katafiasz wrote:
> I consider Arc extremely disappointing
How much Arc code have you written?
Thought so.
Pascal Costanza
You can't add foreach to Java as a library.
Maciej Katafiasz
> The funny thing is I have to stop calling PG a rock star BDFL because
> when you give people MAC you cannot be a dictator.
http://en.wikipedia.org/wiki/MAC_spoofing ?
Cheers,
Maciej
Eli Barzilay
> John Thingstad wrote:
>> På Sat, 02 Feb 2008 15:45:35 +0100, skrev Pascal Costanza <p...@p-cos.net>:
>>
>>> What I'm worried about is that people buy into Paul Graham's
>>> attempt to sell this as a programming language, when in fact it's
>>> nothing more than an extremely simple library for MzScheme. (And
>>> as such it's a category error to say that it's a contender to
>>> Ruby, Python, PHP, whatever.)
>>
>> This is a bit silly. What does it matter what it was written in?
>
> It matters a lot.
It matters a lot sometimes. When you create a language L on top of M,
you obviously skip a few things and just inherit M's behavior. For
example, PG would be crazy to implement a new numeric tower instead of
using mzscheme's -- and he did choose a "vm backend" that gives him
many features that he wants (either to use in the implementation, or
to make arc inherit). But calling the result "an extremely simple
library" is as misguided as saying that mzscheme itself is a library
for C. Arc doesn't share many features of mzscheme, for example: the
module system, function applications, hygienic macros or any other
kind of macros (eg, Arc does not have mzscheme's phase separation).
It doesn't even share mzscheme's namespaces -- in fact, if you look at
the arc compiler, you'll see that it's lisp-1-ness is not inherited
from mzscheme, and making it a lisp-2 would be a simple tweak. It
might not be as far from mzscheme as mzscheme is from C, but to
compare it to a translated-basic interpreter is ridiculous.
> I find it very hard to see how Arc can be regarded as a greater leap
> of innovation than that.
All of the above is unrelated to arc being innovative or not, but --
> To put it differently: The introduction of a foreach statement to
> Java was more interesting!
-- that's certainly a much smaller change to java than arc is to
mzscheme (or scheme, or cl, or any other lisp).
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Rob Warnock
+---------------
| skrev Ken Tilton:
| > The funny thing is I have to stop calling PG a rock star BDFL because
| > when you give people MAC you cannot be a dictator.
|
| http://en.wikipedia.org/wiki/MAC_spoofing ?
Uh... no. I think he meant <http://alu.org/HyperSpec/Body/mac_defmacro.html>,
since in Arc DEFMACRO is abbreviated [isn't everything?] to just MAC,
see <http://ycombinator.com/arc/tut.txt>.
And Kenny's point was that once you give people macros, you lose
the ability to be able to dictate to them what syntax they can use.
At best you can attempt to herd them (like cats -- ha! fat chance)
into staying near a local minimum of "good style". [Though the
danger persists they will find a *better* (for them) local minimum
somewhere far away from what *you* think is "good style". Tough.]
Hence the suggested replacement of BDFL by BCHFL.
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Maciej Katafiasz
> Maciej Katafiasz <math...@gmail.com> wrote:
> | http://en.wikipedia.org/wiki/MAC_spoofing ?
>
> Uh... no. I think he meant
> <http://alu.org/HyperSpec/Body/mac_defmacro.html>, since in Arc DEFMACRO
> is abbreviated [isn't everything?] to just MAC, see
> <http://ycombinator.com/arc/tut.txt>.
>
> And Kenny's point was that once you give people macros, you lose the
> ability to be able to dictate to them what syntax they can use. At best
> you can attempt to herd them (like cats -- ha! fat chance) into staying
> near a local minimum of "good style". [Though the danger persists they
> will find a *better* (for them) local minimum somewhere far away from
> what *you* think is "good style". Tough.] Hence the suggested
> replacement of BDFL by BCHFL.
Yes, I understood all that, I was being facetious. Guess I failed :).
Cheers,
Maciej
ozan s yigit
Ken Tilton <kenny...@optonline.net> writes:
> > um, how does one decide a language is "great" with so little?
> > is it obvious in a "zen and the art of motorcycle maintenance"
> > sort of way?
>
> Sorry, it's back to the temple for ten more years for you. Lisp was
> great even before that grad student created an interpreter for it on
> his abacus.
i don't do temples. there was a literary/philosophical allusion there
but perhaps long before your time. see robert m. pirsig.
>
> > [i was a schemer once; i thought greatness took a lot of implementation
> > and argumentation... 8-]
>
> You do not understand. PG started from the best of Scheme, CL, and
> K. Talk about shoulder-standing. [...]
i understand all too well. yes there is much shoulder standing amongst
lisp family of languages, nearly inevitable, and most of it eventually
horizontal. in any case, best wishes and have fun coding useful things.
oz
--
if you couldn't find any weirdness, maybe
we'll just have to make some! -- hobbes
Ken Tilton
Rob Warnock wrote:
> Maciej Katafiasz <math...@gmail.com> wrote:
> +---------------
> | skrev Ken Tilton:
> | > The funny thing is I have to stop calling PG a rock star BDFL because
> | > when you give people MAC you cannot be a dictator.
> |
> | http://en.wikipedia.org/wiki/MAC_spoofing ?
> +---------------
>
> Uh... no. I think he meant <http://alu.org/HyperSpec/Body/mac_defmacro.html>,
> since in Arc DEFMACRO is abbreviated [isn't everything?] to just MAC,
> see <http://ycombinator.com/arc/tut.txt>.
Not feeling so bad about plonking Maciej now. :) I think anyone yapping
on an Arc thread who has not programmed in Arc belongs in my killfile.
If they have not even read the tutorial... Tim, can I have the keys to
the helicopters tonight?
Meanwhile I am happily creating DEFUN, a def with optional and keyword
parameters. Of course I am using &k and &o instead. :)
kenny
Ken Tilton
ozan s yigit wrote:
> Ken Tilton <kenny...@optonline.net> writes:
>
>
>>>um, how does one decide a language is "great" with so little?
>>>is it obvious in a "zen and the art of motorcycle maintenance"
>>>sort of way?
>>
>>Sorry, it's back to the temple for ten more years for you. Lisp was
>>great even before that grad student created an interpreter for it on
>>his abacus.
>
>
> i don't do temples. there was a literary/philosophical allusion there
> but perhaps long before your time. see robert m. pirsig.
See "I already read it.". The guy has a mental breakdown and turns it
into a book, tries to save his soul with Quality. Only good part was the
bit where his kid had to find their way home because Dad had snapped one
day. I actually ported that to a day hike with some inner city kids,
pretended I was lost (conspicuously, but they still went into survival
mode) and they had to find our way back to civilization.
No, the point I was trying to make is that greatness must be there from
the beginning or not at all. One does not achieve greatness in the last
chapter of the dummies book or revision 12.183.37.
btw, you are not really so far off with zatamm. Had you stopped with z I
would have showered you with bouquets of roses. Zen rejects the mind and
embraces, er, I dunna know, but def letting go and letting the gut talk.
The arrow releases itself, and in boxing the punch throws itself. I just
hate to dress up my assessment in grandiosities like that, as much into
self-glorification as I am.
I've simply been programming for way too frickin long and (cue the Zen)
I learned a while ago to shut up and listen. To myself, of course, not
you yobbos. Generally this is called learning to trust one's instincts.
But this is Lisp, let's cut to the AI. Car and Driver will spend a week
testing a hot new car. Michael Schumacher could back it out of its
parking space and know. If it has a reverse. Kasparov looks at three
moves, his "conqueror" has to look at three kabillion moves. How the
hell do we do that? Zen, schmen, its lotsa experience. Everyone sees the
differences, the Master knows which differences matter, albeit via a
neuronal calculus the Master does not know. What separates the Master is
realizing that this unknowable calculus knows better and so to shut down
the mind so the calculus can Speak. Zen seeks improvement thru less mind.
>>>[i was a schemer once; i thought greatness took a lot of implementation
>>>and argumentation... 8-]
>>
>>You do not understand. PG started from the best of Scheme, CL, and
>>K. Talk about shoulder-standing. [...]
>
>
> i understand all too well. yes there is much shoulder standing amongst
> lisp family of languages, nearly inevitable, and most of it eventually
> horizontal.
Out! Out, damned pessimism! (Borrowing from Stephen King, I think.) Is
tersosity all that CL needs to rule the world? <gasp>
Rob Warnock
+---------------
| Arc doesn't share many features of mzscheme, for example: the
| module system, function applications, hygienic macros or any other
| kind of macros (eg, Arc does not have mzscheme's phase separation).
| It doesn't even share mzscheme's namespaces -- in fact, if you look at
| the arc compiler, you'll see that it's lisp-1-ness is not inherited
| from mzscheme, and making it a lisp-2 would be a simple tweak.
Yeah, I was just musing about that -- not making Arc a Lisp-N, but
the other direction: using a Lisp-N (CL) as the backend target of
the Lisp-1 Arc compiler. If one didn't care about the differences
in the underlying semantics [e.g., a different numeric tower than
Scheme], it shouldn't be too hard to port "ac.scm" & "brackets.scm"
to CL, then use them to recompile all the ".arc" files.
Some work would also be needed to replace some of the MzScheme
libraries that get REQUIRE'd; the messiest of those would probably
be "process.ss".
Pascal Costanza
I seem to be missing something very important, so let me try to rephrase
this as a question: Is there anything in Arc that can't be implemented
as a plain thin library on top of (sufficiently powerful) Scheme or CL
implementations?
Eli Barzilay
> I seem to be missing something very important,
I think that the best thing you should do is follow Kenny's advice and
use it (then look at the sources).
> so let me try to rephrase this as a question: Is there anything in
> Arc that can't be implemented as a plain thin library on top of
> (sufficiently powerful) Scheme or CL implementations?
At least with MzScheme, it is not implemented as a library, but rather
as a compiler. It reads each sexpr, translates it to MzScheme code,
then evaluate the result. You could probably argue that it can be
viewed as a library -- given a powerful enough language. For example,
when you write a macro in Scheme/CL you say that it's part of a
language -- but in (most) other languages that will be wrong since you
cannot extend the language in that way; when you add a new
concrete-level syntax through a reader macro you can claim that this
is a library in a very few number of languages (BTW, I consider naive
use of CL lacking in that aspect: to consider a reader macro as a
"library", I'd want it to not interfere with code that doesn't use
that library).
So, a few of the features that you'll need to implement arc as a
library are:
* tweak your namespace directly
* redefine the meaning of the function application form (eg, in
mzscheme that's `#%app')
* write symbol macros, and make them access the name of the symbol (eg
the `foo:bar' trick)
* add new special forms (= macros), including ones that are already
part of your core language like `if'
* extend the concrete syntax that gets used for code that uses this
library
Many Schemes fall short on several items, CL too (the first and last),
but I'm sure that you'll squint hard enough to argue that (which will
push this thread down an irrelevant flamewar).
MzScheme does have all of these features, but PG and RTM did not use
them and chose to implement a (to-mzscheme) compiler instead (so the
current implementation is *not* a library). In any case, innovative
or not -- this is far from the standard notion of a library, or from
implementing a new language by translating strings in its
implementation.
Pascal Costanza
> Pascal Costanza <p...@p-cos.net> writes:
>
>> I seem to be missing something very important,
>
> I think that the best thing you should do is follow Kenny's advice and
> use it (then look at the sources).
>
>
>> so let me try to rephrase this as a question: Is there anything in
>> Arc that can't be implemented as a plain thin library on top of
>> (sufficiently powerful) Scheme or CL implementations?
>
> At least with MzScheme, it is not implemented as a library, but rather
> as a compiler. It reads each sexpr, translates it to MzScheme code,
> then evaluate the result.
I wasn't interested in how they implemented the syntactic sugar. I was
interested in whether it is more than syntactic sugar.
ozan s yigit
> See "I already read it.". The guy has a mental breakdown and turns it
> into a book, tries to save his soul with Quality. Only good part was
> the bit where his kid had to find their way home because Dad had
> snapped one day. [...]
hmm, i did not realize there was a comic book edition.
> Is tersosity all that CL needs to rule the world? <gasp>
sure, something has to fill the vacuum perl 6 created... :-]
oz
---
don't count your chickens in glass houses until the cows come home.
-- david vestal
Drew Crampsie
> Eli Barzilay <e...@barzilay.org> wrote: +---------------
> | Arc doesn't share many features of mzscheme, for example: the | module
> system, function applications, hygienic macros or any other | kind of
> macros (eg, Arc does not have mzscheme's phase separation). | It doesn't
> even share mzscheme's namespaces -- in fact, if you look at | the arc
> compiler, you'll see that it's lisp-1-ness is not inherited | from
> mzscheme, and making it a lisp-2 would be a simple tweak.
> +---------------
>
> Yeah, I was just musing about that -- not making Arc a Lisp-N, but the
> other direction: using a Lisp-N (CL) as the backend target of the Lisp-1
> Arc compiler. If one didn't care about the differences in the underlying
> semantics [e.g., a different numeric tower than Scheme], it shouldn't be
> too hard to port "ac.scm" & "brackets.scm" to CL, then use them to
> recompile all the ".arc" files.
It only took about 6 hours to get to the point where arc.arc would
compile in my cl-arc. I gave up on it after this, as it was not much
fun :).
The biggest differences were, of course, lisp1 and call/cc. As luck would
have it, the arnesi library includes code-walkers and interpreters
implementing those two on CL, so it was really just s/fn/lambda +
QUASIQUOTE.
Cheers ,
drewc
>
> Some work would also be needed to replace some of the MzScheme libraries
> that get REQUIRE'd; the messiest of those would probably be
> "process.ss".
>
>
> -Rob
>
> -----
> Rob Warnock <rp...@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/> San Mateo,
CA 94403
> (650)572-2607
--
Posted via a free Usenet account from http://www.teranews.com
John Thingstad
A few points that come to mind:
Destructuring works differently and functions and let also allow
destucturing.
It is implemented in Arc.
The syntax if different so it requires different parsing.
(let x 5 (pr 5))
(with (x 5 y 6) (prf "X=~A,Y~A~%" x y))
prf is a subset of format implemented in arc.
Macro processing is implemented in arc.
You seem to have glanced at ac.scm and jumped to conclusions.
The real work is in arc.arc .
Also the you seem to miss the point. The issue isn't so much which
features to add.
It is to provide a simpler language which is terse but doesn't loose any
of scheme/CL's power.
The real effort is in determining what could be removed. The code has been
continually rewritten to simplify/tersify the language and also the
implementation. It is not easy to come up with a simple yet complete
language.
define-condition and defclass syntax doesn't jive well together with the
terse original lingo car, cons, cond, map etc.. In that sense it is a
attempt to get closer to the language originally envisioned by McCarthy.
--------------
John Thingstad