I understand that perfectly. What you are missing though is that extending 
keywords every which way leads to chaos in the language and is, ultimately, a 
very shortsighted solution. I will not reiterate the long list of how this 
affects the language.

For posterity, https://github.com/tc39/ecma262/issues/968

You may argue all you want about how elegant these solutions are, or how useful 
they are, or how they are needed, but this doesn’t change the fact that they 
look and feel chaotic, ad-hoc, half-baked solutions.

Moreover. All the talk about how horrible it would be to break existing code, 
existing design space etc. etc. clearly makes introduction of any complex, well 
designed APIs into the language an impossibility.

Oh, well. I’ve fought my fight. Onwards with “elegant solution of slapping 
metaproperties and function-like behaviour on top of existing things”. 
Hopefully, WebAssembly gets its GC and DOM support before this house of cards 
falls down.

On Sun, 06 Aug 2017 at 01:16 Matthew Robb

<
mailto:Matthew Robb <matthewwr...@gmail.com>
> wrote:

a, pre, code, a:link, body { word-wrap: break-word !important; }

Dimitri I think what you're missing is that while yes the current proposal and 
your proposal are not fundamentally different, the difference is that 
overloading keywords is overloading into previously non existent design space 
whereas overloading globals MUST consider the ramifications of overloading OVER 
existing design space.

On Aug 5, 2017 6:21 PM, "Logan Smyth" <
mailto:loganfsm...@gmail.com
> wrote:

> 

Nothing stops you from *explicitly* defining behaviour for `import.meta`. 
Nothing stops you from *explicitly* defining behaviour of 
Reflect/Proxy/Symbol/what-

have

-you.

> 

However, when the question comes to, say, replacing `import.meta` with `X.y.z`, 
it becomes nigh impossible.

As has been mentioned many times, backward-compatibility of a critical feature 
of JS. We can't take over the behavior of a random variable have have it do 
something else because it can break existing code. Other features are done 
carefully to avoid this issue, but your proposal does not avoid that.

> 

Here’s `import.meta` semantics rewritten for X.y.z. 

> 

X.y.z available only in module context. Usage outside raises a SyntaxError.

That will break existing code, making it immediately a no-go.

On Sat, Aug 5, 2017 at 3:09 PM, Dmitrii Dimandt

<
mailto:dmit...@dmitriid.com
>

wrote:

Honestly, I’ve seen the “you learn new thing and move on” so many times, I’m 
getting tired of it.

I have ~10 years of experience with PHP and ~5 years of experience with 
Coldfusion. Both experiences are pre-2010 (both languages somewhat improved 
since then, even though I don’t know whether Coldfusion is still being 
developed).

Both are, or were, *horrible* languages. Both were, no doubt, driven by “you 
learn new things and move on”. Probably the reason why Coldfusion in its script 
form didn’t have “less than” and “greater than” expressed as “<“ and “>”. You 
had to write “gt”, “gte”, “lt”, “lte”. Loads of fun. `if (x gt y)` etc.

Another argument I really don’t get is “oh, you can’t have an object, it will 
have to change access rules” or “import.meta isn’t a variable, it has access to 
local context, you can’t have that with global objects” or some such.

It’s just grammar isn’t it? Somehow nothing stops you from *explicitly* 
defining a thing called `ImportCall` to randomly turn a static keyword into a 
function-like import(). Nothing stops you from *explicitly* defining behaviour 
for `import.meta`. Nothing stops you from *explicitly* defining behaviour of 
Reflect/Proxy/Symbol/what-have

-you.

However, when the question comes to, say, replacing `import.meta` with `X.y.z`, 
it becomes nigh impossible. “Changing property access rules” and all that. 
Somehow changing how keywords are treated is of no concern though. Somehow 
introducing and explicitly defining behaviour for new global objects is no 
biggie. But don’t you dare touch `import()`, `import.meta`, `function.sent`. 
These are holy cows and their behaviour cannot be implemented in any other way 
than in “this new thing that you learn and move on”.

Here’s `import.meta` semantics rewritten for X.y.z. 

Introduction

X.y.z

  Object | undefined

  An object exposed through the X.y.z property. Concrete subclasses of the 
