I think there are some interesting ideas to explore in both D. Flanagan's
proposal and D. Herman's variations upon it. However, they both seem to be
ignoring the second primary use case that I identified: conflict-free
extensions of build-in or third party objects. While naming
Hi David,
First of all, I think you may not be reading the current private names
proposal. Allen wanted to change the name so he created a new page:
http://wiki.ecmascript.org/doku.php?id=strawman:private_names
Part of what you're reacting against is in fact what he changed (more below).
On Dec 22, 2010, at 7:10 AM, Peter van der Zee wrote:
What about adding an attribute to properties that somehow identify which
classes (in the prototype chain for protected) have access to the object?
I'll leave the somehow up in the air, but you could introduce a [[Private]]
attribute
You've said this apples to oranges thing many times. I just don't get it.
My comparisons at
http://wiki.ecmascript.org/doku.php?id=strawman:names_vs_soft_fields show
that these two semantics address extremely overlapping use cases. For both to
be in the language, with one group (including
On Dec 23, 2010, at 4:27 PM, David-Sarah Hopwood wrote:
We don't know whether [] will be changed
at all. (In the proposal to add a @ or .# operator, it isn't.)
Hm, this looks like a pretty serious misunderstanding of the private names
proposal. In every variant of the proposal, the object
On Dec 23, 2010, at 5:03 PM, David-Sarah Hopwood wrote:
On 2010-12-23 23:55, David Herman wrote:
On Dec 23, 2010, at 4:27 PM, David-Sarah Hopwood wrote:
We don't know whether [] will be changed
at all. (In the proposal to add a @ or .# operator, it isn't.)
Hm, this looks like a pretty
Dave, under the spec for Operation OwnProperties(obj) step 1, you don't
explicitly state that these index properties are to be enumerated in numeric
order. An oversight?
Oops, yes, thanks for catching that. I've updated the wiki.
Also, you misstate that indexes are properties with values
We would probably make it a contextual keyword so you could still use it in
non-expression contexts (e.g., to the right of '.' and left of ':' in object
literals), but unless we played some clever tricks, which I'm not sure would be
worth it, using it as an identifier would be a syntax error.
There's some flexibility built in to the system via module loaders. The
filesystem modules example is hypothetical; it assumes a built-in module
loader that maps files available on the filesystem to corresponding
pre-defined, nested modules.
On the web, you would do almost as you suggest:
//
this one
But will the runtime know how to correctly resolve the (module b = b.js;)
that comes from a.js? Or will that declaration have to be rewritten?
On Tue, Dec 28, 2010 at 1:30 PM, David Herman dher...@mozilla.com wrote:
There's some flexibility built in to the system via module
Hi John,
Module declarations are only allowed at the top level of a script or module,
but for convenience, they can nest within top-level blocks, and are hoisted
to be in scope for the entire containing script or module.
Can someone explain what this sentence means?
To me it says:
Sure. This is the use noasi or use semicolons idea.
Or just no asi. /bikeshed
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
We have previously discussed adding standard handlers to the specification,
i.e. an NoopHandler and a ForwardingHandler.
Yes, and Tom and Mark have been working on this and making good progress. They
have a forwarding handler mostly worked out, which we discussed yesterday at
the
Should we have a no-op or sink standard handler too?
I think so, yes. Especially since you can use that to build one up that
implements just the other traps you want to implement, and let the others fail
soft.
Dave
___
es-discuss mailing list
You can use module loaders to do exactly this (I believe, based on my
understanding of CommonJS). It would look like:
var ml = ... the desired module loader ...
var a;
if (someCondition) {
a = ml.load(a1);
} else {
a = ml.load(a2);
}
Correction: you have to use callbacks for dynamic
On Jan 26, 2011, at 4:04 PM, Brendan Eich wrote:
On Jan 26, 2011, at 1:54 PM, Kam Kasravi wrote:
So what is the behavior if you do new m.load(la1).Foo() if you know Foo is
an exported object?
Sam addressed that directly (nothing is statically known), cited in full
below.
Oh, I
On Jan 27, 2011, at 8:38 AM, Wes Garland wrote:
Kris Kowal's query is interesting: is lazy evaluation worth considering for
Simple Modules?
module M {
export var foo = 42;
export function bar() { return foo; }
alert(hello, world);
}
In the example above,
On the opposite side of the argument, I presume that this means that
modules are evaluated when their transitive dependencies are loaded.
This would imply that the order in which the modules are delivered,
possibly over a network using multiple connections, would determine
the execution
Kowal wrote:
On Thu, Jan 27, 2011 at 9:14 AM, David Herman dher...@mozilla.com wrote:
…but it is required to evaluate them in their declared order,
deterministically.
Would you explain how declaration order is inferred from the contents
of the unordered of files?
It's clear
Too much and too complex, say I! ;)
I liked your previous thinking that we should just return a fresh array. And in
the interest of keeping it dead simple, let's just fix it at 32 bits -- always.
Then the question is: string, array, typed array, or binary data?
I say: let's make it typed array
I've been working on a prototype implementation of the binary data spec in pure
JS (implemented via typed arrays) and I've been bitten by the lack of a
standard mechanism for subclassing Function.
I'm using proxies for the implementation, and Proxy.createFunction doesn't let
me specify a
PS Correction: it's actually a non-standard extension that regexps are callable
in SpiderMonkey. So the invariant is that the only callable non-host objects
are descendants of Function, or possibly host objects. This doesn't change my
overall point, though.
On Feb 23, 2011, at 2:26 PM, David
With your optional argument, I see a second solution that could be
consistent. The prototype chain could contain the provided prototype
then Function.prototype (obj -- proto -- Function.prototype --
null as opposed to your proposition which is: obj -- proto -- null
). Hence, there would be
On Mar 3, 2011, at 5:33 PM, Waldemar Horwat wrote:
If we're saying that Harmony is strict-only, settable by a script tag, what
will indirect eval and the Function constructor do if the evaluated code
doesn't start with a use strict directive?
Yeah, strict-only is probably not quite the
So I think it might be a little misleading to say Harmony is strict-only.
Who ever said that? :-P
Yikes... not playing who-said-what. For whatever reason, Waldemar got the
impression that someone said it, and I'm correcting the misconception, that's
all.
I've written that Harmony is based
Hi Jeff,
I agree that the spec should deal with multiple global objects. I'm aware of a
few of the subtleties of multiple globals, but I wouldn't be surprised if there
are more. Thanks for raising this one. I created a placeholder strawman last
week, because I've been intending to get into
But I miss the linear algebra library to go with it.
Can you send references to example libraries for other systems that you would
like to see?
Especially for the binary data approach, as it's removing an order
that might be implicitly known - sorry, I don't know how to express that
better,
A big favourite of mine (I'm biased, though...) is the Eigen2 library
(LGPL3+):
I can't speak for other browser vendors, but I think that license isn't
compatible with Mozilla's codebase. But thanks for the reference.
Using the small, fixed size subset of that lib and exporting the
Hi David,
We have a strawman for making the enumeration order well-specified:
http://wiki.ecmascript.org/doku.php?id=strawman:enumeration
Would that not be sufficient for the defineProperties case? I'd prefer that to
adding another trap.
Dave
On Mar 12, 2011, at 1:15 PM, David Bruant
P.S.:
A small change, e.g. can be to make next as a getter since it doesn't accept
arguments.
g.next; // 1
g.next; // 2
But, it's a cosmetic and actually not so needed change.
-1
The purpose of the next interface is to change the state of the iterator. A
getter interface obscures
It seems to me there are a couple pieces to Mark's concurrency proposal. One
part is formalizing the event queue that already exists. Another part is
introducing new concepts and features to the language (like promises and vats).
I want to hear what Mark has to say at the TC39 meeting, but my
It seems to me there are a couple pieces to Mark's concurrency proposal. One
part is formalizing the event queue that already exists.
Is this already done in the current proposal? Because I haven't found it.
Sorry, I guess I should say, we can't add concurrency without having it be
Hi Felix,
I have a note on the wiki page offering a less algorithmic approach to
specifying weak maps. I don't think we should be putting GC algorithms in the
spec at all; that would be overspecification. Instead, we should just focus on
defining reachability, and leave implementors free to
measurements.
(They'd be especially hard to automate, but I'd rather have the ability to test
manually than none at all.)
Anyone have experience with this from, say, the JVM and its weak references?
Dave
On Mar 20, 2011, at 8:20 AM, David Herman wrote:
It's weird, though--specifying anything
I said that WHATWG has done some on work specifying what currently
happens in browser (joining with your idea of be[ing] compatible with
existing event queue semantics). One idea would be to see what they've
done, get inspired and specify the event queue in ECMAScript.
OK. I'm on board for
for a
lower constant overhead in the typical case), we should clearly leave to
implementors. There is indeed nothing normative about this.
On Sun, Mar 20, 2011 at 7:20 AM, David Herman dher...@mozilla.com wrote:
Hi Felix,
I have a note on the wiki page offering a less algorithmic approach
right now, bracket notation is a superset of dot notation, but it would no
longer be under the proposed syntax.
I'm afraid I can't figure out what this means, but it doesn't sound true to me.
This gets at my other objection. Code is far harder to debug when every
single property lookup
right now, bracket notation is a superset of dot notation, but it would no
longer be under the proposed syntax.
I'm afraid I can't figure out what this means, but it doesn't sound true to
me.
Right now, everything that can be expressed via dot notation has an analog in
bracket
Brendan and Irakli both beat me to the punch here -- I would really like to see
stronger evidence that an entire lexical scope is really so onerous.
Everything you say about how Java mitigates the problem is just as applicable
to Harmony.
Java doesn't formalize this, you're right — but if I'm
Hoisting isn't nice in general, and from the no use beforedeclaration
in [1], it seems that let bindings won't be hoisted,
not even to their enclosing block.
That page is not yet complete. There's plenty more work to do on it, but we
probably won't be able to find much time to do
Hi Claus,
Interesting idea; I'd never considered lifting some of these good syntax ideas
from Haskell before.
One issue with the Haskell `...` syntax directly is conflict with the
quasi-literals proposal, but we can think about alternatives offline (let's
*not* get into a discussion of
The questions about eval look mostly unproblematic to me. In ES5-strict and
Harmony, eval is unable to modify its caller's scope. In legacy mode, I imagine
the semantics would be pretty straightforward, if problematic; but eval being
able to affect its caller's scope is problematic anyway, so
Allen makes the point that class D extends B {...} may look too much like
languages where it means something quite different.
Yeah, I just don't buy the argument that having different semantics should lead
to different syntax: it proves too much. By definition, JS has a different
semantics
I am really astonished to hear protection keys being thought
of as brittle under transformation: that is just the opposite of what they
are about!
Sorry to astonish you. :)
Executive summary:
- de Bruijn indices are a good assembly language of
binding constructs, suitable for
This is what Sam is referring to -- we've been talking about exactly such a
feature. I continue to believe that something like the ^this feature we've been
talking about is as likely to introduce bugs as it is to fix bugs. It's like
special language support for off-by-one errors.
Dave
PS A
On Mar 29, 2011, at 7:26 AM, David Herman wrote:
This is what Sam is referring to -- we've been talking about exactly such a
feature.
Sorry if that wasn't clear: at the last face-to-face we talked about allowing
you to give your own custom name for the |this|-parameter, so that you could
If I've got this right, the idea of soft bind is that the function
distinguishes whether it's called as a function or as a method; if called as a
function, it uses the lexical binding of |this|, and if called as a method, it
uses the dynamically pass-in binding of |this|.
Note that the .call
Hi James,
1) Files as modules do not need module wrapper
Just to confirm, if a JS file contains only a module definition, the
module X{} wrapper is not needed?
That's correct.
2) Set module export value
Is it possible to support setting the
Hi Sean,
Yes, I'm interested in this possibility as well. It'll probably take some
careful working-through of the details to figure out exactly when/where this is
doable, but it's on my radar.
Thanks,
Dave
On Apr 1, 2011, at 7:37 AM, Sean Eagan wrote:
Why not allow the spread operator to
Also, is it currently specified if rest parameters can have default
values?
I'm more skeptical of this one. It's sort of treating empty arrays as falsey,
which they aren't. And I've never noticed a need for this. But that might just
be the BLUB principle in action. Do you have examples/use
Regarding, import M.* via destructuring, it's also arguable whether we
don't need it since it looks like a with.
I don't see any sense in which it looks like a |with|. It's both syntactically
and semantically different. Syntactically, because it's a global (or
module-global) declaration
The way I think about it is, whenever you have X: Y where X and Y are
identifiers, the one on the left is fixed and the one on the right is variable.
- In an object literal, the one on the left is a symbolic property name and the
one on the right is a variable.
- In destructuring, the one on
Why I was asking -- because I saw it in your talk on ES.next, where you used
exactly this approach, i.e. module Foo = http://modules.com/foo.js; --
without any `require`. That's it.
No problem, I didn't mean to chastise. Just trying to keep focussed.
(should I fix my following presentation
[Disclaimer: I'm not an expert at server code. That said...]
Don't you generally need to manage the policy for these kinds of requests
manually anyway? In particular, you can't actually tell if a user has abandoned
their session, since the browser doesn't let you know when that's happened. So
We shouldn't be making backwards-incompatible changes for features just because
they can be abused. Every feature can be abused. And simplifying the completion
type is not even remotely an important goal.
Sometimes labels are just necessary. Sometimes you have a loop that needs an
early
, just an unfortunate overloading of
terminology. Nothing to see here, move along.
On Apr 9, 2011, at 10:24 AM, Wes Garland wrote:
On Sat, Apr 9, 2011 at 12:47 PM, David Herman dher...@mozilla.com wrote:
When people say Tennent's correspondence principle to mean something like
beta-conversion
function getDefiningObject(obj, key) {
if (!(key in obj))
throw new Error(key + key + not found);
while (!obj.hasOwnProperty(key))
obj = Object.getPrototypeOf(obj);
return obj;
}
On Apr 10, 2011, at 10:24 AM, Axel Rauschmayer wrote:
As far as I am aware, there is
The module system was designed to make it as easy as possible to use, both for
general ease of use and to encourage modular programming. Once you move to an
approach where programmers have to write their own linking specifications, it
tends to get much more complicated. When you make modules
I wondered if someone was going to make this point.
That should be
while (!{}.hasOwnProperty.call(obj, key))
which works even if obj has an own property named 'hasOwnProperty'.
Not if someone mutates Object.prototype.hasOwnProperty or
Function.prototype.call. I don't think we
, and to date there's sadly not enough good, authoritative
material with that kind of advice (how not to be anti-modular).
Dave
On Apr 11, 2011, at 7:07 AM, Mark S. Miller wrote:
On Sun, Apr 10, 2011 at 11:21 PM, David Herman dher...@mozilla.com wrote:
I wondered if someone was going to make this point
Yes, that's the idea.
Best,
Dave
On Apr 11, 2011, at 7:45 AM, Axel Rauschmayer wrote:
My understanding is limited, but here it goes:
You load modules in ES.next as follows:
module JSON = require('http://json.org/modules/json2.js');
A custom module loader (loosely related to a Java
It'll be the WindowProxy as usual, in top level code. Dave has addressed
what it will be in a module recently.
I have to look on Dave's explanation, seems I missed it. But this WindowProxy
won't be assessable then, right? Will it be possible to define a new global
property/variable at
Cool -- is this spec'ed yet?
http://wiki.ecmascript.org/doku.php?id=harmony:modules#this
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I don't think this feature is worth all this discussion or time, which is why I
haven't said very much. But I don't like the idea.
It *is* ambiguous, in the sense that if you wrote the grammar in the natural
way it would be an ambiguous grammar, so you have to rewrite the grammar in
such a way
Think of it this way: dynamic binding no, dynamic assignment yes.
So this means, no function expressions depending on the condition? I.e.:
this[foo] = isDebug ? function () { ... } : function () { ... }
var foo = isDebug ? function() { ... } : function() { ... }
Or I guess, such cases will
Dynamic binding is bad, mmmkay? ;)
Seriously, it's not an efficiency thing. Dynamic scope is easy to write but
hard to predict. JS is lexically/statically scoped almost everywhere, except
for with, eval, and the global object. Strict mode solves with and eval.
Harmony solves the global object.
P.S.: so having this issue as already solved (as a runtime error, but still
-- the error!, not a typo-hazard!)
It doesn't always produce a runtime error. If the property happens to be there,
there's no error. Also, take a look at the confusing issues that arise from the
dynamic semantics of
that important.
Regardless, it's clear I caused confusion by my usage. I'll make an effort on
es-discuss to be explicit about which I mean.
Dave
On Apr 15, 2011, at 6:48 PM, Mark S. Miller wrote:
On Fri, Apr 15, 2011 at 6:28 PM, David Herman dher...@mozilla.com wrote:
The fact is that dynamic scope
Forms like `fluid-let' don't actually make dynamic decisions about *scope* --
they just mutate an existing, statically-scoped variable. We're really just
talking about dynamic decisions about *where a variable is bound*, not *what
the current value of its binding is*. That said, I happen to
The const functions proposal isn't about referential transparency. They still
encapsulate mutable state. What makes them const are the frozen property
table (recall that functions in ES are objects) and the local name that's bound
to the function.
Dave
On Apr 17, 2011, at 1:06 AM, Claus
I don't understand. What is overwriting an operator?
Dave
On Apr 17, 2011, at 7:52 AM, Adam Stankiewicz wrote:
Hello everyone,
My idea is to disallow overwriting of === operator, and make 'compare'
operator implement == instead. Why?
1. === means for me that two variables have reference
We've talked about this on TC39. We'll probably do something, but exactly what
is hard to say at this point. Designing future-proof pragma syntax requires a
bit of gazing into the crystal ball...
Dave
On Apr 17, 2011, at 2:13 AM, Claus Reinke wrote:
Pragmas (ignorable source hints to an
I don't like this idea. It's inconsistent with the behavior of the other traps,
it relies too subtly on a funky stateful idiom, and it's hard to predict when
the traps will actually fire (since it depends on how clients use the proxy).
If there's something being set once-and-for-all I prefer it
Claus,
Thanks for the suggestions. Let me see if I can summarize them and respond
briefly:
* functions with expression bodies
This was proposed for ES4 and implemented in SpiderMonkey. I believe there are
some unfortunate ambiguities in the grammar that came up, and I think they've
been
.)
Dave
On Apr 17, 2011, at 8:55 AM, Adam Stankiewicz wrote:
By overwriting I meant creating a trap for === operator. Sorry for confusion.
Adam
2011/4/17 David Herman dher...@mozilla.com:
I don't understand. What is overwriting an operator?
Dave
On Apr 17, 2011, at 7:52 AM, Adam
OTOH we don't need to standardize __proto__. We might instead poison-pill it
in Harmony, so opting in involves an early error on every use of __proto__,
and you have to migrate by switching to Object.getPrototypeOf or an object
initialiser extension that allows presetting the new object's
Hi Claus,
Thanks for the bug report. I'm afraid I just don't have time for site
sysadminning at the moment. Eventually we are hoping to upgrade the wiki and
move it to our own (more reliable) servers, rather than the 3rd party server
it's currently hosted on. But I won't be able to work on
IMO, writing these issues up as strawmen was a nice way to spark discussion but
I don't see any need for them to clutter the harmony: namespace with extra
proposals.
Why don't we just take the decisions and fold them into the existing proxy
proposals. Does that seem reasonable?
Dave
On Apr
That sounds like a grammar bug -- no time to debug at the moment but I'll
address. A Program should be able to import but not export.
Dave
On May 2, 2011, at 12:50 PM, Erik Arvidsson wrote:
http://wiki.ecmascript.org/doku.php?id=harmony:modules
Based on what evidence are we concluding that the majority of the
javascript developers want - syntax for functions? The fact that
coffeescript is the hot buzzword? Was there some developer-community wide
voting or poll that I missed? Or is it that a few vocal people on these lists
like
But, JSConf has just 150-200 JavaScript developers in attendance.
Right. The JS community has no borders, no government, no constitution, no
membership cards, no census... We welcome everyone. So we have no way of
instituting democratic institutions.
they are definitely not a representative
There's no perfect answer. Shorter return syntax (^ with an ASI change, or
my empty label idea, function f(){:g()}) is ugly, adds overhead, and can
still be left off by mistake (making for the opposite problem from the
capability leak one: returning undefined instead of the intended result
Evidence is good, but that's not exactly scientific. In particular, I'd wager
there's a material difference in this phenomenon between a language in which
*all* functions implicitly return and one in which this is only the case for a
specific convenience form.
That said, we could also consider
How do you define non-method?
A function that is not invoked as method. Right now, the same kind of
construct is used for both true functions and methods. I’m proposing a new
construct (similar to the distinction that Python makes): a function that
does not have an implicit |this|
- self is just another parameter, it can be called anything.
- Function.prototype.call() and Function.prototype.apply() would have one
parameter less.
- IIRC, this is more or less how Python works.
- Probably not worth it, migration-cost-wise.
This breaks the web, so regardless of whether
Yes, I agree that separating them out is a good idea. Allen and I have been
working on this lately, and I've signed up to present private names at the
upcoming face-to-face. Our thinking has been along similar lines to what you
describe here.
Dave
On May 17, 2011, at 6:55 PM, Luke Hoban
Using new for the constructor is one of my favorite feature's of Allen's
proposal. Things I like about it:
1. It's terse. Since almost every class defines a ctor, this is helpful.
constructor is a mouthful and repeating the full class name (like in Java,
C++, etc.) is redundant.
2. I
It's okay in Courier New but not in lots of other popular monospaced fonts. See
attached image.
Dave
inline: Screen shot 2011-05-18 at 4.19.01 PM.png
On May 18, 2011, at 3:30 PM, Allen Wirfs-Brock wrote:
On May 18, 2011, at 3:14 PM, David Herman wrote:
I think I like : about as much
Wouldn't introducing a new built-in constructor in some module scope
actually have less risk (none?) of producing name clashes than messing
with an existing object?
Yes, and I think it's worth considering. We still need to work out the
organization of the standard library in modules.
Dave
Yes, we've talked about this. One of the issues I don't know how to resolve is
if we want to allow the specification of class properties aka statics, then
those need *not* to be in the scope of the constructor arguments, which ends up
with very strange scoping behavior:
var x = outer
All exports of all declared/required modules are computed before execution
starts. So it doesn't matter what order things run in, you won't get any no
such export errors if you import a valid export.
Dave
On May 19, 2011, at 2:13 PM, James Burke wrote:
Looking at harmony modules[1], I wanted
Oh, it wasn't clear to me that we really want to have static members.
I may be biased here, but I always viewed static members as just a
poor man's substitute for a proper module system. Fortunately, it
looks like we will have a real one instead!
I'm sympathetic to that view, but statics also
: Claus Reinke claus.rei...@talk21.com
To: David Herman dher...@mozilla.com
Cc: es-discuss@mozilla.org
Sent: Friday, May 20, 2011 2:51 PM
Subject: Modules first or second class (Re: I noted some open issues on
Classes with Trait Composition)
I think modules are a construct that evaluates
Just a note on this: for me, that means Harmony modules
are a step back from what I can implement in JS/now.
How is it a step back, if you can already implement it? We're not taking
objects away from JavaScript.
Not
having first-class modules has been a major drawback in
Haskell (which has
- they can share static information, such as sets of bindings (not that
import * would not work with first-class modules)...
Oops, meant to say: note that import * would not work
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
Mark and Tom used Ometa for http://code.google.com/p/es-lab/ --
slo-o-o-o-w.
Yeah it has no memoization. Pretty cool nevertheless as far as what he was
able to do. Though I really like what Dave is doing on narcissus.
No credit to me on the Narcissus parser; it was originally written
IANA Rubyist, but I *think* the goal was for blocks to be downwards-only, so
that upvars could live on the stack and everything could be nice speedy. So
they had to syntactically restrict blocks to enforce that they couldn't outlive
the frame in which they were created.
As Brendan says,
To a first, approximation, it would look something like this:
http://doc.racket-lang.org/reference/contracts.html
;-)
Seriously, the idea is to create contracts that can check structural properties
by wrapping values with proxies that lazily do the checking. The core idea,
known as
P.S.: another question I have -- is it worth and makes sense to raise a topic
on considering/standardizing the pattern matching (Dave's proposal)?
http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching Brendan
mentioned on Twitter that it's too late (?), but IMO this proposal is
The point is to encourage people to write *more* well-thought-out proposals
than can fit in an email, not less. Hence Allen's suggestion of blogs,
websites, or github. If language design issues can be resolved in bursts of 140
characters then I think I will need to find a new line of work. ;)
101 - 200 of 654 matches
Mail list logo
