
Arc's Out - pg
http://paulgraham.com/arc0.html
======
brett
Man, I had shit to get done this afternoon.

------
pg
BTW, most existing News.YC usernames are reserved (with the current News.YC
password) on arclanguage.org. The UI should also be familiar...

~~~
shiro
Is the user database is shared, or just copied?

I forgot my news.yc password and wonder if resetting password in news.yc
propagates to the arc forum.

~~~
pg
copied, but I'll reset your pw on both if you want

------
Hexstream
PG: "I am a fairly representative Lisp hacker"

I thought representative Lisp hackers liked long descriptive names over short
cryptic ones? ;P

PS: I feel my karma's going to hell in 3, 2, 1...

edit: It wasn't a challenge. It wasn't "oh, I'll pretend to think my karma
will go down to look like a cool rebel". Hope that clears things up.

~~~
paulgb
I wouldn't have upmodded you, if curi hadn't made the comment about not
upmodding you.

~~~
curi
+1: I see what you did there.

------
jmzachary
"We'll change stuff without thinking about what it might break, and we won't
even keep track of the changes."

Are you hoping to build a user community for Arc? If so, and why would you
release Arc if you weren't, then why are you not interested in keeping track
of changes that break things users might design/code against? Am I being
stupid and missing something here?

Edit: I forgot to mention something else. Congratulations and thanks for
sharing Arc with the rest of us :)

------
reitzensteinm
Going to try it out now, but one thing really struck me in the announcement:

"We'll change stuff without thinking about what it might break, and we won't
even keep track of the changes."

Is that really wise? What's wrong with doing a simple changelog with every
modification? Since you'd expect only experienced programmers to be using Arc,
you don't have to hold our hand explaining the implications of the changes -
but making us diff the source would probably be a bit much.

I mean it doesn't have to be verbose even. Or even tidy. This would be better
than nothing:

* Added a global weak reference hash map to treat any object like a hash using {} syntax, ie, (= {someobj hashindexobj} 5).

* Hash idea sucked. Removed.

~~~
curi
pg has better things to do. you can maintain a website of arc changes, if you
want. or set up a wiki. or diff the source and post results.

~~~
reitzensteinm
Yes, I could, but it would probably be easy to miss subtleties from just the
source alone.

------
bct
Huh. I would have said just the opposite about HTML; seems to me that slapping
down some structural divisions and worrying about layout later is much more
exploratory than starting with the layout.

~~~
olavk
His point is that it is more "exploratory" not to use semantic markup, since
you might not know the semantics of the document structure while you are
developing.

It seems backwards to me though, surely the most "semantic-free" approach is
to default to divs rather than tables to structure the markup.

~~~
philh
It's all meaningless unless you intend it to have meaning. But tables are
probably easier to work with.

(That may change in future, but right now I don't think any mainstream tools
assume markup is semantic. And in any case, tables aren't much moreso than
divs.)

~~~
bct
> right now I don't think any mainstream tools assume markup is semantic.

Depends on what you're talking about; anything that uses microformats does,
for example.

Tools generally can't assume that tables are semantic, because they've been so
heavily abused. That's not going to change though. Perhaps the best solution
is a <yes-this-is-really-a-table> element.

> tables aren't much moreso than divs.

Would you say that a table in a relational database isn't much more semantic
than a string of bytes?

------
dbrush
<http://news.ycombinator.com/whoami>

------
Tichy
What inspires me most about Arc is that it was created strictly for fun (or so
I suppose). In that sense, it having no unicode support is the best feature
for the time being: it is a powerful reminder that if you don't feel like
doing something, it might be an option to simply not do it. It helps if you
have other means to pay your bills, but still.

I don't plan on using arc for the time being, but I hope that maybe I can
steal some ideas from it, so I welcome it's release.

------
abstractbill
I remember reading this in "Arc at 3 Weeks" and being quite excited about it:

 _The Scheme language sneakily increased the scope of the language designer's
powers. From very early, maybe from the begining, the Scheme spec said that
conforming implementations must do tail call elimination. The first time I
read this, I thought "wait, can you require this in a spec?" Arc will see this
increase, and raise it by some standards for profiling._

