Debuggers don’t go back; you have to restart and run through the whole thing

Yes, they do: https://rr-project.org/

https://sourceware.org/gdb/current/onlinedocs/gdb.html/Reverse-Execution.html

OK, my code snippets are Common Lisp. But note that none of them involve list/vector/set literals. I was thinking of [] for array indexing and {} for code blocks.

As for infix macros, sure, that's not hard to do, but it's not built into the language and there being "plenty of libraries" is part of the problem: They're all subtly different, none are standard, and I suspect most people don't use them anyway. (Plus there's fun little design issues like whether a*x + b should parse the same as a * x + b, and if it does, then how do you refer to a variable called a*x from an infix environment?)

It doesn't solve the main issue anyway. Take this snippet from the "infix" readme:

(def hypot  (fn [x y]    (infix sqrt(x ** 2 + y ** 2))))

It ends with a cluster of )))) (reinforcing the "lots of parentheses" impression) and all of those parentheses mean something different: From the outside in, we have the end of a symbol definition (def ...), the end of a function (fn ...), the end of a macro invocation (infix ...), and the end of a function call sqrt(...). It definitely isn't just "the same number [of parentheses] as any other language that uses parentheses to make function calls".

Compare e.g. these versions written in Haskell:

hypot = \x y -> sqrt (x ** 2 + y ** 2)

... or Perl:

sub hypot($x, $y) {    sqrt($x ** 2 + $y ** 2)}

... or if you want to separate the function and symbol definition parts:

*hypot = sub ($x, $y) { sqrt($x ** 2 + $y ** 2) };

I, too, love living in a society that never makes errors, ever, as I myself am quite infallible. https://www.web3isgoinggreat.com/

That's just syntax.

>>> 10 .yearsTraceback (most recent call last):  File "<stdin>", line 1, in <module>AttributeError: 'int' object has no attribute 'years'

Prost! 🍻

To be fair, the C example could be detangled a lot by introducing a typedef:

typedef int Callback_t(int, int);Callback_t *(*fp)(Callback_t *, int);

Both of those declarations look weird to me. In Haskell it would be:

a :: Stringbob :: (String, Int, Double) -> [String]bob (a, b, c) = ...

... except that makes bob a function taking a tuple and it's much more idiomatic to curry it instead:

bob :: String -> Int -> Double -> [String]bob a b c = ...-- syntactic sugar for:-- bob = \a -> \b -> \c -> ...

The [T] syntax also has a prefix form [] T, so [String] could also be written [] String.

OCaml makes the opposite choice. In OCaml, a list of strings would be written string list, and a set of lists of strings would be string list set, a list of lists of integers int list list, etc.

I don't understand the complaint. What exactly is the issue?

I'll update my mems when Microsoft decides to implement C99. (Hey, it's only been a quarter of a century ...)

Isn't this COBOL or 4GL or something?

@racketlauncher831 As far as the C compiler is concerned, there is literally no difference between those two notations. If you declare a function parameter as an array (of T), the C compiler automatically strips the size information (if any) and changes the type to pointer (to T).

(And if we're talking humans, then char *args[] does not mean "follow this address to find a list of characters" because that's the syntax for "array of pointers", not "pointer to array".)

@yogthos ... written by @aphyr