In the table describing the different defop macros, you have two identical column titles (Headers + Redirect). Shouldn't the defopr column title be something like "HTML + Redirect" or just "Redirect"?
First, thanks for catching my errors. I appreciate your comments.
As far as identical titles "Headers + Redirect" for defopr and defopr-raw, I'll take your suggestion and change defopr's title to "Redirect", even though the truth is more complex. The way they work:
defop: takes req as argument, body prints HTML
defop-raw: takes (stream req) as arguments, body prints headers, blank line, HTML
defopr: takes req as argument, body prints headers, returns (not prints) redirect path
defopr-raw: takes (stream req) as arguments, body prints headers, returns redirect path
Everything seemed straightforward between the plain and the -raw macros, until I realized that defopr and defopr-raw both let you modify the headers. So the only difference is defopr-raw uses an extra stream argument, which hardly seems worth a separate macro.
So if I were in charge of Arc, I'd get rid of defopr-raw and arformh, and I'd drop the stream argument from defop-raw.
This may be a longer answer than you were looking for :-)
Nope, not too long, the more information the better. Thanks for the reply, I definitely appreciate the extra info. Keep up the good work, the arcfn site is a godsend for anyone learning Arc.
I just noticed, as I was reading over the srv.arc documentation, that you have a bad link in the section where you create a very simple form and form handler. Your link for the html.arc documentation is http://arcfn.com/html.html when it should be http://arcfn.com/doc/html.html--you're just missing the doc directory in your URL.
kens posted a comment to his submission of the Arc web server documentation giving this URL as well, but I wanted to make sure that this URL made to the front page of the Arc forum, rather than just an addendum to a previous post just in case someone is interested in one but not the other.
Awesome, this is exactly what I was looking for. I've been slowly working my way through the blog.arc and news.arc examples while also reading through srv.arc and app.arc to fully understand everything that is happening in each and these writeups should be just what the doctor ordered. I've been using/reading your site extensively since you first starting posting to it and its been an absolutely invaluable resource to me in my studies.
I'm curious though, you seem to have a definite interest in Arc, but are you also a fan of YC News, and if so are you attending the startup school on the 19th? The reason for my query is that I'll be attending and I'm looking forward to meeting quite a few of the contributors to both communities. Hope to meet you there, if not, and if you reside in the bay area, maybe we should work on getting some type of Arc enthusiasts meetup sometime soon? Ping me if you're interested in either--you can, of course, find my email address with my profile.
Either way, congratulations on an excellent site and keep up the good work.
Thanks for your comments on my documentation. Since your email address is hidden, I'll respond here. (One of the mysteries of news.arc is that the email address you enter in the profile form is not displayed to the public, even though it looks like it would be. You need to put it in the "about" field, as in my profile.) Yes, I've been following YC News since it started, but only as a reader. No, I'm not attending startup school. Yes, I reside in the Bay Area.
Crap, never realized that news.arc hides the email. Anyway, I just added a little blurb about myself and my email address to my Arc forum profile. Thanks for posting back and pointing out my obviously poor assumption.
Also, thanks for reading over my little gotchas that I found in the srv.arc documentation and updating them so quickly on your site. I hope the comments helped out. I'm just about to sit down with the app.arc docs for a bit of enjoyable reading before bed :-)
Since you live in the Bay Area, how would you feel about getting some type of an Arc enthusiasts meeting together? If it sounds interesting maybe we can set something up in meetup.com.
I'll be attending. I don't know how much I consider myself an "Arcster", but I would be more than happy to meet up and talk about Arc, Lisp, startup ideas, etc.
I'd love to see regular expressions in Arc, but just like my comment on infix notation, I don't think it needs to be part of the core language. A module system is already in the list of candidates and I believe with a good module system, regular expressions could be added to the language by an outside and benevolent hacker or by the core team (i.e., PG and RM) as an included module rather than as part of the Arc language itself. By the same token, I would love to see of the code now (e.g., the app.arc, srv.arc, and html.arc) refactored into modules once the system is complete.
As an aside, both me and raymyers have written basic module systems.
The hardest part (which we haven't built yet) is macros, both private in the module, and macros defined by the module for use by external code/other modules.
I would say the first implementation is in MzScheme for two reasons, both related to the design of scheme and the stated goals of Arc.
First, Scheme was designed to be a very pure dialect of Lisp. In other words, it is trying to be a minimalist language with only what is absolutely needed in the language itself. Until only recently (i.e., before the ratification of R6RS) the language specification for Scheme was around 30+ pages whereas the spec for CL numbered several hundred pages (I believe over 500 pages at least). One of PG's stated goals was to create a language built on axioms, thus he wants a very simple language very akin to the ideas behind Scheme.
The second reason, as I see it, is that Scheme supports continuations natively which makes certain types of applications (i.e., web applications) very easy to write--its no wonder that the main examples given to date have been web based applications all using continuations to share state between rendered pages.
Finally, as for why MzScheme, well, its well supported, very portable, speedy, has plenty of available libraries (using a CPAN-esque system), and overall its probably the best Scheme dialect available. (Please, no flaming here, I know others may be better in certain areas, but overall, MzScheme probably has the greatest combination of advantages and the lowest barrier to entry of all the Scheme implementations out there.)
I wholeheartedly agree with your suggestion that implicit currying be added to Arc. Currying was always one of those things that I felt was missing from Lisp, especially since it was based on lambda calculus from the beginning. Also, combining currying with composition provides tons of flexibility for creating new functionality in the language, just look at what all can be done with it in Haskell.
No, please don't add a library function for infix operations. I don't think it adds anything to the language other than clutter, and it becomes basically a crutch for those new to lisp that will just make it harder for them to transition to the lisp way of thinking.
