Comment by geocar

5 hours ago

The "monograph game" as you put it, is not for mere funsies: We say x+y instead of plus(x,y) because the former is obviously better.

4 comments

geocar

Reply
psychoslave  2 hours ago

Anything can be credited better for some metric and evaluation scale, and what is obvious to one can be surprising to someone else.

x+y is several step away from plus(x,y), one possible path to render this would be:

  x+y
  x + y
  + x y
  + x , y
  + ( x , y )
  + ( x , y )
  +(x,y)
  plus(x,y)

And there are plenty of other options. For example considering method call noted through middot notation:

  x·+(y)
  x·plus(y)
  x·plus y
  augend·plus(addend)
  augend·plus addend

And of course the tersest would be to allow user to define which operation is done on letter agglutination, so `xy` can be x×y or x+y depending on context. The closest things I aware being used in an actual programming language is terms like `2x` in Julia interpreted as "two times x". But I don’t think it allows to configure the tacit operation through agglutination, while it’s allowing to switch first index to be 0 or 1 which is really in the same spirit of configurability over convention.

  • geocar  32 minutes ago

    > and what is obvious to one can be surprising to someone else.

    That is how obvious things work. If you were not surprised that a[i:j] and :[a;i;j] are the same (: a i j) then it is because it was obvious to you, and now that you have had it pointed it out to you, you were able to show all of the different other variants of this thing without even being prompted to, so I think you understand the answer to your question now.

volemo  4 hours ago

I say (+ x y). :P

  • geocar  2 hours ago

    I was distracted by this too; I programmed largely in CL and emacs from 1999-2014.

    I highly recommend reading: https://dl.acm.org/doi/10.1145/358896.358899

    One thing that helped me tremendously with k (and then APL) was when I noticed the morphism xfy<=>f[x;y]<=>(f x y).

    This wasn't a new idea; it's right there in:

    https://web.archive.org/web/20060211020233/http://community....

    starting almost the first page (section 1.2). I simply had not considered the fullness of this because a lot of lispers prefer S-expressions to M-expressions (i.e. that there's more study of it), largely (I conjecture) because S-expressions preserve the morphism between code and data better, and that turns out to be really useful as well.

    But the APL community has explored other morphisms beyond this one, and Whitney's projections and views solve a tremendous amount of the problems that macros solve, so I promise I'm not bothered having macros slightly more awkward to write. I write less macros because they're just less useful when you have a better language.