Abstract Module Record specification type are expected to fill this field when 
creating the Module Record, usually by delegating to the host environment. It 
is undefined by default, but must become an Object before it is ever accessed 
by ECMAScript code.

  X.y.z available only in module context. Usage outside raises a SyntaxError.

(somehere in Left-Hand-Side Expressions I guess, too late for me to sift 
through the standard)

XYZ : 

   X.y.z

Module semantics

1.1.2 Source Text Module Records

1.1.2.1 ModuleEvaluation( ) Concrete Method

The ModuleEvaluation concrete method of a Source Text Module Record performs 
the following steps:

- Let module be this Source Text Module Record.

- Assert: ModuleDeclarationInstantiation has already been invoked on module and 
successfully completed.

- Assert: module.[[Realm]] is not undefined.

- If module.[[Evaluated]] is true, return undefined.

- Set module.[[Evaluated]] to true.

- For each String required that is an element of module.[[RequestedModules]], do

- Let requiredModule be ! HostResolveImportedModule(modu

le, required).

- NOTE: ModuleDeclarationInstantiation must be completed prior to invoking this 
method, so every requested module is guaranteed to resolve successfully.

- Perform ? requiredModule.ModuleEvaluatio

n().

- Let moduleCxt be a new ECMAScript code execution context.

- Set the Function of moduleCxt to null.

- Set the Realm of moduleCxt to module.[[Realm]].

- Set the ScriptOrModule of moduleCxt to module.

- Assert: module has been linked and declarations in its module environment 
have been instantiated.

- Set the VariableEnvironment of moduleCxt to module.[[Environment]].

- Set the LexicalEnvironment of moduleCxt to module.[[Environment]].

- Suspend the currently running execution context.

- Push moduleCxt on to the execution context stack; moduleCxt is now the 
running execution context.

- Let importMeta be ObjectCreate(null).

- Let importMetaValues be ! HostGetImportMetaProperties(mo

dule).

- For each Record {[[Key]], [[Value]]} p that is an element of importMetaValues,

- Perform ! CreateDataProperty(importMeta, p.[[Key]], p.[[Value]]).

- Perform ! HostFinalizeImportMeta(importM

eta, module).

- Set module.[[ImportMeta]] to importMeta.

- Let result be the result of evaluating module.[[ECMAScriptCode]].

- Suspend moduleCxt and remove it from the execution context stack.

- Resume the context that is now on the top of the execution context stack as 
the running execution context.

- Return Completion(result).

etc.

On Sat, 05 Aug 2017 at 23:50 Logan Smyth

<
mailto:logan+smyth+%3cloganfsm...@gmail.com%3E
> wrote:

> 

The thing is, I clearly provide arguments in favour of my opinion.

>

> 

We now have:

> - keywords that are just keywords, really (typeof, case, break, etc.)

> ...

Totally fair. I understand that's where your coming from. 

> 

How can adding “properties” to semantically fundamentally different things 
elegant? Or increasing the number of extremely context-dependent things? Or 
overriding existing keywords with new and exceedingly confusing behaviours?

This is an argument for literally never changing the language. New things 
always seem confusing at first, then you learn and move on.

> 

Riiiight. Because import.meta is not a magically-populated not-quite-global 
variable. Oh. Wait. That’s *exactly* what it is.

`Introspect` is a variable with well-defined existing behavior as a variable. 
`import` is not a variable, it has no meaning when used as a value until the 
spec assigns it a behavior. That is the point I'm trying to get across. Is it 
less than ideal? Yeah, having `module` as a keyword would be perfect, but we 
have to work within the bounds of the language that we have.

> 

Even though it’s worse. import is a not-really-a-function-not-

real

ly-an-object-not-really-a-

stat

ic-not-really-a-dynamic-

keywor

d which is clearly far worse than a properly defined API.

What is a properly defined API for this case? Access to `.meta` needs to be 
able to know what module you are inside of. It needs some kind of context that 
ties it to the file that is asking for metadata. Within the existing behavior 
of the language, w

e can't just make a new global object like `Symbol` or `Reflect` because it has 
no way to know what file is asking for metadata.

The options are either:

* Add new syntax to expose the per-module-specific information, like 
`import.meta`, which cannot conflict with any existing code.

* Co-opt existing property-access behavior to make it behave differently from 
how it would in other contexts, like 

