Math.log2 applied to powers of 2
Just tried in the console of Chrome (with Experimental JavaScript features flag enabled). Math.log2(8) 2.9996 Firefox gives me the correct answer (3). Question: Should Math.log2 give exact results for powers of 2? The same issue holds for Math.log10 (might be applicable for nonnegative powers only): Math.log10(1e15) != 15 in Chrome. —Claude___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
On Tue, Sep 16, 2014 at 6:48 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Sep 16, 2014, at 12:57 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: We have long standing consensus on the current ES6 class design and that includes a `super()` constructor call that can be arbitrarily placed within the constructor body. I'm ok with consensus if it's real and strong. We aren't there yet, and AFAIK we never had cow-path-based use-cases for super calls tucked into the middle of constructors. We definitely had concerns about uninitialized objects, and people wanted to deal with constructor called as function. But conditional super()? I don't remember that. The ES6 max-min class and @@create instantiation proposals have always allowed arbitrarily placed `super` calls in methods (and up until the recent discussions) we treated class constructors as just the `constructor` method of the class prototype. The cow path for arbitrarily placed method super` is well paved and supports the fully generality of before, after, and around specialization in over-riding subclass methods without requiring additional syntactic affordance. It's a cow path that is about as old as OO programming and is just as applicable to constructor methods as to any other kind of method. I don't think this is really correct. As far as I can tell, the established pattern is - languages that reveal uninitialized objects (Python, Ruby) allow base-class constructor calls anywhere - languages that ensure the base-class constructor is called (C#, C++, Java) require it to be called up front The proposed changes make ES fall in neither category. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
Just for the sake of capturing everything, here's an updated version of the extended header idea: https://gist.github.com/zenparsing/5efa4459459b9f04d775 Cheers! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
historically powerful also thanks to its flexibility, I think JS.next should fall in the first category: base-class constructor calls anywhere - this makes the second one possible, and also other patterns available too. my .02 On Thu, Sep 18, 2014 at 4:36 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Sep 16, 2014 at 6:48 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Sep 16, 2014, at 12:57 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: We have long standing consensus on the current ES6 class design and that includes a `super()` constructor call that can be arbitrarily placed within the constructor body. I'm ok with consensus if it's real and strong. We aren't there yet, and AFAIK we never had cow-path-based use-cases for super calls tucked into the middle of constructors. We definitely had concerns about uninitialized objects, and people wanted to deal with constructor called as function. But conditional super()? I don't remember that. The ES6 max-min class and @@create instantiation proposals have always allowed arbitrarily placed `super` calls in methods (and up until the recent discussions) we treated class constructors as just the `constructor` method of the class prototype. The cow path for arbitrarily placed method super` is well paved and supports the fully generality of before, after, and around specialization in over-riding subclass methods without requiring additional syntactic affordance. It's a cow path that is about as old as OO programming and is just as applicable to constructor methods as to any other kind of method. I don't think this is really correct. As far as I can tell, the established pattern is - languages that reveal uninitialized objects (Python, Ruby) allow base-class constructor calls anywhere - languages that ensure the base-class constructor is called (C#, C++, Java) require it to be called up front The proposed changes make ES fall in neither category. -j ___ es-discuss mailing list 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
Re: new instantiation design alternatives
On 17 September 2014 19:24, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/17/14, 1:15 PM, Andreas Rossberg wrote:
In the light of that, I'm stilling missing the
compelling reason to introduce new^ at all.
Say you have:
class A extends B {
constructor() {
this = new super();
}
};
class B {
constructor() {
// what here?
}
};
(apologies for any obvious syntax mistakes).
Well, nothing has to go there. Since B does not have an extends
clause, it has -- according to Allen's gist -- its `this` initialized
implicitly (with an object having the derived constructor's prototype,
like you want).
What new^ adds to the table is the ability to bypass this mechanism
and implement non-standard inheritance or creation patterns within the
class syntax. But honestly, I don't understand why the class syntax
has to directly support such special use cases, let alone _encourage_
them with seductive syntax.
I feel like I'm missing something.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
On 9/18/14, 12:51 PM, Andreas Rossberg wrote:
Well, nothing has to go there. Since B does not have an extends
clause, it has -- according to Allen's gist -- its `this` initialized
implicitly (with an object having the derived constructor's prototype,
like you want).
Wait. How does the |new super()| invocation know what prototype to use,
exactly? Is it basically passing in the new^ value as some sort of
hidden state under the hood without exposing it with a name?
What new^ adds to the table is the ability to bypass this mechanism
and implement non-standard inheritance or creation patterns within the
class syntax.
Well, it adds the ability to explain what happens when you do:
class A extends HTMLElement {
...
}
right?
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
On 15 September 2014 19:20, Brendan Eich bren...@mozilla.org wrote: Andreas Rossberg wrote: Want to safe the colon for type annotations.:) Someone building a compile-to-JS language (not LLJS) pointed out to me what LLJS already did: C-style `type declarator` annotations, with [no LineTerminator here] in between. This obviously is off-topic for this thread but I can't resist... C-style (actually, Algol-style) declaration syntax is an evolutionary dead end. It does not scale. It quickly becomes unreadable (to both humans and parsers) when types have more structure than just being names. It buries the most important piece of information (_what_ is being declared) behind/inside a random pile of type syntax. It has the wrong scoping order for e.g. functions (which is why C++11 needed to introduce an alternative syntax for function types). And so on and so forth. I'm really glad that TypeScript and others broke with this unfortunate C tradition and adopted a better, also well-established notation (while other competition showed less taste). I rather not regress behind that. ;) /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Math.log2 applied to powers of 2
On Thu, Sep 18, 2014 at 10:56 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Sep 18, 2014 at 3:17 AM, Claude Pache claude.pa...@gmail.com wrote: Question: Should Math.log2 give exact results for powers of 2? The same issue holds for Math.log10 (might be applicable for nonnegative powers only): Math.log10(1e15) != 15 in Chrome. I have no idea of the computation complexity underlying a log implementation, so given that: yes, it should totally give exact results for powers of 2, and log10 should do the same for (positive) powers of 10. (Negative powers of 10 can't actually be represented by a JS number, so there's no need to talk about them.) It would also be useful, though perhaps not feasible, if they are guaranteed to be monotonic everywhere and strictly monotonic near those exact values; that is, for all x 2^k, log2(x) k for all x 2^k, log2(x) k and similarly for log10. If this property held, then naïve number of digits tests expressed using logarithms would always give the right answers. (This probably conflicts with generally desirable rounding properties, however.) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Math.log2 applied to powers of 2
On Thu, Sep 18, 2014 at 3:17 AM, Claude Pache claude.pa...@gmail.com wrote: Just tried in the console of Chrome (with Experimental JavaScript features flag enabled). Math.log2(8) 2.9996 Firefox gives me the correct answer (3). Question: Should Math.log2 give exact results for powers of 2? The same issue holds for Math.log10 (might be applicable for nonnegative powers only): Math.log10(1e15) != 15 in Chrome. If you can, please file a bug against v8: https://code.google.com/p/v8/issues/entry I consider these to be bugs in the implementation. —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Ray ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: new instantiation design alternatives
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Dmitry
Lomov
new^ is really just for 'constructors that are callable as functions as well'.
This is not really correct. Looking through Allen's gists, it's important in
several scenarios. E.g. allocating an exotic object, but still getting the
prototype linkage correct:
```js
class Base2 {
constructor(x) {
this = [ ]; //create a new exotic array instance
Object.setPrototypeOf(this, new^.prototype);
this[0] = x;
}
isBase2 () {return true}
}
```
Or ignoring the super-class constructor, but still getting the prototype
linkage correct:
```js
class Derived4 extends Base2 {
constructor (a) {
this = Object.create(new^.prototype);
this.a = a;
}
isDerived4() {return true};
}
```
Or deriving from an abstract base class:
```js
class D7 extends AbstractBase {
constructor () {
this = Object.create(new^.prototype); //instances are ordinary objects
}
}
```
Note that if we adopted the Domenic alternative, i.e. implicit `this =
Object.create(new^.prototype)`, the latter two would no longer need the
corresponding line in their constructor, leaving usage of `new^` for (a)
different [[Call]] behavior and (b) exotic allocation.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Math.log2 applied to powers of 2
On 9/18/14, 2:12 PM, Kevin Reid wrote: for all x 2^k, log2(x) k for all x 2^k, log2(x) k I'm not sure this is viable. Consider, for example k == 960, x = 2^960 + 2^908. The exact value of log2(x) would be 960 + log2(1 + 2^-52) = 960 + ln(1+2^-52)/ln(2) 960 + 1/ln(2) * 2^-52 960 + 2^-51 where the two inequalities follow from ln(1+x) x for small x and ln(2) 0.5. But 960 + 2^-51, represented as an IEEE double, is 960, because we only have about 43-44 digits of mantissa precision left for the non-integral part of this number... In fact, the smallest representable double larger than 960 is 960 + 2^-43, as far as I can tell. So to get the property you want, we'd need to have log2(x) equal to that for 2^960 x 2^960 + 2^917 at the very least, which is quite a bunch of doubles, for many of which the exact log2 value is definitely closer to 960 than to 960+2^-43. (This probably conflicts with generally desirable rounding properties, however.) If by that you mean the argument above, I clearly agree. ;) -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Math.log2 applied to powers of 2
On Thu, Sep 18, 2014 at 11:40 AM, Raymond Toy toy.raym...@gmail.com wrote: On Thu, Sep 18, 2014 at 3:17 AM, Claude Pache claude.pa...@gmail.com wrote: Just tried in the console of Chrome (with Experimental JavaScript features flag enabled). Math.log2(8) 2.9996 Firefox gives me the correct answer (3). Question: Should Math.log2 give exact results for powers of 2? The same issue holds for Math.log10 (might be applicable for nonnegative powers only): Math.log10(1e15) != 15 in Chrome. If you can, please file a bug against v8: https://code.google.com/p/v8/issues/entry I consider these to be bugs in the implementation. Done, thanks: https://code.google.com/p/v8/issues/detail?id=3579 ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
On Sep 18, 2014, at 11:29 AM, Dmitry Lomov wrote:
You haven't specified the constructor body, I assume you have intentionally
omitted it, and in that case the above is equivalent to
class A extends HTMLElement {
constructor() {
this = new super();
}
}
There is no explicit passing of new^ here.
new^ is really just for 'constructors that are callable as functions as
well'. Andreas is right that it is esoteric, but supporting that seems to be
a requirement for classes design.
But just so there is no confusion, there is implicit passing of new^ going on
in this example. That's necessary in order for HTMLElement to correctly the the
[[Prototype]] of the object allocates.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: new instantiation design alternatives
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Domenic Denicola I'm just quoting Allen's gist. It's a base class whose constructor always throws (in the gist, by doing `this = undefined`). Almost all DOM classes are currently like this, for example. Actually, this is a really important point. Since HTMLElement is abstract (throws on construct in all cases), the *only* way of extending it is by doing `this = Object.create(new^.prototype)`. You *cannot* extend it with `this = new super()`, either implicitly or explicitly, since `new super()` throws. So if you want to extend HTMLElement, you will need `this = Object.create(new^.prototype)`, either implicitly or explicitly. (And I argue for implicitly.) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
On Thu, Sep 18, 2014 at 10:06 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: dslo...@google.com [mailto:dslo...@google.com] On Behalf Of Dmitry
Lomov
I am not sure what do you mean by abstract class here.
I'm just quoting Allen's gist. It's a base class whose constructor always
throws (in the gist, by doing `this = undefined`). Almost all DOM classes
are currently like this, for example.
Got it.
I think the Dominic alternative is problematic in that it makes it
easy to forget to call base constructor. In majority of the cases you
really want to do it, and implicit this = Objec.create(new^.prototype)
will do the wrong thing without warning you.
My argument for it is that it works exactly like normal function-based
inheritance works today. That is:
```js
function Base() { }
Base.prototype.foo = function () { };
function Derived() {
// note: no Base.call(this)
}
Derived.prototype = Object.create(Base.prototype);
var d = new Derived();
assert(typeof d.foo === function);
```
Despite omitting the `Base.call(this)`, which is analogous to omitting
`this = new super()`, I still have a correctly set-up prototype linkage. I
would prefer if the following ES6 code:
```js
class Base { foo() { } }
class Derived extends Base {
constructor() { /* note: no this = new super() */ }
}
var d = new Derived();
assert(typeof d.foo === function);
```
also had the assertion pass. With alternative 1 (no implicit super; no
implicit `this = Object.create(new^.prototype)`), the assertion will fail,
as the prototype linkage will be incorrect.
Note that in no explicit constructor invocation case you will fail
earlier (on return from Derived constructor), and this is an early error.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
On Thu, Sep 18, 2014 at 10:26 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 18, 2014, at 1:11 PM, Domenic Denicola wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Domenic Denicola
I'm just quoting Allen's gist. It's a base class whose constructor
always throws (in the gist, by doing `this = undefined`). Almost all DOM
classes are currently like this, for example.
Actually, this is a really important point. Since HTMLElement is
abstract (throws on construct in all cases), the *only* way of extending it
is by doing `this = Object.create(new^.prototype)`. You *cannot* extend it
with `this = new super()`, either implicitly or explicitly, since `new
super()` throws.
So if you want to extend HTMLElement, you will need `this =
Object.create(new^.prototype)`, either implicitly or explicitly. (And I
argue for implicitly.)
But that won't give you a real HTMLElement exotic object, if there is such
a thing, and won't initialize it properly.
But you can get around that problem if the HTMLElement constructor is
defined appropriately using this^:
Of course s/this^/new^/, I presume.
class HTMLElement {
constructor(...args) {
if (this^ === HTMLElement) then throw new DOMError(can't create
using new);
if (this !== undefined) {
new^, not 'this'
//assert: must have been called via new super()
this = privateAllocatedDOMElement();
//initialize newly allocated DOMElement
}
}
}
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: new instantiation design alternatives
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] But that won't give you a real HTMLElement exotic object, if there is such a thing, and won't initialize it properly. But you can get around that problem if the HTMLElement constructor is defined appropriately using this^: That's a good point, thanks for explaining. (I assume you mean `new^`? You keep saying `this^` here and in other messages so I wonder if you've had a shift in thinking.) At this point my only real argument for implicit `this = Object.create(new^.prototype)` is that it's what happens with function-based inheritance. I agree with Dmitry that there probably is no good default so I guess I just find taking cues from what functions do to be the best guidance. But requiring explicit initialization seems fine too. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
of course! I don't know why my brain wiring keeps producing this^.
Allen
On Sep 18, 2014, at 1:28 PM, Dmitry Lomov wrote:
On Thu, Sep 18, 2014 at 10:26 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 18, 2014, at 1:11 PM, Domenic Denicola wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Domenic Denicola
I'm just quoting Allen's gist. It's a base class whose constructor always
throws (in the gist, by doing `this = undefined`). Almost all DOM classes
are currently like this, for example.
Actually, this is a really important point. Since HTMLElement is abstract
(throws on construct in all cases), the *only* way of extending it is by
doing `this = Object.create(new^.prototype)`. You *cannot* extend it with
`this = new super()`, either implicitly or explicitly, since `new super()`
throws.
So if you want to extend HTMLElement, you will need `this =
Object.create(new^.prototype)`, either implicitly or explicitly. (And I
argue for implicitly.)
But that won't give you a real HTMLElement exotic object, if there is such a
thing, and won't initialize it properly.
But you can get around that problem if the HTMLElement constructor is defined
appropriately using this^:
Of course s/this^/new^/, I presume.
class HTMLElement {
constructor(...args) {
if (this^ === HTMLElement) then throw new DOMError(can't create using
new);
if (this !== undefined) {
new^, not 'this'
//assert: must have been called via new super()
this = privateAllocatedDOMElement();
//initialize newly allocated DOMElement
}
}
}
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
On Sep 18, 2014, at 1:30 PM, Domenic Denicola wrote:
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
But that won't give you a real HTMLElement exotic object, if there is such a
thing, and won't initialize it properly.
But you can get around that problem if the HTMLElement constructor is
defined appropriately using this^:
That's a good point, thanks for explaining. (I assume you mean `new^`? You
keep saying `this^` here and in other messages so I wonder if you've had a
shift in thinking.)
At this point my only real argument for implicit `this =
Object.create(new^.prototype)` is that it's what happens with function-based
inheritance. I agree with Dmitry that there probably is no good default so I
guess I just find taking cues from what functions do to be the best guidance.
But requiring explicit initialization seems fine too.
yes, but basic function constructors are the equivalent of class definitions
without an extends clause. It's been suggested that an optional extends clause
that `function` could someday be added to function definitions:
if we did that, we would probably apply the same rules as for subclasses with
an extends. But it probably actually isn't needed. When you look closely, the
semantics of
class Foo extends Bar {
constructor () {}
}
are exactly what we would defined for
function Foo() extends Bar {
}
so it adds no know expressiveness.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
Domenic Denicola wrote: But requiring explicit initialization seems fine too. So are you withdrawing your variation (option 3 or whatever it is)? Not advocating, just asking (trying to keep up!). Unless the head syntax camp rallies somehow, I'm convinced: option 2 (https://gist.github.com/allenwb/5160d109e33db8253b62) is the winner. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: new instantiation design alternatives
From: Brendan Eich [mailto:bren...@mozilla.org] So are you withdrawing your variation (option 3 or whatever it is)? Not advocating, just asking (trying to keep up!). Since nobody else seems to be fighting for it, and I am highly interested in consens-ing upon something, I guess I am. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
On Sep 18, 2014, at 2:04 PM, Domenic Denicola wrote: From: Brendan Eich [mailto:bren...@mozilla.org] So are you withdrawing your variation (option 3 or whatever it is)? Not advocating, just asking (trying to keep up!). Since nobody else seems to be fighting for it, and I am highly interested in consens-ing upon something, I guess I am. I'm find with it too, so I'll present it next week as the recommended design. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Multiline template strings that don't break indentation
This might be beyond the current state of template strings but wouldn't it be nice if there was a delimiter character we can use to depict the beginning of each line of a multiline string? A similar solution like Scala multliline strings but without `stripMargin` method at the end. For example: var multiLineString = `This is a template string. |Even though each line is indented to keep the |code neat and tidy, the white space used to indent |is not in the resulting string` And if we actually want to include vertical bar we can escape it? -- Merih Akar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Re: Multiline template strings that don't break indentation
ALL of these things can be accomplished with your own custom tag. I really encourage you and others to learn about the tag part of tagged template string. From: Merihmailto:meriha...@gmail.com Sent: 2014-09-18 16:36 To: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org Subject: Re: Re: Multiline template strings that don't break indentation This might be beyond the current state of template strings but wouldn't it be nice if there was a delimiter character we can use to depict the beginning of each line of a multiline string? A similar solution like Scala multliline strings but without `stripMargin` method at the end. For example: var multiLineString = `This is a template string. |Even though each line is indented to keep the |code neat and tidy, the white space used to indent |is not in the resulting string` And if we actually want to include vertical bar we can escape it? -- Merih Akar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
Kevin Smith wrote: Just for the sake of capturing everything, here's an updated version of the extended header idea: https://gist.github.com/zenparsing/5efa4459459b9f04d775 Cheers! In the interest of the full dialectic, I encourage everyone tempted by new^ and all-degrees-of-freedom-including-hanging-yourself to look at this. It doesn't address some use-cases (constructor called differing from new'ed, notably), but perhaps that could be orthogonal via some MOP (if truly the hard/exceptional/native-legacy case). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
https://gist.github.com/zenparsing/5efa4459459b9f04d775 Cheers! In the interest of the full dialectic, I encourage everyone tempted by new^ and all-degrees-of-freedom-including-hanging-yourself to look at this. It doesn't address some use-cases (constructor called differing from new'ed, notably), but perhaps that could be orthogonal via some MOP (if truly the hard/exceptional/native-legacy case). That version almost, but not quite, holds together. Another revision is forthcoming... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
