In Paris too, and I'd be glad to meet some other lispers. Especially since I'm still in the early process of learning Lisp. But I guess we should find another way of dealing with IRL meetings than the forum...
The answer is that arc quasiquotation gets compiles down to scheme quasiquotation, and mzscheme's quasiquote handler understands (... unquote bar) to be equivalent to (... (unquote-splicing bar)). Since the arc compiler doesn't understand unquotes of this style, you'll only get the correct results when the expression unquoted is the same in arc and scheme - ie: it's either a literal, or it's a local variable. For example:
; this works because the local 'x in arc is compiled to 'x in scheme as well
arc> (let x 0 `(a . ,x))
(a . 0)
; this works because '+ in scheme adds numbers just as in arc
arc> (let x 0 `(a . ,(+ x 1)))
(a . 1)
; the following examples do not work
arc> (let x '(b) `(a . ,(join x '(c))))
Error: "reference to undefined identifier: join"
arc> (let x '(b) `(a . ,(+ x '(c))))
Error: "+: expects type <number> as 1st argument, given: (b . nil); other arguments were: (c)"
arc> (= x '(b))
(b)
arc> `(a . ,x)
Error: "reference to undefined identifier: x"
It's funny how a surface bug turns out to lead to something deeper in this way. I feel like Alice down the rabbit hole.
I used slightly longer examples to show the difference when the list members were unquoted. I don't understand at all why it works, because as far as I can tell, the same code branch (that maps over the quasiquoted list) is invoked in both cases.
Scheme uses #n( ... ), where n is the size of the vector.
You can see it when you create a tagged object (tagged objects are represented by a scheme vector)
arc> (annotate 'foo 'bar)
#3(tagged foo bar)
arc> do
#3(tagged mac #<procedure: do>)
But you're right of course, it doesn't have to be implementation-dependent, there are lots of other options.
The big question is whether vectors are really fundamental or "just an optimisation". Hint: the use of built-in representations for numbers and strings are already considered an unfortunate compromise for the sake of performance :)
Yeah, maybe they are just an optimization but they are definitely going to be present in production implementations and I think they should be standarized beforehand, and since they are already available in the underlying mzscheme, I think it shouldn't be too problematic to get vectors in Arc.
Again, I suggest {...} for vectors, since they stand out (so to avoid confusing them with lists) and because they remind of array oriented languages.
I'm sure there will be heated debates about the trade-offs between the "hundred-year" aspect of arc and the need to deploy reasonably fast applications. Here are some quotes from http://www.paulgraham.com/hundred.html
"Having strings in a language seems to be a case of premature optimization."
"Logically, you don't need to have a separate notion of numbers, because you can represent them as lists: the integer n could be represented as a list of n elements. You can do math this way. It's just unbearably inefficient."
So arc already deviates from the ideal minimal language; it might well deviate some more, I don't know. In a perfect world, the underlying VM should be able to figure out the most efficient implementation for each particular list you want to represent, and we would never need to bother ourselves with such details.
For comparison, "primitive types" in java are a performance compromise that (a) seriously mess up the language, and (b) are less and less relevant with each iteration of Moore's law.
Notwithstanding any of the above, I have shamelessly used
(mac fpush (thing place) ; a very primitive, naive, fast 'push
`(assign ,place (cons ,thing ,place)))
because the standard 'push uses 'atomic-invoke internally which slows some things down intolerably. Hence ... heated debates.
The only problem with using standard array notation for arc is that [] are already tied up for anonymous functions.
However, I think that too much syntactic sugar like this will end up damaging arc. Partly due to aesthetic reasons, but mostly due to the fact that each user has a different view on aesthetics, and adding too much will just exacerbate the "everyone has their own version" problem.
hmm, come to think of it, I've never used my table literal syntax {...} myself in a program. I wrote it so that I could write out and read back tables, which I use all the time, but that would work just as well with some long syntax like (literal-table k1 v1 k2 v2 ...) which doesn't use up precious syntax characters like { or #{.
should fix the ant config issue. On a mac, I think ant-optional comes with the Developer Tools. I should add this to the readme, thanks for pointing it out.
what color theme are you using?
On the spiral app? "theme" is too dignified a term for my crude CSS :) ... I found white dots on a dark background were easier to look at, so I set up the rest of the page in a similar way - dark bg, bright text. Did I understand your question correctly?
Yay, I've solved the ant problem emerging some stuff related to the ant package, thanks for pointing that out :D
I'm excited about having java libs available in arc, although it would be nice to have an obvious way to disable tests on startup (now that I know it's fully functional I would like to speed the initialization up).
About the color theme: I meant the color theme used in the arc code. I bet you took those colors from an editor. Anyway, it doesn't matter at all..
Oh, the syntax highlighting, yes, welder (arc editor that comes with rainbow) can htmlify arc code so that it's easy to paste into a blog or other web page; then it's just a matter of a little CSS to decide what colour you want for different kinds of tokens.
You can just comment out the (run-all-tests) line in rainbow-libs.arc, but you're right, it should be optional somehow.
Let me know how you get on with accessing java libs, I've tried to make it as simple and concise as possible, so that your code still looks like arc code and not some outrageous contaminated half-blood hybrid monstrosity ...
I don't see how to inject request-scoped variables - it seems you can only call functions in the global namespace. In other words, how would you render
<span>hello, @(current-user)</span>
for multiple concurrent users?
A separate, and totally subjective, observation: one advantage of having prs all over the place is that output gets sent directly to the client, rather than getting buffered on the server (caveat: depending on how the stream is implemented I suppose). Writing to a string and then printing that string might be more resource-intensive; only an issue for high-volume sites though. The big win I've had with prs all over the place is that when something goes wrong (and arc isn't always very helpful when something goes wrong), you can "view source" in your browser and see where output stopped, and then hopefully make a guess as to where the error is in your code.
