Everyone who comes to Lisp has problems with the syntax at first. It's not hard, it just takes time to unlearn all that bad syntax from other languages :)
It also sounds like you're not used to functional programming. That's a much harder hurdle, because it's a completely different way of thinking, a whole new world. You basically have to learn to program all over again.
But it's worth it. Imperative programming is simple to learn, but can only take you so far. In contrast, you can spend your whole life learning functional programming and you'll just keep getting better and better at it. There's a virtual infinity of new abstractions and techniques you can use, and there are whole branches of computer science inventing more: iterators, generators, zippers, monads, arrows, lazy lists... It's endless.
So don't worry if you find Lisp hard. Everyone does. All I can say is that everyone who has persevered at it and mastered it comes to love it and never wants to go back.
I've interviewed a lot of people who have experience with Lisp, and I ask them if they think learning Lisp is worthwhile. Almost all of them reply with some variant of "Why on earth would you do that?" I've received a couple "Yes, definitely" replies from people who are hard-core Lisp hackers. So empirically it seems that most people who learn Lisp don't find it particularly rewarding.
I've talked to many fewer people than you, but my impression has been slightly different. Broadly speaking, the engineer-type programmers tend to dislike Lisp, and the computer-science-type programmers tend to like it. (Those two classes cover, in my [albeit limited] experience, two of the principle ways of thinking about programming.)
Eh. It's attitude, not job description :) And anyway, you should probably take that with a relatively enormous grain of salt, as small sample sizes aren't conducive to accurate data.
Well, every implementation of Lisp does indeed contain an interpreter: eval!
But the way Lisp compilers deal with recursive macros is to not allow them. From the Common Lisp spec:
"All macro and symbol macro calls appearing in the source code being compiled are expanded at compile time in such a way that they will not be expanded again at run time."
That rules out recursive macros. I think they're allowed when Lisp is being interpreted, but you should probably just not use them.
It's the start of a new project for me (and hopefully later on a postdoc position on the topic). The idea is to build some kind of smart animals in an artificial world, without having to design them, or run through countless of iterations with genetic algorithms to get one.
With a good basic structure, they should be able to get smart on their own ;).
I'm running the same and I don't get that error. Can you open other files ok? Have you tried running (open-input-file "svg.arc") from MzScheme? Also, have you double checked that the file is actually in the right place? (I only say that because that's the only way you should be getting this error, so it's worth looking again just in case.)
Thought this was quite an interesting paper. It discusses how to specify a Common Lisp-like language very precisely by using the language itself, the way Arc does.
It's also interesting because it shows how few axioms it takes to define large parts of CL, even though CL is hugely complex and was never developed with that intention. It makes me feel confident that Arc will never need a large number of axioms, and that if it looks like it does then someone's doing something wrong.
Well, parsing a float is implemented, in the sense that read will parse it for you, so that's not the problem. I suspect it doesn't work because num is just a place-holder for "this kind of number is not yet fully implemented; don't expect much". It will probably die in a future release.
Tag refusing to print attributes it doesn't understand has bitten me a few times. I have my own file adding all the extra attributes I use (you know, really obscure ones like id and onclick).
The Stalin Scheme compiler is 33000 lines long. That's an aggressively optimising compiler, so nothing will be much more complicated than that.
To translate something like that 'easily', you'd have to use automatic translation to Arc for most of it. Looking at the code, I think that'll be quite easy, and you'll get say 90% of the code converted that way. That leaves about 3300 lines. So I'm guessing this is of moderate difficulty.
Do you think this would be a realistic amount of work for one summer?
What about part two (converting the compiler to compile Arc instead)? I suppose I would gain something on an understanding of the operation of the compiler while doing part one, but this seems rather intimidating to me.
And I'm not really sure Stalin is the right compiler to base an Arc in Arc on. (Although I suppose that wasn't really the point of your post.)
Can you suggest any other Scheme compilers I might try to port?
I don't know much about Scheme compilers (or Scheme for that matter, I'm a Lisp guy), so I can't really say.
For the conversion to an Arc compiler, it's similar enough to Scheme that I don't think it'll be a big issue, especially as it's implemented on MzScheme. Quite a few tricky Arc functions are just MzScheme functions under a different name (e.g. threading, I/O stuff). That brings up a point: you really want a compiler for the subset of MzScheme that Arc uses, not Scheme itself (although a Scheme->Arc compiler would be cool too).
Is it too much work for a summer? Depends on what you want to achieve. A completely non-optimising Arc compiler, based on code ripped from other projects, would probably be really easy to implement. Writing a Scheme compiler in one semester is standard coursework on some CS courses. So I guess the important questions are:
1. What good Scheme compilers written in Scheme already exist?
2. How much actually needs to be converted? (Most of the runtime will probably be implemented in C anyway, so no conversion necessary).
3. Given the spread of possible compilers you could convert, do any of them look like a summer's worth of work?
