Live data from Hacker News

Sweet-expressions: A readable format for Lisp-like languages

dwheeler.com

41–50 of 84 posts

Re: Sweet-expressions: A readable format for Lisp-like languages

#41

Earlier quoted context omitted.

A comparative usability study on a language is very simple to perform: you basically print out some code samples, let people with no experience in the language (but general programming experience) read them for a set time period, and then evaluate their comprehension. That is just one axis of usability, optimizing for comprehension by someone unfamiliar with the language. Usability is also optimizing for the experien…

Also, people with 'no experience in the language', but with 'general programming experience' will be primed with the conventions of mainstream languages and biased against s-expressions. (Btw, it's J ef Raskin.)

By "general programming experience," I didn't mean "mainstream programming experience," but rather "having been given a survey of techniques for programming in iterative, functional, OOP, declarative/constraint-based, concatenative, etc. languages, without having learned a single one." In other words, someone who was taught to program for the purposes of the test.

Re: Sweet-expressions: A readable format for Lisp-like languages

#42
post #40

The parens are a cue so that the editor indents my code properly. How do you propose to make emacs auto-indent sweet expressions? It seems that I would have to manually do that as indentation would convey meaning. Whitespace is a notorious pain in the ass to get right, parens are visible, countable, and highlight-able. Infix is stupidly ambiguous and is the cause of multitudes of errors; a 'natural' way to describe m…

People claim the same issue with Python, but I don't think it's really hurt anyone much. It's usually very obvious and auto-indent is surprisingly possible on a lot of it.

Re: Sweet-expressions: A readable format for Lisp-like languages

#43
post #40

The parens are a cue so that the editor indents my code properly. How do you propose to make emacs auto-indent sweet expressions? It seems that I would have to manually do that as indentation would convey meaning. Whitespace is a notorious pain in the ass to get right, parens are visible, countable, and highlight-able. Infix is stupidly ambiguous and is the cause of multitudes of errors; a 'natural' way to describe m…

I agree that sexpr are the best syntax out there for a language because it's consistent and simple. However, this expression thing is a good idea. I've been waiting for something like this for a while.

    Anyway, I don't 'get' the 'aversion' the syntax is trivial to explain [etc]
Although you mightn't get it, I'm sure you have run into it a bit and realise it's widespread. Perhaps nine in ten people who identify as programmers would dislike it. The practice of ignoring that hasn't done any favours for lisp takeup. It's still a fringe language.

Like the author says,

    But most software developers have abandoned Lisp precisely because of Lisp's hideous, inadequate notation
This syntax is a gateway that allows you to smuggle lisp into a workplace. It looks like python. When people ask about what you're doing you say "Oh, that's this cool language called Racket. As you can see, it reads a lot like python, but I've found it allows me to do xyz nicely. Here, let me show you how this script works." Then you would show them the script, perhaps show them a repl tool that appears to work just like python's and they'd be able to get around your your scripts as much as they can around your existing python code. Sweet!

    How do you propose to make emacs auto-indent sweet expressions?
You could have emacs auto-transform into sexpr when you loaded a file, and save to sweet expressions when you saved. Should be trivial. From your perspective, you could like in a sexpr world. Except when you were stepping your colleague through the code - remember to vi for that bit. Otherwise the game will be up.

Re: Sweet-expressions: A readable format for Lisp-like languages

#44
I liked the somewhat elegant heuristic for general infix-to-prefix conversion:

{...} contains an "infix list". If the enclosed infix list has (1) an odd number of parameters, (2) at least 3 parameters, and (3) all even parameters are the same symbol, then it is mapped to "(even-parameter odd-parameters)". Otherwise, it is mapped to "(nfx list)" — you'll need to have a macro named "nfx" to use it

That being said, (still-prefer 'I (using 'parentheses :in 'Scheme)).

Now, if someone added mix-fix syntax to Scheme...

Re: Sweet-expressions: A readable format for Lisp-like languages

#45
post #30

I am not a big fan of lisp, but u can not really change the lisp syntax and have lisp anymore. (+ 1 2) has more features included then '1+2', because u can for example add 3 numbers easily like (+ 1 2 3) and you can treat all that as a list and parse it to whatever u need, recurse over it and so on. With a "better" syntax u just don't have these features anymore. Someone who would use sweet-expressions actually has n…

I think you've misunderstood. This does not take away any of those issues. With this setup, you can write (+ 1 2 3) or +(1 2 3) or (1 + 2 + 3) and they would all translate into (+ 1 2 3). You can treat any of them as a list. You can still parse, transform, do anything with it. There is no loss of functionality here. Think of it as a macro that aliases "plus" to +. There is no difference between (plus 1 2 3) and (+ 1 2 3) in a macro defined in this way. They are S-expressions under an invisibility cloak. But they're still S-expressions within.

Re: Sweet-expressions: A readable format for Lisp-like languages

#46

Earlier quoted context omitted.

Shriram Krishnamurthi (author of PLAI http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/ ) recently suggested one: http://shriram.github.com/p4p/ I've been meaning to go through it in detail, but to be honest I really like s-expressions, really really. I'd even say the regularity of syntax is one of lisp's greatest features (even Clojure's [] and {} literals are going too far for my taste...)

Thanks for that pointer. I never expected Shriram to propose one :) The parens are quite acceptable if you use syntax coloring options in DrRacket to make them light grey, which is what I do. Imo, P4P is just not worth the learning delta .. particularly because it doesn't solve the single biggest readability issue - math expressions - which exists even if you make all parens invisible. In my company, I came up with o…

Just out of curiosity, I created two gists with the P4P examples coded using the tab syntax I mentioned -

tab-syntax version: https://gist.github.com/716416 scheme-syntax version: https://gist.github.com/716417

Re: Sweet-expressions: A readable format for Lisp-like languages

#47
post #7
post #3

Somebody has invented a more conventional-looking syntax for Lisp every couple years since John McCarthy first suggested M-expressions. Nobody[0] has ever cared enough to use any of them. People who "get" Lisp get over any aversion to the syntax, and usually even come to appreciate it. People who can't get over the syntax never actually get Lisp. [0] For large values of nobody

Because the people who "get" Lisp are almost always theoreticians who know what they want to code before they code it. They use Lisp as a write-only language. Meanwhile, working programmers avoid it, because it's very hard to step into someone else's Lisp codebase and understand it (and not just because of the fact that anything could mean anything due to macros—code is already visually indistinguishable from data wi…

>> Because the people who "get" Lisp are almost always theoreticians who know what they want to code before they code it.

Nope, actually it's the other way around. People write a lot of prototypes which they rapidly evolve.

Re: Sweet-expressions: A readable format for Lisp-like languages

#48
Well, that's just plain stupid. When will people who don't get Lisp acknowledge, that the syntax is that way on purpose, to allow easy metaprogramming? It's not a bug, it's a feature!! When I program in other languages, I see just a bunch of rubbish useless noise, stupid operator preference issues, and very inelegant lambda lists. With Lisp, all the syntax issues goes away, and the code looks absolutely lovely.

Re: Sweet-expressions: A readable format for Lisp-like languages

#50
The new and "readable" syntax looks truly ugly compared to the S-expression counterparts. Why is it that some people dread parentheses so badly and other people just never mind and choose to spend the time working with them?

The main reason I consider parentheses and S-expressions superior to other syntax is that it allows for flexible navigation in the source code. I can move forward and backward, upward and inward in the tree, unit-by-unit and the unit can be a literal or a compound S-expression or anything and it just works the same. (At least in Emacs.)

Post reply on HN