Think about the traditional lisp printer and pretty printer. It's just that in this case pretty might potentially mean that certain parentheses could be omitted if indentation could still make the meaning clear.
So you might potentially have a printer that wouldn't attempt to remove parentheses, and a pretty printer that would do so to an extent.
As for the reader, if parentheses were optional but still allowed in normal s-expressions, then you could probably get away with using the same reader for normal and indented input.
sounds like a lot of work, but more importantly I feel that the reader and printer would lack internal consistency. That is, it would be harder for programmers to wrap their head around the reader/printer concept.
The reason I do not like this is that you are enforcing line breaks and whitespace, and this creates an asymmetry between the reader and the writer. Are you going to force the writer to return lisp code this way? What about lisp lists?
pg wrote an "essay" about this recently. He is going to focus on the space between the core language axioms and the library features. What this means is: expect no new libraries, expect new language idioms.
I checked out Gambit-C but my question is, where is the community? It looks like it's just some guys research project, then some other researcher made Termite on top of it. It's community is either non-existent or in hiding, it would seem...
That's a good question, and I have no idea--I just came across it because of Termite (which looks quite nice, by the way; those concurrency primitives [which are Erlang's, really] ought to be in Arc, but I digress). My point was really that it is technologically feasible to do so.
ah okay. You are saying it's possible to put this in Arc because it's in Gambit. Okay, sure. Gambit seems to be a much more performant implementation of scheme that Arc is striving to be. I think there is a lot to be said about serializing closures. Persistence is the nasty nasty dark secret of Computer Science. Our only tool that semi works is Relational Databases, but they aren't good for everything.
Live code upgrades is a great feature. Lisps already support this to some degree. If you make an app and expose a REPL on some local port then you can recompile functions on the fly. I'm not sure how it handles the current execution stack when this happens though.
Lisps pass some objects (lists, hash tables) by reference, but others (integers, symbols) by value. In languages that offer it like C++, explicit pass-by-reference is useful because A) these languages don't deal with objects as references by default and B) to pass extra information to the caller of the function (e.g. having a boolean reference that's set to true if some condition is met).
However, A is a non-issue in Lisps and B is trivially solvable by returning a pair, so I don't see how pass-by-reference could be useful.
Consider deleting a node from a binary tree. You want a function that looks at a node and, if it's a match, unlinks it from its parent. Passing by reference allows you to do this cleanly. The alternative is to peek ahead at each subnode (messy) or to pass information up the call stack (inefficient, as the function can no longer be tail-recursive).
I'm not advocating C++ references, which I think are too implicit. If a function call foo(x) can change the value of x, there needs to be some visual indication of this. I'd prefer something like plain C pointers, with which you can pass the address of an object: foo(&x).
Of course an alternative is store objects wrapped in containers, and this isn't too bad a solution.
A Lisp variable is implicitly a pointer to an object. Passing it to a function generates a copy of the pointer, which is pass-by-value. With pass-by-reference, the function would get a reference to the pointer. So e.g. reverse could be called for side effect: you could say (rev xs) instead of (= xs (rev xs)).
Your point about Page Rank is unfounded. Google doesn't look at pages it has already indexed to figure out Page Rank. It gathers a fresh copy then follows those links which would all work. And anyway, most of Page Rank is about other people linking to you.
If links stops working after a while, I'm pretty sure people will stop linking. And if not, visitors following the links will get a bad experience.
You may be right that it wont hurt page rank directly, though.
Concurrency is the next big thing in programming languages. If you want to take advantage of the increasing parallel hardware you have to support it. If Arc can't support concurrency, languages like Erlang who can will become the de facto standard.
I've heard that a lot, but I don't quite buy it. Thing is, distributed computing is the current big thing in architectures. If you can't scale your architecture across multiple commodity PCs, you're in for lots of pain, regardless of whether it supports multiple cores or not. Nobody wants to have to buy a SunFire just because their website got big.
If you have distribution, it's no big deal just to run multiple processes on one box and let the OS handle concurrency. You can treat each processor like it's a separate machine, let the OS handle scheduling, use your architecture's distributed-computing features, and silently take advantage of the blazingly fast IPC between different processes on the same machine.
I think in a case like hosting web apps, you can get away with using the OS's scheduling to run lots of instances of your server software and call it architectural concurrency. Witness Rails' standard deployment model with a pack of mongrels. Each rails instance is single-threaded, but you are running several on the machine and let the OS juggle them.
I think the appeal of Erlang and others like it is if you have a single app that you want to speed up with additional cores (it's hard to run a database on a bunch of commodity PCs as separate instances... it's done that way today, but will multimaster DBs really scale to 10,000 machines? Probably have to ditch the central DB for something more parallel) I think that if we have really hit the single core speed limit, then this eventually will matter, but not until the single thread becomes too big for one core to handle. (Assuming software requires more resources over time here... who knows.)
To get away from the webapp example... I imagine, for the foreseeable future, your web browser is really only going to need one core, and having more cores just means you can run more browsers at a time (like a pack of foxes, if you will), but a single browser won't get any speedup. In 10 years, when everything on the web is rendered in OpenGL 5 instead of text markup, maybe your browser will want some more parallelism (or maybe we'll just farm that off to dedicated graphics hardware).
I don't think it's really something critical for Arc right now. It's hard to follow the Erlang model without become Erlang (just like it's hard to do everything Lisp does without becoming Lisp), but I think that having parallelism baked into the language (or at least thought about) would be neat from a personal-coding-fun standpoint.
right now, two cores makes Javascript intensive apps not suck. For instance, without two cores I can't handle Google's Apps, with two cores they function nicely.
That one seems kinda expensive. I'd try slicehost.com or vpslink.com depending on your bandwidth needs.
What you need is a VPS server so you can setup arc yourself.
Alternatively though, you might be able to hack arc to work on a site like nearlyfreespeech.net. Their CGI support includes mzscheme http://example.nfshost.com/versions.php
