sweet-expressions syntax

[redbar0n]

This is probably a long shot, given that it’s about (beloved) syntax, but I hope you will at least «give it 5 minutes» before potentially shooting it down.

Many will probably disagree with me, but I do think the readability of Lisps are a reason they haven’t gone more mainstream since 1958. I might be wrong about that. Nonetheless, I happened to come across Dr. Wheeler’s work on making S-expressions more familiar to the vast majority of programmers coming from non-lisp languages. He calls them sweet-expressions.

They would still keep the homoiconicity and code-as-data characteristics. As well as being fully compatible with existing well formatted lisp-style code, in general. (Though, some modifications for the static typing syntax in Carp would likely be needed.)

Please have a look:

https://dwheeler.com/readable/index.html

Examples (using Scheme):

1. S-expressions:

(define (fibfast n)
  (if (< n 2)
    n
    (fibup n 2 1 0)))

Sweet-expressions:

define fibfast(n)
  if {n < 2}
    n
    fibup(n 2 1 0)

2.

S-expressions:

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

Sweet-expressions:

define fibup(max count n-1 n-2)
  if {max = count}
    {n-1 + n-2}
    fibup max {count + 1} {n-1 + n-2} n-1

3.

S-expressions:

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

Sweet-expressions:

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

Is there any chance Carp would be able to accomodate this kind of S-expression syntax?

[jacereda]

Kind of related: https://scopes.readthedocs.io/en/latest/dataformat/

[hellerve]

Let me preface this by saying I personally am not a fan of sweet expressions syntax, but that doesn’t really matter to the argument. It does color my argument though, and I thought it’d just be fair to share that beforehand.

I don’t think we should support the syntax currently because:

• maintaining another syntax concurrently is a maintenance burden, and I’m not sure whether it would pay off. We’ve had contributors and people writing packages, and syntax has never been much of a concern. That might be survivor bias, or it might not be; there is no way to tell. Sweet expression syntax comes up every so often in Lisp circles, and whenever it is actually implemented, very few people end up using it (such is the case in Racket and with SRFI-110, the original stomping grounds of sweet expressions).
• superceding the current syntax would mean requiring to rewrite all the standard library code and all third party packages, and I’d rather like to avoid that unless there is a really good reason for it. Taste is not a good enough reason, I’d argue.
• there is a lot of prior art for Lisp and people that come into the community are often able to refer to previous Lisp exposure, however slight, to make sense of what’s going on in the syntax. Introducing a completely new syntax with less saturation might or might not ease the learning curve, but it removes any feeling of familiarity, which is what often brings people to Carp, especially from Clojure.

Lastly, because I like to work with Lisps, I think you do them some wrong by saying “they haven’t gone more mainstream since 1958”. Clojure is alive and well, even mainstream now. So is WebAssembly, which uses an S expression syntax—it’s not even a Lisp, the committee just deciced that S expressions are the way to go! I think the pervasiveness of technologies based on Lisp or S expressions is debatable, and any discussion on this topic will rely heavily on anecdotal evidence, and that’s probably not especially productive.

Anecdotal evidence, because I couldn’t help myself—feel free to disregard

I will say that I’ve been paid to write Lisp (Clojure and Common Lisp) even in hip young startups that do hip young startup things. The team sizes I’ve seen write Lisp ranged from a handful to a hundred. I don’t want to make it seem like I discount any potential problem with the syntax, but I do want to push back on the notion that “Lisps are dead” lest it becomes a self-fulfilling prophecy.

[eriksvedang]

@hellerve Thanks for writing a proper response, I agree 100% with it.

@redbar0n Feel free to implement it in a fork :)

In short, this will not happen.

[redbar0n]

Thanks for a thorough response @hellerve.


I totally understand the issue of maintenance burden and a potential arduous rewrite. I wouldn't want to impose that on anyone if I didn't think it ultimately would be helpful to them.

Out of curiosity: Is it possible to write language level macros in Carp, so that someone who wanted to use this syntax, could build a library that implements it on top?

I fully agree that Lisps, particularly Clojure, is live and well, and used by tons of programmers. I disagree, however, that Lisps, even all of them combined, amount to being mainstream. As evidenced by any measure or index of language popularity, whether one uses PYPL, TIOBE, StackOverflow Developer Survey, or some other objective measure.



I don’t think readability simply a matter of taste. I think providing familiarity and as low a threshold to get started as possible, is generally vastly underrated.

I see it as a feature if Carp would be even more able to easily channel people in from the mainstream, than simply from other substreams (like Clojure and other Lisps). But you might see that as a bug. With more developers interested in using Carp, the average quality of developers in the community would shrink, for sure. However, I think I could’ve argued very convincingly for the importance of this issue, to the potential benefit of Carp (if wide adoption is a goal). But since the issue is already closed, I realise it would be to argue a moot point.

You are the maintainers, and have the main burden and responsibility for Carp, so I highly respect that you have the final say.

[jacereda]

I don’t think readability simply a matter of taste. I think providing familiarity and as low a threshold to get started as possible, is generally vastly underrated.

Scopes is doing something close to what you propose and AFAIK it isn't gaining much traction. It's an awesome language in some ways (you can even write GPU code in scopes as easily as CPU code, given that it can generate SPIR-V), but I'm not sure syntax is one of them.