as we all know, innovation in programming language design is being held back by a shortage of bracket characters. as we wait for Unicode to rectify this problem, designers are pushed into more and more desparate compromises
@joe Call me back when Swift has solved the paren/tuple ambiguity by adopting ⟨ ⟩.
@zwarich what paren/tuple ambiguity? A scalar and a 1-tuple are just canonically equivalent
Seems like the generic argument ambiguity is the bigger sin
@joe The generic argument ambiguity can be solved by [ ] like how Scala does it.
@pervognsen @zwarich @joe i'm still hoping for a research project that's something like the Dion project*, where lexing is done only in $EDITOR, and the file format directly represents "list-of-(token-or-list)", so that your parser only ever sees a token or a sublist, and never sees delimiters (like '(', '[', '"', ';'..), and then all of these delimiter problems are completely avoided (and writing a parser gets *much* easier).
[*] but without the fatal flaw where 50% of the dev team is fashy
@pervognsen @zwarich @joe (presumably the type of sublist would either be detected by parsing routines auto-loaded by the editor, and potentially selected by the user with something like an autocomplete menu in the case where it's initially ambiguous)
@pervognsen @zwarich @joe this keeps bugging me because things that could be represented as "list-of-(token-or-sublist)" are *everywhere*:
- all programming languages (including the command shell, which could get a lot more ergonomic if designed for this),
- all config file formats?
- log file formats
- intermediate data in unix command pipelines
- plain human-language text
@JamesWidman @pervognsen @zwarich does AppleScript count?
@JamesWidman @zwarich @joe I'm extremely unconvinced by any attempt at moving away from text as source code. You run into the problem where you have to rebuild an entire ecosystem of text-based tooling.
@pervognsen @zwarich @joe that is definitely a challenge, but i wonder if it can't be overcome with transitional tools and/or legacy tools that are adapted to perpetually support the superset of (new_binary_format ∪ old_flat_character_buffer_format)
e.g. it seems like (neo)vim ought to be able to present a façade that mostly looks & feels like plain text as an interface to this binary format.
@pervognsen @zwarich @joe it would still be super-expensive to implement, but hopefully everyone would mostly be able to use all the old tools, because the old tools would learn how to read/write/present the new format.
@pervognsen @zwarich @joe to some extent users are kind of half-ready for this, considering that treesitter has been integrated in editors for a while now, so e.g. people are already used to vim motion commands that navigate around syntax trees (and presumably there would be treesitter parsers that consume the new binary format to produce treesitter trees)
@pervognsen @joe It's a bit more general; it works for any inductive type with a single constructor:
https://lean-lang.org/doc/reference/latest/The-Lean-Language/The-Type-System/#anonymous-constructor-syntax
@joe
I live in 愛知県.
^ error: expected expression after open prefecture-parenthesis.
Nov 13, 2024, 9:52 PM@joe wake up... new brackets just dropped