1. String operations are costly, printing to stdout is not. ie. if I need to run a function to generate some numbers, dumping them at the right time to stdout has very little overhead, having to weave them within a string operation costs so much more.
2. There's a benefit having a web server that pushes changes out to the browser incrementally via stdout. The user doesn't have to wait for the entire operation to complete to see the results. ie, what if the last half of your server operation, provides no output for half of your users?
3. Adding on to #2, for troubleshooting and iterative development purposes, it's nice to see a portion of the output within your browser to see how far a long your operation got, results wise, before it hit an error.
Sounds like a case of sacrificing expressiveness for performance. Somehow I think this goes against the design principles of arc.
For #2 and #3, the output has to be so huge before you reap this benefit. Most apps don't have this property, and if they did, I'd think there's a deeper design problem. Such problems can be better solved using asynchronous javascript requests (aka ajax).
> For #2 and #3, the output has to be so huge before you reap this benefit.
I think it's, more so, a case of how complex your code is rather than how big your output is. I can have 200,000 lines of code that outputs 20 small numbers. Knowing it hit the 8th number and what that number is can be huge for both a user and for development.
Also - maybe it's just me, but having partial output has helped me with 20 lines of code and very little output.
> Sounds like a case of sacrificing expressiveness for performance.
Also - maybe it's just me, but I've been spending most of my time with Clojure, where the Ring web server requires a string for an output. I found my code became less expressive than arc.
So, for Clojure, I actually wrote my own html framework to mimic arc's functions that write to stdout, then just put a big wrapper on it at the end: (with-out-str (println "stuff")). Next I plan to see if I can hack Ring@Jetty to pipe the output too.
Kinda funny, I went to Clojure and did the opposite of you. :)
So I gave it another whirl and here's my attempt to capture the essence of you're problem:
For example you would like to do this:
[1] arc> (spanclass "links"
(string "use this link:"
(tag (a href "http://mydomain.com/the-place-to-go") "here"))
And have it return this:
<span class="links">use this link:<a href="http://mydomain.com/the-place-to-go">here</a></span>
and your first attempt might be something like this:
[2] arc> (spanclass "links"
(pr:string "use this link:"
(tag (a href "http://mydomain.com/the-place-to-go")(pr "here")))
only you find it returns the wrong results:
<span class="links"><a href="http://mydomain.com/the-place-to-go">here</a>use this link:</span>
so now you're probably thinking by having functions return strings like this:
[3] arc> (tag (a href "http://mydomain.com/the-place-to-go") "here")
"<a href=\"http://mydomain.com/the-place-to-go\">here</a>"
then the original function [1] would have worked.
Instead, with arc, you need to approach your code differently. You need to think about the timing of when things are happening rather
than having available 'string-things' that you can compose by nesting your functions.
So with arc [1] needs to become [4]:
[4] arc> (spanclass "links"
(pr "use this link:")
(tag (a href "http://mydomain.com/the-place-to-go")(pr "here")))
<span class="links">use this link:<a href="http://mydomain.com/the-place-to-go">here</a></span>
Am I capturing it correctly? Does this answer your question on how I compose my functions?
I've re-looked into your original questions, in an attempt to provide a meaningful response, but I find the scenario's are not concrete enough.
For example I find the re-arrange function a little vague.
i.e. could you not:
(def something (a b c)
(output b c a))
Could you provide an real-case like example where you feel you can show a clear difference? For, I found, even your row example can easily work with stdout inside a function rather than using pg's macro. ie. Not liking how some of the existing functions/macros work doesn't mean string weaving is the answer.
And row is a pretty crappy example, even when I built my Clojure library, I ditched pg's implementation and went with a more useful implementation, yet it still uses stdout. You have to remember that pg only built those macro's to support his specific cases in his HN app.
Also, for > Too many tricks. Too clever.
Well it's a library, it's not expected you're crafting macros for your regular coding. I mean there's only so many HMTL cases you need to handle right? So if the library is complete, providing (macro's or not) succinct code and faster results, then it's probably good to have - tricks inside or not.
