Rich Hickey: extensible data notation

Re:Rich Hickey: extensible data notation by jcromartie on Friday September 07, 2012 @07:39AM (#4488571)

How so? Prefix notation reads left-to-right nicely when you are dealing with verbs. Boolean logic is less natural, but also makes up much less of my programs (especially when using functional patterns like predicates, map, reduce, filter, etc.).

I also think that while Boolean expressions in Lisp are less natural than "this AND that OR another", they are clearer when they get large (with good formatting of course).

[ Parent | on HN ]

Re:Rich Hickey: extensible data notation by jahewson on Friday September 07, 2012 @10:09AM (#4489098)

In English we say 1 + 2 * 3 as "one plus two times three":

     1    +   2   *     3
    one plus two times three

But in Lisp when read naïvely left-to-right this becomes "times add one two three", which is nonsense in English.

     (*    (+  1   2)   3)
    times add one two three

Most people cite "lots of brackets" as their reason for disliking s-expressions, but I think the unfamiliar ordering is a less superficial criticism. Of course, for those of us manipulating ASTs they're very natural, because we see language as trees.

[ Parent | on HN ]

Re:Rich Hickey: extensible data notation by randallsquared on Friday September 07, 2012 @10:21AM (#4489172)

But in Lisp when read naïvely left-to-right this becomes "times add one two three", which is nonsense in English.

So, "the product of the sum of 1 and 2, and 3"? Reads fine in English, as long as you refer to the results instead of describing what to do. :)

[ Parent | on HN ]

Re:Rich Hickey: extensible data notation by Scriptor on Friday September 07, 2012 @11:00AM (#4489411)

People always mention the infix operators, but really, how often do you come across them in your code? Unless you're working on something highly mathematic, it really isn't that big of a deal. Otherwise, sexprs visually are a matter of rearranging parentheses for basic function calls.

    (function1 (function2 1 2 3))

    function1(function2(1, 2, 3))

There is no difference in the way we read the first over the second.

[ Parent | on HN ]

Re:Rich Hickey: extensible data notation by sbmassey on Friday September 07, 2012 @11:40AM (#4489628)

When you consider that infix operators include '==', '!=', '<' and '>', I suspect that most code uses them quite a lot.

[ Parent | on HN ]

Re:Rich Hickey: extensible data notation by jcromartie on Monday September 10, 2012 @10:12AM (#4499829)

I should have said simple math and boolean logic.

Of course 1 + 2 * 3 is more familiar that way, vs the Lisp way. But you have the Lisp way wrong (unless your example was Smalltalk)... it would be:

    (+ 1 (* 2 3))

Which could be read left-to-right as "sum 1 and the product of 2 and 3".

Also, most math functions in Lisp are variadic. So if you have this in infix:

    x + y + z + 1
    // x plus y plus z plus one

You could do it in Lisp as:

    (+ x y z 1)
    ;; sum x y z and one

There are plenty of cases where an algorithm is naturally expressed as a map or a reduce, where infix or prefix has nothing to do with it. I don't find myself using a lot of the kind of math that would be better in infix.

It might even be useful to give math operators new names in Lisp, because of the way that things like < > = == are a bit awkward when read as their equivalents in infix. They are all variadic, after all.

Compare:

    (x == 10 && y == 10) && (x < y && y < z && z < 100)

Vs.

    (and (== x y 10) (< x y z 100))

That's already an improvement, but the reading is strange. So what if we alias those operators?

    (all-true? (same? x y 10) (ascending? x y z 100))

I don't know if I'd actually use those names, and I don't think I would do this in code, but you get the point. You can even tell how a list of numbers is sorted in Lisp by simply doing:

    (apply < nums)

[ Parent | on HN ]

Re:Rich Hickey: extensible data notation by sixbrx on Friday September 07, 2012 @12:44PM (#4489966)

"Add 1 and the product of 2 and 3"

"Multiply the sum of 1 and 2 with 3".

[ Parent | on HN ]