4 ms·

This is a super neat hack. Unfortunately, this kind of custom notation can make a project much less readable to outsiders who are only familiar with the base la

• srcreigh 5y ago
  Racket does too. (when (0 . < . x) (displayln "positive")) Although in Racket you could also add your own syntax.
  • anon_123g987 5y ago
    Infix operator in R: > '%mult%' <- function(a,b) a*b > 3 %mult% 5 [1] 15 Using infix operators as functions: > '*'(3,5) [1] 15
  • bhrgunatha 5y ago
    I've always wondered why that was added. It feels to me against the idiom (argot?) of any lisp. It's not composable either. (0 . < . x . < . 12) read-syntax: illegal use of `.` Typing those extra '.'s gets annoying very quickly too.
    • srcreigh 5y ago
      My guess is Racket/PLT scheme's history as a language for teaching programming to students. Racket has some other things that are non-lispy. Support for alternate (maybe non-SEXP) syntax readers and for loops come to mind. At least it's all simple. Sometimes terrifyingly simple, but simple. They're useful too. Non-SEXP reader could be used to create a non-infix dialect of Racket. Loop macros like for/or can be used as a more ergonomic way than recursive functions to walk a list to find/transform one of its elements.
    • kazinator 5y ago
      MacLisp had an extended dot notation similar to this for hunks: https://www.maclisp.info/pitmanual/hunks.html https://www.maclisp.info/pitmanual/hunks.html
    • soegaard 5y ago
      It was an experiment - I think the general consensus is that it was a bad idea. The double dot notation is mostly used for inequalites: (x . < . 3) instead of (< x 3) and for function contracts: (any . -> . boolean?) instead of (-> any boolean?)
  • mhitza 5y ago
    I just assumed Racket supports curly infix notation, but looking just now I see that you need to use the infix pragma and wrap things with @{} I liked GNU Guile for the fact that it's enabled by default, thus the following is a bit more readable in my opinion (when { 0 < x } (diplay "positive") (newline))
    • soegaard 5y ago
      FWIW a user can add this syntax himself to a language if he needs to. A hypothetical `curly-infix` language could be used like this: #lang curly-infix racket (define (fact n) (if (= n 0) 1 {n * fact(n-1)})) The reader for `curly-infix` can use a read-table to alter how `{<infix-expression>}` is read. The result can the be passed to the language after the `#lang curly-infix` which in the example is just `racket`, but could be something else. Hmmm. Maybe I should make a `curly-infix` wrapping `infix` from my `infix` package.
• hansvm 5y ago
  I wouldn't be totally surprised if the reason Python disallows custom operators is because it either requires a lot more context in the parser or a lot of care in how they're used (or a hack re-using existing operators like TFA). Neither option is without its costs. Languages that have them usually opt for the former. E.g., in Python `foo|bar` is totally unambiguous right now, give or take some nuance as to whether it's in a string/comment/whatever, but outside that tiny bit of context it's clear what's a variable and what's an operator. As soon as I can define `oo` and `|ba` as operators though it's a lot less clear what's going on, and all parsers (including editors, not just the cpython interpreter) need to be able to understand those semantics to work reliably. Edit: I'm having a tiny bit of trouble finding it, but my memory just came back to me, and there's a PEP floating around where Guido's rationale was just that there wasn't a solid use case so it wasn't worth implementing. Later the numpy folks introduced the @ symbol as a solid use case (matrix multiply), but nobody could come up with a sufficiently convincing argument for arbitrary operators -- we gained the @ operator and don't have the rest.
  • deleted 5y ago
    [deleted]