Agreed. I find the code in html.arc to be very confusing. When I look at it, I tend to feel either critical of the code or that pg must be way smarter than me.

I posted more-or-less the same question a few months ago [1]. From shader's comment there:

> By printing directly to stdout you don't get to have as many tail calls, but you don't have to worry about much complexity when it comes to aggregating output or adding new functionality. A simple pr is all it takes to add output, and you don't need to worry much about context.

This relates directly to your closing question:

> Wouldn't it be easier if everything just returned strings and then these strings were concatenated together?

If everything returns strings, it's nontrivial to make your functions composable. You can't stack them on top of each other unless they take strings as their arguments as well. But then you can only stack them on top of each other, not treat them as user-facing functions. So you have to keep at least a couple groups of functions with strictly different roles. Perhaps you've already thought of this.

---

If so, then this way of building html is probably a performance hack.

> If everything returns strings, it's nontrivial to make your functions composable.

Really?

> You can't stack them on top of each other unless they take strings as their arguments as well.

Exactly.

Isn't that how all html templating schemes work? A python example is Jinja macros[1]

Composing html elements as functions that take strings and return strings is the only way that makes sense to me.

> But then you can only stack them on top of each other, not treat them as user-facing functions. So you have to keep at least a couple groups of functions with strictly different roles. Perhaps you've already thought of this.

I'm not really sure what you mean.

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?

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.

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"))

  <span class="links">use this link:<a href="http://mydomain.com/the-place-to-go">here</a></span>

  [2] arc> (spanclass "links" 
             (pr:string "use this link:" 
               (tag (a href "http://mydomain.com/the-place-to-go")(pr "here")))

  <span class="links"><a href="http://mydomain.com/the-place-to-go">here</a>use this link:</span>

  [3] arc> (tag (a href "http://mydomain.com/the-place-to-go") "here")
  "<a href=\"http://mydomain.com/the-place-to-go\">here</a>"

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>

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))

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.

It doesn't do much, but builds a base for writing composable html elements.

It reuses the 'tag macro from html.arc as a base (no need to rewrite that part) but captures the output in a string (using 'tostring, of course). Thus the 'btag function becomes the base to build and compose html tags.

The few extra functions included serve as example of how to compose tags.

For example, 'hstack stacks its arguments horizontally using table columns.

'prn expressions are interspersed in between code blocks. They serve as examples, and I was using them for debugging.

    (def listify (arg)
         (if (acons arg) arg (list arg)))

    (def btag (tagspec content)
         "Low level tag function, takes two arguments: tagspec and content
         content can be a list or an atom"
         (let content (listify content)
           (tostring (eval `(tag ,tagspec (pr ,@content))))))

    (def element (tagspec . content)
         "Simple element, just a convenience wrapper around btag"
         (btag tagspec content))

    ; alias
    (= e element)

    (def section content
         (btag 'div content))

    (def inline content
         (btag 'span content))

    (prn (element 'div "Hello"))
    (prn (element 'div "Hello " "World"))
    (prn (element 'div "Hello" (element 'span "World")))

    (prn (section "Hello" (inline "World")))

    (def vstack args
         "Stack things vertically"
         (string:map section args))

    (def hstack args
         "Stack things horizontally"
         (btag '(table cellspacing 0 cellpadding 0)
            (btag 'tr
               (map [btag 'td _] args))))

    (prn "Testing vstack and hstack")
    (prn (hstack "hstack" (section "hello") (inline "world")))
    (prn (vstack "vstack" (section "hello") (inline "world")))

    (def kls (classes . content)
         "Generates a div with the classes given in 'classes'"
         (let classes (string:intersperse " " (listify classes))
         (btag `(div class ,classes) content)))

    (prn (kls 'big "Hello " "world"))
    (prn (kls '(small big) "Hello " "world"))

- almkglor's whtml.arc: https://github.com/nex3/arc/blob/arc2.master/whtml.arc

- jazzdev's sml.arc: https://github.com/nex3/arc/blob/master/lib/sml.arc

- my html.arc: http://arclanguage.org/item?id=12010

> that's why I'm considering playing with coffee-script/node.js next

Yes. That's where I'm at.

I think CoffeeScript is wonderful. If only it had macros we'd be set. I've made a bit of progress on that front (i.e. https://github.com/evanrmurphy/SweetScript) and will post about it soon.

Working on this: https://github.com/fab13n/parsec-coffee-script

It is.

I'm not sure about macros, but having something similar to s-expressions would be nice.

Yes, s-expressions too. But what aren't you sure about regarding macros. (And what do you see as the benefit of s-expressions besides macros?)

> The only still kinda holding me back is html templating. Doing them in {{ templates }} like that was a horrible experience with Django.

For this specific problem (html generation), the advantage of s-expressions is you can build a tree with it, with minimum boilerplate. For example, the closing tag is just a ')'. Also, again for this specific problem, because we're mostly just generating strings, just having functions would probably suffice.

> Are you referring to http://mustache.github.com/ ?

I'd love for you to use it and to have your feedback. Of course, it's still unstable, poorly documented, etc. Please open lots of issues and send me emails to the tune of "Why the hell <x>?". I'll always try to give you a personal response.