`Introspect.context`. It would either have to introduce an entirely new 
keyword, which as I mentioned is a breaking change, or it would have to 
fundamentally override the behavior of accessing a property on an object to 
allow the object to know what module the property was accessed from.

Since new keywords are out the window, I guess it could be said that the 
argument here are two sides, one arguing for more syntax to keep the execution 
model simple (import.meta) vs keeping the syntax simple at the expense of 
making the runtime behavior of the code more complex by changing how property 
access works.

I fall on the side of syntax because changing the behavior of property access 
to expose the current file seems massively more complex and seems much more 
likely to me to confuse people.

On Sat, Aug 5, 2017 at 2:29 PM, Jordan Harband

<
mailto:ljh...@gmail.com
>

wrote:

> 

There’s no code anywhere which doesn’t have an object called Symbol invoked 
with `new Symbol()`?

Any such code would either have a local `Symbol`, would have defined a global 
`Symbol` that shadowed any pre-defined one (including the new global in ES6), 
or would have thrown a ReferenceError or TypeError. Adding `Symbol` won't break 
any of that code (because the code that threw was already broken).

On Sat, Aug 5, 2017 at 2:20 PM, Dmitrii Dimandt

<
mailto:dmit...@dmitriid.com
>

wrote:

> [Reflect] Not a breaking change because adding a new global isn't new syntax, 
> it's just a new variable that exists and essentially can't break much.

It either isn’t a breaking change, or can’t break much. It cannot be both.

> Not a breaking change because this constructor did not exist before.

Are you entirely sure? There’s no code anywhere which doesn’t have an object 
called Symbol invoked with `new Symbol()`? The moment you add a global 
anything, you break someone’s code somewhere.

> I don't think I'd call super properties metaproperties for this reason. 
>`super` property access is its own class-related syntax that isn't related. I 
>do think it sets a perfectly reasonable guideline that makes it clear most 
>people have no problem accessing properties off of keywords.

I fail to see where you see guidelines specced out in the specifications of 
metaproperties or superproperties. “Most people” end up just stuck with these 
because they are either unaware that these changes are coming or are not active 
enough to voice their concerns.

> The biggest issue for me in this whole thread is that it's all extremely 
> opinion-based. What one person calls complex another would call elegant.

The thing is, I clearly provide arguments in favour of my opinion. Let me just 
summarise them for you.

We now have:

- keywords that are just keywords, really (typeof, case, break, etc.)

- keywords that are just keywords, but don’t even exist in a language. They are 
reserved for future use in various contexts: always reserved, only in strict 
mode, only in module code etc. (enum, public, private, await etc.). May never 
be used and may possibly be removed, as some keywords have been (int, byte, 
char etc.)

- literals that are basically keywords (null, true, false)

- non-keywords that are for all intents and purposes keywords (eval, arguments)

- keywords that look like objects (because they have additional properties) 
which are not objects (new with new.target)

- keywords that look like functions (because they are invoked like functions 
and return values like functions) which are not functions (import and import())

- keywords that look like objects *and* functions but are neither (import and 
import() and import.meta)

It gets even worse. Because “metaproperties” are not just attached to keywords. 
They are attached to keywords which have *fundamentally different semantics* in 
the language: 

- `new` is an operator[2], it gets `new.target`

-  A function is a callable object [3], and it gets a `function.sent`

- import is … I don’t know what import is. It gets transformed into a separate, 
made-just-for-import CallExpression and then it gets an `import.meta` on top of 
that (as a hardcoded “metaproperty”).

All of the above are basic facts about the language as it exists now. How can 
adding “properties” to semantically fundamentally different things elegant? Or 
increasing the number of extremely context-dependent things? Or overriding 
existing keywords with new and exceedingly confusing behaviours?

> > So there’s really *nothing* stopping you from designing a proper 
> > System/Module/Loader/Introspec

t/Avocado or any subset thereof instead of slapping “metaproperties” on 
everything in sight :)

> 

> I don't think anyone has claimed that `import.meta` is meant as a replacement 
> for these. We still need a loader spec

and a System spec and an Introspect spec, and ... That is why all these random 
additions to vastly different things in the language look like ad-hoc 
shortsighted solutions with no respect for the language or its evolution. “We 
need a thing, we have nowhere to put this thing, let’s add this thing to a 
keyword, because new.target (bad design) has opened a door for us”.

