JordanEvery now and then people share languages with very minimal or very uniform syntax (think Lisp, or Haskell, or Forth) and go "look, all the noise is gone". And to each their own, and familiarity goes a long way, but I think I've pinned down my feelings about it, which is "that wasn't noise, that was signal; I was using as scaffolding when reading the code and now I have to wade through every token linearly".
pcbeard
Joe Groff (1M Context)
d@nny disc@ mc²@joe @pcbeard @jrose i assumed sigils were type specifiers for the symbol and not coercion operators for quite a while. one difficulty i have is with good ideas that don't support user extension without forking the language (scala's unapply operation for extensible case matching was an epiphany to me).
if you go far enough with this you may eventually arrive at a stable HIR which makes the choice of concrete syntax an explicit decision. curiously scala 3 has this and in private tooling devs say it is terrible to write against compared to odersky's former protege eugene burmako's semanticdb. it does indeed allow the scala compiler itself to support multiple forms of concrete syntax but if the compiler is to take upon the role of tooling, it would be wise to separate this phase.
in the same way, the compiler should not integrate linear path traversal for library search into the rest of compilation (and certainly not for interpreters), but instead make this its own distinct phase generating an explicit mapping, which tooling can override. this is a general mechanism that can be observed for any command-line tool, where cli parsing tends to produce a serializable configuration that could alternately be deserialized as an explicit preprocessing phase.
i used to think a macro API was the key to multiple concrete syntaxes, but a macro API is itself a syntax, and i don't actually like most macro APIs (elisp has a destructuring one developed by a haskeller maintainer i do quite like). generating source code is also a sort of macro API, which is what coffeescript does. so if the language wants to do better than generating source code, it may as well entirely decouple source code from input.
arguably, this would seem to disparage syntax, and the value of language designers in crafting syntax like wall does. i believe that the design and craft of syntax is harmed when it runs into petty squabbles, or (more commonly) when it stops users from immediately upgrading to new versions. i also don't think a change in semantics should be signalled through a parsing error.
серафими многоꙮчитїи@hipsterelectron @joe @pcbeard @jrose Algol 68 had an idea they called 'stropping', which was a way to have a certain section of the syntax be separately defined - the canonical 'publishing' version of the language used visual indicators (like bold vs non-bold) to eg determine keywords. The stropping was a way to convert from flat text to styled text, there were various standards, and they could be more or less customised.
@hipsterelectron @joe @pcbeard @jrose Basically, I find that there are various interesting and underexplored/underexamined points in designs in the history of plt and the history of programming as a craft more generally where you can decouple things within 'the language/runtime/compiler/development process/etc' if you are careful.