Very nice little article! Learned some new terms.<p>To anybody dabbling as I do in syntax design, who may be looking for an extremely minimal representation for trees (even more minimal than S-exprs!) I would like to introduce my little project called Jevko: <a href="https://djedr.github.io/posts/jevko-2022-02-22.html" rel="nofollow">https://djedr.github.io/posts/jevko-2022-02-22.html</a><p>It is pure distilled treeness. Its grammar fits into one line, if compressed well:<p><pre><code> Jevko = *("[" Jevko "]" / "`" ("`" / "[" / "]") / %x0-5a / %x5c / %x5e-5f / %x61-10ffff)
</code></pre>
This took me years of syntax golfing to figure out. I think it's turned out pretty nice. It's complete, formally defined, with a few simple parsers written, except it has no users. ;D<p>To relate back to the article, an interesting and AFAIK original feature of this syntax is that newlines or other whitespace are neither significant nor insignificant nor "possibly significant" in Jevko. I'd call it whitespace-agnostic. Various whitespace rules can be laid on top of it, producing for example a Lisp-like language with native multiword identifiers with spaces, e.g.:<p><pre><code> define [sum primes [[a][b]]
accumulate [
[+]
[0]
filter [
[prime?]
enumerate interval [[a][b]]
]
]
]
</code></pre>
here "sum primes" and "enumerate interval" are two double-word identifiers. It's the only right_solution to the identifierWars, I-tell-you!
I find the section on "syntactic salt" interesting:<p>> The opposite of syntactic sugar, a feature designed to make it harder to write bad code. Specifically, syntactic salt is a hoop the programmer must jump through just to prove that he knows what’s going on, rather than to express a program action.<p>This is perhaps an uncharitable way to describe it, but the concept does ring a bell. Rust's unsafe {}, C++'s reinterpret_cast<>(), etc - all slightly verbose. More important than jumping through hoops, the verbosity helps when <i>reading</i> code to know that something out of the ordinary is going on.
Another exploration of syntax: <a href="http://rigaux.org/language-study/syntax-across-languages.html" rel="nofollow">http://rigaux.org/language-study/syntax-across-languages.htm...</a>
I began designing a language that handled recursion and iteration as relations between variables which are topologically sorted to determine control flow.<p>Each function is a toplogical graph of stream functions so it is similar to a data flow language or reactive programming language. The goal is that you should express the critical insight of the algorithm to work out what to write and the code is not nested so there is very little tree structure.<p>Algebralang is rough notes on how it would appear.<p><a href="https://github.com/samsquire/algebralang" rel="nofollow">https://github.com/samsquire/algebralang</a><p>Example programs in the repository are binary search, btrees, a* algorithm.<p>I wrote a multithreaded parallel actor interpreter in Java and it uses an invented assembly language which doesn't have a bytecode, it's just text.<p><a href="https://github.com/samsquire/multiversion-concurrency-control#parallel-interpreter" rel="nofollow">https://github.com/samsquire/multiversion-concurrency-contro...</a><p>I like the ideas behind ani language
<a href="https://github.com/waves281/anic" rel="nofollow">https://github.com/waves281/anic</a>
I actually like the VB-style, but VB did it mostly wrong: if you start the block with X, you should always end it with "End X". Thus, you'd have While ... End While instead of crap like "Wend" and "Next" (in For...Next).<p>It's more legible to know what block is being ended. C-style continually frustrates me that area. The End-X style just never found a nice way to wrap text for longer statements.<p>C-style also has a problem in that there is no way to define arbitrary blocks: it relies too much on key-words. I'm trying to remedy this with "Moth" syntax:<p><a href="https://www.reddit.com/r/ProgrammingLanguages/comments/ky22dx/simplified_take_on_moth_colonfree/" rel="nofollow">https://www.reddit.com/r/ProgrammingLanguages/comments/ky22d...</a><p>It's LINQ-esque but without the bloated Lambda conventions, and influenced by XML in that you have a simple syntax pattern that can "implement" many domains' needs. It started with an attempt to merge the best of Lisp and C-style. (Whether it succeeded or not is hotly contested. I welcome other attempts.)
> Because C does not have real arrays<p>C does have real arrays, they just get implicitly converted to pointers to their first element in a lot of cases (for a multitude of reasons in part having to do with simplifying the language), A[B] is defined as such so it works with normal pointers and arrays-converted-to-pointers in the same manner.<p>Try using an array with sizeof, unary &, or in the form of a string literal used to initialise an array. In those situations it suddenly stops behaving like a pointer to its first element and definitely behaves like something which is unlike anything else in C (hint: it's an array).
Fun read. I would love to read what if it's not text based, is it going to be different? Visual programming seems to suffer from composability and it's also bounded to be using human language as well, box with border is hard to comprehend, can get messy easily.<p>I mean, visual but text-like theme. It seems to be in sweat spot. Only fix some downside/limit of text.
I enjoy this sort of "one example, multiple different lenses" style of discussion. It reminds me of this book... Exercises in Programming Style by Cristina Videira Lopes.
Another interesting weird syntax I ran across a few years ago is OGDL: <a href="https://ogdl.org/" rel="nofollow">https://ogdl.org/</a><p>It's sort of an alternative to S-expressions with much less punctuation, but the data model is slightly different — in S-expressions you label the leaves, and in OGDL you label the nodes. In other contexts these node-labeled trees are sometimes called "rose trees"; they are the basic data model of, for example, Prolog. Labeling nodes is almost equivalent to labeling arcs, but OGDL does support multiple references, so not quite.<p>The OGDL proposal was intended for data, like XML, not programs. They started out by trying to simplify YAML, which has arrays and dicts, and they simplified it by unifying them into a single structure.<p>Here's one of their examples:<p><pre><code> network
eth0
ip 192.168.0.10
mask 255.255.255.0
gw 192.168.0.1
hostname crispin
</code></pre>
This is not quite just an edge-labeled digraph because, as in S-expressions, the order of arcs within a node is significant; you can have multiple edges with the same label in the same node, and you can select edges by ordinal rather than, or in addition to, label.<p>This is of course amenable to use as a programming syntax.
Seems down <a href="https://web.archive.org/web/20221018135106/https://cs.lmu.edu/~ray/notes/syntaxdesign/" rel="nofollow">https://web.archive.org/web/20221018135106/https://cs.lmu.ed...</a>
I wonder what would be possible if we could move away from the text editor and code with an e-pen on a tablet, the way mathematicians use a black board, where the parsing is not from left to right, but follows specific paths in two dimensions (like the notations for fractions, square roots, sums, integrals, etc. we learned at high school). -- Has this been tried out recently?
I really like the term "Sugary Functional Style" -- sweetening pure functional programming with faux procedurality.<p>Looks like it's a (three word) Google Whack at the time of writing: <a href="https://www.google.com/search?hl=en&q=%22Sugary%20Functional%20Style%22" rel="nofollow">https://www.google.com/search?hl=en&q=%22Sugary%20Functional...</a>
It's awesome to see an article from Dr. Ray Toal on HN this morning! In my biased opinion, the excellent tenured professors at LMU's CS program make it a stand out for its size.
> [mark the end by] .. spelling the initial word backwards<p>This reminds of the quirk in shell. if/fi, case/esac but ... do/done?<p>It might be because `od` was taken for octal dump.
The `infix` syntax is missing from the major items. Without infix syntax, all languages are just variations of LISP -- I guess that was all the article is about.