On Fri, Jun 19, 2015 at 12:29 PM, Alex Russell <[email protected]> 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 <[email protected]> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
