(Note, this explanation is for the standard Arc 3.1, not Anarki.)
They're not defined in Arc itself. They're handled by ac.scm, the Arc "compiler" written in Scheme. Specifically, the top-level function ac takes an Arc expression and transforms it into equivalent Scheme code. The function takes the form of a big cond, like:
(define (ac s env)
(cond ((string? s) (ac-string s env))
((literal? s) s)
((eqv? s 'nil) (list 'quote 'nil))
((ssyntax? s) (ac (expand-ssyntax s) env))
...))
The ! and . operators are part of what's called ssyntax, which you can see is involved in the last clause I included in the cond snippet above. I've always thought it's ambiguous what the first "s" stands for: probably "special" or "symbol". At any rate, we can see further down that ssyntax? is defined like so:
(define (ssyntax? x)
(and (symbol? x)
(not (or (eqv? x '+) (eqv? x '++) (eqv? x '_)))
(let ((name (symbol->string x)))
(has-ssyntax-char? name (- (string-length name) 1)))))
(define (has-ssyntax-char? string i)
(and (>= i 0)
(or (let ((c (string-ref string i)))
(or (eqv? c #\:) (eqv? c #\~)
(eqv? c #\&)
;(eqv? c #\_)
(eqv? c #\.) (eqv? c #\!)))
(has-ssyntax-char? string (- i 1)))))
First, note that + and ++ never get interpreted as ssyntax. This has to do with an earlier version of Arc that used + as a ssyntax operator (it got changed later to &). Also, _ is an exclusion; it's the special variable used by the bracket function syntax, where [+ _ 1] = (fn (_) (+ _ 1)). _ is not currently used as an ssyntax operator, but there's a lingering idea for stuff like +_1 to expand into [+ _ 1].
Otherwise, a symbol is considered to have ssyntax if it has any of the special characters: :, ~, &, ., or !.
The actual meaning of each ssyntax operator is a little bit complicated. It all goes through expand-ssyntax, defined by
As you can see, this dispatches to the different functions expand-compose, expand-sexpr, expand-and, and experimentally to expand-curry. Each of these functions will actually recursively call expand-ssyntax, so it turns out that you can have multiple ssyntax operators in the same symbol. This also means that the order of the cond clauses here is important, as they establish the precedence of each operator: : and ~ have higher precedence than . and !, which have higher precedence than &.
You can peruse the Scheme code further to find out how specifically each ssyntax operator works. But, you can also just use the ssexpand function in Arc, which will give you the result of calling the Scheme function expand-ssyntax, because ac.scm has the line
Heh, make that 13 - I voted for both Arc/Nu and Anarki Stable (looks like I'm a lone bird here) as I use them both. I hope I haven't jiggered the poll. :)
I see it as work too. Maybe we should reject this rational thinking and focus on something we like.
Personally, I like the idea of jumping ship to Arc/Nu (or merging!). Then we can port the Arc/Nu compiler to Arc/Nu and extend it to compile itself to every platform; who needs other implementations? :-p As I understand it, Arc/Nu has a fully reorganized codebase and very few entrenched users, so it's reasonable to refactor it again and again.
Arc/Nu has a "3.1" folder and a "nu" folder, so the website could introduce the Arc 3.1 documentation as though it's really just documentation for a compatibility mode. ;) Meanwhile, anyone who has a passion for consistency can work on documenting this mode in the same way I described above. :-p
Come to think of it, I might just be outlining more and more work. If Arc/Nu somehow becomes a vibrant community project, it's design by committee, right? I'm going to get some sleep.
"Were you suggesting that we should highlight things like arc-nu and arcueid?"
Well, I'm suggesting that they share documentation for their common features. If that sharing gives them more or less prominence on the site, I don't mind either way.
I think author intent matters here. If a new so-called "Arc implementation" comes along, sometimes it'll sacrifice improvements for the sake of compatibility (arcueid), and sometimes it'll sacrifice compatibility for the sake of improvements (Semi-Arc). I think this will correlate with our ability to share documentation between projects.
Jarc is an interesting case. It shows how subjective I am: Jarc changes the treatment of unbound variables to make it easier to call Java methods, but this doesn't affect most working Arc programs. Jarc doesn't support continuations, but it would if it could. I consider Jarc to be on the side of compatibility, but maybe only because I've found it easy to write Arc programs that work on Jarc despite these differences. Maybe I would have judged Semi-Arc the same way, if only my programs didn't rely on quite so much hygiene violation and ssyntax manipulation.
---
"I would like to be utterly oblivious to compatibility :) "
Yeah. Even though I recommend sharing documentation, I don't look forward to splitting hairs in what amounts to a standardization process.
"Interesting, I hadn't paid attention to the licensing terms. I thought anybody could do anything with the code, period."
Whoops, you just reminded me it isn't that bad. :) Per (4)(b), a closed-source project (or a project under a different license) is just fine as long as it doesn't interfere with a separate Arc installation and it doesn't call itself "Arc."
Playing out some scenarios...
Theoretically, I could invoke (4)(b) to continue development of Rainbow.js under the MIT license plus a few restrictions. In particular, any forks of Rainbow.js could not be named "Arc" or interfere with Arc, but they could be named (and/or interfere with) "Rainbow" or "Rainbow.js."
Interestingly, the Artistic License 2.0 grants an explicit patent license for the Copyright Holder's patents, but not for the Contributors' patents. Not that this is necessarily a problem; I like the MIT license, but it doesn't specifically mention patents at all.
It seems like I'm now okay with AL2.0. Effectively the only thing it prohibits is using the name "Arc" without respecting the original creators. That condition would pretty much be ensured by trademark law anyway, if Arc were a product being sold.
P.S.: I'm not a lawyer. As if that weren't enough, I've demonstrated an ability to misunderstand this license over and over and over. :)
I've cast my vote for Rainbow. For the most part, I've only ever used Arc as a topic for discussion, as shallow inspiration (e.g. naming conventions), or as a platform for language-implementation-independent libraries I rarely used. But there have been two exceptions:
I briefly maintained my website's static site generator as an Arc+Penknife project. It could run on Arc 3.1, Anarki, and Rainbow, but I preferred to run it using Rainbow for speed.
At one point I wanted to fill a gap in our Arc-in-the-browser discussions, and I especially wanted to show there was no innate reason for ClojureScript to omit 'eval, so I spent a lot of effort porting and adapting Rainbow to make Rainbow.js. I figure this means I have a special investment in Rainbow, even if I don't run Rainbow or Rainbow.js for any serious business.
---
"Do people think I should add even deeper spin-offs like nulan and lathe and blade?"
Lathe and Blade shouldn't make it on this list.
Lathe is a suite of language-implementation-independent foundational Arc libraries, some of which specifically make it easier to write language-implementation-independent Arc code. I suppose you could program for Lathe as though it's an Arc platform, but that just means polyglot programming for several Arc platforms all at once.
Blade was a language project that never got off the ground, and it pretty much didn't have anything to do with Arc.
"Like you, I believe the Arc language should be free to change in ways that break existing code. However, I think some of the Arc community's most large-scale projects have been the multiple implementations of Arc, and I think that's worth representing on the website, even if the community evolves to have some other focus later on."
I'm not sure how to interpret this :) Were you suggesting that we should highlight things like arc-nu and arcueid? I'm totally supportive of that. It didn't occur to me to want incompatible variants to steal all the thunder from compatible variants -- especially since I would like to be utterly oblivious to compatibility :) Or did you mean something else?
(At the risk of unnecessarily repeating myself,) I am only opposed to linking flatly to http://ycombinator.com/arc/arc3.1.tar (die! die! :) without any provisos or qualifications. We already have a frontpage for arc3.1.tar; we don't need another.
"Ideally, I would like to see arc3.1 be shown as default, along with a pack containing separate patch files for critical bugs."
This could actually be quite cool! Full transparency; we show the default, and we enumerate its biggest issues along with their fixes. That sets expectations in advance. Yes, make it so :)
You: "About password issue. If PG switches hash, he surely will consider about compatibility.."
I'll quote PG and RTM again: "Arc is still fluid and future releases are guaranteed to break all your code."http://www.arclanguage.org
I interpret this sentence on the frontpage to mean that he will not be concerned about compatibility. Arc is for exploratory programming. If you have users you're on your own. I really don't see how you can interpret it any other way.
The good news is that migrating passwords isn't hard. I've done it for a site myself.
"There's no value in being strictly compatible with an old, buggy release that never guaranteed compatibility in the first place. We should instead focus on a live version that's getting fixes over time, whether it's anarki or arc-nu or rainbow-js or something else."
If we agree it's a fix, then we can document it the correct way and just take note of which bugs exist in which implementations. Arc 3.1 is just one implementation for these purposes.
If someone wants a real reference implementation to test against, they can use a version of Arc that has relatively few bugs, such as Anarki's stable branch or your curated Arc repo.
Like you, I believe the Arc language should be free to change in ways that break existing code. However, I think some of the Arc community's most large-scale projects have been the multiple implementations of Arc, and I think that's worth representing on the website, even if the community evolves to have some other focus later on.
---
Speaking of choosing a canonical, main-documentation-worthy variant of Arc, I've always been reluctant to develop upon any existing implementation of Arc, due to licensing.
Now that I take yet another look at the Artistic License 2.0, I think it isn't nearly as complicated as I've interpreted it in the past. It's still odd, though: I think technically anyone can make closed-source products out of Arc, Anarki, Arc/Nu, Rainbow, Rainbow.js, Jarc, etc. as long as they give their source code to Paul Graham and Robert Morris in private (per section (4)(a)).
I'd prefer to use a more generic permissive license, something that obviously permits distribution of closed-source binaries, rather than being quasi-permissive depending on the participation of pg and rtm.
Ideally, I would like to see arc3.1 be shown as default, along with a pack contains seperated patch files to critical bugs.
And we can treat anarki as a fully fork, with no restriction and full freedom.
About password issue. If PG switches hash, he surely will consider about compatibility, without that, all users of HN will need to reset their passwords.
Ok, glad we can agree on the common ground of bug fixes. Perhaps we should make the stable branch in anarki the default. I'm not sure what's on it at the moment, but it's probably quite close to arc3.1, and we can patch in the biggest fixes to it.
In general, I'm uncomfortable supporting a version that we are not empowered to update. That's basically my biggest objection.
This community has had a culture of letting newcomers come in and show off new ideas to each other. I think that is valuable, so I'm in favor of allowing anyone to update the default version most of us use. But we can agree to disagree on that score :)
(I still think you're WRONG about the password issue :) What'll you do if PG switches the hash in the next release? SHA-1 is insecure, and an insecure default is a recipe for reputation damage down the road. Good thing arc isn't very popular..)
Although not thought every point throughtly, I have read gotchas page for several times.
I'm not against to bug fixes, but I think anarki has go far beyond that.
Take password hash for example, if let me choose, I'll remain it as is. If someone have hosted HN-like site using arc3.1, it'll be hard for them to use anarki instead because of that change.
Ok, I'm outvoted just looking at the votes, so feel free to make arc3.1 the default.
But I still think you're chasing some mythic notion of compatibility. From http://www.arclanguage.org: "Arc is still fluid and future releases are guaranteed to break all your code." There is no "reference" here; if you want upgrades to be smooth you're guaranteed to be disappointed.
"if PG can release a new version, that would be the most suitable choice. :)"
Even if that new version gets no bugfixes for 4 years?! O_O What if that next version takes ten years to show up? Heck, what if it takes a year to show up. Are you sure you'll still care?
I don't know anybody on this site who still uses arc 3.1. Even my 'curated bugfixes' repo at http://github.com/akkartik/arc was a short-lived thing. It's just the nature of this community to go off on some tangent :)
Have you read the gotchas page? Many of those gotchas I'm talking about aren't minor bugs. They took weeks of pain and in some cases months to come up with a fix. I wouldn't wish that pain on anyone. For example, for several months I thought that arc and racket was just really slow, all it could do was 1 request per second. But it just seemed slow because all my requests were getting throttled because of some code in HN that most sites will never need, because they'll never have that much traffic.
Perhaps the compromise position would be the 'stable' branch of anarki. But I'm not aware of anyone who uses it. I really think that if you want to benefit from this community anarki is the most common baseline, and the whole point of a new site is to give newcomers the benefit of more updated information than the existing site, and to get them using what the veterans here are most familiar with so that they can get their questions answered soonest.
If the community has new ideas should we go try them out, or should we wait for PG to first grant them his permission? I know what he'd do :) And if people here have new ideas it's worth getting them feedback from others as long as we can be responsive to issues when they come up. And I think we're pretty responsive :) Arc is a bleeding-edge language, and we shouldn't try to act otherwise.
(Incidentally, yes, the HN site on anarki is indeed data-incompatible with arc3.1. It hashes passwords with sha512 rather than sha1, for one: http://arclanguage.org/item?id=17278. Which would you use?)
Hold on, I'll post a poll. I don't actually know that anarki is the most commonly used :) I'm also interested in rocketnia's reasoning of this whole issue.
I am wandering what's the purpose of people who come here.
Some random thoughts:
1. want to learn about Lisp and Arc
2. want to learn about language design and implementation
3. want to deploy a clone of Hacker News
4. want to use Arc as a daily programming tool
5. want to make a fork :)
For 1, I think bugs in Arc is not too fatal for those guys, we just need to make them aware of those bugs.
For 2, they need to, and I think they would like to investigate those bugs, so I think its better to let them fix those bugs by themself, learning from mistakes is effective. :)
For 3, those people will not tolerant of bugs, but compatibility is also critical for them, both about codes and data. As they need to consider how much work they will need to do when PG release a new version.
For 4, they will satisfied with anarki or other forks.
For 5, as a fork, they need to treat something as a reference, and I think vanilla arc is the most suitable one.
So I think it's more suitable to make vanilla arc as default, as it can make more people happy. Anyone not satisfied with it can choose forks.
PS: I'm in group 3. :)
I'm not sure how far has anarki diverged from vanilla arc, and whether data is still compatibe with it, so I decide to use vanilla arc, and integrate some bug fixes.
PS 2: Of course, if PG can release a new version, that would be the most suitable choice. :)
There's no value in being strictly compatible with an old, buggy release that never guaranteed compatibility in the first place. We should instead focus on a live version that's getting fixes over time, whether it's anarki or arc-nu or rainbow-js or something else.
The documentation at arcfn has been out of sync with arc3.1 as well as anarki for many years. I love that we're fixing this, but I'd rather gradually bring the docs in sync over time than switch to a more misleading version of the code.
I'm open to being convinced otherwise about this, and if you like you can revert the frontpage change while we argue :)
"I think we should make anarki the default; 3.1 has some bugs and gotchas. Even if the docs will only support arc 3.1 for starters, there's still value in combining them with anarki, I think."
Seems like you and I disagree about this at the moment. :)
---
"I love the favicon :)"
Eh? Isn't that the favicon that comes bundled with Arc? (Hmm, I see the "ref" pages have no favicon at all. O.o )
As opposed to the Arc 3.1 favicon, I prefer the version currently used here on arclanguage.org. Its colors seem to have been tweaked to address the blue-and-black contrast issue identified on the original logo thread: http://arclanguage.org/item?id=9438
What I cancern about is the compatibility of anarki and 3.1.
If anarki is stickly compatibe with arc3.1, or at least have a branch which make compatibility as one of its goal, then its good to make anarki as default.
Currently there are some compatibility issues, so I'm afraid it will confuse starters.
tryarc.org is really cool, I was not aware of it.
arc.sh also fails here.
I just run `jekyll --server --auto`. Maybe caused by failing to fetch css files?
Thanks for the apologies. As for me, I wanted to stop you from getting carried away and potentially causing harm to people, but I'm sorry if I've given you a bad experience in the process.
I had seen that blog post of yours. I also particularly noticed this tweet you retweeted, which aptly summarizes a common theme between your blog and your Arc Forum posts:
Founders: What are you doing right now? Is that thing a 10X
improvement or a 10% improvement? Always work on 10X. Every
minute counts.
This kind of mindset can be encouraging, but it seems like it's causing you negative stress. If so, I hope you can set aside some extra time for other things you like to do, even if they feel unproductive. I don't know if those things will be remotely on-topic for Arc Forum, but feel free to bring them up if they are. :)
