Until you permanently lose user data because of a pull request that contained whitespace changes.
Yes, I've seen this happen in production, yes it could have been prevented in other ways... but why invite disasters like that upon yourself?
I worked on Quartz for a few tears, that's over 10 million lines of Python code and many thousands of commits per day. If concerns like that really were anything more than nitpicking, projects like that would know about it.
Recent GCC now has a warning for indentation that doesn't match code structure. (Had to recently patch a breakage in GNU Binutils in an embedded distro due to this being a -Werror).
This lovely typo deserves to be noticed.
Surely it is good advice not to exclude whitespace from a diff when using a whitespace-sensitive language?
In ETNs (the new family of programming languages I'm talking about), there are no "whitespace changes", in the sense that all changes to the code affect actual nodes in the program.
This is a really important property that embeds diffs with a whole lot more meaning. You can not only see the number of lines changed, but also the number of nodes changed. If you expected a change to only change content and not change any nodes, and you saw in a negative number in the nodes changed field, you would know immediately that something had gone wrong.
This is one of the many new beneficial properties unique to these languages.
It changes the behavior in the sense that there is no w=1 option. All whitespace is significant. The idea of ignoring whitespace would be like the idea of ignoring angle brackets in html. Whitespace is an essential part of TN and ETNs and is never ignored.
Diff tools then can benefit by showing not only aggregate line diffs but aggregate node and word level diffs without knowing anything about the meaning of a program.
This has been “discovered” many times, but somehow this dream language never approaches even Lisp in popularity. (Though a loosely similar transformation of it's basic ML-based syntax is used in Haskell to reduce parens, but that's not a Lisp base.)
So far I'm only aware of one previous discovery--https://srfi.schemers.org/srfi-49/srfi-49.html--, which nsajko pointed me to a couple weeks ago, (https://news.ycombinator.com/item?id=14606595). Are you aware of other identical or near identical implementations? The tiniest details matter here. I'd be very interested in more.
> but somehow this dream language never approaches even Lisp in popularity.
Agreed! That's what I'm hoping to help change. It's going to be a long slog, but I'm very confident the math works out and it's going to happen. The tooling needs to be built to take advantage of the properties of these languages before they will catch on. But once that happens, I think we're in for a whole new world in programming.
? print list sum 0 1 2
1 2
? (print (list 1 2 3 (sum 1 1 1 1)))
1 2 3 4
? print (list 1 2 sum 1 2 4)
1 2 3 4
? print 1 + 2 * 3 + 4
11Logo came very close to TN and ETNs but adding the parens and other visible syntax I believe was a design mistake. It's not obvious, but when working with large programs in 2 and 3 dimensions (only possible with parens free lisp, or ETNs as we call them), you gain tremendous productivity benefits
srfi-110, srfi-119.
Some thoughts on 110 and 119 in my comment below.
Fascinating but I don't think it has many users!
A quote from that page...
(Note: there are no parentheses in Z. Zero.)
Which, if you think about it, is the natural
grouping for the definition of the name
argument syntax I gave above.
To pass additional arguments to a function,
the arguments are put on the next line and
indented to the column of the first argument:1. A single space for indenting nodes works much better. 2. strings don't need quotes.
> The problem is that it requires all of your functions to have a fixed arity I think, or at least a lower bound on the arity, or you use newlines as part of the syntax.
This was my initial thought as well.
However, in my latest batch of ETNs (the name I give to these types of lisps), I've found that a simple convention of putting any variadic argument last seems to work well.
An example may help. Here would be a language blueprint that defines 2 node types:
=+2
description Adds two numbers
pattern resultIdentifier number number
=+
description A variadic adder of unknown arity
pattern resultIdentifier number+
=+2 sum 2 5
print sum
# prints 7
=+ sum 1 2 4
print sum
# prints 7Honestly, there is no flaw in the parentheses. You just need to write more Lisp.
The parentheses are one of the best things in Lisp.
I wonder if the creator has considered just not having parens at all?
- http://nonelang.readthedocs.io/en/latest/dataformat.html#nak... - http://readable.sourceforge.net/ - https://github.com/boxed/indent-clj
As 110 and 119 also note, Egil was on to something. Although I came to it from a different angle, I think he had it about 90% correct.
My contribution is identifying the split between TN and ETNs, and then getting the details perfect with TN. Getting the details perfect meant showing how to craft it so that every single input was a valid TN program. My motivation was, if you can write it/build it in real physical life (3D world), or in other words, if nature allows it, then why shouldn't your compiler? I think 49 missed a few tiny details (like " It is an error if neither one of the leading space/tab seqquences are a prefix of the other, nor are they "...in my TN, there are no errors, and extra spaces are translated into separators for empty words).
Nope, you've just made it awful, white-space with syntactic meaning is just god-awful. It's the worse thing about Python, there's a reason it's not a more popular language feature.
Unless done perfectly, whitespace with syntactic meaning languages are quite annoying.
If I had a nickel for every time I had a tab vs space bug in Python when I was first starting to code.
I just started publishing my results.
http://breckyunits.com/the-flaw-in-lisp.html
What I've discovered is that the parentheses are completely unnecessary in Lisp, and in fact cause much harm by making Lisp harder to read and maintain in the long run. Drop the parentheses in Lisp by switching to whitespace/geometry for syntactic structure and you suddenly have the dream language.
Your example above would be something like:
You might think that looks a little strange too at first, but the neat thing about that code is you can write it on a piece of graph paper, draw lines around each word, connect the indented nodes, and you'd have a tree visualization of your syntax code without doing a single transformation of the source.