Re: simple modules

I thought I would also mention that contexts (as in execution context), sandbox, security and other terms are also heavily used in html5. Defining a module framework without at least being familiar with current and upcoming browser environments may result in an implementation that is at odds w

Re: simple modules

On Tue, Feb 2, 2010 at 5:16 PM, Mark S. Miller wrote: > On Fri, Jan 29, 2010 at 5:13 PM, David Herman wrote: > >> We had a good discussion about modules at this week's meeting, and Sam >> Tobin-Hochstadt and I have worked out a strawman for a simple module system. >> I've posted a first draft to

Re: simple modules

Is there a fundamental theoretical comp sci reason why module state is shared? Is the core idea of using lexical scoping in the simple_module proposal undermined by not having shared state. If not, could possibly non-shared state be the default behaviour. And shared state modules - which share sta

Re: simple modules

On Feb 2, 2010, at 5:16 PM, Mark S. Miller wrote: * I find your import syntax too complicated and too redundant with other concept already on the proposals page. Given , I would define your ImportDeclaration as ImportDeclarat

Re: simple modules

Hi Mark, Thanks for the detailed feedback. > * You list "Dynamic upgrade" in the goals and then mention it again in a TBD. > I do not understand how this proposal could be stretched to accommodate > dynamic upgrade. I also do not think this is a criticism. I only mention it > since it is one o

Re: simple modules

