Seems legit.

I don't understand this part. The people who left X after Musk's takeover seem to be mostly people who were on the winning side of Covid, i.e. the side that used the state and media apparatus to coerce people to participate in a medical experiment.

Comments URL: https://news.ycombinator.com/item?id=40490866

Points: 2

# Comments: 1

To turn it off in Firefox, go to about:config and set "javascript.options.asyncstack" to false.

In Chrome, in Devtools enter ctrl+shift+p and search for "async stack traces".

Re your two points:

You could have "symbol fexprs", analogous to symbol macros, I guess.

For places I think the first-class solution as employed by T and others is better, and would work fine with fexprs: (set (name-of person-1) "sam") simply stands for ((setter name-of) person-1 "sam").

IOW, name-of is expected to be a reader function. Every reader function has a writer function attached to it, that we extract with (setter name-of). Then we call that writer function with the rest of the original arguments.

Comments URL: https://news.ycombinator.com/item?id=38905561

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=37612975

Points: 279

# Comments: 185

The most trivial counterexample is an interpreter - it can simply evaluate the macros just like ordinary functions.

A step up in complexity is a compiler that - during compilation - compiles macro definitions by emitting code and dynamically loading it (Goo does this http://people.csail.mit.edu/jrb/goo/goo.htm , and I have also put a toy implementation of this together using dlopen, and there are probably many other impls that do this.)

A) An exciting research problem! Shutt himself says that he doesn't see any fundamental obstacles to compiling them. It's just that nobody has done it yet.

B) Actually not a big deal for many applications. Take PicoLisp, which has been cheerfully used in customer-facing applications for decades. It's an ultra-simple interpreter (its GC is 200 LOC https://github.com/picolisp/picolisp/blob/dev/src/gc.c ) The same architecture can be used for Kernel implementations.

Things have changed. Fexprs are coming back in a big way.

You need to check out John Shutt's Kernel language https://web.cs.wpi.edu/~jshutt/kernel.html

Yes, older Lisps messed fexprs up. Kernel fixes this. The vau calculus used by Kernel is simply a lambda calculus that, unlike CBN and CBV, doesn't implicitly evaluate arguments. The rest of the calculus is the same.

What this means is you get powerful hygienic metaprogramming (arguably as powerful or even more powerful than Scheme's most advanced macro systems) at a low low price and with very elegant theoretical properties. In Kernel, hygiene is achieved simply with the usual lexical scope that's already in lambda calculus.

So vau calculus is simpler than the CBV lambda calculus used by Lisps. Because it doesn't evaluate arguments, so it does less than those calculi. And by doing less it gains the great power of being able to do hygienic metaprogramming in the same calculus, without second-class contraptions like macros.

> What do you return for an index into the array?

An option/maybe type would solve this much better.

> Yes, I know, it can be clumsy to trace it back to its source

An exception would be much better, alerting you to the exact spot where the problem occurred.