💾 Archived View for idiomdrottning.org › re-reasons-for-operators captured on 2023-01-29 at 17:00:54. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
➡️ Next capture (2024-06-16)
-=-=-=-=-=-=-
This debate between Conman and Drew left my head spinning.
Do you even Lisp?
Some issues with the example: it says 1.9 but it should be 1.0, and there’s also a design issue in that fmul is biadic. Also, the reference operator, &, is also an operator.
But let’s stick with the biadic version here and leave that & and “1.9” in for now. Notice what happens with a li’l paredit magic?
fassign(&xn1,
fmul(
fmul(
fadd(
fmul(A,
yn),
B),
xn),
fsub(1.0,
xn)))
fassign(&yn1,
fmul(
fmul(
fadd(
fmul(C,
xn),
D),
yn),
fsub(1.9,
yn)))
We get direct programmatic access to the syntax tree itself! Perfect for writing metaprograms. Of course, that would look nicer without those cluttersome commas.
Laid out in a tree like this, you can see exactly what gets added to what, what gets multiplied with what etc.
Also, you can see that those programs are doing the same thing but just doing it to different vars. In Scheme-style Lisp, this program would look like this:
(define (frob f o dh dv) (* (+ (* f dv) o) dh (- 1 dh))) (define xn1 (frob a b xn yn)) (define yn1 (frob c d yn xn))
Yes, * and + are valid function names in Scheme.
As for the overloading or not camp, I obv come down in favor since while Scheme doesn’t inherently have overloading I added it to brev. I love magic!
The fanciest define of all time
JBanana chimed in with a similar sentiment,
to which I’ll add that the reason Lisp has parens is so that it can support variadic forms like lambda.
For an example, Idiomdrottning’s define (which is a type of overloading, it replaces a built-in form with a custom one) would be so confusing to me if I was to jump into and try to contribute to a program using it. It works like a normal define all throughout, and then all of a sudden it does something totally unexpected. [...] She even wrote about the unexpected and subtle pitfalls of the alternate define, which someone looking at some subsection of a codebase would never expect until their modifications mysteriously don’t work as expected.
Hahaha, yeah. (Soon enough brev will almost be like it’s own li’l dialect of Lisp.)
This define really is a hilarious and very appropriate example of the kind of magicky implicit programming that you guys are against, because not only is define, the most core of the core functions overloaded… The purpose of the overloading and what the new version can do is to create overloaded versions of other functions! (A la Java, or rather, Haskell since it can destructure).
It’s certainly fair game for this kinda criticism!
I mean, I love this style of programming and I made this define that way on purpose. I can see the more explicit, Zig-school programming that y’all favour as sometimes getting overly boilerplatey, “the human compiler at work”.
Me trying to go “this define doesn’t apply to what you are criticizing” would be a complete self-foot-shot since it was made to be a core part of the high-magic language I’ve always dreamed of. It’s part of my overall reaction to reading stuff like the “no hidden control flow” here.
(Now, I think Zig is absolutely awesome as a systems/backend language, and would love to see, for example, Chicken switch to using it as a backend instead of C.)
The one note I have is around the “smug Lisp vs C debate”: it seemed to me that these peeps weren’t debating against Lisp, they were debating as if they had never heard of the basics of Lisp. For example the difference between functions and operators, or the issues of prefix vs infix. It’s less that I was saying “Lisp is so much better than C” (I mean, it is, but that’s not the conversation I thought I was started), it was more “Whoa, spend a few months with Lisp and you’ll get a new perspective on this debate”.
(Note “as if they had never” isn’t the same as saying “they had never”; I’m only saying that to the extent that they had, they weren’t making that clear.)
I’m not good at verbalising the point I’m trying to make here, the point being the core of the whole “pre- and postfix-languages are laid out in a way that resembles the syntax tree” spiel.
Speaking of “the spookiness doesn’t apply to my fave thing” line of arguments,
mbays proposed that typeclasses can make it less spooky.
I kinda don’t agree with that.
For example, in Haskell, you can have a method do one thing on an empty list and another thing on a non-empty list. Which is awesomely spooky and magic and I love it and that’s also how the fancy brev define works (by leveraging the hard work done in the wonderful “matchable” library).