Whoops, I guess I never posted it here. XD I made it right after we had a thread about yet another one of these languages, and then I chatted about it with Pauan and never returned to it.

Maybe I was waiting until I could document what I meant with the columns. Google Pages disappoints me, because although it'll support a sortable table like this, there's no option to add an explanatory caption. I was thinking of posting an explanation in a comment, but that's not a community-editable part of the wiki, right?

Guess I'll describe my intentions right here. Feel free to migrate these explanations to a better home, and of course, feel free to redesign the table to make it better.

---

Language: The name of the language.

Whitespace: In what way does whitespace matter to the parsing of a program text?

Infix arithmetic: Some users care about expressing their arithmetic-heavy code using traditional infix notation. Does the language syntax tailor itself for this purpose by special-casing particular arithmetic operators? If so, the answer is "Hardcoded." Otherwise, does it provide generic mechanisms so this user can be satisfied? If it doesn't, the answer is "No." If it doesn't provide hardcoded mechanisms but does provide generic ones, what are they?

Affects semantics?: To make it onto this list, the language must have a syntax that transforms into a uniform yet non-semantic nested structure like s-expressions. It must also have some sugar that's explained as an abbreviation of particular kinds of structure. By the time the programmer has a structured representation of the code to work with, are there still visible remnants of these abbreviations? If so, how so?

---

Maybe the infix arithmetic column would be better off as two: A "generic infix" column and a "domain-specific notation" column. Just because a language provides good generic mechanisms doesn't mean it can't hardcode some traditional notations too.

Maybe if the "Affects semantics?" answer is "No", we should add another shade of meaning to indicate that the project actually has no semantics to affect. I think Readable Lisp S-expressions pretty much falls into this category, and so does "Gel: A Generic Extensible Language."

On the other hand, Gel actually saves a lot of detail about the user's input (e.g. which parentheses they used), and any language that uses Gel would probably have to normalize away the unwanted detail in a second stage, possibly in a way that the programmer can notice.

I think it means whether the parsing happens before macros are run or not. In Arc, ssyntax happens after macros, so macros can affect the meaning/behavior of ssyntax. In most Lisps, syntax is read before macros, so macros can't change the meaning.

---