On Feb 3, 2010, at 12:20 PM, David Herman wrote: Although it should perhaps not be possible to export a `let' binding; those really are supposed to be purely local. The issue arises because we do want 'const' bindings to be exportable, and they are supposed to be block-scoped exactly like '

Re: simple modules

On Feb 2, 2010, at 6:23 PM, Kris Kowal wrote: Different module contexts may have different module ID resolvers, so for example it would be possible for host environments to provide a SecureESContext that didn't allow identifiers to resolve to the "filesystem" module or the "dom" module. T

Re: simple modules

[including the list, which got inadvertently cut] > Yes, I understand that short import is not "with", it just "smells" > like "with" and like "global". Your reasons are correct for language > implementers and I am telling about language users. To be clear: this is not for implementers, it's for

Re: simple modules

On Feb 3, 2010, at 11:10 AM, Kevin Curtis wrote: Is there a fundamental theoretical comp sci reason why module state is shared? Sam knows more about such things than I do, but my answer is "who cares?" :-P Computer scientists and programming-language theorists do not all agree on whether

RE: simple modules

I don't really think that "module state" should be a formal concept in a "second class" module system where modules are just units of static code organization. Such modules have little if anything to do with computational state. It is the declarative and imperative code within the module tha

Re: simple modules: module managment vs. configuration management

Hi Allen, Since this thread was referred to by the "simple modules" thread, here are some remarks. On Sat, Jan 30, 2010 at 7:43 PM, Allen Wirfs-Brock wrote: > One of the points that I recall is the importance of not entangling “module > management” with “configuration management”. ... > Module m

Re: simple modules

>> - a "module context" is a set of module instances > > Please call this something else. Okay. > It is confusing for "context" to > mean "execution context" and "module context" depending on the > "context". I've called this a "system of modules" or "sandbox of > modules" in the past. Well, a

Re: simple modules

> If not, could possibly non-shared state be the default behaviour. And shared > state modules - which share state within contexts - are somehow marked as > shared at module definition. e.g. > module ModShared { > "use shared" // or some mechanism to signify shared state > ... IMO, this would be

Re: simple modules: module managment vs. configuration management

Reading over my comments, I realized I could summarize: Configuration management is just as important to the integrity of the code in modules as the code itself. Getting the wrong "version" of some important library can break your code just as badly as having a bug in your own code. With that, sca

Re: simple modules

On Wed, Feb 3, 2010 at 8:50 PM, Allen Wirfs-Brock < allen.wirfs-br...@microsoft.com> wrote: > It may be conversationally convenient to use the term “module state” to > talk about the computational values and binding created by the code within a > module but it really shouldn’t mean anything much d

RE: simple modules: module managment vs. configuration management

> -Original Message- > From: ihab.a...@gmail.com [mailto:ihab.a...@gmail.com] > Sent: Wednesday, February 03, 2010 12:52 PM ... > I don't have an issue per se with whether module IDs are string > literals or not, but just to guide where this is going, I'd like to > propose a candidate goal:

Re: simple modules

> Well, a "module system" is a language construct that provides modules. I > think "sandbox" sort of suggests more isolation than is necessarily provided. > PLT Scheme uses the worst possible name for the concept (I won't even say > what it is, it's so awful). > > I'll think about alternatives

Re: simple modules

On Thu, Feb 4, 2010 at 10:11 AM, David Herman wrote: > How about "module group"? But it's not a group of modules; it's a group of their instances (or whatever you want to call them -- the extension of the types in the modules). Ihab -- Ihab A.B. Awad, Palo Alto, CA

Re: simple modules

Yep. I thought ModuleInstanceGroup was a little over the top. :) Dave On Feb 3, 2010, at 3:30 PM, ihab.a...@gmail.com wrote: > On Thu, Feb 4, 2010 at 10:11 AM, David Herman wrote: >> How about "module group"? > > But it's not a group of modules; it's a group of their instances (or > whatever y

RE: simple modules

> > Well, a "module system" is a language construct I not sure I agree with that characterization. A Module is a "language construct" as it as specific syntactic element of the language. It is a specific thing that you have to learn about when you "learn" the language. It isn't clear to me tha

Re: simple modules

>>> Well, a "module system" is a language construct > > I not sure I agree with that characterization. A Module is a "language > construct" as it as specific syntactic element of the language. It is a > specific thing that you have to learn about when you "learn" the language. I was pretty imp

Re: simple modules

On Wed, Feb 3, 2010 at 3:11 PM, David Herman wrote: > > Well, a "module system" is a language construct that provides modules. I > think "sandbox" sort of suggests more isolation than is necessarily > provided. PLT Scheme uses the worst possible name for the concept (I won't > even say what it is

Re: simple modules

I like it. I might prefer "module loader" for a bit more concreteness. But it has the benefit of concreteness and familiarity. Dave On Feb 3, 2010, at 4:03 PM, Mark Miller wrote: > On Wed, Feb 3, 2010 at 3:11 PM, David Herman wrote: > > Well, a "module system" is a language construct that prov

Re: simple modules

On Feb 3, 2010, at 4:07 PM, David Herman wrote: I like it. I might prefer "module loader" for a bit more concreteness. But it has the benefit of concreteness and familiarity. +1 on module loader, loader for short. Thanks, Mark! /be Dave On Feb 3, 2010, at 4:03 PM, Mark Miller wrote: On

RE: simple modules

It's still not clear to me what we are trying to name? According to the proposal, a Module is a syntactic element that is part of an Application and Application can consist of multiple Modules. A complete Application is presumably represented by an external container such as a source file so w

Re: simple modules

Sorry for the confusion-- we're discussing a name for something that is not part of the current strawman. One of the things Sam and I were trying to do was separate the concerns of modularity and isolation. So there's a not-fully-worked-out strawman waiting to be written for isolation. That's wh

Re: simple modules

On Thu, Feb 4, 2010 at 12:06 PM, David Herman wrote: > The rough idea of the impending strawman is that there would be the ability > to create a new ModuleLoader with which one could load modules completely > isolated from the current setting. Isn't that just the "pim" portion of the emaker style

Re: simple modules

On Thu, Feb 4, 2010 at 11:50 AM, Allen Wirfs-Brock wrote: > ... or are we naming a specific semantic abstraction that we > intend to reify that permits some sort of dynamic intercessions in the > binding of ModuleSpecifiers, ... Yes, I think. Does everyone agree? Ihab -- Ihab A.B. Awad, Palo A

RE: simple modules

OK, I think I get the concept. I certainly agree that there is a real world need for a unit of isolation for the processing of groups of Applications (in the simple module proposal sense or Programs in the ES3 sense) . Such a unit would presumably represent independent processing of the group

Re: simple modules

On Wed, Feb 3, 2010 at 12:39 PM, Brendan Eich wrote: > On Feb 2, 2010, at 6:23 PM, Kris Kowal wrote: >> This verbiage implies black-listing.  It would be good to be clear >> that the object formerly known as a "module context" should be >> explicitly populated with a white-list of module instances