Suggestion for making s-expr more readable


#1

HTMLBars is a thing which will soon be with us, and along with it will be full sexpr support, allowing you to do something like this:

{{reverse(capitalize(firstName))}}

This is amazing, and will allow for some really interesting helper composition. A suggestion which I mentioned to @matchy yesterday was to allow an alternative form for writing the above:

{{firstName |> capitalize |> reverse}}

This might look suspiciously like filters in angular, but is not. I think the closest allegory would be F# pipelining or Haskell composition. For example in F# you could write:

let square x = 
   2 * 2

let isEven x = 
   x % 2 = 0

let result = isEven(square(5))

Or, can use the built in pipeline operator and do the following:

let result = 5 |> square |> isEven

While the pipeline operator in F# is defined for you, it’s implementation is:

let (|>) x y = 
  y x

All this might seem academic, and perhaps premature considering that htmlbars is a little ways off, but I feel that reading left to right is more readable and also approachable for beginners. Just like:

"foo".capitalize().reverse()

is more readable than

 reverse(capitalize("foo"))

#2

This was discussed over Twitter.

Pipelines only take a single argument, which is a dealbreaker for the intended valid sexpr usecases (query-params, url-for, etc). Also, I personally want subexpressions to feel a little ugly, because that will hopefully keep people from putting too much logic in their templates. We aren’t trying to complete with Angular’s template filters. We believe that transformation logic belongs in your controller code.


#3

Ugliness won’t prevent people from abusing these, especially since they won’t have to go back to the view and do extra work to create a more semantic solution. Look at PHP, it’s pretty ugly while it’s all over the markup, but people still do it.

Sub-expressions are going to get ugly, and unreadable fast. They’ll require comments, because you won’t know what it’s doing from a glance, if there is any complexity. An alternative syntax is surely something to think about.


#4

Yall should make like Emblem and write an alternate syntax that generates a Handlebars AST. It’s actually pretty darn easy to do (not easy to learn Jison for the first time, but the parser is probably the simplest part about Handlebars, and easiest to swap out).

Even before we get to sexprs there’s some ambiguities built into Handlebars which I think should go away, namely {{foo}} being ambiguous as to whether it’s a helper or a property lookup. I think I’d prefer something like {{foo()}} to explicitly mean a helper and {{foo}} unambiguously to be a property lookup, all of which is doable from just building your own parser that generates Handlebars AST. Then nested stuff would just look like {{foo(propertyLookup, bar())}}

I’m not glued to the idea of making it look JavaScripty, but I agree that ugliness won’t do a whole lot to prevent abuse, and I think the disambiguation (noted above) and the gentler learning curve of Ember would be beneficial.