I thought that was a great idea. Too few languages have good support for
profiling. Did the idea get dropped? I don't see anything obviously related in
arc.arc or in the tutorial.

~~~
vegashacker
I'm sure the idea didn't get dropped cause it's pretty darn important -- and
it'd be a major back peddle for PG. It certainly might have been postponed,
though.

I wonder if PLT Scheme's profiling tools are good enough on Arc programs (or
useful at all?). I hear they have pretty good ones, but haven't used them
myself. Arc might be different enough from MzScheme that the information that
the PLT profiler returns on Arc programs isn't so useful.

------
davidkellis
Looking through the tutorial (<http://ycombinator.com/arc/tut.txt>), I think
it's beautiful.

~~~
lg
Just read the first half, very good explanations in minimal verbiage. Arc
looks beautiful here even if only for the de-parenning of so many CL operators
(i.e. let). In fact I'm a little sad to still see so many parens in the
code... I guess my whitespace-significant dreams were overreaching.

------
aristus
Wow.

    
    
      $ wc -l arc0/*
        1093 ac.scm
         535 app.arc
        1496 arc.arc
          16 as.scm
         107 blog.arc
          48 brackets.scm
          61 code.arc
           2 copyright
         360 html.arc
           7 libs.arc
          80 pprint.arc
         119 prompt.arc
         462 srv.arc
         223 strings.arc
        4609 total

------
dcurtis
Arc is cool. I can't wait to see what it evolves into.

P.S. Do you have a personal vendetta against the W3C, or something?

~~~
Xichekolas
You probably missed the thread here on YC News he is mostly like responding
to... I would link you to it, but it was honestly pointless to begin with...
and I'm lazy.

------
Readmore
The Arc tutorial is awesome! All the examples really hammer the dialect in to
you. About half way through you start to realize, 'wait a minute... I can
actually read this!'.

Thanks PG

~~~
extantproject
It really is a simple and effective tutorial. I like it.

------
akkartik
Version control:

    
    
      $ git clone http://codewikia.com/arc

------
pius
Very cool . . . it'll be nice to play around with Lisp again.

What's the license, by the way?

~~~
curi
This software is copyright (c) Paul Graham and Robert Morris. Permission to
use it is granted under the Perl Foundations's Artistic License 2.0.

------
ced
So, is this the right thread to talk about actual language design?

1\. I think using cons to represent lists is an ugly hack. I mean, why should
a cons only hold 2 elements? Why not generalize them to n elements, and call
them lists?

2\. Has anyone tried unifying macros and functions? The distinctions between
the two is one of the worst part of Lisp IMO, and I don't think there should
be anything fundamental about it.

Otherwise, it's nice to see a new Lisp of course.

~~~
rcoder
Okay, I'll bite...

1\. Recursion and cons cells naturally complement one another. They can stand
in for n-ary tuples, vectors, and arrays reasonably well for small values of
n, and when your dataset gets large, well, you switch to a more efficient data
structure. Hell, with Arc you even get 'push' and 'pop' as built-in functions.
What exactly is the problem?

2\. Again, I don't see how this is a problem. Macros are compile-time
rewriting rules. In an eagerly-evaluated language like Lisp, they are pretty
much a necessary evil to prevent unnecessary side-effects while still allowing
for flexible syntax. I can imagine doing without them in a lazy language like
Haskell, but I'm not aware of any popular, lazy languages in the Lisp family.

That being said, I'm interested to know if you've working with other languages
where #1 and #2 aren't a problem.

~~~
ced
1\. But what do you _gain_ from having cons cells limited to 2 elements? I
contrast cons cell list mostly to Python lists, which just seem to me to be a
better abstraction... Do you think in terms of 2-element pairs or in term of
lists? I guess in a way you are right, if the two are essentially equivalent,
maybe there is no problem.

2\. Macros come with a ton of pitfalls and limitations. On Lisp has a nice
list of reasons to avoid macros. But consider if your macros are really called
at run-time rather than compile-time, and you have a special operator like
eval, but that evaluates in the calling context. Then you can write normal
functions like this:

    
    
       (defmacro average (x y)
           (/ (+ (eval-in-caller x) (eval-in-caller y)) 2))
    

and

    
    
       (defmacro my-if (condition x y)
           (cond ((eval-in-caller condition) (eval-in-caller x))
                 (t (eval-in-caller y))))
    

defun can be written straightforwardly as a special case, and in fact extended
so that eg.:

    
    
       (defun do-many-tymes (n-times &not-evaluated body) ...)
    

would behave half like a function and half like a macro. These run-time
"macros" can be function-quoted, recursive, and have no problem with variable
capture. With such a defun, you no longer need a defmacro.

These are my fantasies about fixing stuff, so I won't waste anyone's time by
writing more. I don't know if that could work. Macros are just so ugly... I
was curious to see if PG or anyone had tried alternatives.

~~~
shiro
I think they've been done and abandoned. You might want to dig some history to
see why (I don't have references handy. Maybe asking comp.lang.lisp would
help).

(1) Let's separate implementation and semantics issues. In semantics level,
list as a datatype is defined recursively:

    
    
      List a = () | (a, List a)
    

This definition maps well to recursive algorithms.

It also maps well to the implementation that uses cons cell, but as you say,
it's not the only way to implement it. There was a technique called CDR-
coding, which represents a list as if it's a vector (e.g. cell's CDR doesn't
contain a pointer but it overlaps the next cell's CAR); specially tagged
pointer distinguished normal cells and CDR-coded cells. I guess it was
abandoned since deailng with set-cdr! would be very messy. But if you're
creating a new dialect, you can go for big change like dropping set-cdr! (some
of Scheme people even talking about dropping mutable cells.) In today's
computer where access locality means a lot, maybe you can shed a new light to
this old technique.

(2) I think the current state of macro was the result of simplification. IIRC,
the old lisp dialects allow to pass around syntactic values (FSUBRs) as if
it's first class, but it's easily messes up the semantics. It's conceptually
_simpler_ to restrict macros as curretly they are. If passing macro around is
allowed, you'll never know how (+ 1 2) in the following function is evaluated
until runtime:

    
    
      (defun call-it (x) (funcall x (+ 1 2)))
    

It may be evaluated as a normal expr, or in a completely different way,
depending on whether x is a macro or not. Or are you suggesting that, in this
case, (+ 1 2) is evaluated immediately because funcall is not a macro? It is a
possible strategy, but then it clipples the expressive power, since it can't
represent the same thing as:

    
    
      (defmacro call-it (x) `(,x (+ 1 2)))
    

But there are still people who wants to unify macros and functions. Search
comp.lang.lisp and comp.lang.scheme---I've seen some discussions there. Also
search "first class macros"; there are some papers.

Another way to eliminate (most) need of macros is to adopt normal order
evaluation. I've seen some Lisp dialects using lazy evaluation by default.
Beware that it changes the programming style _a lot_ , though.

~~~
ced
Thanks a lot for the comments. You seem to know much more about these things
than I do, so I don't have much to add.

2\. call-it: What's the problem with not knowing (+ 1 2) until run-time?
Efficiency? Then I would argue that expressive power of the core language
ought to take precedence. In an actual implementation, funcall could leave (+
1 2) to be evaluated (or not) inside the function body. I would add funcall-
normal-function to the language, which would amount to a funcall + (declare
(normal-function f)). Both for documentation and for efficiency.

Of course, not knowing if (funcall x (print 2)) will print 2 is unsettling in
a way, but that's the same basic argument that's made against macros. They
disrupt the evaluation order.

I read about normal-order before, but it didn't make much practical sense.
I'll Google your pointers and look it up.

~~~
shiro
> call-it: What's the problem with not knowing (+ 1 2) until run-time?

Not only efficiency. _You_ don't even know if (+ 1 2) means "1 plus 2" or
"choose 1 or 2 randomly" or "generate a sequence of numbers between 1 and 2"
until you know what x really is (assuming funcall does delay evaluation of its
arguments and passes the original form in case x is indeed a macro).

The macro version of call-it has the same problem, of course, but if you
embrace first-class macros in the above way, _every higher order function
call_ will have the problem. Considering how often HOF is used, the impact is
huge.

However, as you suggested, you can have two versions of funcalls, one of which
evaluates args no matter what x is; then this problem will be solved.

(Or you can use hygienic macros, then you can deduce what '+' means purely
from its lexical context, at least.)

~~~
ced
> Considering how often HOF is used, the impact is huge.

Well, yes, that would be the point :)

I think I understand what you mean, but I don't see how this is more
dangerous/worrying than what is already there. Ok, so (funcall fn (+ 1 2)) may
or may not evaluate (+ 1 2). But call-it is already willing to give total
control to fn. Will fn call a continuation and never return? Launch nuclear
weapons? Giving it additional control over the evaluation of the arguments
seems innocent enough.

------
mechanical_fish

        bash-3.2$ ls | xargs -n 1 wc -l 
    
          1093 ac.scm
           535 app.arc
          1496 arc.arc
            16 as.scm
           107 blog.arc
            48 brackets.scm
            61 code.arc
             2 copyright
           360 html.arc
             7 libs.arc
            80 pprint.arc
           119 prompt.arc
           462 srv.arc
           223 strings.arc
    

4609 lines of code as of today.

~~~
tlrobinson
what's wrong with

    
    
        wc -l *

~~~
mechanical_fish
Nothing!

Nobody said _I_ was going to be a highly efficient Arc programmer. :)

------
oditogre
Edit: Ontopic: "So while Arc is not the perfect Lisp, it seems to be better
for at least some kinds of programming than either of the leading
alternatives." What kinds did you have in mind?

Offtopic, but what exactly is that a picture of? I see chairs, and a face in
the background (looks like a reflection) - is it a picture taken through a
window? Why is it there?

~~~
pg
Webapps like this one.

The new picture on the frontpage of pg.com is a self-portrait shot in/through
a window at the Grand Trianon, in the grounds of Versailles. I noticed that if
I held my head in the right place I could line up my eyes with the wallpaper
pattern.

~~~
comatose_kid
You hacked Proctor and Gamble's website? Cool!

------
vlad
I called it! <http://news.ycombinator.com/item?id=98502>

------
jsjenkins168
GWT also uses tables for layout extensively in its compiled output. I dont
think its an ugly hack, as long as you can learn and work around ambiguities
with table cell height between browsers.

But then I guess that is all part of exploratory programming.

~~~
tlrobinson
Tables for layout is awful in terms accessibility and semantics, among other
things.

Tables are meant for tabular data, and when you use them for layout it breaks
those semantics, which in turn makes it much harder for screen readers to make
sense out of it.

It's also just ugly, in my opinion.

~~~
anewaccountname
Name one screen reader that handles divs and doesn't handle tables.

~~~
pius
Most screen readers handle both. The problem is that screen readers will
attempt to read the contents of tables as if they were tabular data.
(Surprise, surprise. :P)

This turns out to be a relatively poor user experience.

------
dag
So...what happens to Common Lisp now?

As well, any bets on who writes the first book?

~~~
mcxx
Do you really think that Arc is a competitor for CL?

~~~
pg
It is for me. I literally wrote it so I wouldn't have to use CL anymore.

------
foonamefoo
The function 'trues' seems like clutter when you can just write:

(keep [_] seq)

~~~
pg
That would _call_ the elements of seq.

~~~
foonamefoo
Oh, right.. two much python in my head, not enough lisp. Now I'm interested,
what is the shortest lambda in arc that just returns the first argument? If
I'm getting this right the best I can come up with is [progn _], turning my
example into:

    
    
        (keep [progn _] seq)
    

And thus I see the need for trues =P.

~~~
foonamefoo
Hmm I bested it... ['(_) 0] beats [progn _] by one character, but it sure is
ugly.

~~~
bayareaguy
Does [1 _] work?

------
juanpablo
"Arc embodies a similarly unPC attitude to HTML. The predefined libraries just
do everything with tables...."

But, why should Arc libraries generate HTML at all, instead of a list?

~~~
curi
To make webpages.

~~~
juanpablo
Maybe you don't want to generate HTML but instead an RSS feed, a SVG image,
JSON data, etc.

So a hardwired table-HTML output isn't good.

------
bsaunder
"The most important thing is not to constrain the evolution of your ideas. So
the less you commit yourself in writing to what your data structures
represent, the better."

Exactly! I think most developers don't get this statement. Committing yourself
to data structures is like mixing cement IMHO. Once you've started this get
harder to change quickly.

------
mynameishere
I predict a goldrush of people writing open source frameworks, widget
libraries, and blog software.

~~~
byrneseyeview

        (load "blog.arc")

------
yawn
How does Arc make exploratory programming easier than Scheme, Common Lisp,
Python, etc?

------
dawnerd
I've never looked into Lisp at all, but this actually sparked my interest.

------
TheTarquin
So I've been considering trying to get into Lisp. Any of you folks who have
been playing with Arc have a sense about whether or not it would be a good
dialect with which to start?

------
iamelgringo
Thanks, Paul.

------
comatose_kid
Paul: Small detail - there's a minor typo in your article:

"I spent a fews days"

Thanks for arc.

------
gills
Congratulations! I'm looking forward to 'exploring' it.

~~~
gills
What? Described as "for exploratory programming".

------
parenthesis

       (while 1 (pr "This is so exciting! "))

~~~
parenthesis
Of course, while 0 would work just as well; my brain was half in C-mode.

------
brlewis
This article has a lot of value besides the arc announcement; I think it
should be listed among the pg essays.

------
eVizitei
_sigh_ every time I think that I know all the cool languages, somebody goes
and builds a new one.

;)

------
rob
Has there been any apps released with Arc yet? (aside from
news.ycombinator.com)

------
tjr
And there was much rejoicing!

------
mov
Congratulations PG! It's on my to-play-list ;-)

------
allenbrunson
jens alfke:

    
    
      http://mooseyard.com/Jens/2008/01/96-characters-ought-to-be-enough-for-anyone/
    

i agree with all of that.

~~~
Tichy
"I would simply have made the language's "character" data type 16 bits wide
instead of 8, and provided four trivial library routines to convert such
strings to and from UTF-8 and CP-1252 encodings for I/O purposes. That's about
an hour's work, and all you need for really basic Unicode support; once you
have that, you"

If he can do all that in one hour, I am really impressed. It would take me
more than one hour alone to research the utf-8 and CP-1252 encodings. Changing
regular expressions libraries to work with 16 bit, as well as the index
operations for strings might take some work, too.

I suppose that guy could rewrite the whole Arc within a day...

------
juanpablo
Congratulations

------
Todd
At long last...

------
axod
"Which is why, incidentally, Arc only supports Ascii."

Is this why unicode is absolutely broken on ycnews? :( Seems a shame not to be
even to use characters like pi in comments/titles IMHO Does a pound sign work?
GBP

edit: no it doesn't. Seriously, if done right unicode support doesn't have to
take that long. Especially if you're building something without the need for
backward compatibility.

Just my 2c.

~~~
iamelgringo
Dudes, really...

PG just released an entirely new dialect of lisp for web programming, he's
mentoring about 20 startups right now, and runs Hacker News... "Oh, and can
you add Unicode support, it would only take 2 or 3 days..."

I know that not having Unicode supported in your web language is inconvenient,
and at times is a show-stopper. But really. Give the guy a break. If PG
doesn't want to "spend a single day on character sets". Don't ask him to spend
a day on character sets.

If you want Unicode support in Arc, code it up and submit it.

~~~
shiro
IMHO, it's not an issue of _implementation_. It's an issue of _design_.

If PG explicitly says "ok, I don't have time to do Unicode stuff now, but my
idea is that a string is a sequence of characters, regardless of how a
'character' is represented", then somebody can go ahead to change Arc Unicode-
clean (it won't be much work assuming MzScheme has support of Unicode).

If PG says "the language Arc (not mere an implementation) doesn't support
beyond Ascii", then I feel that PG reserves that part of design (e.g. it may
conflate byte-array and multibyte strings, or it may use richer character
representation than unicode codepoint, such as a character object that holds
the sequence of base char + modifiers, or it may hold raw byte array plus
encoding info). In that case I hesitate to change Arc code without
understanding PG's intention.

