If you look at Arc's source, it certainly seems like PG prefers short names everywhere - it's more like what I've seen from Haskell people. I generally prefer medium-long names. Scheme's call-with-current-continuation is too long. Arc's ccc is too short. Ruby's callcc is just right.
"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 :)
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).
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.
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.
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.)
> 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?
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.
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.
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.
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.
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.
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!'.
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.
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.
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:
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.
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.
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.
> 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.)
> 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.
This reminds me of how "macros" work in Factor, in a way. You don't avoid manually creating the s-expression (though Scheme and Dylan have a nice mechanism for that), but there is a finer line between macros and regular functions. A macro is a function which takes a bunch of arguments and returns another function which takes no arguments and does the action of the macro. Basically, it's constant-folded at compiletime if possible. The runtime definition is memoized. For Factor's syntax, this kind of macro is practical for everything but new definition syntax and datastructure literals (neither of which this idea would work really well on, and which there is a different mechanism for). In general, a macro operates just like other words and can be quoted and executed like them.
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?
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.
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.
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.
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.
It is a trade off. If you want to support Internet Explorer, some kinds of layout are not easily achievable without using tables. W3C cannot be blamed for the deficiencies of IE though, so I'm not sure if this is what PG is alluding to.
Agreed, in fact if everyone used tables for tabular data only, we could have nice browser-supplied column-reordering and row resorting, I think.
Right now that kind of thing is intractable because there's no easy way to distinguish a table-for-data from a table-for-layout. I think it could be cool to have some way of putting something in your page HEAD that means: "In this page, tables are used exclusively for tabular data: you can activate your reordering features".
You could ask on comp.lang.lisp if you wanted some really well-informed opinions wrt the impact of Arc on CL, but I wouldn't advise it unless your skin is thick and flame-resistant.
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:
"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.
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?
"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...
"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.
What??? I kinda like being able to talk about things as fundamental as money, without having to use (GBP). I'd like to use currency symbols for a start, what about math? I'd like to use pi occasionally.
How about I want to add a nice 'tm' or (c) sign.
People care if a website is using correct unicode characters or not.
Perhaps they don't know/care because the majority of websites now are unicode, and just work.
Users care if their name is zoe (with an accent on the e), or if they want to discuss prices of things in euros or GBP.
I wrote a php forum a while back. You wouldn't believe the number of emails telling me that the gbp sign doesn't show up properly when they post a comment.
Even if the users don't care (although they very much do when their characters all show up jumbled), the conversation here in this thread _is_ very much about the coders. Saying unicode is irrelevant is pretty strong in this context and IMHO, pretty bizarre.
Yah, I can see how it sucks but unfortunately that's the way it will have to be for Arc given PG's disinclination to spend time over it. If you end up contributing a unicode fix, who knows, it might even get incorporated and others will thank you as well :)
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.
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.
By the same logic, commenters should be able to put arbitrary HTML in their comments. Very large font sizes. Blink tags. After all, HTML support does not have to take that long: just pass the HTML straight through to the browser. If commenters could use very large fonts and blink tags here, do you not believe that some of them would?
The freedom of the citizen of Hacker News to express himself is being suppressed! Paul Graham, add support for blink tags now!
I was talking about this place, news.yc, not about Arc programs in general. Of course a place for Spanish speakers or Chinese speakers is going to support the charset for that language. I _hope_ we can agree that we do not want comments in languages other than English in this place.
Man, I had shit to get done this afternoon.
BTW, most existing News.YC usernames are reserved (with the current News.YC password) on arclanguage.org. The UI should also be familiar...
Works like a charm.
Handy, thanks.
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.
copied, but I'll reset your pw on both if you want
Nice, but I registered me2 because I didn't know this. A note to let me know would help.
It's true, the familiarity goes down to sharing the same favicon.ico
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.
I would have upmodded you, if you hadn't made the comment about your karma going down.
I wouldn't have upmodded you, if curi hadn't made the comment about not upmodding you.
+1: I see what you did there.
I commented because this seemed like an opportunity to say something funny and cleverly self referential, but I guess this'll get me modded down.
If you look at Arc's source, it certainly seems like PG prefers short names everywhere - it's more like what I've seen from Haskell people. I generally prefer medium-long names. Scheme's call-with-current-continuation is too long. Arc's ccc is too short. Ruby's callcc is just right.
"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 :)
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.
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.
Yes, I could, but it would probably be easy to miss subtleties from just the source alone.
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.
If your HTML is generated programatically, you can roll your own mechanism for separation of concerns in the source.
I see merits in standards compliance, but making my life easier is not necessarily one of them.
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.
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.)
> 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?
http://news.ycombinator.com/whoami
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.
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.
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.
Looking through the tutorial (http://ycombinator.com/arc/tut.txt), I think it's beautiful.
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.
Wow.
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?
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.
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
It really is a simple and effective tutorial. I like it.
Version control:
Very cool . . . it'll be nice to play around with Lisp again.
What's the license, by the way?
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.
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.
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.
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:
and
defun can be written straightforwardly as a special case, and in fact extended so that eg.:
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.
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:
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:
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:
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.
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.
> 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.)
> 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.
This reminds me of how "macros" work in Factor, in a way. You don't avoid manually creating the s-expression (though Scheme and Dylan have a nice mechanism for that), but there is a finer line between macros and regular functions. A macro is a function which takes a bunch of arguments and returns another function which takes no arguments and does the action of the macro. Basically, it's constant-folded at compiletime if possible. The runtime definition is memoized. For Factor's syntax, this kind of macro is practical for everything but new definition syntax and datastructure literals (neither of which this idea would work really well on, and which there is a different mechanism for). In general, a macro operates just like other words and can be quoted and executed like them.
4609 lines of code as of today.
I would suggest including a copy of the tut.txt ( aka wget http://ycombinator.com/arc/tut.txt ) too.
what's wrong with
Nothing!
Nobody said I was going to be a highly efficient Arc programmer. :)
i wonder how many lines were optimized/stripped until reaching this number
I usually measure code trees rather than LOC. There's a fn (called codetree) in there somewhere to do it.
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?
looks like pg in europe taking the picture of a old hotel from the outside
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.
You hacked Proctor and Gamble's website? Cool!
I had to tilt my monitor to see the pattern. Then it's pretty funny.
I called it! http://news.ycombinator.com/item?id=98502
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.
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.
Name one screen reader that handles divs and doesn't handle tables.
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.
It is a trade off. If you want to support Internet Explorer, some kinds of layout are not easily achievable without using tables. W3C cannot be blamed for the deficiencies of IE though, so I'm not sure if this is what PG is alluding to.
Agreed, in fact if everyone used tables for tabular data only, we could have nice browser-supplied column-reordering and row resorting, I think.
Right now that kind of thing is intractable because there's no easy way to distinguish a table-for-data from a table-for-layout. I think it could be cool to have some way of putting something in your page HEAD that means: "In this page, tables are used exclusively for tabular data: you can activate your reordering features".
So...what happens to Common Lisp now?
As well, any bets on who writes the first book?
Common Lisp will keep chugging right along.
You could ask on comp.lang.lisp if you wanted some really well-informed opinions wrt the impact of Arc on CL, but I wouldn't advise it unless your skin is thick and flame-resistant.
I couldn't resist.
http://groups.google.com/group/comp.lang.lisp/browse_thread/...
> How wrong is it to regard [Arc] as a new Morris worm that infects
> MzScheme installations with unhygienic macros and empty lists that
> serve as false?
A somewhat different question is its impact on Scheme. My bet is mzscheme gets pretty popular this year.
Do you really think that Arc is a competitor for CL?
Maybe not. But unlike CL, Arc has a snowball's chance in hell of competing with Java.
It is for me. I literally wrote it so I wouldn't have to use CL anymore.
Here's the book answer: http://www.oreillymaker.com/link/7957/arc/
The function 'trues' seems like clutter when you can just write:
(keep [_] seq)
That would call the elements of seq.
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:
And thus I see the need for trues =P.
>two much python
and two little english
Hmm I bested it... ['(_) 0] beats [progn _] by one character, but it sure is ugly.
Does [1 _] work?
The shortest literal fn would be [if _]. But really you'd use idfn, not a literal fn.
"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?
To make webpages.
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.
"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.
I predict a goldrush of people writing open source frameworks, widget libraries, and blog software.
How does Arc make exploratory programming easier than Scheme, Common Lisp, Python, etc?
I've never looked into Lisp at all, but this actually sparked my interest.
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?
Thanks, Paul.
Paul: Small detail - there's a minor typo in your article:
"I spent a fews days"
Thanks for arc.
Congratulations! I'm looking forward to 'exploring' it.
What? Described as "for exploratory programming".
Of course, while 0 would work just as well; my brain was half in C-mode.
This article has a lot of value besides the arc announcement; I think it should be listed among the pg essays.
sigh every time I think that I know all the cool languages, somebody goes and builds a new one.
;)
Has there been any apps released with Arc yet? (aside from news.ycombinator.com)
And there was much rejoicing!
Congratulations PG! It's on my to-play-list ;-)
jens alfke:
i agree with all of that.
"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...
Congratulations
At long last...
"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.
Now is your chance. The source code is just sitting there. ;)
1. Spend time fixing major deficiency in language that prevents it from being usable. 2. Use language.
Maybe I'm being harsh :) I'm sure it's great really, but these days people expect unicode support on websites.
These days, most people don't even know/care what Unicode is.
These days, most people don't even know/care what functional programming is.
What??? I kinda like being able to talk about things as fundamental as money, without having to use (GBP). I'd like to use currency symbols for a start, what about math? I'd like to use pi occasionally. How about I want to add a nice 'tm' or (c) sign.
People care if a website is using correct unicode characters or not.
Perhaps they don't know/care because the majority of websites now are unicode, and just work.
Coders care, users don't. Just like they don't care about tables used for layout.
Users care if their name is zoe (with an accent on the e), or if they want to discuss prices of things in euros or GBP.
I wrote a php forum a while back. You wouldn't believe the number of emails telling me that the gbp sign doesn't show up properly when they post a comment.
Even if the users don't care (although they very much do when their characters all show up jumbled), the conversation here in this thread _is_ very much about the coders. Saying unicode is irrelevant is pretty strong in this context and IMHO, pretty bizarre.
Fine. My point it that it's hardly a "major deficiency" that would make arc "unusable".
I think that's a fair point - quite distinct from the original comment though.
that's what I get for trying to be snarky.
Yes, but they get peeved when cut+paste doesn't work the way they expect.
Yah, I can see how it sucks but unfortunately that's the way it will have to be for Arc given PG's disinclination to spend time over it. If you end up contributing a unicode fix, who knows, it might even get incorporated and others will thank you as well :)
Io has a nice, simple solution for character encoding:
http://iolanguage.com/scm/git/checkout/Io/docs/guide.html#TO...
Perhaps arc could use the same approach.
Summarising:
> In Io, symbols, strings, and vectors are unified into a single Sequence prototype which is an array of any available hardware data type
> A String is just a Sequence with a text encoding, a Symbol is an immutable String and a Vector is a Sequence with a number encoding.
Pretty cool. Thanks for the link.
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.
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.
By the same logic, commenters should be able to put arbitrary HTML in their comments. Very large font sizes. Blink tags. After all, HTML support does not have to take that long: just pass the HTML straight through to the browser. If commenters could use very large fonts and blink tags here, do you not believe that some of them would?
The freedom of the citizen of Hacker News to express himself is being suppressed! Paul Graham, add support for blink tags now!
I don't think expressing yourself in your own language using your own currency symbols is quite the same as using html. Nice try, but no.
I was talking about this place, news.yc, not about Arc programs in general. Of course a place for Spanish speakers or Chinese speakers is going to support the charset for that language. I _hope_ we can agree that we do not want comments in languages other than English in this place.