I'm not worried about its lack of 'eval so much. They're placing a strong emphasis on ClojureScript's ability to leverage the Closure Compiler to weed out dead code. Inasmuch as they encourage dynamic programming techniques at all, they'll end up with dynamically minded libraries that make their compile-time efforts seem weaker than they are. Apparently they draw the line at reflection, and 'eval is beyond that point.
What I'm more worried about is that under the current plan, it looks like there "won't [ever] be" any "thread-related things" (http://cloud.github.com/downloads/clojure/clojurescript/cloj...). I don't find Clojure remarkable for static analysis, for syntax, or for collaboration between programmers. What I find remarkable about Clojure is the way it furnishes its standard libraries with things that anticipate concurrency, so that when people write their own concurrency-related Clojure libraries, they're all likely to synergize with each other.[1] Even if ClojureScript doesn't get to have shared-state concurrency thanks to the JavaScript platform,[2] I think it would be great if its biases could somehow be repurposed for use with web workers or AJAX.
[1] At least I imagine they synergize. I haven't used Clojure or stumbled upon many concurrency-related Clojure libraries, so I hardly know how well they work together in practice.
In practice, in both my Arc and JS code, I use eval only when I absolutely have to... which is almost never. It's usually when I'm doing something incredibly hacky, like trying to eval macros at runtime...
Anyways, the traditional wisdom in JS is to avoid eval as much as possible. 99.99% of the time, eval is bad. It slows down your code, makes things like static analysis harder (or impossible), and it's usually completely unnecessary.
So, I don't see any practical problems with removing eval, but I do see some philosophical problems. eval has been a part of Lisp for so long, that it almost feels like a Lisp without eval isn't really a Lisp...
In any case, from a practical perspective, a lack of eval isn't a big deal at all. But I can see why some people might want eval (for non-practical reasons).
Having both macros and eval always seemed redundant to me, because they're both for letting you treat code as data. Also, since the eval in most lisps (Arc included) doesn't accept a second parameter for the environment context, they might as well not have eval in the first place.
1. A good theoretical lisp should be fexpr-based and have an eval which accepts both parameters.
2. A good practical lisp wants to be fast, so it should use macros instead of fexprs. Eval is basically irrelevant here.
"...they might as well not have eval in the first place."
Although I agree with you in principle, eval is needed in at least one place: load. So I don't think we can necessarily get rid of it completely, unless we used a different method of loading/evaling files...
eval is also used in a few other places in ar, but not very many. So rather than getting rid of it, I think a better solution is to say, "eval is generally a bad idea, so use something else unless you absolutely positively must use eval" which is exactly what we do.
By the way, I'll note that when I tried to use eval to expand a macro at runtime, it ended up being horrendously slow. I changed it to use a function (which did the same thing, but with thunks) and suddenly my code ran at least 100 times faster than it did with eval.
Ah, you're right. You may not be able to do away with eval.
And do you know what you just helped me realize? If we've already identified ourselves as a practical lisp, why should we try to get rid of features like eval in the first place?
A theoretical lisp tries to get rid of unnecessary features to approach being as minimal as possible. A practical lisp has already decided that it would rather be useful than theoretically minimal.
So a practical lisp probably shouldn't worry about getting rid of things unless they are actively causing problems. If it wants to be as useful as possible, it might as well leave in unnecessary features. Because they're probably still useful some of the time to some people, even if they're not totally necessary.
Nice. Since we're on different versions of Windows, I can totally believe that. But you only got it for one definition of factorial and not the other? Did you type them in differently somehow? (Say, by putting a newline at the beginning of the second one, or by entering the first one as the very first command of the REPL session?)
Actually, there's a chance I may be able to even though I'm on XP, since it may have more to do with the version of MzScheme being used. I'll see what I can do.
This is a bit off-topic, but despite your best efforts, you are probably not using the latest version of Arc. Sounds like you've been following the instructions at http://www.arclanguage.org/install for the whole time you've been posting here, and those are out of date by almost two years, even linking to a version of Arc 3 (one of a few Arc 3s, I think :-p ) instead of Arc 3.1. I think this is a better starting resource: http://sites.google.com/site/arclanguagewiki/.
Old versions of Arc needed to run on MzScheme 372 because it was the last MzScheme with mutable lists, but now Arc 3.1 uses some pointer manipulation to mutate lists behind Racket's back, meaning any version of Racket is fine. However, this actually introduced a rare garbage collection bug, if you can believe it. ;) That means there is actually a legitimate reason to keep using MzScheme 372, but as described at http://sites.google.com/site/arclanguagewiki/arc-3_1/known-b..., pretty much every Arc setup besides the official one avoids this bug, and it's possible to patch the official one too.
Anyway, you're the first person I've heard of who's tried Arc on Windows 7 (which isn't to say there aren't Arc Forum lurkers in the same position ^_^ ). If you encounter Arc-on-Windows-7 stumbling blocks, please continue talking about them like you have in this thread!
The -m option means to call the "main" function now. Just leave it out. It used to mean "--mute-banner", which suppressed the "Welcome to MzScheme" line.
That "racket -f as.scm" command is the right one. The 'setuid issue is one of a few known issues on Windows, and it has a known fix: http://arclanguage.org/item?id=10625.
Guess Pauan broke the link by replacing the master branch with one that could be pull-requested back into awwx/ar. Here's import.arc on the "old" branch: https://github.com/Pauan/ar/blob/old/lib/import.arc
By the way, Pauan, how did you manage to make that switch? Your GitHub history has an entry that says "master is now 2be9ac7", and your pull commit worked out better than mine did. I'd like to know your secret. ^_^
Yeah, sorry, that was intentional, but I didn't realize the links would break. In hindsight, I should have.
Well, it's pretty simple[1], really. I used git fetch upstream to grab all the changes from ar. Then I used git reset --hard to reset my master branch to ar's branch, completely destroying everything on my branch, including commits.
Then I used git push -f to force my changes onto GitHub. Voila, now my fork is in the exact same state as ar. Of course, before I did all that, I created the old branch, so I wouldn't lose my work. Here's roughly what I did:
git branch old
git push origin old
... do stuff ...
git fetch upstream
git reset --hard 2be9ac75f67edfe9b3c43a9515dd78acebba6f1c
git push -f origin
At least, I think that's what I did. I actually had to experiment and mess up some stuff before I figured out how to do it. So my directions may be wrong and you may bork your repo!
But their directions are somewhat different from mine. I don't think I needed git pull for instance, and git push origin :master didn't work for me. So I had to use -f to force the push, since git was kindly telling me that it might destroy my commits (which I wanted to do).
---
After using git for a while, I gotta say, I like it a lot more than Mercurial. git gives you the power to do stuff, whereas Mercurial seems to hold your hand a lot more, and say, "no I can't let you do that, Dave"
Now, I'm not saying Mercurial is bad, just that I like the raw power of git, in the same way that I like the raw power of Arc. So for me personally, git seems to be the winner.
It's too bad the links break. But wait, the pull requests' links don't break, because they link directly to the blobs.... I bet the blobs will stick around as long as at least some branch points to them, so playing fast and loose with lots of branch-renaming is only going to hurt tip-of-branch links. Too bad GitHub doesn't have some way to specify redirects (or at least I think it doesn't).
Also, I'm not actually sure how well my old branch actually works, since I've moved onto working on ar. I do plan to port import.arc so it works on ar, since ar now has defcall (yay).
The first 3 examples of hello all functioned as I thought they should. But when I got to the fourth one, I expected a form with some prompts and a link. Rather, all I got was a web page saying It's alive. Where did that come from?
"It's alive." is just a tongue-in-cheek message printed by default to the root page (probably http://localhost:8080/) of a running instance of the Arc server. You can see where it comes from if you open the file srv.arc in your arc directory and look for the line:
(defop || req (pr "It's alive."))
The || from that is a symbol for empty, so just as your (defop hello ...) command puts a page at http://localhost:8080/hello, (defop || ...) puts a page at http://localhost:8080/. (Nothing comes after that final slash since we used the empty symbol instead of "hello".) You could replace the default "It's alive." message by running a command like
(defop || req (pr "jsgrahamus rox!"))
at the REPL.
Were you able to get this stuff working, by the way, or are you still stuck??
In running through the tutorial, I did the following:
arc> (defop hello req (pr "hello world"))
#<procedure: gs1709>
arc> (asv)
ready to serve port 8080
^Z
[1]+ Stopped ./goarc
mint@mint ~/bin $ ./goarc
Use (quit) to quit, (tl) to return here after an
interrupt.
Then I wanted to try some more, and it seems that the port is still in use.
