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
On Tue, Feb 2, 2010 at 5:16 PM, Mark S. Miller erig...@google.com wrote:
On Fri, Jan 29, 2010 at 5:13 PM, David Herman dher...@mozilla.com 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.
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
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 http://wiki.ecmascript.org/doku.php?id=harmony:destructuring
, I would define your ImportDeclaration as
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
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.
This
[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 users.
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
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 that
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
allen.wirfs-br...@microsoft.com wrote:
One of the points that I recall is the importance of not entangling “module
management” with “configuration
- 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 module system is a
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
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,
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
-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: The
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 and
On Thu, Feb 4, 2010 at 10:11 AM, David Herman dher...@mozilla.com 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
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 dher...@mozilla.com wrote:
How about module group?
But it's not a group of modules; it's a group of their instances (or
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 that a
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 imprecise,
On Wed, Feb 3, 2010 at 3:11 PM, David Herman dher...@mozilla.com 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
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 dher...@mozilla.com wrote:
Well, a module system is a language
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
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
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
On Thu, Feb 4, 2010 at 12:06 PM, David Herman dher...@mozilla.com 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
On Thu, Feb 4, 2010 at 11:50 AM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com 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?
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
On Wed, Feb 3, 2010 at 12:39 PM, Brendan Eich bren...@mozilla.com 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
29 matches
Mail list logo
