Harlan: A new GPU programming language (The H) [LWN.net]

The H introduces a new Scheme-based programming language for GPUs. "Scheme serves as the basis because it has history at Indiana University, where some previous experience of building Scheme-based compilers has been gathered. [Erik] Holk has also gained GPU programming experience working with the Rust programming language; unlike Harlan, however, this language works much closer to the hardware. Holk reveals that the name Harlan comes from a mishearing of fried chicken icon Colonel Sanders' first name, Harland, and this association is also why all the file extensions for Harlan programs are .kfc."

to post comments

Harlan + readable? Let me know!

Posted Jul 4, 2013 18:34 UTC (Thu) by david.a.wheeler (subscriber, #72896) [Link] (55 responses)

Since Harlan is based on Scheme, it should be possible to use the "readable" notation extensions as described in the Readable Lisp S-expressions Project site. E.G., "{a + b}" could be an abbreviation for "(+ a b)". If anyone does so, please let me know!

Harlan + readable? Let me know!

Posted Jul 5, 2013 11:40 UTC (Fri) by heijo (guest, #88363) [Link] (19 responses)

Awesome, why didn't this exist earlier?

Parenthesis hell and prefix ops are what makes Lisp languages unusable in practice.

Harlan + readable? Let me know!

Posted Jul 5, 2013 12:39 UTC (Fri) by renox (guest, #23785) [Link] (8 responses)

>Awesome, why didn't this exist earlier?

Because some don't like it when they write {1 + 2 * 3} and the computer answers 9 instead of 7?
The parenthesis aren't readable but at least they work as expected..

Harlan + readable? Let me know!

Posted Jul 5, 2013 13:08 UTC (Fri) by sbakker (subscriber, #58443) [Link] (1 responses)

> Because some don't like it when they write {1 + 2 * 3} and the computer answers 9 instead of 7?

That expression is not a valid curly-infix expression, see http://sourceforge.net/p/readable/wiki/Solution/, point 1, sub 3:

all even parameters are the same symbol (aka eq? or eq). It maps to "(even-parameter odd-parameters)". E.g., {n <= 2} ⇒ (<= n 2), and {7 + 8 + 9} ⇒ (+ 7 8 9).

Harlan + readable? Let me know!

Posted Jul 5, 2013 13:28 UTC (Fri) by renox (guest, #23785) [Link]

>That expression is not a valid curly-infix expression

I don't think you're correct, in the page you've linked, it is written:
- Other infix lists are mixed and map to "($nfx$ parameters)". E.g., {2 + 3 * 4} ⇒ ($nfx$ 2 + 3 * 4)
- By intent, there is no precedence; just use another list. E.g., {2 + {3 * 4}} ⇒ (+ 2 (* 3 4))

So it is a "valid" curly-infix expression, just one with a "surprising" result.

Infix and precedence

Posted Jul 5, 2013 15:31 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link] (5 responses)

Historically many "infix" systems for Lisps also build in some read-time precedence system, but this turns out to be problematic for Lisps.

Instead, curly-infix does not force any specific precedence system. If you want precedence, you can get it by defining $nfx$ - which is more flexible.

In practice, we’ve found that simple infix is all that’s needed most of the time in Lisp-based languages Just use additional braces, like "{{1 + 2} * 3}" or "{1 + {2 * 3}}". There is experimental evidence that even in languages like C or Java with precedence, developers (1) rarely use precedence rules and (2) often apply them incorrectly. See the link above for more info.

Infix and precedence

Posted Jul 5, 2013 15:37 UTC (Fri) by renox (guest, #23785) [Link]

Oh, I fully agree that precedence isn't very useful and that developers should use parenthesis instead, but I think that I misunderstood the $nfx$ thing, it's not very well explained either..

Infix and precedence

Posted Jul 5, 2013 16:33 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

There is experimental evidence that even in languages like C or Java with precedence, developers (1) rarely use precedence rules and (2) often apply them incorrectly.

Quite so. Being keenly aware that at least one of C's precedence rules is demented, I don't even rely on the parts that conform to traditional arithmetical precedence rules - I write a + b * c as a + (b * c).

Infix and precedence

Posted Jul 5, 2013 18:09 UTC (Fri) by viro (subscriber, #7872) [Link] (2 responses)

The link you are quoting claims (a) only about 1/3 of cases where parens could be omitted are omitting those and (b) about 5% of developers flunked the test.

For (a) you give no information about the dependency of those stats on project (i.e. how uniform it is, how much of that is a function of coding style conventions on given project, etc.). And in any case, refering to 1/3 as "rarely" is a bit too strong, innit?

For (b) the size of group is unspecified, the correlations between failure rates for different operator pairs not given, and no way to tell how many hadn't been paying attention to the questions/were half-asleep/drunk/from marketing.

TBH, I've seen more convincing ones from politicians...

Infix and precedence

Posted Jul 5, 2013 18:32 UTC (Fri) by viro (subscriber, #7872) [Link] (1 responses)

Gyah... I've misread (b) *and* didn't get to the paper that is presumably the primary source there (and got timeouts when trying to grab it now). As for the first part, upon more careful reading (and again, modulo not having the paper in question) it appears that the rate is no _less_ than 1/3 - in expressions with at least two binary operators, 2/3 had been fully parenthesised, which might or might not have been necessary...

Al, about to instrument sparse and try to collect that kind of information over the kernel tree...

Infix and precedence

Posted Jul 8, 2013 23:20 UTC (Mon) by david.a.wheeler (subscriber, #72896) [Link]

If you create such data I'd love to see it!

The Linux kernel was in their dataset for measuring usage (section 4: "The following subsection discusses measurements of binary operator usage in the visible source of a number of large C programs (e.g., gcc, idsoftware, linux, netscape, openafs, openMotif, and postgresql)"). But the paper was posted in August 2006; it's entirely possible that things have changed significantly since then.

That paper also doesn't present separate data for each program; it just presents the accumulated set. I'd be curious to know if there's a lot of variance. In particular, the Linux kernel may not be the fairest test. Writing a kernel is known to be especially hard, and if you're a kernel developer you're already in an elite group of developers. My guess is that all kernel developers know that "*" has higher precedence than "+"; what's remarkable is that a number of professional programmers did not know that (!!!).

Harlan + readable? Let me know!

Posted Jul 5, 2013 13:55 UTC (Fri) by heijo (guest, #88363) [Link] (9 responses)

But... would it be possible to use {} for S-expression syntax, use nothing or () for infix and add comma to separate parameters?

That would actually make it look like a normal language.

Grammar like this should work:


expr-no-infix:
 T => T
 () > ()
 (a, b, c) => (a b c) [where a, b, c is expr-no-indent]
 f(a, b, c) => (f a b c) [where f is expr-in-infix, a, b, c is expr-no-indent]
 f() => (f) [where f is expr-no-infix]
 {a b c} => (a b c) [where a, b, c is expr-in-infix]
 f{a b c} => (f a b c) [where f, a, b, c is expr-in-infix]
 f{} => (f) [where f is expr-no-infix]

expr-infix:
 a o b o c => (o a b c) [odd num of exprs, where o, a, b, c is expr-in-infix]
 o a o b o c => (o a b c) [even num of exprs >= 2, where o, a, b, c is expr-in-infix]

expr-in-infix:
 expr-no-infix
 (expr-infix)

expr-no-indent:
 expr-no-infix
 expr-infix

exprs-child: [evaluates to a list of expressions]
 a, b, c => a, b, c [if line has no indented children, where a, b, c are expr-no-indent]
 a => a [where a is expr]

expr:
 expr-no-indent
 f a, b, c \n\t u \n\t v => f(a, b, c, u..., v...) [where f is expr-in-infix, a, b, c is expr-no-indent, u, v is exprs-child]
 f a b c: \n\t u \n\t v > f(a, b, c, u..., v...) [where f, a, b, c is expr-in-infix, u, v is exprs-child]
 : \n\t u \n\t v \n\t w => (u... v... w...) [where u, v, w is exprs-child]

indentation is ignored inside () or {}

If spaces between f and (a, b, c) are allowed, this creates ambiguities in some places, but it can be resolved by specifying that the unspaced syntax has highest priority, while the spaced one lowest.

So the examples can be written:

    define fibfast(n)     ; Typical function notation
      if n < 2            ; Indentation, infix {...}
        n                 ; Single expr = no new list
        fibup(n, 2, 1, 0) ; Simple function calls

    define fibup(maxnum, count, n-1, n-2)
      if maxnum = count
        n-1 + n-2
        fibup(maxnum, count + 1, n-1 + n-2, n-1)

    define factorial(n)
      if n <= 1
        1
        n * factorial(n - 1)

    define solve-kalotan-puzzle
      lambda ()
        let
          :
            parent1(amb('m, 'f))
            parent2(amb('m, 'f))
            kibi(amb('m, 'f))
            kibi-self-desc(amb('m, 'f))
            kibi-lied?(amb(#t, #f))
          assert
           distinct?(list(parent1, parent2))
          assert
           if kibi eqv? 'm
               not kibi-lied?
          assert
           if kibi-lied?
              xor
                (kibi-self-desc eqv? 'm) and (kibi eqv? 'f)
                (kibi-self-desc eqv? 'f) and (kibi eqv? 'm)
          assert
           if not kibi-lied?
              xor
                (kibi-self-desc eqv? 'm) and (kibi eqv? 'm)
                (kibi-self-desc eqv? 'f) and (kibi eqv? 'f)
          assert
           if parent1 eqv? 'm
              and
                kibi-self-desc eqv? 'm
                xor
                 (kibi eqv? 'f) and (kibi-lied? eqv? #f)
                 (kibi eqv? 'm) and (kibi-lied? eqv? #t)
          assert
           if parent1 eqv? 'f
              (kibi eqv? 'f) and (kibi-lied? eqv? #t)
          list(parent1, parent2, kibi)

    solve-kalotan-puzzle()

    defun print.tree, (tree, &optional, depth(0))
      tab(depth)
      format(t, "~A~%", first(tree))
      loop for subtree in cdr(tree) do:
        tab(depth + 1)
        format(t, "= ~A", first(subtree))
        if atom(second(subtree))
          format(t, " => ~A~%", second(subtree))
          progn
            terpri()
            print.tree(second(subtree), depth + 5)

Which now look fully normal, with no weird {} parens or space separation of parameters.

I think this is much better than the proposed sweet expressions.

Harlan + readable? Let me know!

Posted Jul 5, 2013 14:02 UTC (Fri) by heijo (guest, #88363) [Link] (5 responses)

Actually, replace expr-infix with:

expr-infix:
 a o b o c => (o a b c) [odd num of exprs, where o, a, b, c is expr-in-infix]
 o a => (o a) [where o, a is expr-in-infix]
 o a o b o c => (o (o a) b c) [even num of exprs >= 4, where o, a, b, c is expr-in-infix]

This makes (- a - b - c) work as expected.

Auto-detection of infix, etc.

Posted Jul 5, 2013 18:12 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link] (4 responses)

Your example omits key details, such as how to determine what are infix operators. Early versions of sweet-expressions did auto-detect infix operators, but that turns out to create more problems than it solves. Then you have to memorize whatever determines what an infix operator is, and you need an escape mechanism in case you do not want to use it that way. This turns out to be remarkably error-prone. The problem doesn't occur in other languages because there's typically a fixed set of infix operators that cannot be extended, but in Lisps you can trivially create new operators, so that limitation doesn't make much sense.

After a lot of experiments trying to auto-detect infix operators, I decided that it was better to stop trying to do that, and instead make infix operator use explicit using {}. You can see some of the early "readable" discussions and related docs if you want to see more.

Auto-detection of infix, etc.

Posted Jul 5, 2013 20:04 UTC (Fri) by heijo (guest, #88363) [Link] (3 responses)

It would work like sweet expressions, except that the {} aren't required, because "infix content" is the default, and commas are the list separator.

So "a b c(d, e)" becomes (b a (c d e)) because b is the infix operator.

If you want a prefixed list instead, then you'd need to say "(a, b, c)", "a(b, c)", "{a b c}", "a{b c}" or "a\n\tb\n\tc".

Auto-detection of infix, etc.

Posted Jul 7, 2013 17:26 UTC (Sun) by HelloWorld (guest, #56129) [Link]

"d," is a valid symbol name in Scheme, so that isn't compatible.

Sweet-expressions version 0.1

Posted Jul 8, 2013 23:10 UTC (Mon) by david.a.wheeler (subscriber, #72896) [Link]

That's not bad, what you've described is basically sweet-expressions version 0.1. However, for a variety of reasons I abandoned that approach. It creates a lot of backwards-compatibility problems, and when I wrote programs in it I found that it's way too error-prone. I believe being explicit about where infix operators occur is the better approach, after trying it the other way.

I tried and abandoned auto-detection of infix

Posted Jul 8, 2013 23:24 UTC (Mon) by david.a.wheeler (subscriber, #72896) [Link]

My first version (0.1) auto-detected infix, too. I abandoned this in version 0.2; if you're curious why, see my paper discussing version 0.2. You need not agree (when does everyone agree on anything?), but I did consider this approach and after experimentation intentionally abandoned it.

Harlan + readable? Let me know!

Posted Jul 5, 2013 14:10 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link] (2 responses)

Regarding: "But... would it be possible to use {} for S-expression syntax, use nothing or () for infix and add comma to separate parameters?"

Sure, but if you swap the meanings of {} and () you'd have serious backwards-compatibility problems. Using () to surround lists means that practically all existing Lisp code works as-is.

Also, I tried adding commas to separate parentheses. They turn out to be a real pain. There are so many parameters to be passed that they create a major syntactic pain. In other languages you need commas so the parser knows to stop the infix processing; since {} already surrounds infix, they become unnecessary.

Harlan + readable? Let me know!

Posted Jul 5, 2013 15:25 UTC (Fri) by heijo (guest, #88363) [Link] (1 responses)

Yes, backward compatibility with Lisp and a language that looks like Python aren't very compatible goals.

I suppose one could have comma-separation only in the function-call syntax f(a, b, c) and leave space-separation without the syntax and outside infix expressions, but it makes it somewhat inconsistent.

Or simply an hack that if the first character in a line is ( then it's an S-expression, otherwise it's the new syntax.

Commas, python-looking

Posted Jul 5, 2013 15:49 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link]

Quick clarification: There are 3 additions from the "readable" project. curly-infix-expressions add "{a + b}" as an infix abbreviation for (+ a b), neoteric-expressions add "f(x)" as an abbreviation for "(f x)", and sweet-expressions add indentation processing. The "full" curly-infix-expression approach (defined in SRFI-105) allows neoteric-expressions inside {...}.

For more on why commas aren't used as parameter separators in neoteric-expressions, see: SRFI-105's "Comma-separated parameters".

As far as being "python-looking", though, sweet-expressions do pretty well. The draft SRFI-110 spec, which adds sweet-expressions to Scheme, has various examples. Here's an example of a sweet-expression:

define fibfast(n)   ; Typical function notation
  if {n < 2}        ; Indentation, infix {...}
     n              ; Single expr = no new list
     fibup n 2 1 0  ; Simple function calls

Most developers could figure out what that sweet-expression means, and note that you don't need a huge number of parens.

Ick.

Posted Jul 5, 2013 21:27 UTC (Fri) by jonabbey (guest, #2736) [Link] (33 responses)

Getting rid of S-expressions seems like a terrible idea to me. I'd not like to have to give up macros and other self-modifying code systems for the sake of making people who haven't properly learned the language happy. ;-/

Recursion for GPUs?

Posted Jul 5, 2013 21:29 UTC (Fri) by jonabbey (guest, #2736) [Link] (8 responses)

In any event, it's interesting that they chose Scheme to base Harlan on. Scheme tends to heavily favor recursive implementations over iteration, and I wouldn't think recursion would naturally fit GPU programming tasks.

Recursion for GPUs?

Posted Jul 5, 2013 23:36 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (7 responses)

Iteration and recursion are equivalent, you can transform either into the other mechanically so (assuming a sufficiently good compiler) it needn't make any difference to what ends up running on the processor.

In particular tail recursive algorithms (very common in Scheme programs) are really trivial to transform, it's the sort of thing they show undergraduates rather than blow their tiny minds with a serious optimisation trick in an introductory compilers course.

Recursion for GPUs?

Posted Jul 6, 2013 21:56 UTC (Sat) by dvdeug (subscriber, #10998) [Link] (6 responses)

I suspect that in any sufficiently non-trivial case, a mechanical translation is going to get you a mess. Certainly the artificial jumps that programmers go through for tail recursion don't make the case that natural code can be mechanically translated in such a way that it makes no difference. (I'm sure figuring out which recursive algorithms can be translated without a stack is equivalent to the halting problem.)

Recursion for GPUs?

Posted Jul 7, 2013 9:09 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (4 responses)

"Certainly the artificial jumps that programmers go through for tail recursion don't make the case that natural code can be mechanically translated in such a way that it makes no difference."

I'm not really sure what you were trying to say here. Is it just that you're struggling to see how this is actually done? Does it help if I tell you that the underlying hardware on a general purpose processor doesn't really have any such thing as a "stack" of stored values but is merely emulating it by reserving a large contiguous portion of memory and tracking a pointer to the top of the "stack" ?

Recursion for GPUs?

Posted Jul 7, 2013 10:39 UTC (Sun) by dvdeug (subscriber, #10998) [Link] (3 responses)

I do know how recursive functions are implemented in assembly. But if I'm looking at code written in any high-level language that supports iteration and recursion that uses an explicit stack to store subproblems, I'm going to feel that's a recursive algorithm bludgeoned into an iterative solution, hopefully because it's actually time-critical and the programmer actually tested on real hardware and compilers and found that his implementation saved a few cycles. Otherwise that's going to be a bad sign.

If you want to get the maximum efficiency out of hardware, you have to think like that hardware. Most general purpose processors do have stacks; the X86 instructions have quite a few instructions that move things explicitly to or from the top of the stack. (You can call it not a stack, but I get to point out that it's not a "pointer", either; it's a just a collection of bits that can be interpreted as a reference to memory.) If your processor doesn't support a hardware stack, then the cost of function calls can make recursive code expensive. And I stand by my statement that you didn't understand; compilers cannot magically turn complex enough recursive code into the code the programmer would have written thinking iteratively.

Recursion for GPUs?

Posted Jul 7, 2013 17:43 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (2 responses)

"compilers cannot magically turn complex enough recursive code into the code the programmer would have written thinking iteratively."

I think this just ends up with weaselling. Compilers can (and as the LLVM example linked below shows, have done for years, even for quite tricky cases) turn elegant recursive programs into fast iterative machine code. If you write lousy recursive code it will still be lousy code, but nobody claimed otherwise.

"If you want to get the maximum efficiency out of hardware, you have to think like that hardware"

Good luck with that, the hardware is very, very complicated. Most often when people say this they mean "I have this idealised fairytale processor in my head and I write programs as though I was directly emitting machine code for that fairytale processor" and the results are both more error prone and sometimes slower too. We've had several "why not just pointers?" threads on LWN where this fairytale model betrayed people, because they forgot that cache misses can turn microseconds into milliseconds and undo all your "optimisation" in a stroke.

I remember years ago my Z80 microprocessor had a manual which explained how many clock cycles it would take to execute particular instructions. For some instructions the answer was a range, like 3-8 cycles. You could thumb through the book and figure out if your "faster" machine code would actually be faster or not. Today's CPUs still provide such information, but almost always the answer is "it depends" because the CPUs have become so much more complicated.

Recursion for GPUs?

Posted Jul 7, 2013 22:58 UTC (Sun) by dvdeug (subscriber, #10998) [Link] (1 responses)

But you would have us forget that cache misses can turn microseconds into milliseconds. That some people have poor models of the hardware doesn't mean that good models of the hardware aren't useful.

I'll note that the LLVM example linked below points out that Haskell won't transform even simple recursion into tail recursion. An idealized fairy tale version of your compiler can hurt as bad as an idealized fairy tale version of your processor.

Premature optimizations, etc...

Posted Jul 8, 2013 0:57 UTC (Mon) by hummassa (guest, #307) [Link]

Anyway, the time to think the microoptimizations is not when you are *writing* the code, is when you are *testing* the code and refactoring it. This way, you write your code elegantly but if your compiler cannot do its job properly then you microoptimize it.

Recursion for GPUs?

Posted Jul 7, 2013 10:43 UTC (Sun) by oldtomas (guest, #72579) [Link]

I suspect that in any sufficiently non-trivial case, a mechanical translation is going to get you a mess

It seems compilers these days are a bit farther along. See for example here

Besides, if you want looping, all practical Schemes have loop constructs, which I would use just because they are more readable.

Whether they are implemented as tail recursive calls beneath the bonnet shouldn't make a difference to you.

Ick.

Posted Jul 5, 2013 23:00 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

As far as I can tell from reading the website for readable, it introduces new abbreviations but doesn't stop you writing normal LISP code.

S-expressions are good for you

Posted Jul 7, 2013 10:37 UTC (Sun) by oldtomas (guest, #72579) [Link] (18 responses)

"Getting rid of S-expressions seems like a terrible idea to me"

Very much seconded.

"I'd not like to have to give up macros and other self-modifying code systems..."

Exactly. LISPs introduced this incredibly powerful notion that "code == data == code". Homoiconicity. Few other languages followed along. Not only the macro system becomes infinitely more powerful than all those crippled preprocessors, templating systems, etc. but it allows playful transformation of programs into other programs. A seamless landscape between simple substitution macros and whole code walkers converting, e.g. a program into continuation passing style.

Things which look very powerful (like XSLT) are just a sad copy of what they could have been had they been done with S-expressions (ah, and they started being S-expressions: DSSSL; they were changed to this ugly XML in the hope that "web programmers" (whatever that might be) could more easily handle that. As if hiding functional programming behind an ugly façade would make it easier).

To me it's a bit depressing to see that the main issue when LISP is mentioned "this awkward parehtheses syntax". I mean: I can't really stand Python's indentation-driven syntax (it ain't even particularly original), but when discussing Python's features, that's just a minor point, ain't it?

S-expressions are good for you

Posted Jul 7, 2013 17:43 UTC (Sun) by HelloWorld (guest, #56129) [Link] (17 responses)

> Very much seconded.
The above-mentioned Readable project preserves homoiconicity, it just makes Lisp more readable.

> Things which look very powerful (like XSLT) are just a sad copy of what they could have been had they been done with S-expressions (ah, and they started being S-expressions: DSSSL; they were changed to this ugly XML in the hope that "web programmers" (whatever that might be) could more easily handle that. As if hiding functional programming behind an ugly façade would make it easier).
An XSLT program is just an XML document, and thus you can manipulate it with XSLT. How is this any less homoiconic than DSSSL?

S-expressions are good for you

Posted Jul 7, 2013 19:16 UTC (Sun) by oldtomas (guest, #72579) [Link] (5 responses)

> The above-mentioned Readable project preserves homoiconicity, it just makes Lisp more readable.

Yes, of course: I didn't expect less of smart folks coming from Lisp culture. I still prefer the simplicity of S-expressions (less impedance bumps between the structure I see and the structure the machine sees).

> An XSLT program is just an XML document, and thus you can manipulate it with XSLT. How is this any less homoiconic than DSSSL?

Sorry, I think I was unclear: of course you are right, XSLT/XML is homoiconic (last week I was playing around with Schematron, which uses XSLT to generate an XSLT -- and then transformed the resulting report with XSLT to generated an annotated version of the original XML :). It's just unnecesarily ugly, IMHO.

The point I was trying to make is that it inherited precisely this cool property from a Lisp.

S-expressions are good for you

Posted Jul 8, 2013 4:56 UTC (Mon) by wahern (subscriber, #37304) [Link] (4 responses)

The point of XSLT was as a standard representation for code generators and abstract program editors. The idea was that there was so much software out there reading and writing HTML, why not standardize on it for all data interchange (XML), including code (XSLT), in that domain.

There are good WYSIWYG XSLT programming editors, just none that are open source AFAIK. Sadly, XSLT never really caught on, so we're left with a few expensive proprietary products and the nascent FOSS tools from before people lost interest.

Actually, XSLT 1.0 works perfectly well in all modern browsers. I use it for all my personal websites because it allows me to keep using a simple, static web server without worrying about the latest PHP or Ruby exploits, or having to compile anything ahead of time. In terms of web page templating, nothing works better. Existing projects keep getting progressively closer, but like Zeno's Paradox never quite reach it. And eventually people lose interest in each project and begin the long process of emulating it all over again.

Happily

Posted Jul 8, 2013 11:33 UTC (Mon) by renox (guest, #23785) [Link] (3 responses)

> Sadly, XSLT never really caught on,

Sadly?? I had the misfortune of having to use XSLT and I can sumarize easily my reaction: "kill this abomination with fire".
A poor language with an awful syntax..

Happily

Posted Jul 8, 2013 12:46 UTC (Mon) by hummassa (guest, #307) [Link]

IMHO (I have to deal with it from time to time) it's "a nice and powerful language with a hideous syntax"...

Happily

Posted Jul 12, 2013 14:23 UTC (Fri) by epa (subscriber, #39769) [Link]

It is at least a rigorously specified and standardized language, unlike 99% of templating systems.

Happily

Posted Jul 18, 2013 16:47 UTC (Thu) by nix (subscriber, #2304) [Link]

I concur, having written tens of thousands of lines of XSLT to do unspeakable things with financial protocols. I ditched most of it and went procedural in the end: it was a little longer, but *much* easier to comprehend. Reading XSLT for too long tends to end up feeling like jabbing pitchforks into your eyes...

S-expressions are good for you

Posted Jul 8, 2013 12:50 UTC (Mon) by dakas (guest, #88146) [Link] (6 responses)

>> Very much seconded.
> The above-mentioned Readable project preserves homoiconicity, it just makes Lisp more readable.

My computer begs to differ. The thing you have to keep in mind is that LISP does not come with a program syntax. The programmer does not write a program that is parsed into some intermediate data structure by the compiler. Instead, the programmer writes down a machine-readable printable representation of the parse tree.

Which is pretty much the whole point of the LISP language family. Imagining that infix language will magically turn this into a more human-adapted language is like imagining that it's easy to learn Hebrew if one just writes the letters left to right.

There is no "homoiconicity" like you claim anyway since heuristics are employed for deciding whether to format/print Lisp structures in infix or postfix, so the print form can be completely different to your input form either way.

S-expressions are good for you

Posted Jul 8, 2013 13:32 UTC (Mon) by hummassa (guest, #307) [Link]

> There is no "homoiconicity"
...

"You keep using that word. I do not think it means what you think it means."

S-expressions are good for you

Posted Jul 9, 2013 14:46 UTC (Tue) by david.a.wheeler (subscriber, #72896) [Link] (4 responses)

"The thing you have to keep in mind is that LISP does not come with a program syntax. The programmer does not write a program that is parsed into some intermediate data structure by the compiler. Instead, the programmer writes down a machine-readable printable representation of the parse tree."

Lisp does not have a syntax specific to programs, it has a generic syntax that is used for both data and programs. But it's an inconvenient notation; reading it is a lot like reading assembler code, and most people don't want to directly read either one. There are already abbreviations in Lisp in wide use; most people write 'x, not (quote x), because the former is a more convenient abbreviation. The "readable" project is just adding additional abbreviations for that generic syntax. Thus, these additions are useful for both data and programs.

I'm sure you know, but it's important to emphasize, that LISP does have syntax. Parentheses, spaces, and so on all have syntactic meaning. The readable project is just adding a little more syntax, but that additional syntax can be used at any time: for code, for data, for data used as code, whatever.

Adding infix to lisp does make lisp much better adapted to people. Infix isn't naturally "better" in some cosmic sense, but today's developers spend 12-20+ years in school, where they learn how to write math expressions using infix. Nearly all books that present mathematics (say, for an algorithm) use infix too. Lisp's inability to handle infix notation, the practically universal notation for math, is a problem.

Funny you should mention Hebrew, since it proves my point. In modern Hebrew, numbers are written left to right using traditional "Arabic" numbers. Just look at images for Israeli money. The old number-writing system is used for religious or traditional purposes, but that's it. Practically everyone around the world knows how to write numbers left-to-right, using 0..9, and even those who normally write right-to-left use the standard math notation (left-to-right). Modern math notation is just too standardized, and widespread, to ignore. Lisp should learn from Hebrew speakers.

Most developers will never, ever, use a language that fails to provide infix notation. Infix is the standard; prefix-only notation is not.

That's not homoiconicity. That's textual representation of the written form, something that lisp has never guaranteed. Quick test - type this into a Lisp system:

'(a . (b . (c . ())))

You'll almost certainly get "(a b c)". What? Did Lisp make a mistake? No, the print form in Lisp can be completely different from your input form. That has always been true, from the 1950s one.

Homoiconicity simply means that, when you read an expression, a human can immediately determine the underlying data structure. Sweet-expressions do this quite well.

S-expressions are good for you

Posted Jul 10, 2013 16:51 UTC (Wed) by bjartur (guest, #67801) [Link] (2 responses)

Arabic numbers are little endian, both in speech and writing. Europeans read them from left to right, and thus have to interpret them as big endian.

Can you provide an example of an Arabic text in which numbers are big endian? I had assumed Europeans tried to write numbers as they were taught by Arabs, messing only with the glyphs. In special considering that numbers are little endian both in Arabic speech and when using the traditional Arabic glyphs.

S-expressions are good for you

Posted Jul 11, 2013 10:40 UTC (Thu) by gioele (subscriber, #61675) [Link] (1 responses)

> Arabic numbers are little endian, both in speech and writing. Europeans read them from left to right, and thus have to interpret them as big endian.

_Most_ European read them from left to right. In German, numbers are middle-endian: 172 = einhundert zweiundsiebzig.

S-expressions are good for you

Posted Jul 11, 2013 13:19 UTC (Thu) by bjartur (guest, #67801) [Link]

I retract all of my statements on speech. According to a better authority of Arabic only the last two digits are swapped in speech, just as in Danish and German.

S-expressions are good for you

Posted Jul 11, 2013 21:17 UTC (Thu) by cesarb (subscriber, #6266) [Link]

> Infix isn't naturally "better" in some cosmic sense, but today's developers spend 12-20+ years in school, where they learn how to write math expressions using infix.

Infix reduces the average distance between the operator and the operands. That might not make it "naturally better", but is a data point.

There might be reasons for the predominance of infix other than merely path dependence.

S-expressions are good for you

Posted Jul 8, 2013 13:48 UTC (Mon) by jezuch (subscriber, #52988) [Link] (3 responses)

> The above-mentioned Readable project preserves homoiconicity, it just makes Lisp more readable.

Readable to *whom*? Personally, I find infix expressions unreadable, even though I've been conditioned from birth to consider them the Only True Notation.

But I also, personally, find imperative style massively counter-intuitive, even though it, too, is being worshiped as the Only True Execution Model and even though I work with Java code daily. So I may be weird, or something ;)

S-expressions are good for you

Posted Jul 8, 2013 14:01 UTC (Mon) by HelloWorld (guest, #56129) [Link] (2 responses)

> Readable to *whom*?
To 99% percent of all programmers. Please don't do as if this weren't a clear-cut issue.

S-expressions are good for you

Posted Jul 8, 2013 20:00 UTC (Mon) by ebiederm (subscriber, #35028) [Link] (1 responses)

Actually the evidence is that people can not get code imperative code with infix notation complety correct. Code without irregularities like assignments and infix notation can be much easier to reason about. As evidence by the fact modern C compilers turn C code into pure functional code before optimizing it.

Now I do think languages like scheme and lisp get into trouble when coming up with magic syntax let, defun, set!, etc and still using parenthesis when you can not think of the code as normal function application.

As for operations like + and * I am not at all certain they come up commonly enough for me to care about infix vs prefix notation. And I really think interesting mathematical operations where you need precedence on + and * to figure out the expression are sufficiently rare that I likely would not mind parenthesis in that case.

In short give special syntax for special forms before special syntax for expressions.

S-expressions are good for you

Posted Jul 8, 2013 20:57 UTC (Mon) by HelloWorld (guest, #56129) [Link]

> Actually the evidence is that people can not get code imperative code with infix notation complety correct.
They don't get get functional code without infix notation completely correct either. What's your point?

> As evidence by the fact modern C compilers turn C code into pure functional code before optimizing it.
How is what C compilers do relevant to what kind of source notation is more readable? Please don't distract from the topic at hand.

> And I really think interesting mathematical operations where you need precedence on + and * to figure out the expression are sufficiently rare that I likely would not mind parenthesis in that case.
The Readable S-Expressions project doesn't define precedence rules. (+ a (* b c)) must be written as {a + {b * c}}.

Stop spreading FUD

Posted Jul 7, 2013 17:37 UTC (Sun) by HelloWorld (guest, #56129) [Link]

The Readable S-Expressions project was carefully designed with macros etc. in mind and doesn't affect the homoiconicity at all. Really, is it so hard to actually read up on something *before* spreading FUD about it?

Sweet-expressions=s-expressions+abbreviations

Posted Jul 8, 2013 23:07 UTC (Mon) by david.a.wheeler (subscriber, #72896) [Link] (2 responses)

jonabbey said: "Getting rid of S-expressions seems like a terrible idea to me. I'd not like to have to give up macros and other self-modifying code systems for the sake of making people who haven't properly learned the language happy. ;-/"

Um, what? Sweet-expressions do not "get rid" of s-expressions. They are s-expressions, with a few additional abbreviations. This is just like 'x is an existing abbreviation for (quote x). You can still use macros, quasiquoting, and all the other stuff you're used to.

Sweet-expressions=s-expressions+abbreviations

Posted Jul 8, 2013 23:16 UTC (Mon) by jonabbey (guest, #2736) [Link] (1 responses)

So I am seeing in reading your site. I haven't read enough of it to comment much beyond that yet.

Sweet-expressions=s-expressions+abbreviations

Posted Jul 8, 2013 23:36 UTC (Mon) by jonabbey (guest, #2736) [Link]

Alright. It seems like the big trade-off with your system is the need to mentally internalize the S-expression representation when it comes time to do macros or other code transformations. It's probably reasonable to expect programmers working at those levels to be able to cope with the "real" representation created by the reader, but it is a real cost, however justified.

Harlan + readable? Let me know!

Posted Jul 8, 2013 11:30 UTC (Mon) by smitty_one_each (subscriber, #28989) [Link]

*cough*Haskell*cough*

Harlan: A new GPU programming language (The H)

Posted Jul 10, 2013 16:32 UTC (Wed) by daglwn (guest, #65432) [Link]

Will anyone really use this given the existence of OpenACC? Honestly, all these specialized languages for GPUs is really the wrong way to go.