pwpwp

Light gray text on white??

The fires in HSS in Germany were determined using web crawling for the year 2023 because no other data was available. All other probabilities were calculated using researched data. The results show a significantly lower probability of an HSS fire compared to a general house fire.

Seems legit.

covid

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.

You can put the actual definition on page 4, or you can make it easy for the reader and just say "hypermedia controls (like links and buttons)" the first time you mention the term in the abstract.

So I've read the title and the abstract, and I still have no idea what a "hypermedia control" is.

Maybe address any of the issues raised in the post?

Actually, I built this because I don't really understand async/await. Now that I understand generators (somewhat), I might be able to grok async/await ;-)

IOW, there isn't any real stack growth, it just appears that way when running in the devtools with the "async call stacks" feature enabled.

This appears to be an artefact of the "async call stacks" feature.

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".

T: http://mumble.net/~jar/tproject/

Overall I agree: yes, with fexprs you lose some code introspection ability compared to macros. I haven't found it to be a big deal in my fexpr-based hobby Lisp so far.

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.

I find the claim about image-based development being required for macros somewhat unfounded.

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.)

Those things take time. I am convinced that the next big Lisp dialect will be a Kernel.

Lack of compilation for fexprs is:

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.

This is all documented.

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.

Good points!

I don't find this convincing.

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.

Does the WASM port include full-text search (FTS)?

Every worker can only access a fixed set of databases?

Would be useful if this had a comparison with Emacs, which also resolves the GURQ.

It's missing #DADB0D

Does this support RTC data channels, too, or just A/V?

Is this related to the EmDrive?

Northern Italy's health system also collapsed in 2018 (and probably other years, too) from the flu:

https://translate.google.com/translate?sl=it&tl=en&u=https%3...

IDGI, just store the structured data in Git.

No fexprs? https://web.cs.wpi.edu/~jshutt/kernel.html

Genode is really great, check it out: https://genode.org/documentation/genode-foundations/

One of the newest Lisp dialects, Kernel, is pretty close to lambda calculus, though. Like in LC, there is no implicit evaluation of arguments. A fexpr receives the "source code" of its input expressions, similar to LC. Then it can explicitly evaluate those it cares about.

https://web.cs.wpi.edu/~jshutt/kernel.html

MacPaint and QuickDraw Source Code https://www.computerhistory.org/atchm/macpaint-and-quickdraw...

The only way to get higher-order control in CL is through whole-program rewriting, e.g. SCREAMER https://www.cliki.net/screamer so I think this qualifies as "can't".