> I'd _much_ rather have a static syntactically-defined way to access that 
> information over a magically-populated not-quite-global variable like 
> `Introspect.context.sent`.

Riiiight. Because import.meta is not a magically-populated not-quite-global 
variable. Oh. Wait. That’s *exactly* what it is.

Even though it’s worse. import is a not-really-a-function-not-real

ly-an-object-not-really-a-stat

ic-not-really-a-dynamic-keywor

d which is clearly far worse than a properly defined API.

On Sat, 05 Aug 2017 at 22:37 Logan Smyth

<
mailto:logan+smyth+%3cloganfsm...@gmail.com%3E
> wrote:

`await` could be added because there is no case in existing code where `await 
<expression>` would have been valid code, so it is backward-compatible. The 
same applies for all of the meta-property proposals. The same is not true for 
`Introspect.context.module`. It's not just a question of it a given construct 
could be made to behave the way you want, it's also a question of it it would 
be compatible with existing code.

> Introduced in ECMASCRIPT 2015: Reflect is a built-in object that provides 
> methods for interceptable JavaScript operations. 

Not a breaking change because adding a new global isn't new syntax, it's just a 
new variable that exists and essentially can't break much.

> Introduced in ECMASCRIPT 2015: The Symbol() function returns a value of type 
> symbol, has static properties that expose several members of built-in 
> objects, has static methods that expose the global symbol registry, and 
> resembles a built-in object class but is incomplete as a constructor because 
> it does not support the syntax "new Symbol()”. 

Not a breaking change because this constructor did not exist before.

> ECMAScript 5 introduced: yield, let

Not a breaking change because those two can only occur in locations where they 
can't conflict with existing ES5 code. The extremely limited cases where `let` 
_could_ be in conflict are explicitly handled in the grammar to prevent 
breaking changes.

> ECMASCRIPT 6 introduced: await as a reserved word in module code

Same as above.

> So, introducting new things into the language is not really such a big 
> problem as it’s made out to be ;)

No-one said introducing things was not possible, but we can't break existing 
code.

> 

Don’t forget that `super` gets its own properties. Since there’s no 
specification of what “metaproperties” are, they are just called 
superproperties[7] in the grammar. Because reasons.

I don't think I'd call super properties metaproperties for this reason. `super` 
property access is its own class-related syntax that isn't related. 

I do think it sets a perfectly reasonable guideline that makes it clear most 
people have no problem accessing properties off of keywords.

> 

The problem with “metaproperties” is that they make the language more complex, 
chaotic and make it difficult to reason about the language.

This seems to be the core of your argument, but I honestly don't quite see why 
it is more complex/chaotic. The biggest issue for me in this whole thread is 
that it's all extremely opinion-based. What one person calls complex another 
would call elegant.

What specifically is difficult to reason about that wasn't already complex? 
Same for `function.arguments`. You're saying you think it's better to have an 
automatically-created `arguments` variable in every single function instead of 
having syntax to access it? `arguments` and `this` as two auto-initialized 
bindings are some of the most confusing parts of JS.

> 

So there’s really *nothing* stopping you from designing a proper 
System/Module/Loader/

Introspec

t/Avocado or any subset thereof instead of slapping “metaproperties” on 
everything in sight :)

I don't think anyone has claimed that `import.meta` is meant as a replacement 
for these. We still need a loader spec, but having a syntactic way to access 
data about the current active module is absolutely a useful thing to have. It's 
no different than CommonJS's __dirname and __filename among others. The logic 
for implementing a loader is separate from the logic for defining the behavior 
of module execution itself.

I'd _much_ rather have a static syntactically-defined way to access that 
information over a magically-populated not-quite-global variable like `

Introspect.context.sent`. In a perfect world absolutely `module` could have 
been a keyword, but at this point making that change seems like an absolute 
no-go because it could easily break existing code.

> 

Like look. function.sent?? Really? And it’s extremely highly context-specific: 
“function.sent can appear anywhere a YieldExpress would be legal. Referencing 
function.sent outside of a GeneratorBody is a Syntax Error.”

It's the exact same context-specific behavior as `yield` and they are both tied 
to generator functions. How is that in any way unexpected?

On Sat, Aug 5, 2017 at 12:43 PM, Dmitrii Dimandt

<
mailto:dmit...@dmitriid.com
>

wrote:

