Curly-infix and readable Lisp [LWN.net]

Curly-infix and readable Lisp

Posted Dec 5, 2012 8:26 UTC (Wed) by dakas (guest, #88146)
In reply to: Curly-infix and readable Lisp by HelloWorld
Parent article: GNU Guile 2.0.7 released

The sweeten tool does this already. It employs heuristics to decide questions like these.

Meaning that the output is not predictable and can change from version to version.

They aren't perfect, but what's the worst that could happen? You get a string representation of a data structure that isn't as nice as it could have been, so what?

You need to be fluid in two languages instead of just one and transparently deal with either output.

The whole point of infix notation is to reduce the amount of thinking you need to invest. Now you need to be fluid in two representations and transparently translate back if sweeten decided to "infixify" a list that was not intended as an arithmetic expression, and vice versa.

At any rate, I am just making predictions. The only one in a position to dispel them is Father Time. I suspect I have had him visiting more often than you did, but at any rate I'm willing to take what he will eventually have to say in that matter.

(Log in to post comments)

Curly-infix and readable Lisp

Posted Dec 5, 2012 21:10 UTC (Wed) by david.a.wheeler (guest, #72896) [Link]

dakas said:

Meaning that the output is not predictable and can change from version to version.

You have the incorrect belief that that Scheme output is currently predictable and cannot change from version to version. That is not true, of either the Scheme spec or its implementations.

The Scheme specification R7RS draft 7 for "write" is "Writes a representation of obj to the given textual output port". Note that this is *a* representation, not *the* representation, as there are many possible representations without curly-infix. Similar text exists for R6RS (library section 8.2.12 on put-datum), and R5RS (section 6.6.3); it always says "a" not "the" and does not proscribe a particular representation.

Different Scheme implementations do write the same list differently, too. Let's run the trivial program (write (read)) and give the program the input ''x (x quoted twice). The scsh version 0.6.7 implementation reports ''x, while guile version 1.8.7 reports (quote (quote x)) - obviously different from scsh.

Since Scheme does not guarantee a particular format for a list - and permits implementations to use abbreviations when they choose - curly-infix represents no change in this matter.

The "sweeten" heuristic is to write infix form if there are 3-6 parameters, and the operator is punctuation, "and", or "or". It's a longer heuristic, but it means that users can see {a > b} instead of (> a b), and a lot of users prefer the latter.

You need to be fluid in two languages instead of just one and transparently deal with either output.

There is no "two languages". There is an underlying list notation, and a simple abbreviation that you can optionally use. Yes, you have to fluid in the two representations. Give it 10 minutes, you'll get it.

At any rate, I am just making predictions. The only one in a position to dispel them is Father Time. I suspect I have had him visiting more often than you did, but at any rate I'm willing to take what he will eventually have to say in that matter.

Here we agree!