Among these three approaches, the 'extend approach is the one for which it's most important to pay attention to the order in which extensions occur in the code (or on the REPL) for efficiency and precedence purposes.
Here's my personal take on when to use 'extend vs. something else:
If there's a facility that does what you need, use it, but if there isn't, use 'extend ^_^
'extend is a hack, or rather, a tool for hacking. I mean that in a good way, I use it all the time. But pile too many hacks on top of each other and you get a mess.
So if you're extending a function in a way that can be done with generics, that's good, because now you can do your definitions in an independent order and you're not wondering what hacks are going to be messing up your hack.
I'm still wondering if `(1) expanding to '(1) is intentional or not.
A quasiquote expander can expand `(1) into '(1) or (list 1), or even (join '(1) ' nil), which is what Bawden's simple, correct, but inefficient quasiquote expander does.
The expander may choose '(1) as being more efficient than (list 1), but isn't required to do so to be a quasiquote expander.
Since it's an optimization, I wouldn't write code that relies on a particular instance of `(1) evaluating to the same list every time, that's just an accidental result of the optimization. Instead, use a plain quote for that.
Though "developing a Windows application in Arc" and "producing a Windows executable" are also two different things: you could create a Windows installer for your users that puts your application files down inside of your application directory inside of Program Files, including a copy of MzScheme and your Arc program, and adding shortcuts from the Start menu and Desktop etc to launch MzScheme with your Arc program. That's a different task than creating one monolithic executable that contains everything.
If you don't get an answer here, you might try asking in an MzScheme forum or mailing list.
From MzScheme's perspective, Arc is just a big MzScheme program that it's running, and your Arc program is just data that's being fed to the program. So your question is really, "can MzScheme produce Windows executables?"
I haven't looked at your quasiquote examples in particular, but note that standard Arc uses MzScheme's quasiquote expander, which is buggy for nested quasiquote expansions.
Fortunately it's easy to use a working quasiquote expander: it's a one line change to the Arc compiler so that if a "quasiquote" macro has been defined, it gets used instead of the builtin MzScheme version. Then we can load a quasiquote implementation written in Arc, such as fallintothis' port of the Common Lisp quasiquote expander.
That's precisely the purpose of my Scheme/Arc parser (scheme-parser0.arc at http://awwx.ws/hundred-year-parser) -- use that as a starting point, and implement whatever parser you want. It doesn't handle incremental parsing yet though, so it isn't a drop in replacement for "read" now.
You'll get this error if the browser has closed the connection and isn't reading the data.
One thing to check is what headers are being sent. For example, with the wget utility, you can use the -S option to see the server headers. First look at the response you're getting from the working server, and then compare it with the response you're getting from the Arc server which isn't working.
If you look at the Arc compiler around line 448 in ac.scm from Arc 3.1, you can see that the first thing it does it is check whether the "fn" in the first position of a "call" form is a macro:
that's why an identifier being a macro takes precedence over an identifier being a lexical variable.
But you can easily change it. The "lex?" function will tell you whether an identifier is a lexical variable at that point. So you can change the test in the cond for "macfn" to something like "(and macfn (not (and (symbol? fn) (lex? fn env))))" and an identifier being a lexical will take precedence over an identifier being a macro.
My goal for the parser is that it should be very easy to do the kind of thing that you're talking about, so to whatever extent that it isn't, do let me know, so that I can fix it.
Alternatives include established lexers and parsers such lex, yacc, and bison (http://oreilly.com/catalog/9781565920002) which have a parser DSL (domain specific language, a mini-language devoted specifically to parsing). If you like regular expressions the grammar rules in perl6 are worth checking out. If you like your parser language to be programmable so that you can build complex parsers out of smaller ones in your own way, Haskell's parsec is a good one to look at.
I believe one of your primary tradeoffs will be speed vs. flexibility. If lex/yacc/bison will do what you want, then they will be among the fastest since because their parser language is limited, it can be compiled down to code that parses fast.
As you move up through the options of Perl, parsec, etc., and my parser, you gain programmability and flexibility at the cost of speed.
If know exactly what you want to parse, it makes sense to go directly to the fastest parser that will do what you want. If you're not complete sure, if you want to experiment, then from an exploratory programming point of view it makes sense to start with the most programmable and flexible parser library as that won't impose constraints of what kinds of things you can parse; and then, after you've figured out exactly how you want your parser to work, evaluate whether it's fast enough for you or if you need to go to a faster one that will do what you want, if perhaps will more code or more effort.
I'm more interested in doing this using Lisp than anything else. I'm just trying to figure out which Lisp suits my needs the best. Is there one that is particularly suited for this task, or is it just a matter of preference?
In particular, you've said so little about what what exactly you want to parse, what parsers you've tried, and how they haven't suited your needs that I have no way of making further suggestions.
I'm just asking in general for the most part. I have very little planned at the moment.
I've done a little bit of work with parsing, but I'm somewhat new to lisp. And it's a bit difficult to choose between scheme, clojure, common lisp, and arc. The thing that I'll most likely spend most of my time doing with it is parsing and writing toy interpreters, so focusing on the parsing libraries available seemed like a good approach.