I just realised that there is also the argument that “global object cannot get 
current context” and other limitations applied to whether a theoretical 
“System/Module/Loader/Introspe

ct” would be a global module, or object, or keyword, or any (potentially 
context-sensitive) combination of these.

However, this all basically depends on what you specify in the standard, 
doesn’t it? :)

- Dynamic import has a “forbidden extensions” section[1] and how it should work 
when it’s invoked as a CallExpression [2]

- import.meta has a full section describing how the runtime should behave when 
encountering this particular property[3]

- new global objects like Reflect, Proxy, Symbol have specifications on what 
they are and hoe they should be treated [4]

A theoretical global object/keyword/identifier/spec

ial form X could be specified as <object/keyword/identifier/avo

cado>. X.someProperty: when encountered, let context be Ctx, let A be B, and C 
be B, populate with properties from here and there and everywhere.

Or look at the AwaitExpression[5]. There are specific limits in place to guard 
where and how it’s used and when it is to be evaluated as AwaitExpression.

So there’s really *nothing* stopping you from designing a proper 
System/Module/Loader/Introspec

t/Avocado or any subset thereof instead of slapping “metaproperties” on 
everything in sight :)

Like look. function.sent?? Really? And it’s extremely highly context-specific: 
“function.sent can appear anywhere a YieldExpress would be legal. Referencing 
function.sent outside of a GeneratorBody is a Syntax Error.” [6] 

Look. Here’s a proposal: `Introspect.context.sent can appear anywhere a 
YieldExpress would be legal. Referencing Introspect.context.sent outside of a 
GeneratorBody is a Syntax Error.` And then you can use 
`Introspect.context.target` instead of `new.target`. 
`Introspect.context.module` instead of `import.meta`. Clean. Reasonable. 
Extensible. Future-proof.

[1] 
https://tc39.github.io/proposal-dynamic-import/#sec-forbidden-extensions

[2] 
https://tc39.github.io/proposal-dynamic-import/#sec-import-calls

[3] 
https://tc39.github.io/proposal-import-meta/#sec-source-text-module-records

[4] 
https://tc39.github.io/ecma262/#sec-reflectionhttps://tc39.github.io/ecma262/#sec-proxy-objectshttps://tc39.github.io/ecma262/#sec-symbol-objects

[5] 
https://tc39.github.io/ecma262/#prod-AwaitExpression

[6] 
https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md

On Sat, 05 Aug 2017 at 20:40
mailto:dmit...@dmitriid.com
<
mailto:dmit...@dmitriid.com
> wrote:

The problem with “metaproperties” is that they make the language more complex, 
chaotic and make it difficult to reason about the language.

See my previous post about the multitude of keyword and keyword-like types that 
the language has. It’s so bad that even “metaproperty” concept itself isn’t 
defined in the standard except as a hardcoded `new.target` [1]

If you read, for example, through the import.meta draft, you see things ripe 
for inclusion in a proper API object.

