Would it be worth implementing 'def directly? This would give a lot more functionality right away. This could be temporary until macros are implemented.
Possibly. There's a bunch of "macro" transformations in xe.arc, possibly I'm just a bit too lazy to think. However I don't like depending on those transforms, I want to do it "properly"
Unless I've messed up the parentheses, those should be equivalent. I think the problem is that expand-metafn-call is being called by setforms when it shouldn't be. (Or alternatively, it shouldn't give up and die.) The example works if you first turn expand-metafn-call into a nop:
No, it was a mistake by me: Anarki works similarly to ArcN in this case. Sorry for muddying the waters. ^^
The problem appears to be that the current '= was meant for use with the older ssyntax, which supports only : for composition. I'll take a better look maybe later, I'm just home from work, cooling off (very hot in the philippines right now)
The "invert" thing is really confusing, I didn't add docstrings to all the '= related stuff because of that. Me, I say refactor '=. LOL
Edit: Fixed on the git.
(def metafn (x)
(set x (ssyntax x))
(and (acons x) (in (car x) 'compose 'complement)))
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.
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.
Actually asv doesn't even support that. It has jfnurl* which is called an asynchronous request, but really it's just a normal request with the result thrown away. The client still blocks for the duration of the request, so nothing is really asynchronous. I suspect asynchronous communication is a not-yet-implemented feature.
But to answer your question, it depends what you mean by two-way async. HTTP only supports requests from the client to the server, so you need to use something like polling, Ajax, HTTP server push, or Comet (see http://en.wikipedia.org/wiki/Comet_%28programming%29). I don't think there's anything in srv.arc that would prevent a persistent server connection, if threadlife* is increased from 30 seconds. (A thread per persistent connection would eventually have scaling issued, though, I think.)
I took a closer look at using Ajax with Arc. It turns out to be pretty easy, thanks to script.aculo.us. I've written details at http://arcfn.com/2008/04/ajax-and-arc.html - please let me know if it works for you or not.
I've substantially changed my example, so it now fetches country data using Ajax.
The biggest problem with using Ajax is that the Arc web server doesn't support .js files, which is a big oversight for a web-targeted language. Consider this a bug report suggesting support for .js static files. (Really the design should allow arbitrary static files with arbitrary mime-types, rather than hard-coding the list.)
If anyone has Arc running on a public web server and wants to run the Ajax example, let me know and I'll add a link to your site from my page. (My hosting isn't suitable for running Arc.)
Actually, the Anarki supports exactly what you want with static files: a root directory for static files, and a table mapping extensions to mime types for them.
And there's a typo on your page: you don't close the code tag around "/getcontents?field=population&name=value", so the rest of the page is in monospaced font.
That said, your site is consistently fantastic, and I find it amazingly useful. Please keep it up!
One question I have after reading that article: why doesn't Arc have keyword parameters? The article makes keyword parameters sound like the best thing since sliced bread, so it's a bit surprising that they aren't in Arc.
My guess on why the web server uses CPS rather than native continuations is that web pages inherently have many branches (e.g. multiple links), and that's easier to program with multiple continuation functions than with first-class continuations. (At least I don't see an easy way to do it with first-class continuations.)
I would guess that pg is hoping hash tables and alists can fill the roles that keyword parameters otherwise would be used for... "need keyword parameters? have the function accept an alist."
Same with defop. Accessing the GET/POST arguments to an operation is done via (arg req "foo"). It would have been worlds nicer if I could just define something like
I have wondered a few times why arc doesn't have keyword parameters. It is one of my favorite features in Gauche scheme. Other great features are clos like object system, module system and a thread system that supports preemption which is hard to find in scheme implementations.
In addition, I think keywords would make the library far more transparent. Right now I still have to root around and figure out what the heck I'm supposed to pass in.
The server will need to specify arbitrary content-types eventually, and that's way easier than supporting xhtml, so specifying an arbitrary MIME type seems like the obvious solution to me. Also, the official MIME type for SVG is image/svg+xml, so trying to use xhtml both for SVG and HTML seems like a fragile hack.
Thanks for the great replies- I was actually also wondering how the RSS feed in news.arc deals with this... Is there some hack in there for overriding the Content-Type or are web browsers more forgiving for RSS feeds? I couldn't find any specific handling in news.arc for this issue on inspection the other day...
Firefox's Live HTTP Headers plugin tells me that news.ycombinator.com/rss has "Content-Type: text/html; charset=utf-8". I imagine RSS clients are not very strict about what they accept.
Yes, I think UTF-8 would be a disaster with modifiable strings. mzscheme uses UCS-4 (UTF-32) internally, and that would be the simplest approach. If you are willing to ignore Unicode characters > 65536, then UCS-2 would be okay with half the memory usage. When you talk about a character represented by several code points, are you talking about Unicode surrogates for characters > 65536? (Oversimplifying, two UCS-2 surrogate characters are used to represent one Unicode code point > 65536.) I think you'd be better off with UTF-32 than UTF-16 and surrogates, as surrogates look like a nightmare that you'd only want if you need backwards compatibility, see Java's character support: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Character....
Oh, Unicode combining characters and normalization. I classify that as "somebody else's problem." Specifically, if you're writing a font rendering engine, it's your problem. If you're writing an Arc compiler, it's not your problem. If you want complete Unicode library support in your language (like MzScheme's normalization functions string-normalize-nfd, etc.), then you just use an existing library such as ICU, and it's not your problem. ICU: http://www-306.ibm.com/software/globalization/icu/index.jsp