PG is absent here. He hasn't posted in over five years. He's also mentioned that he doesn't care about initial popularity, as he doesn't think it matters for a "hundred-year language". I somewhat disagree; if people write off a language in year 0 because it's unpolished, they may not revisit the language in year 5 when it is.
It would be cool to have an Arc conference. I've met up with both akkartik and waterhouse when I traveled to SF for Startup School. Perhaps if you're interested, you could organize a virtual conference, or even a virtual chat with Google Hangouts or the like. Sacha Chua holds virtual hangouts for Emacs, and they've been pretty cool.
The people that run HN don't seem to be interested in doing so, and they almost never post here (except like one time: http://arclanguage.org/item?id=19389). So getting even an updated Arc release hasn't happened, nevermind actually letting the community push Arc forwards.
The community is definitely stagnant. PG has been the driving force behind its publicity, so because he hasn't said anything about Arc in a while, there isn't new blood coming in.
That said, Arc is probably a better language if you want to hack the language, and Clojure is better for almost everything else. This is especially true if you need libraries, or want something that Just Works^TM.
> I should have found the solution by myself. I'll try to do better next time.
Screw that. Asking for help is just fine. You weren't sure what was going on, so you asked for help. (This is something I struggle with too). Forget what you "should" have done; you tried and when you needed help, you asked for it, with a very good, simple example that showed the problematic behavior.
Oh you didn't. Absolutely not. I was thinking loudly here (I'm always trying to improve), nothing wrong with your answer. Thanks again for your help :)
Interesting. How many people have you gotten into Arc? You mention that you "found it difficult to explain to beginners how to get an Arc REPL up and running".
Arc 3.1 actually doesn't require an old version of mzscheme -- you can just use racket, and start it with `racket -f as.scm`. And no, the instructions on this site don't say anything about that.
zck: I would probably say about ten to fifteen people. I was working on designing a LISP/ML like language which had a lot of similarities to Arc, so I went on a bit of an Arc binge and showed it to a bunch of friends at school. I found that it was a little difficult for some people to set up.
Does Arc 3.1 run properly though on MzScheme 372 or does it need to run on Racket?
"Does Arc 3.1 run properly though on MzScheme 372 or does it need to run on Racket?"
The only problem I've had running on MzScheme 372 is that it can be awkward to track down documentation for that version. Newer versions sometimes have more features available.
Arc doesn't have all the I/O primitives that Racket has -- Racket has an almost ridiculous variety of primitives for file manipulation, sockets, garbage collection, delimited continuations, FFI, concurrency, UI, etc. -- so Arc programmers have often hacked on the language implementation to support their applications. This hacking happens in Racket (aka MzScheme), so having a nice version of Racket is helpful.
That's awesome that you've introduced it to that many people. I haven't really been able to get people interested more than tangentially. Good for you.
>Does Arc 3.1 run properly though on MzScheme 372 or does it need to run on Racket?
I haven't tried running it on MzScheme 372; once I could just use the most recent version of Racket, I decided to just do that. It seems easier than staying on an old version.
> In this example, the + and - look like punctuation separating the phrases "gdc a", "b c", and "(square d)", and it takes me a moment to realize "b c" isn't a meaningful expression.
Agreed. This is possibly my main complaint with mixing infix syntax with prefix syntax.
> gcd (a + b) (c - square d) (* ML )
(gcd ((+) a b) ((-) c (square d))) ( ML again *)
This is the same in Haskell^1. But I really dislike how this is done. It conflates calling a function (by surrounding it in parentheses) with converting an infix function to prefix. And if the function is unfamiliar, you don't know which it is. I assume this is taken care of by the parser, so it's into the arbitrariness of syntax, not the clear standard of function application^2.
[1] I assume Haskell got it from ML.
[2] This is unless you assume some insane return type that's basically "if called infix with two arguments, return a number; if called with zero arguments, return a prefix function of two arguments that returns a number".
I think so. I'm primarily familiar with Haskell, but I hope those examples at least work in SML too.
A lot of the syntactic similarity starts to break down once the examples include lambdas, pattern matching, and top-level declarations, but I think that's similar to how the similarity between Lisp dialects breaks down when we look closely enough.
---
"It conflates calling a function (by surrounding it in parentheses) with converting an infix function to prefix."
I was making it look similar to Lisp syntax for the sake of argument, but parentheses aren't actually used like Lisp function calls there. In that example, parentheses are just used for two purposes:
- Grouping.
- Referring to infix variables (+) without applying them, which would otherwise be impossible to do.
The syntax for function application is juxtaposition with left associativity, so "gcd a b" is grouped as "(gcd a) b".
Agda[1] and some notes on Epigram 2[2] track "spines" of elimination contexts for the purposes of type inference and implicit argument elaboration. I think Haskell might use spines to resolve type class instances as well. In that case, the meaning of gcd in ((gcd a) b) can depend on the types known for a and b. With this kind of trick, Haskell's instance resolution can supposedly be used to write what are effectively varargs functions[3].
I prefer the parentheses-based Lisp notation to any notation I've seen that removes them. Perhaps I haven't seen a notation that is simple enough for my taste.
The big benefit that parentheses have is that they make the correct parsing of the text obvious, especially when combined with decent automatic indentation^1. If I never have to read something like `[x * 2 if x % 2 == 0 else x for x in a_list]` or `[x * (2 - x % 2) for x in a_list]` again^2, I'll be thrilled.
So my question is: unless you can make the correct parsing obvious, why skip the parens?
Obviously Arc is somewhat of an unconventional choice, so you might run into more problems. I'm not saying that to discourage you, just to make you aware of what you're getting into.
You might also look into Clojure, if you want something with more libraries.
But if you decide on Arc, I'd say (as usual) that you can just do development on whatever machine you're working on -- you won't be doing anything heavyweight enough that you need a separate dev machine.
Having not run Arc in production, I'll defer to akkartik's suggestions for picking a cheap VPS.
