The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

Mark S. Miller erights at google.com
Fri Jun 19 18:12:55 UTC 2015


On Fri, Jun 19, 2015 at 12:29 PM, Alex Russell <slightlyoff at google.com>
 wrote:

> I do not share Mark's view. Contra his sentiment, I was using the "small"
> version of JS for many years and noted that most non-trivial uses required
> finding or building a library. That choice of library (which exist to fill
> in platform and language deficiencies) leads to a a split in common use
> that's just as pernicious as "choosing a subset".
>
> Writing JS in the large continues to need more help.
>
>
On Fri, Jun 19, 2015 at 10:42 AM, Mark Volkmann <r.mark.volkmann at gmail.com>
wrote:

> It sounds like you are advocating for a larger standard library in JS. I
> think many on this thread are focusing on whether more syntax features
> should be added.
>


First, from many arguments with Alex, I am indeed confident that Alex and I
have different views about these matters.

In my post, I definitely meant more than syntax, but I also agree that the
force of my point gets weaker as we move from core language to
standardizing libraries. The overall standard language can be seen as
consisting of these major parts:


  * 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
namespace.
  * standard convenient library modules


I have listed these in order, according to my sense of the costs of growth
and the urgency for minimalism. For all of these we still need to exercise
discipline. But it is only for the last one that we should consider growth
of absolute size to be unbounded; restricting ourselves only to the rate of
growth as we wait for candidates to prove themselves first by the de facto
process. Ideally, TC39 should stop being the bottleneck on the last bullet
anyway, as external de facto and de jure processes should be perfectly
capable of independently arguing about and evolving standard convenience
modules.


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150619/ba34a097/attachment-0001.html>


More information about the es-discuss mailing list