6 ms·

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 intere

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_enjarify_in_go_and_rust/ https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

UncombedCoconut 5y ago
FWIW: A pattern along these lines is in B of A's Quartz, allowing the construction of table filters like "Where('colname') <<inlist>> ['cat', 'dog']".
dataflow 5y ago
> infix operator is a bad idea outside of math operations, in my opinion What about string + string?
- powersnail 5y ago
  I was too rash with my comment. Indeed, string + string is also quite intuitive.
  - dataflow 5y ago
    Haha no worries. I think there are more cases outside (what ordinary folks would call) "math", where infix operators make sense; they're just not as common or obvious. Like one example is when you want to build expression trees; you're not actually doing math there, but merely creating a representation of the very expressions you're writing. Another one is &, |, ^, ~ for enum flags (which you can define bitwise so it's "math" in that sense, but which you might want more domain-specific logic for). Another one is overloading <, =, > for arbitrary objects. And so on. I think the real rule is "it should be intuitive rather than confusing". :-)
- naniwaduni 5y ago
  It's always been a bad idea, because concatenation is a natural product, not a sum. We should write string * string.
  - deleted 5y ago
    [deleted]
  - dataflow 5y ago
    I guess, but that ship sailed already.
  - lisper 5y ago
    > concatenation is a natural product, not a sum Huh? Why?
    - dataflow 5y ago
      Because monoids, abstract algebra, etc. More simply, "addition" is generally defined as a commutative operation, which this isn't. When people want a non-commutative operation, they call it "multiplication". For a more superficial but tangible reason, if you just consider the notation, AB is the concatenation of A and B, which is the notation for a product in math. (Recall putting "A" "B" next to each other in Python literally means concatenation, and it's a product in math.)
      - housecarpenter 5y ago
        I think when mathematicians call an operation denoted by juxtaposition a "product", that's usually because it's denoted by juxtaposition for some independent reason and they're drawing the syntactic analogy with the numerical product, and there isn't any deeper connection with multiplication than that. Independent reasons for using juxtaposition might include: 1. juxtaposition is shorter than any alternative and hence a natural choice for the most common / only operation on the set in question 2. the operation is roughly analogous to function composition, and when you apply two composed functions it looks like f(g(x)) with f and g juxtaposed (if the functions are among those that have the longest history of being written as prefix operators, e.g. sin, cos, log, you don't even need the paren between the f and the g) 3. juxtaposition is a natural way to express an operation which is just "putting stuff together", such as string concatenation So while it makes sense to denote string concatenation by juxtaposition in mathematics, I think it's a bit of a leap to go from there to say that A * B is the right notation for a programming language. (Actually using juxtaposition would be fine, but a general-purpose programming language is likely to want to reserve juxtaposition for something else.) Also if you run with the idea that string concatenation = putting two strings together, well, addition is sort of like putting two numbers together. Rephrasing that in mathematical language: natural numbers can be encoded as elements of the free monoid on one generator, in which case the monoid operation turns out to be addition. I think that might be why the A + B notation is preferred over A * B when we have to choose one or the other.
- cttet 5y ago
  not quite, since `a + b != b + a` feels a bit weird.
  - dataflow 5y ago
    I think you missed the other thread... https://news.ycombinator.com/item?id=30081517 https://news.ycombinator.com/item?id=30081517
    - cttet 5y ago
      (a, b) would make more sense if then. Jokes aside, + also quite break the reading flows of the string such as user_name + ": " + attr1 + "| " + attr2 + "\n" is more difficult to parse by eyeball for me then concat(user_name, ": ", attr1, "| ", attr2, "\n")
      - dataflow 5y ago
        I mean sure, but the fact that you had to write 6 strings to illustrate this should tell you something, right? This user_name + ": " + attr1 is easier to eyeball than concat(user_name, ": ", attr1)
        cttet 5y ago
        To me they are similar though. I used Python quite a lot, for string concatenation, I mostly use fstrings. `+` is used mostly in the `+=` case.
bayesian_horse 5y ago
I can see how it could be useful in actually increasing readability. Just as always, use with caution.

UncombedCoconut 5y ago

FWIW: A pattern along these lines is in B of A's Quartz, allowing the construction of table filters like "Where('colname') <<inlist>> ['cat', 'dog']".

dataflow 5y ago

> infix operator is a bad idea outside of math operations, in my opinion What about string + string?

powersnail 5y ago
I was too rash with my comment. Indeed, string + string is also quite intuitive.
- dataflow 5y ago
  Haha no worries. I think there are more cases outside (what ordinary folks would call) "math", where infix operators make sense; they're just not as common or obvious. Like one example is when you want to build expression trees; you're not actually doing math there, but merely creating a representation of the very expressions you're writing. Another one is &, |, ^, ~ for enum flags (which you can define bitwise so it's "math" in that sense, but which you might want more domain-specific logic for). Another one is overloading <, =, > for arbitrary objects. And so on. I think the real rule is "it should be intuitive rather than confusing". :-)
naniwaduni 5y ago
It's always been a bad idea, because concatenation is a natural product, not a sum. We should write string * string.
- deleted 5y ago
  [deleted]
- dataflow 5y ago
  I guess, but that ship sailed already.
- lisper 5y ago
  > concatenation is a natural product, not a sum Huh? Why?
  - dataflow 5y ago
    Because monoids, abstract algebra, etc. More simply, "addition" is generally defined as a commutative operation, which this isn't. When people want a non-commutative operation, they call it "multiplication". For a more superficial but tangible reason, if you just consider the notation, AB is the concatenation of A and B, which is the notation for a product in math. (Recall putting "A" "B" next to each other in Python literally means concatenation, and it's a product in math.)
    - housecarpenter 5y ago
      I think when mathematicians call an operation denoted by juxtaposition a "product", that's usually because it's denoted by juxtaposition for some independent reason and they're drawing the syntactic analogy with the numerical product, and there isn't any deeper connection with multiplication than that. Independent reasons for using juxtaposition might include: 1. juxtaposition is shorter than any alternative and hence a natural choice for the most common / only operation on the set in question 2. the operation is roughly analogous to function composition, and when you apply two composed functions it looks like f(g(x)) with f and g juxtaposed (if the functions are among those that have the longest history of being written as prefix operators, e.g. sin, cos, log, you don't even need the paren between the f and the g) 3. juxtaposition is a natural way to express an operation which is just "putting stuff together", such as string concatenation So while it makes sense to denote string concatenation by juxtaposition in mathematics, I think it's a bit of a leap to go from there to say that A * B is the right notation for a programming language. (Actually using juxtaposition would be fine, but a general-purpose programming language is likely to want to reserve juxtaposition for something else.) Also if you run with the idea that string concatenation = putting two strings together, well, addition is sort of like putting two numbers together. Rephrasing that in mathematical language: natural numbers can be encoded as elements of the free monoid on one generator, in which case the monoid operation turns out to be addition. I think that might be why the A + B notation is preferred over A * B when we have to choose one or the other.
cttet 5y ago
not quite, since `a + b != b + a` feels a bit weird.
- dataflow 5y ago
  I think you missed the other thread... https://news.ycombinator.com/item?id=30081517 https://news.ycombinator.com/item?id=30081517
  - cttet 5y ago
    (a, b) would make more sense if then. Jokes aside, + also quite break the reading flows of the string such as user_name + ": " + attr1 + "| " + attr2 + "\n" is more difficult to parse by eyeball for me then concat(user_name, ": ", attr1, "| ", attr2, "\n")
    - dataflow 5y ago
      I mean sure, but the fact that you had to write 6 strings to illustrate this should tell you something, right? This user_name + ": " + attr1 is easier to eyeball than concat(user_name, ": ", attr1)
      - cttet 5y ago
        To me they are similar though. I used Python quite a lot, for string concatenation, I mostly use fstrings. `+` is used mostly in the `+=` case.

bayesian_horse 5y ago

I can see how it could be useful in actually increasing readability. Just as always, use with caution.