Conversation

Notices

1. Embed this notice
   Niki Tonsky (nikitonsky@mastodon.online)'s status on Friday, 01-May-2026 02:28:03 JST Niki Tonsky

   If I ever to create my own programming language, I’ll make sure that |x| means abs(x)

   • Embed this notice
     Niki Tonsky (nikitonsky@mastodon.online)'s status on Friday, 01-May-2026 02:54:53 JST Niki Tonsky

     in reply to

     • Mark Dominus

     @mjd I am not sure I ever dreamed of overloading brackets but I still want a language strings use paired “” quotes instead of identical "" ones. I just feel slight discomfort when start and end symbol of a sequence are the same

   • Embed this notice
     Mark Dominus (mjd@mathstodon.xyz)'s status on Friday, 01-May-2026 02:54:54 JST Mark Dominus

     in reply to

     @nikitonsky For a while I was thinking about a language where the semantics of brackets was user-definable at compile time. You could have (a,b,...) assemble one sort of list, and [a,b,...] assemble a second sort, and then similarly “applying” (juxtaposing) the expression E to the object from [a,b,...] might perform an array lookup on E or something like that.

     My main idea was to permit the programmer to choose and define notations for things like sets, bags, tuples, and vectors, and for array and hash subscripting to be controllable and not hardwired into the syntax. But I'm sure that `|x|` was one of my example use cases.

     Some paper of @pigworker has a horrible hack in which `Ii x y z … iI` is defined so as to perform a certain sort of computation, with `Ii` and `iI` playing the role of brackets `Ii` has a typeclass defined so that `Ii x y z...` accumulates the `[x, y, z, ...]` at compile time, and then `iI` is some unique value with a special type that triggers the compiler to figure out that it has seen the whole list and should actually do the thing.

   • Embed this notice
     Niki Tonsky (nikitonsky@mastodon.online)'s status on Friday, 01-May-2026 18:51:42 JST Niki Tonsky

     in reply to

     • Andrew Helwer

     @ahelwer shame it didn’t work out. But this is specific to TLA+, most other languages don’t have | and || infix operators. The only problem with parsing would be that you can’t nest it, like you can’t write abs(abs(x)) and then parse it reliably ||x||

   • Embed this notice
     Andrew Helwer (ahelwer@discuss.systems)'s status on Friday, 01-May-2026 18:51:43 JST Andrew Helwer

     in reply to

     @nikitonsky we looked at adding this to TLA+ recently for set cardinality, but the already-existing | and || infix operators made for some really horrifying parse ambiguities https://github.com/tlaplus/rfcs/issues/9