The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)
Mark S. Miller
erights at google.com
Sat Jun 20 20:35:41 UTC 2015
On Sat, Jun 20, 2015 at 11:18 AM, Bill Frantz <frantz at pwpconsult.com> wrote:
> While I am also concerned with the problem of ever-expanding languages
> because the larger they grow, the harder they are to learn, and the harder
> it is to read someone else's code which uses unfamiliar features, there are
> other issues that are equally important.
> I find the most unappreciated feature of a language is the list of things
> it can't do. For a bit of background, my first program was written in
> machine language, and after struggling with it, the instructor introduced
> the class to a wonderful tool: assembler language. Sufficient to say, I
> know about languages with built in footguns.
> The advantage of having a language that doesn't allow certain things is
> that you don't have to worry about them when you are debugging or reviewing
> a program. Memory safety is high on the list of useful features which JS
> has. Another very valuable feature is the ability to limit what a piece of
> code can do before you invoke it. In the JS arena, this kind of limitation
> allows web sites which give their users security assurances to run
> arbitrary JS provided by advertisers. ES2015 has a number of features to
> support this usage, but because of the need to not "break the web", they
> are a bit delicate to use.
> It would be good to include a list of the things you can't do in the
> language specification so failures in this area are clearly bugs in either
> the implementation or the specification. I would suggest for JS that this
> list include the things required for confining a piece of JS code running
> within a larger environment, like a web page to keep it from doing all the
> things the web page can do.
Hi Bill, regarding the list of bullets
On Fri, Jun 19, 2015 at 11:12 AM, Mark S. Miller <erights at google.com> wrote:
> * fundamental syntax -- the special forms that cannot faithfully be
> explained by local expansion to other syntax
> * semantic state -- the state than computation manipulates
> * kernel builtins -- built in library providing functionality that, if
> it were absent, could not be provided instead by user code.
> * intrinsics -- libraries that semantic state or kernel builtins depend
> on. For example, with Proxies, one might be able to do Array in user code.
> But other kernel builtins already have a dependency on Array specifically,
> giving it a privileged position over any replacement.
> * syntactic sugar -- the syntax that can be explained by local expansion
> to fundamental syntax.
> * global convenience libraries -- could be implemented by unprivileged
> user code, but given standard global naming paths in the primordial global
> * standard convenient library modules
your point is another reason to prioritize the first four bullets over the
last three. To understand what can't be done requires a deep understanding
of at least the first three and arguably the fourth. However, the last
three bullets cannot have any effects on the inabilities provided by a
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss