Lisp advocacy (for the last few decades) is always about how you can write anything in 10 lines of macros, but I never see anyone discuss security or whether the result actually does what you meant it to do.
Macros are "just" functions whose inputs are S-expressions and outputs are S-expressions, and they are run at compile-time and not run-time. The semantics of the execution of a macro corresponds more or less to the semantics of Lisp itself, which, in a simplified view, can be completely understood in a first course in computer science (as in SICP).
Any statements about correctness of a macro will derive from statements about correctness of code more broadly, for which there's a lot of literature and is an ongoing active and popular field of research.
Any statements about the security implications of a macro will derive from (1) statements about the security of a compiler more generally and (2) statements about code more broadly, both of which have lots of literature, and both of which have active research communities.
I don't know if there are many useful things to frame around security and correctness about macros specifically (without resorting to the above derivations), which is probably why there's no literature that I know of about it.
There is no the implementation of JavaScript. There are several, all with their own issues, security and otherwise.
(The implementation is usually the one with the security issues, not the programs you run on it. Of course, either one’s possible if it crosses a trust boundary.)
I don't think anybody has done a formal study or written some kind of report on the security of said implementations, however.
A gentleman named Paul Dietz implemented something called the "ANSI compliance test suite" [1], which is an implementation-agnostic battery of tests that examines how well an implementation adheres to the ANSI specification of Common Lisp. Dietz is also known for his prolific fuzz and randomized testing of Common Lisp implementations. He's been a source of obscure bug reports for years, and those bugs are always promptly fixed.
I did think of a specification-level security issue - bignums reduce math errors but mean operations are O(N), which puts you at great risk of DoS issues and sidechannel leaks in security-sensitive math.
And of course Lisp’s features like macros tend to be powerful, and security has a “rule of least power” meaning those are harder to verify if you can’t statically analyze them.
Sure, the Common Lisp standard specifies a default syntax mode, where the s-expression reader (-> the function READ) can execute arbitrary code at read time.
It does still have the other similarities; it has closures and a prototype based object system. In the 90s we only had boring Blub languages, so most of the influence that allowed such powerful concepts came from Lisp. (Though I think the prototypes are from Self.)
JS has other differences on the “correctness” spectrum, like all numbers are doubles instead of bignums. But even if that’s “incorrect”, just imagine how much more memory your Chrome tabs would use if you let people use bignums everywhere.
Bye, why would a fully numeric tower js only use the least machine friendly format everywhere ? Did I miss something ?
do you have any link to a source for this claim?
AFAIK JavaScript started as a language called Mocha, which was hacked together in a few days: Java syntax, Scheme functions + Self object system + plus a bunch of other things.
At that time: no symbols, no s-expressions, no cons cells, no lists, no macros, no tail call optimization, ...
Macros allows you to decompose and simplify problems in a way that is impossible with functions. Macros are especially good at removing boilerplate and writing syntactic glue code.
Since macros are programs making sure that they do what you meant them to do you can use similar techniques as you use for other programs: making them small and obvious, testing.
And what do you mean about doing what you mean it to? The semantics of macro expansion are well-defined.
Does Lisp do anything more than other similar languages to help you avoid mistakes in meaning? I guess not. But it doesn’t claim to, as you say, so what’s the problem?
Lisp advocates don’t talk about something Lisp doesn’t claim to do and most other languages don’t do. Why’s that surprising?
But the main argument is that Lisp is hyperproductive if you’re an individual brain genius who’s memorized every emacs key combo. And my point is that it doesn’t matter if you can produce something fast if you can’t know if that thing actually works.
This is the traditional “static vs dynamic typing” argument but you know, a lot of new languages have new kinds of safety features going beyond “static typing”.
And of course Lisp does make unusual decisions affecting safety. Making all numbers bignums means math is more likely to be correct since it won’t overflow, but untrusted user input can pretty easily DoS you.
> But the main argument is that Lisp is hyperproductive if you’re an individual brain genius who’s memorized every emacs key combo.
I certainly haven't, though I suspect this is a bit of an exaggeration.
In reality things that are hopelessly broken and released quickly win market share all the time which is in contradiction to your statement.
The old Tony Hoare quote seems apt: "There are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors."