arc> ([(prn "You entered " _)] 34)
You entered 34
Error: "...urces/arc/ac.scm:974:33: arity mismatch;\n the expected number of arguments does not match the given number\n expected: 1\n given: 0"
Do you see something different? I think your defop expression is also incorrect. It just happens to have the right side-effect before it runs into the error. You probably have errors at the server -- that aren't visible on the browser.
arc> ([(prn "You entered " _)] 34)
You entered 34
Error: "car: expects argument of type <pair>; given ()"
That's good investigation. Note the work described in this thread uses Arc 3.1, not Anarki.
Btw do you mean there's something wrong with defop, or that the example I wrote is incorrect? I had gotten that example from: http://arcfn.com/doc/srv.html
(Once you resolve this issue I'd also recommend switching to the Nu branch described in the above link. It's a much more clean and modern implementation.)
Look for votejs* in news.arc, how it's defined and where it's used. You can insert arbitrary javascript by similar means, including the analytics code.
Note though, while votejs* may be appropriately placed in the page header section, my understanding is that you want your google analytics script tags to occur after your body section (or at the end of your body section) such that the page display doesn't have to needlessly wait.
"I wonder how the pursuit of this feature could impact the design of a language's macro system."
Whoa, how do you mean?
One idea I've been thinking about a lot is to attach metadata to code. We can do a lot to code (pretty-print, optimize, ...) besides just eval it, and metadata might help with those without affecting eval.
My favorite use for this idea is to give functions levels:
This can be used in a variety of ways by different tools. You could flag as errors any calls from a lower to a higher level, so that level 3 functions could only call functions in levels 1-3. You could tell tracers to trace everything until level x, not below. You could tell debuggers to automatically step past calls below level x and step _into_ calls above that level. In gdb I often accidentally hit 'next' when I meant 'step', and now I have to restart and laboriously try again from scratch.
You could syntax-highlight calls within a level to be more salient to calls to lower levels. We've all seen open source projects with this structure.
void main() {into
... // lots of option parsing crap
if (doSomething()) { // the actual app code
... // more crap
}
... // more crap
return -1;
}
Here wouldn't it be cool to be able to highlight the doSomething() compared to all the other calls?
In general, syntax highlighting sucks[1] because we simply highlight the things it's easiest to infer. Metadata might help reduce the inference burden and open up new uses for color.
If we syntax-highlight (withs ...) this way, since it expands into several (fn ...) forms it'll give a different color to each of its variables. But that's assuming we're able to perform some amount of macroexpansion frequently enough to be useful as the programmer edits, and it also assumes we can relate the original syntax to the transformed version returned by the macro.
It would be interesting to see a macro system tailor-made for purposes like these. Some hygienic macro systems might already apply, but I wonder what the options are here. I think Reactive Demand Programming would be an effective ingredient for this kind of incremental program visualization, but that's not a complete plan on its own.
Fun fact: if you used boxes, it would be really easy to associate the "withs" form with its expanded form, since the boxes would be the same.
The Nulan IDE already incrementally macroexpands as you're typing, and syntax-highlights boxes different colors depending on their scope. So this would be fairly trivial to add in.
After playing with it some more, I'm finding that this actually works better in arc than in wart. In wart perhaps I should require parenthesizing it differently:
(iflet x ((...) :satisfies f)
'branch1)
Otherwise it interacts poorly with paren-insertion. Things like this with multiple branches:
iflet x 2+3 :satisfies even?
x+1
3+4 :satisfies even?
x+2
