[HN Gopher] A trick to have arbitrary infix operators in Python
       ___________________________________________________________________
        
       A trick to have arbitrary infix operators in Python
        
       Author : prionassembly
       Score  : 62 points
       Date   : 2022-01-24 12:58 UTC (1 days ago)
        
 (HTM) web link (tomerfiliba.com)
 (TXT) w3m dump (tomerfiliba.com)
        
       | powersnail wrote:
       | This is hilarious. Probably nobody is going to use this in
       | production, (infix operator is a bad idea outside of math
       | operations, in my opinion), but it's interesting to see how much
       | you can coerce a language into almost a different language
       | altogether.
       | 
       | This is on par with the "Generics in Go"^1 hack. Is there a list
       | of this kind of funny language hack somewhere?
       | 
       | [1]:
       | https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
        
       | dragonwriter wrote:
       | > As you may already know, there are 3 kinds of operators
       | calling-notations: prefix (+ 3 5), infix (3 + 5), and postfix (3
       | 5 +)
       | 
       | There's more than that; Raku, for instance, recognizes two more
       | classes: _circumfix_ (pair of symbols defining operator surrounds
       | operands) and _postcircumfix_ operators (like circumfix, but with
       | an additional first operand outside of a preceding the paid of
       | symbols), and lets you define new operators in any of the five
       | notational classes.
        
       | barrenko wrote:
       | Just stop.
        
       | animal_spirits wrote:
       | (2012)
        
       | assbuttbuttass wrote:
       | This is pretty neat, but I always find I prefer the simplicity
       | and extensibility of lisp's syntax, despite the difference to
       | math notation. For example, the author's example of
       | add(add(add(5,6),7),8)... is just (+ 5 6 7 8 ...).
       | 
       | Haskell supports custom infix operators, but you end up having an
       | unreadable soup of <* <$> <$ >>=
        
         | toomanydoubts wrote:
         | >but you end up having an unreadable soup of <* <$> <$ >>=
         | 
         | True to some extent. After learning haskell, I find these
         | operators very readable actually.
        
           | dataangel wrote:
           | How do you Google them? As a Haskell newbie this was a big
           | problem for me.
        
             | bobbylarrybobby wrote:
             | Often, by type signature using Hoogle
        
             | yoyohello13 wrote:
             | In ghci you can do:
             | 
             | Prelude> :doc <$>
             | 
             | and
             | 
             | Prelude> :t (<$>)
        
             | lalaithion wrote:
             | https://hoogle.haskell.org/?hoogle=%3C%24%3E
        
       | atorodius wrote:
       | Pretty neat trick. I often wish for a built in way to do a bit
       | more operator magic, but I can see why it would be bad to have
       | it.
        
       | joe_the_user wrote:
       | People are used to math infix operators and can use them
       | efficiently.
       | 
       | But working with infix operators in other contexts would be a
       | complete nightmare. Limiting what a given expression can "bind"
       | to, what it can form a large expression with, is a way to limit
       | the processing needed to understand a given piece of code. Being
       | able to say one thing a hundred different ways isn't good if the
       | read has to search for a hundred different maybe-meanings a given
       | string might have.
        
         | ogogmad wrote:
         | Sometimes it's nice to be able to do piping:
         | object | dothis | dothat | dosomething
         | 
         | I suppose the piping operator is infix. I feel like some of the
         | advantages of the notation                 object.f()
         | 
         | over                 f(object)
         | 
         | in object oriented programming are due to this.
        
           | runevault wrote:
           | I love |> in f# because of this type of thing, piping
           | operations together instead of nesting or the like just reads
           | so much cleaner. And yes in cases where they are all methods
           | on the type you can have the function return self and then do
           | value.Func1().func2().func3().etc() but only if they are
           | methods on the class.
           | 
           | But I also don't care for arbitrary infix operators (which
           | I'm pretty sure f# supports but I haven't used it in a way
           | where I run into them). I know I'm crazy but I almost wish we
           | did away with ALL infix operators, even stuff like +/-* and
           | just do everything as functions. You know, like Lisp :P
        
         | yccs27 wrote:
         | Yeah, relying on operator precedence makes for some of the most
         | infuriating to read code.
        
       | yccs27 wrote:
       | 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 language. Probably the reason why
       | Python disallows custom operators.
       | 
       | Incidentally, the Wolfram Language has a similar notation for
       | arbitrary functions: a~Plus~b.
        
         | srcreigh wrote:
         | Racket does too.                   (when (0 . < . x)
         | (displayln "positive"))
         | 
         | Although in Racket you could also add your own syntax.
        
       ___________________________________________________________________
       (page generated 2022-01-25 23:00 UTC)