It gets even worse. Because “metaproperties” are not just attached to keywords. 
They are attached to keywords which have *fundamentally different semantics* in 
the language: `new` is an operator[2], it gets `new.target`. A function is a 
callable object [3], and it gets a `function.sent`. Import is … I don’t know 
what import is [4]. It gets transformed into a separate, made-just-for-import  
CallExpression[5] and then it gets an `import.meta` on top of that [6] (as a 
hardcoded “metaproperty").

Don’t forget that `super` gets its own properties. Since there’s no 
specification of what “metaproperties” are, they are just called 
superproperties[7] in the grammar. Because reasons.

All this is chaos from the perspective of developer experience. And truly looks 
like random ad-hoc solutions to immediate problems with no long-term goals. 
Imagine how much better *and* future-proof it would be if all this was in the 
form of a unified centralised API? There is a reason people laugh at PHP for 
its API and language design. 

[1]
https://www.ecma-international.org/ecma-262/#sec-meta-properties

[2] 
https://www.ecma-international.org/ecma-262/7.0/#sec-new-operator

[3] 
https://www.ecma-international.org/ecma-262/7.0/#sec-terms-and-definitions-function

[4] 
https://www.ecma-international.org/ecma-262/7.0/#sec-imports

[5] 
https://tc39.github.io/proposal-dynamic-import/#sec-left-hand-side-expressions

[6] 
https://tc39.github.io/proposal-import-meta/#sec-left-hand-side-expressions

[7] 
https://www.ecma-international.org/ecma-262/7.0/#sec-left-hand-side-expressions

On Sat, 05 Aug 2017 at 18:59 Matthew Robb

<
mailto:matthew+robb+%3cmatthewwr...@gmail.com%3E
> wrote:

I really can't find a good resource on direct vs indirect evaluation but my 
understanding is it's one of the main considerations for using a keyword over 
an identifier for contextual information. One example which is already in the 
language would be 'eval' which you can read a little about here: 
http://2ality.com/2014/01/eval.html

Now you might be able to have an API that gets you the same result as the 
context sensitive keywords but it would be less ergonomic among other things: 
Reflect.getModuleMetaProperty(

someModuleNs, 'propName') but this becomes much more difficult to do FROM 
WITHIN THE MODULE ITSELF. Anything that is, let's call it tangible, cannot 
receive implicit contextual information it must have something passed to it 
that it would use to look up said information. 

Sure there could be arguments made about introducing new environment type 
records to the top level module scope of all modules but this is potentially 
much more error prone and likely to lead to more and bigger questions down the 
road. 'module' in particular is a really bad choice imo as node/commonjs have 
already introduced a 'module' identifier into all of their module scopes hence 
`module.exports = ...`. There may be solutions to working around that in one 
form or another BUT the 'trend' in TC39 to use keyword meta properties for 
context sensitive information is to avoid solving ever edge case of conflict 
that would impact existing code and users. It really is a fairly ripe space for 
powerful and ergonomic features like `super` which feel like "magic". The same 
is true for import.meta but it may be harder to identify right off as the uses 
haven't all been fully introduced such as environment specific properties and 
potentialy other loader hooks.

NOW as I was writing this it came to mind that we DO have a new syntactic form 
for private data coming in the form of private fields which use a hash prefix. 
It would be interesting to explore using the same syntax for module scoped 
private fields:

```js

console.log(#dirname);

```

- Matthew Robb

On Sat, Aug 5, 2017 at 12:35 PM, Dmitrii Dimandt

<
mailto:dmit...@dmitriid.com
>

wrote:

Too bad emails don’t have "thumbs up" and “+1”s :) So here’s my "+1” to you

On Sat, 05 Aug 2017 at 18:28 "T.J. Crowder"

<

">"T.J. Crowder"

> wrote:

On Sat, Aug 5, 2017 at 5:05 PM, Dmitrii Dimandt

<
mailto:dmit...@dmitriid.com
> wrote:

> So, in my opinion, the argument for not adding new global entities

> such as System, or Module, or Loader (or heck, even all three of

> them) being “these are not keywords, we can’t introduce them” is

> really really weak.

Is anyone making that argument? I certainly am not. Not only is it possible to 
add more global entities, as you point out, it's been done repeatedly: 
`Symbol`, `Reflect`, etc. They just can't be *keywords* without breaking 
things. They have to be identifiers. Which means they have bindings with 
values. Which means those values can be copied. Which has implications.

On Sat, Aug 5, 2017 at 5:08 PM, Dmitrii Dimandt

<
mailto:dmit...@dmitriid.com
> wrote:

>

> That’s not what I was really aiming at :)

>

> The original concern was “to get ‘module’ : 1. It's a

> context-sensitive keyword, and code that's using it needs to 

> be updated when migrated to a module. “

>

> I was just pointing out that ‘import’ is already a context-

> sensitive keyword (as are a bunch of others, like super.

> Is super a keyword BTW?)

My point was that this would be the only case I know of where it would be a 
keyword in one context but an identifier in another in the *exact same 
production*. `super`, `import`, etc., are **always** keywords. You just can't 
use them except in certain contexts. So I shouldn't have said 
"context-sensitive keyword" so much as "keyword or identifier depending on 
context." (But then...I did, earlier; I figured the shorthand was okay after 
spelling it out longhand. :-) )

But again: Maybe that's feasible. Or maybe it's not a problem passing the value 
around, in which case a predefined `module` identifier only in module code 
isn't a problem anyway.

-- T.J. Crowder

______________________________

_________________

es-discuss mailing list
mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

______________________________

_________________

es-discuss mailing list
mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

______________________________

_________________

es-discuss mailing list
mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to