I agree. As I said in the other thread, it is a good idea to have an Arc-powered Arc forum.
Before contacting pg or rtm, I think it is a good idea that we talk about what we want to change around here, so that we can give them a clear idea of what we want.
1) Grant admin access to arclanguage.org to a high karma ranking Arc Forum member to update that painfully outdated home page OR update the home page appropriately, with added links to other Arc focused sites such as https://sites.google.com/site/arclanguagewiki/
2) Regarding modifying the current HN based forum:
a. A built in search utility, of course
b. Add 'popular' and 'sticky' tabs to the existing new | threads | comments, etc tabs.
- The 'popular' tab could be a pure karma based collection of the heaviest threads (sum of plus votes, in descending order).
- The 'sticky' tab should be threads created or selected by the admin, usually a collection of how tos, work arounds and frequently sought help. Order should be admin settable, and there should be an area above each thread where the admin can clearly highlight the purpose of the thread.
- if possible, the sticky threads should remain commentable unlike normal threads that become uncommentable after a certain period. I'm not sure how this would affect the site from a performance standpoint as I understand HN currently uses this strategy to optimize performance.
If performance is not a factor, then I would suggest that all threads remain permanently open to commenting. That way an inactive thread could become active and show up under the 'comments' tab, and be of use long after the original contributors have left it.
Guys, these are all great comments, but there are no signs that PG has even visited this forum in a long time, let alone made any changes to it. I want to set expectations.
I know. Last time he posted was 470+ days ago.
He probably would've said it if he had made any change.
So we are left with the following choices, if we want to improve the arc forum : bug pg for changes by sending him emails, or deciding as a community to move discussion about Arc somewhere else.
What are the odds of getting pg's attention? We should do all we can to get it, and only if all else fails should we look into the option of moving elsewhere.
Should we file a petition with pg and rtm, and if we do, where would the best place be to present it? I figure something along these lines might be necessary.
So, if you want to create an interpreter for "standard arc code" (i.e. vanilla arc), I think you have to recreate this behaviour, and all the other quirks of the functions defined in ac.scm and arc.arc, unless they are definitely bugs.
By passing nil as the first argument to +, it causes + to treat the remaining arguments as a list. Likewise, passing "" as the first argument causes it to be treated as a string. I much prefer this model to JavaScript's somewhat insane model where it takes both arguments into account.
With Arc, it's simple: the return type of + is always the same as the type of the first argument to +. I can understand if you (dido) don't like this kind of polymorphism or implicit coercion, but it does fit in well with Arc's philosophy.
I would also like to note that if it were up to me, (+ 'foo "bar") would also be valid: it would return the symbol 'foobar. And (+ (obj a 1) (obj b 2)) would return (obj a 1 b 2). Arc 3.1 doesn't do this by default, though, unfortunately.
I would also like to point out that I'm not against using + for only addition. In Arubic I would probably prefer a different operator for concatenation, like `join`, or maybe `cat`.
Well, I don't have a great dislike for overloading operators per se. I don't mind the fact that you can add together arguments of many different numeric types together and get a reasonable result (I was particularly irked by the +. operator in Ocaml for example). What I don't particularly like is that the + operator is used as a concatenation operator as well as an addition operator. The two operations are not at all the same, and using one operator to do both things seems more troublesome than not. I even remember that Paul Graham once wrote that he felt that using + in that way was not such a good idea after all for many of the same reasons, but unfortunately it seems that that opinion didn't quite gain traction in the most recent versions of Arc that have come down to us.
Well, I suppose I'll just have to suck it up, my personal opinions aside. I set out to make with Arcueid a C implementation of Arc, not my own personal Arc dialect. The most recent git head now accepts this behavior.
"Well, I suppose I'll just have to suck it up, my personal opinions aside. I set out to make with Arcueid a C implementation of Arc, not my own personal Arc dialect."
Once you start down the Arc path, forever will it dominate your destiny. :-p Really though, I'm glad to hear you're seeing your goal through before you veer off in some other direction.
For a while Rainbow has been the fastest Arc implementation, by my measure. Now Rainbow.js and Nu have come along and challenge that, and with Arcueid there's a C competitor in the race as well. :)
"Now Rainbow.js and Nu have come along and challenge that"
While Nu is drastically faster in certain areas, like the + function, in general it's slower than Arc 3.1 (by my estimates, about 5-10%). Unfortunately any Arc implementation built on Racket will have a hard time beating Arc 3.1's speed, simply because Arc 3.1 already pushes Racket pretty far. To get faster, I think you'd either need to find some serious oversight in Arc 3.1, or use Racket's modules.
Oh, sorry. :) Because of your your active work to make it fast, I figured it would challenge at least Arc 3.1, if not Rainbow, and I guess I got carried away. :-p
While you could probably trivially start from Arc 3.1 and streamline things here and there (like '+), you have a point about Nu adding other features.
That's right, and because the compiler is only a (small but important) part of Arc, I can only do so much. Arubic, however, can potentially be a lot faster than Arc 3.1, because it makes many more changes to the language. But that's a different topic.
Anyways, the only real reason Nu would be slower than Arc 3.1 is because it wraps every global Arc variable in a function. This is so useful that I consider it worth the 5-10% performance hit.
"Well, I suppose I'll just have to suck it up, my personal opinions aside. I set out to make with Arcueid a C implementation of Arc, not my own personal Arc dialect."
I too struggled with this. I wanted to change ar significantly in ways that I considered better. Then when I started the Nu project, it too made many incompatible changes to Arc 3.1. I still believe these ideas are good and improve Arc 3.1, but they're incompatible nonetheless.
But now my opinion is that any new language based on Arc should be cleanly separated. So I've started my work on Arubic (my own language based on Arc) as a separate project from Nu. To be more specific, it's one language implemented with Nu, the other one being Arc 3.1.
So now the Nu compiler should be very compatible with Arc 3.1, and any incompatible changes (like Arubic) will be implemented as something akin to a module or library. I think, ideally, an Arc implementation should be reasonably compatible with Arc 3.1, but still allow you to easily change it into a different language if you wish.
"What I don't particularly like is that the + operator is used as a concatenation operator as well as an addition operator. The two operations are not at all the same, and using one operator to do both things seems more troublesome than not."
Concatenation has an identity element, and it's associative, making it a monoid operation. I just think of '+ as a polymorphic monoid operation. When the monoid is a group, unary '- comes in to be an inverse operator. When the group is a field, '* comes in to be a multiplication operator, with unary '/ as its inverse.
So I don't have any mathematical objection to using '+ for concatenation, and I actually think it fits quite well. I've even thought about using '+ for function composition, since that's another monoid. (However, recently I've been more attracted to the idea of managing each monoid theory as a separate entity, rather than sniffing the arguments to figure out which operation to use. This is made easy by Haskell type classes, which essentially do the sniffing at compile time based on the static type system.)
Thank you for this.
Your excellent links make me think that, while it is obviously a good idea to have an arc-powered arc forum, it would probably be a good idea not to have it behave like HN and more like a regular forum.
While it make sense for a news aggregator to prevent thread necromancy in order to have only fresh content on the new page, on a forum like this, it only provokes burying of interesting content, (especially painful since we no longer have a custom search) and needless thread duplications.
Hmm, maybe I should create another thread for this.
This has been brought up before, multiple times I believe. Unfortunately no competitor or substitute to the Arc forum has become popular, so it looks like we're stuck with it for the near future.
Right now it seems to me that the best alternative to the Arc forum would be convore[1], which ar uses[2]. It has some problems, though. In particular I remember it being quite difficult to paste in code snippets. That would be problematic for a forum related to Arc. Any other suggestions?
I agree. The Arc community will be better served with more forum focused ways to highlight important/useful threads no matter how old. Dedicated threads with high visibility, including sticky posts within those threads, are used to great effect at many successful community sites.
And search is a huge missing feature on this forum. Googling Arc Forum helps, but not the same thing.
