Re: Destructuring object outside of var declaration

[Thaddee Tyl]

On Tue, Sep 17, 2013 at 4:27 PM, Brendan Eich  wrote:
>> Nathan Wall 
>> September 17, 2013 10:06 AM
>> I'm wondering what the best syntax is for object destructuring outside of
>> a var declaration.  For instance, the following works in Firefox Nightly and
>> Traceur:
>>
>> […]
>>
>> var a, b;
>> ({ a, b }) = foo;
>>
>> Is the above what people are expected to use (when they need to use
>> destructuring outside of a var/let declaration or function arguments), or is
>> there another form available?
>
> That's it. Lars Hansen originated destructuring for ES4 and implemented
> array patterns in Futhark (Opera's engine of the time), but not object
> patterns. His first proposal used
>
> &{a: x, b: y} = foo
>
> for just the reason you cite, but no one was keen on the ASI hazard
> (previous line must end with a semicolon). We cut the & pretty soon in ES4's
> evolution.
>
> I say use var/let/const, it's better style; or else suffer a parentheses
> tax. This is pretty much a non-issue in practice, AFAICT.

Have things evolved?

var foo, bar;
({foo, bar}) = {foo: 2, bar: 3};

is a "ReferenceError: invalid assignment left-hand side" in Firefox
Nightly 51.0a2, and a "SyntaxError: Unexpected token (" in Google
Chrome  54.0.2840.90.

var foo, bar;
{foo, bar} = {foo: 2, bar: 3};

is a "SyntaxError: expected expression, got '='" in Firefox, and *it
works in Google Chrome*.

var extract = () => ({foo:1, bar:2});
var foo, bar;
{foo, bar} = extract();  // SyntaxError: expected expression, got
'=' in Firefox and Chrome
({foo, bar}) = extract();  // ReferenceError: invalid assignment
left-hand side in Firefox, SyntaxError: Unexpected token ( in Chrome

I tried figuring out what the correct behaviour is from
http://www.ecma-international.org/ecma-262/7.0/index.html#sec-destructuring-assignment,
but the rabbit hole goes deep, so I have no idea who to file a bug
with.

(Obviously, the "right" way to do it, `({foo, bar} = extract())`,
works in both Firefox and Chrome. They, hum, could use some better
error messages, too, to guide users towards that.)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES7 - the standard

[Thaddee Tyl]

(Small typo, the path was changed to
, since that is the
direction we go for naming.)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES7 - the standard

[Thaddee Tyl]

> Could the spec next time have a non-normative section with the main
changes

I agree with Peter. For the purpose of being helpful, I tried making a
page related to the changes:
, so that it can be
linked to.

As far as I know, there is only Array.prototype.includes() and the
exponentiation operator added. Is there something else?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ideas on type hinting and named parameters

[Thaddee Tyl]

I like that syntax.

I wonder about the runtime semantics of it, though. (I know TypeHint
is a TODO, but…)
Is there any implication at runtime of a function that returns a String?
Is this:

```js
var point = {
  x Number,
  y Number
};
```

… the same as this?

```js
var point = {
  x: Number(),
  y: Number()
};
```

In which case we would need rules for constructors to always have
default parameters, right?

If those annotations are all only for a non-runtime type check, I feel
strange now about having type analysis only for newly defined symbols.
Since this is meant as some kind of pre-runtime `assert(symbol
instanceof Type)`, we might want to check:
- field types (such as `foo {bar Number}`)
- parameter types (such as `Array[Number]` or `Map[String, Array[String]]`)
- function types (such as `function(String) Number`)
- union types (such as `RegExp | null`)
- generics, possibly with extends / superclass (such as
`function(items Array[T extends Entity], unmap function(Number) T)`)?

Could we typedef types? Could we define covariance and contravariance
rules in new types with generics?

On a side-note, we can actually track the full list of methods used
for each parameter, and check that each function call respects them.
Maybe type inference has been researched enough that we can now use
better tools that need no type hints.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Reflect.type

[Thaddee Tyl]

On Mon, Jun 8, 2015 at 4:38 PM, Nick Krempel  wrote:
> On 8 June 2015 at 15:05, Thaddee Tyl  wrote:
>> Ah! Good. I expected it to fail just like this:
>>
>> ```js
>> function Thing(){}
>> function SubThing(){}
>> SubThing.prototype = Object.create(Thing)  // BUG:
>> Object.create(Thing.prototype) intended?
>> SubThing.prototype.constructor = Thing
>> Object(new SubThing) instanceof Thing  // Then this would be true.
>> ```
> That only fails because of the probable bug on the third line.

You're right. Sorry.

So, what is left? Is Reflect.type useful? Adding `Undefined` and
`Null` as types for which `Object(null) instanceof Null` etc. seems
unnecessary, since we'd use triple-equal comparison.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Reflect.type

[Thaddee Tyl]

On Sat, Jun 6, 2015 at 6:23 PM, Jordan Harband  wrote:
> if `class SubThing extends Thing {}`, then `new SubThing instanceof Thing`
> would be true.

Ah! Good. I expected it to fail just like this:

```js
function Thing(){}
function SubThing(){}
SubThing.prototype = Object.create(Thing)
SubThing.prototype.constructor = Thing
Object(new SubThing) instanceof Thing  // false
```

> Based on your isA examples, `Object(foo) instanceof bar` should be reliable
> within a single realm, and works everywhere, without the need for a new
> builtin method.

I can't think of a way to make something work across realms, so that's
indeed the best we have got.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Reflect.type

[Thaddee Tyl]

You suggest a list of types of fixed size. The lack of exposition of
user-definable value types is a problem you mention.

Having a better typeof is not as useful as having a better instanceof.

This would be more valuable:

```js
isA(42, Number) === true  // Doesn't work with instanceof
isA([1,3], Array) === true  // Does work with instanceof
isA({one:1}, Object) === true  // The distinction between array and
object was always weird with typeof
class Thing {}
isA(new Thing, Thing) === true
class SubThing {}
isA(new SubThing, Thing) === true  // Detects subclassing / prototype
chain (which instanceof does not do)
```

JS needs Ruby's is_a?.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: why not just import new language into browser?

[Thaddee Tyl]

On Wed, May 27, 2015 at 5:01 PM, 李白|字一日  wrote:
> Web Api, Native Client are all the efforts made to make the browser side to
> be a platform other than HTML + CSS + JAVASCRIT Parser.

Web API (by which I assume you mean the APIs defined in the W3C and
WHATWG standards) is definitely not an effort made to make the browser
side to be a platform other than HTML + CSS + JS.

> obviously client side languages should be subsetted and provided limited
> accesses to the browsers.

If you really believe that, prove that it is practical and does not
incur a performance hit by implementing it on your choice of
open-source browser.

Everyone seems to believe otherwise. DOM bindings are tricky enough as
they stand, they have been heavily optimized by every browser, and
they won't want to see all that work flushed so that browsers can
finally start having new kinds of incompatibilities.
“Hey, I built this page in Python! It is Chrome-only, because only
Chrome implemented the VM-DOM bridge of my dreams. Also, running the
very same code in PythonJS is faster on other browsers, partially
because they didn't complicate their DOM bindings, partially because
JS engines are freakishly fast:
.”

There is no point in caring about what language browsers provide,
because they indirectly support any. You want to write it in C++?
Please do; there's a compiler for that, it's called Emscripten. It
uses sourcemaps so that your debugger shows your C++ source code, just
like gcc/gdb uses DWARF on ELF assembly.

What you want is already there, you simply have wrong assumptions
about what is there.

> the aim is to make DOM manipulating more easier for other languages.

Any compiler can offer that. Cheerp has that. Dart2js has that.
Scala.js has that.

> especially for mobile applications where fast speed needs badly.

Then don't make DOM bindings slower by requiring multiple VMs. Like I
said, I would be very surprised if you could make things faster than
an optimized asm.js output by somehow adding the ability to run
multiple VMs in a browser.

> the javascript engine can be… downloaded from the internet

Why are you only suggesting things that would make webapps slower, if
what bothers you is speed?
(Also, do you really want any webpage to be able to install malware
instantly? How would the browser see the difference between a JS
engine and malware hidden in a JS engine?)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Renaming test262 (was: JavaScript 2015?)

[Thaddee Tyl]

On Fri, Jan 23, 2015 at 1:05 AM, Brendan Eich  wrote:
> Andrea Giammarchi wrote:
>> I mean ... how should I call my browser that is not 100% compliant with
>> HTML5, a fully compliant HTML 1997 browser ?
>
> Of course this question arose with respect to HTML5, which was nowhere near
> "done" (is it yet?) before marketeers at browser vendors started touting
> compatibility and various players hyped the orange shield. (And then Hixie
> said it was a living spec, version-free. :-P)

I feel like browsers shouldn't tout compatibility with a version (be
it ES6 or ECMAScript 2015). They ought to tout a test262 score.

Unfortunately, "We score 90% on test262!" would be a really bad ad.
Roughly nobody knows what test262 is associated with.

I feel we should rename test262 as well. Maybe simply "The JS Browser
Score". Developers know what JS is.

Suggestions welcome.

As a side-note, I expect test262 to be versionless (or rather, "the
latest version available, with more tests coming in). Currently,
 mentions ES5.1. Am I right to believe
it will be bumped to ES 2015 when it comes out? Should work begin on a
new branch in here: ?

I for one would be happy to start working on it.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Eval, literal eval, safe eval

[Thaddee Tyl]

Michał: Thanks for pointing this out. Strict mode doesn't quite work
like I expected it to. I wonder if anything can be done for that
Function('')() behaviour. (Weirdly, I was able to fix the function(){
this.a } behaviour.)

Additionally, this technique, at least for now, cannot be applied to
the global object: it leads to strange errors like
'NS_ERROR_NOT_AVAILABLE: prompt aborted by user' emanating from
nsPrompter.js in Firefox. It does work fine in Chrome, although
everything on the page gets reset, the page gets redrawn, even the
devtools seem to reload. Also, running a simple `Function('1+1')()`
results in a weird "TypeError: object is not a function", which is
odd, considering that `Function instanceof Function` is true. (That
said, `Function.name` returns 'Object'.)

Florian: it turns out that the Chrome DevTools did eventually rely on
a more robust sandbox, not sure when. A simple ([]).__proto__.push
reset used to suffice.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Eval, literal eval, safe eval

[Thaddee Tyl]

On Sun, Nov 23, 2014 at 12:38 PM, Florian Bösch  wrote:
> Btw. you can do a sort of sandboxed eval today by overriding all names found
> in window. There are some caveats however. The so sandboxed code can still
> access (and change) object internals, such as
> "mystring".constructor.prototype.asdf = function(){ console.log("gotcha");
> }.

You can do a lot more. You can prevent the issues you point out (and
many others) by mocking all built-in object's prototypes that you want
to feed the sandbox (so that modifications are actually performed on a
throwaway prototype), and by removing all new properties that weren't
there before and replacing those that were there before.

I have an implementation of such a sandbox in ES5.1
[here](https://github.com/espadrine/localeval), and a testing ground
[there][localeval website].
It does use eval(). And Function(). No Realm creation.

For all purposes, it is a safe eval. I really wish that Chrome would
use it in their DevTools; I broke them so many times while writing
this library that I have lost count. They actually use no sandbox at
all in their [js console].

[localeval website]: (https://espadrine.github.io/localeval)
[source]: https://github.com/espadrine/localeval
[js console]: 
http://isawsomecode.tumblr.com/post/31418387725/making-the-js-console-intuitive

> A sandboxes primary purpose isn't just to restrict access to global symbols,
> it's also to prevent it from corrupting the surrounding codes internals. One
> way to do that of course would be to have the so sandboxed code run in total
> isolation on a separate VM instance, however there's some issues with that
> too.
>
> It would often be the case that you'd want to provide an interface to the
> sandboxed code. So sandboxing alone isn't quite sufficient, you'd also need
> to have a suitable API/syntax to describe interfaces, safe to pass to the
> sandboxed code, such that the sanboxed code cannot corrupt any piece of
> those interfaces.

Most of that is (laborious but) easy. The thorny bit in localeval is
passing values to the sandbox. While it obviously works in the version
without a timeout (although infinite loops aren't protected against),
the version with a timeout, which relies on web workers (or processes
in node), doesn't pass non-JSON-serializable values fine.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Math.TAU

[Thaddee Tyl]

On Wed, Jul 2, 2014 at 5:52 PM, A Matías Quezada  wrote:
>  1. Use Math.PI * 2 everywhere
>  2. Create a TAU constant on every file
>  3. Create a TAU constant on a single file and require this file from
> everywhere just for this

4. Do Math.TAU = Math.PI * 2 once somewhere. It even works in node.js,
inside of the same process, leaking through require()s.

And some do it:

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

Loops, Let, Closures

[Thaddee Tyl]

The following ES6 code's behaviour puzzled a few developers I know.
The results indicated below each snippet are run through
SpiderMonkey's implementation.

It is related to 13.6.3.2. I believe the wording of the current draft
leaves the interaction with closures open to interpretation.

for (let i = 0; i < 3; i++);
console.log(i)

(i is scoped, so it is not defined on line 2. So far so good.)

for (let i = 0; i < 3; i++) {}
console.log(i)

(same)

let funs = [];
for (let i = 0; i < 3; i++) funs[i] = () => console.log(i);
funs[0]()

(shows 3, not 0: i is not captured in the closure)

let funs = [];
for (let i = 0; i < 3; i++) { funs[i] = () => console.log(i); }
funs[0]()

(same)

let funs = [];
for (let i = 0; i < 3; i++) { let j = i; funs[i] = function() {
console.log(j); } }
funs[0]()

(shows 0; i is captured in the closure)

According to me, it would be cleaner if the let binding in any loop
was independently captured in the closure.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Thaddee Tyl]

On Thu, Jan 30, 2014 at 8:27 PM, John Lenz  wrote:
> I don't argue that it isn't a useless "let".

For the sake of argument, can you construct a non-block-scoped `if (…)
…` which is actually any useful, assuming your mental model of

if (…) … <==> if (…) { … }

(which must be removed from teaching material) applies?

By the way, even in the current specification of let, we can still
construct a useless let:

for (let x = 42;false;) console.log(x);

(which is the same as the example you gave, using "if").
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardizing console APIs: Where?

[Thaddee Tyl]

On Wed, Feb 27, 2013 at 7:55 PM, François REMY
 wrote:
>> In browsers, when logging an object, you can actually click on an arrow
>> to browse through all its properties.
>> Serializing the whole thing on every single console.log, when those
>> happen in a loop,
>> would make the debugging experience a nightmare, performance-wise.
>
> True but we may expect the string representation to be exact while the 
> details are loaded when expanded only.

Immediate string conversion can still be costly (which is why Firefox
and Safari use a cache).
It is a matter of tradeoff.
Paste this in the developer console:

(a=[], function() { for (var i=0 ; i<10 ; i++) { a[0]=i;
console.log(a); } })()

When Chrome does console.log in a huge loop (which can happen by
accident), the tab and the whole DevTools are unresponsive.
When Firefox' DevTools does the same, you can interact with the page
(and the rest of the DevTools) quite fine.
(I'm running it in gmail right now, fwiw.)
I tried to make something as fast in Firefox' JSTerm add-on, but it
isn't as resilient.

> The clickable behavior is an extension to the Console API (which is 
> text-only). I agree that this part should not be standardized.

What subset of  do
you wish to standardize?
How would the standard require to process the following?

   console.log('%cThis is red text on a green background', 'color:red;
background-color:green');

Where do we draw the line?
Can the standard compete with Firebug's ad hoc description, if it is
but a subset?

Also, testing this standard is… hard.

> However, IE has a console.clear() function that I find useful, it should 
> probably be standardized.

That, too, is in .

> BTW it should be noted that some browsers only enable logging on a page if 
> the console window is open (or was opened at some point in the page 
> lifetime). This is maybe a way to avoid the slow down that more powerful 
> logging tools could cause.

Best effort. That's the spirit.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardizing console APIs: Where?

[Thaddee Tyl]

On Wed, Feb 27, 2013 at 5:07 PM, Brian Kardell  wrote:
> On 26/02/2013 23:06 , Brian Kardell wrote:
>>
>> 1. Does anyone else feel like we _should_ have a standard
>
>
> I think that this thread has shown that there are interoperability issues.
> Given that this is a debugging tool, you really want it to have predictable
> behaviour so as not to waste time looking for a problem that in fact comes
> from the console API.

If I'm not mistaken, the only interoperability issue that was raised
is that the display of logging data at high frequency (using `console.log`)
has a delay which may cause it to show a newer representation of the memory slot
than was passed to `console.log`.

If there was a standard, I do not believe that it should forbid this buffering.
Doing otherwise may greatly impact performance.
Remember, this issue only happens on high frequency logging;
having the logging block for immediate string conversion
will make something that happens *very often* take a lot more time!

How much time?
In browsers, when logging an object, you can actually click on an arrow
to browse through all its properties.
Serializing the whole thing on every single console.log, when those
happen in a loop,
would make the debugging experience a nightmare, performance-wise.

That being said, the standard shouldn't forbid blocking behavior either.
If it can afford to be precise, let it be!

Right now, displaying data through `console.log` is "best effort".
In order to get better information, you should set a conditional breakpoint.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardizing console APIs: Where?

[Thaddee Tyl]

On Fri, Feb 22, 2013 at 5:31 PM, Rick Waldron  wrote:
> On Fri, Feb 22, 2013 at 11:13 AM, Brian Kardell  wrote:
>>
>> Recently I read a post about Chrome adding a console.table API which
>> mentioned some things in other browsers.  My immediate reaction was "is this
>> a new proposal for addition to console standard API, because that could be
>> pretty handy actually" but then after a moments pause and about an hour
>> search, I realized:  There is no codified standard for console API.  Turns
>> out that public-browser-tools-test...@w3.org has sort of agreed to take it
>> up, but it doesn't seem like anything much has happened yet and I'm
>> wondering why that should be bound to anything with the browser since
>> console is a pretty universal thing in implementations.  Not saying it
>> should or shouldn't be ECMA, just that it seems to be in the wrong place now
>> if, indeed, anything is happening there.
>
>
> A very smart addition to the future standard library modules—which are
> dependent on a Module spec of course. Write a strawman?

I beg to differ.

The standard for console APIs is at
, along with
other devtools-related standards.
It is very functional (changes happen regularly by cross-browser
consensus, and suggestions are welcome from anyone).
Sure, not all devtools support it all, and they may have bugs, but
they each strive to fix their implementation.
Duplicating standards will only duplicate efforts.

You may notice that console.table is defined there now (and has been
for some time).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Polyfill for Maps and Sets

[Thaddee Tyl]

On Thu, Jan 17, 2013 at 8:12 PM, Domenic Denicola
 wrote:
> Dude, do you even read the spec?
>
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.14.5.4

So this is just the wiki lacking some updates?

http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Polyfill for Maps and Sets

[Thaddee Tyl]

On Thu, Jan 17, 2013 at 7:58 PM, Brandon Benvie
 wrote:
> There's multiple polyfills for Map, Set, and WeakMap (WeakMap not being
> fully implementable, but close). Here's one:
> http://benvie.github.com/harmony-collections.

This polyfill isn't exact in the same way that I described.
The difference is, instead of shamelessly adding 'getKeys' in the way
that I suggested,
it shamelessly adds 'forEach', which isn't in the spec.

I'd be happy with any of those, although, again, I believe that
'getKeys' would prove more useful in practice.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Polyfill for Maps and Sets

[Thaddee Tyl]

I believe it is impossible to do even a partially functional polyfill
for Maps and Sets in ES5.
Indeed, the only way to iterate through it is with the 'for (… of …)'
construct, which is sure to break in ES5.

I wish there was a way to polyfill it.
Something like 'Map.prototype.getKeys' could return an array of key
entries, for instance.
Obviously, Sets would benefit from the same treatment.

In the case of Sets especially, I can see this method as being
something that everybody would end up writing many times manually,
similar to how they now write the boilerplate to treat 'arguments'
like an Array, over and over again.

Could we consider something like that, please?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "var" declarations shadowing properties from Window.prototype

[Thaddee Tyl]

On Wed, Aug 15, 2012 at 8:16 AM, Boris Zbarsky  wrote:
> On 8/15/12 3:48 AM, Axel Rauschmayer wrote:
>>
>> In FF 14, I’m getting the following results (if there is an element
>> whose ID is "foo"):
>>
>>  $ "foo" in window
>>  false
>>  $ foo
>>  ReferenceError: foo is not defined
>
>
> This is an artifact of how the repl you're using (presumably the Web Console
> in Firefox) is implemented.  In particular, if you're using the Web Console
> its global is NOT the window, which allows you to declare variables visible
> in the repl but not leaking to the web page.  But it leads to some weird
> artifacts with the global scope polluter, since there isn't one here,
> really.

I'd like to add that this is a genuine bug in the Web Console, not the
way we meant it to behave.
`window.Object instanceof Object` is meant to be true.

See bug https://bugzilla.mozilla.org/show_bug.cgi?id=774753 about it.
Use Firebug's console to avoid running into those issues.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES Modules: suggestions for improvement

[Thaddee Tyl]

On Tue, Jun 26, 2012 at 10:12 AM, John J Barton
 wrote:
> As I understand it, two issues drive the need for standardization of
> modules:
>   1) we want one environment for all JS,
>   2) to move beyond the limitations of RequireJS and CommonJS requires
> parsing, and that is considered too expensive for library implementations.
> The first point is obvious, the second one is implicit in the blog posts by
> Isaac and James.


Another point that I believe Isaac is making is that too much syntax
is likely to confuse developers and allowing certain features, such as
nested modules or `import *`, can be harmful to programmer efficiency
in the long term, if used.

For the purpose of discussion, I made a gist [0] of Isaac's proposal.
Most of the module examples [1] are there.

  [0] https://gist.github.com/2997742
  [1] http://wiki.ecmascript.org/doku.php?id=harmony:modules_examples

Isaac, feel free to correct it.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: More fun with undefined

[Thaddee Tyl]

On Thu, Jun 14, 2012 at 3:29 PM, Allen Wirfs-Brock
 wrote:
> This is a different issue, but I wonder how badly the web would break if we
> made undefined a reserved word.  Does anybody in JS really declare a
> different local binding for undefined?  In ES5 we got away with making
> undefined read-only.  Maybe we should continue pushing and see if we can
> eliminate the rebindable undefined hazard.

JQuery [1] famously has an "undefined" parameter, like so:

(function( window, undefined ) { … }(window))

What would happen in this case?

  [1] http://code.jquery.com/jquery-1.7.2.js
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Default operator strawman - ||| rather than ??

[Thaddee Tyl]

On Tue, Jun 12, 2012 at 10:17 PM, David Herman  wrote:
> On Jun 12, 2012, at 6:33 PM, Thaddee Tyl wrote:
>
>> My point still stands. Being "undefined"-specific is arbitrary.
>> CoffeeScript could have been "undefined"-specific; they were
>> "undefined" + "null"-specific, which I believe makes more sense.
>
> Can you make the full argument? I'm genuinely undecided on this question, and 
> having trouble deciding on the criteria.

"undefined" and "null" share a lot of behavior that other falsy values
don't have.
The most critical one is to throw a TypeError on some occasions,
including when invoking the abstract ToObject operation.
Besides, it often has a similar meaning: I have seen in a lot of code
a de-facto standard wherein null is used to indicate a value that is
voluntarily undefined. You can see this pattern all over node.js code,
for instance.
This lets the user know when a parameter was meant to be set to
nothing, and when we should use a default parameter instead.
Harmony's default parameters will make this easier, while letting a
null value through -- which will make this pattern even more common.
On the other hand, we often want to react in a certain way if the
parameter is not set, either because it was not supplied or because it
was set to null.

Besides, the null value can be obtained from the standard library,
when calling certain methods.
Object.getPrototypeOf(...), string.match(...), even calling the toJSON
method of a Date can return null.
Having a way to deal with those return values by providing a default
value would be nice.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Default operator strawman - ||| rather than ??

[Thaddee Tyl]

On Tue, Jun 12, 2012 at 6:11 PM, Tab Atkins Jr.  wrote:
> On Tue, Jun 12, 2012 at 2:52 PM, Thaddee Tyl  wrote:
>> On the other hand, non-existent properties are a use-case.
>> CoffeeScript provides a similar feature, but for null properties.
>>
>> For example, the following:
>>
>>    o =
>>     a: 1
>>     b: 2
>>
>>    alert o.c?.d
>>
>> compiles to:
>>
>>    var o, _ref;
>>
>>    o = {
>>      a: 1,
>>      b: 2
>>    };
>>
>>    alert((_ref = o.c) != null ? _ref.d : void 0);
>>
>> Special-casing undefined makes as much sense as special-casing null,
>> like CoffeeScript does.
>>
>> My point is that it is not obvious whether the non-existent properties
>> use-case should be "undefined"-specific or "null"-specific (or both).
>
> That's... pretty wrong.  In the example above, o.c returns undefined,
> not null.  If CoffeeScript *actually* compiles to the code you posted,
> then it only works because they're using != instead of !==, and null
> and undefined are both falsey.  However, it'll break if o.c is defined
> and is a falsey value like 0 or false.
>
> Try it.  Put the following in your nearest console and see what it returns:
>
> ({a:1, b:2}).c === undefined

CoffeeScript's property checking returns "undefined" if the property
is either undefined or null, and returns the property itself
otherwise.
If the property is false or 0, it returns the property (either false or 0).
I don't understand why you say it breaks if o.c is a falsey value like
0 or false.

The following code:

Boolean.prototype.d = 'Property'

o =
 a: 1
 b: 2
 c: false

alert o.c?.d

will show "Property", as we'd expect.

My point still stands. Being "undefined"-specific is arbitrary.
CoffeeScript could have been "undefined"-specific; they were
"undefined" + "null"-specific, which I believe makes more sense.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Default operator strawman - ||| rather than ??

[Thaddee Tyl]

On Tue, Jun 12, 2012 at 1:56 PM, Tab Atkins Jr.  wrote:
> On Tue, Jun 12, 2012 at 1:37 PM, Peter van der Zee  wrote:
>> On Tue, Jun 12, 2012 at 5:29 PM, T.J. Crowder  
>> wrote:
>>> In the current default operator strawman[1], the operator is ??, e.g.:
>>>
>>> a = b ?? 5;
>>>
>>> is shorthand for
>>>
>>> a = b !== undefined ? b : 5;
>>
>> I missed this discussion. What validates the introduction of this
>> syntax over the equally simple and already possible `a = b || 5`? Is
>> the comparison to `undefined` (and why not `==null` as well??) really
>> worth the introduction (and subsequent loss of future usage) of the
>> double question mark? Whatever it's usual name is (double wat?).
>
> If b is falsey (0, false, null), it'll use the 5, even though you only
> intended it to be used when b is undefined.
>
> "undefined" is special-cased here because it's an extremely common
> value to check against.  It's used when an argument isn't supplied, or
> when you try to pull a non-existent property off of an object.

A non-supplied argument is a use-case that is already covered by
default parameters.

On the other hand, non-existent properties are a use-case.
CoffeeScript provides a similar feature, but for null properties.

For example, the following:

   o =
a: 1
b: 2

   alert o.c?.d

compiles to:

   var o, _ref;

   o = {
 a: 1,
 b: 2
   };

   alert((_ref = o.c) != null ? _ref.d : void 0);

Special-casing undefined makes as much sense as special-casing null,
like CoffeeScript does.

My point is that it is not obvious whether the non-existent properties
use-case should be "undefined"-specific or "null"-specific (or both).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Digraphs *and* Unicode pretty-glyphs, for arrows, triangle, etc.

[Thaddee Tyl]

On Thu, Apr 5, 2012 at 5:00 PM, Adam Shannon  wrote:
> I don't see anything inherently wrong with adding some nice sugar to
> ES, because the people who will be using this "math heavy" notation
> will be those who are used to it. The "everyday" ecmascript programmer
> probably won't touch these because they might add extra work for them.
> Plus, it'd be nice to be able to read math in ES (for us math oriented
> folk).

Leksah  is a Haskell IDE whose editor converts ->
and other operators to their unicode equivalent. It saves the file in
ascii.

If you want that feature in the editor, do it. On the other hand,
there is no reason to make programming JS harder for people with a
weaker editor.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Digraphs *and* Unicode pretty-glyphs, for arrows, triangle, etc.

[Thaddee Tyl]

On Thu, Apr 5, 2012 at 7:23 AM, Brendan Eich  wrote:
> From http://www.scala-lang.org/node/4723 (hat tip *Corey
> Farwell*‏@*frewsxcv* 
>
>  *
>
>
> ):
>
> |=>   ⇒   // implemented
> <-  ←   // implemented
> ->   →   // implemented
> ==  ⩵
>>>
>>>  ≫
>
> <<   ≪

  ⋙
>>
>> =  ≥
>
> <=  ≤
> ::  ∷|
>
>
> Corey suggested editors could do the input conversion when users type the
> digraph. If Scala can go here, why not JS?

↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: value objects

[Thaddee Tyl]

On Tue, Mar 20, 2012 at 2:20 PM, Andrew Paprocki  wrote:
> On Tue, Mar 20, 2012 at 4:27 AM, Herby Vojčík  wrote:
>>>
>>> I understand lots of apps want "native" int64 as soon as possible
>
>
> I would love to see IEEE754r as soon as possible. Being able to represent
> certain financial calculations accurately and interface with other parts of
> a working system that use IEEE754r is ideal. I have found very little need
> for treating full 64-bit values as Numbers within script. (They usually wind
> up being unique identifiers or keys that can be passed through as
> hex/strings.) These are just my observations, though.

How is IEEE754r able to more accuracy when dealing with financial
calculations? I always thought that integers were enough for that
purpose, all calculations being as precise as it can get.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: optional "function" keyword

[Thaddee Tyl]

From: Brendan Eich
>From: Isaac Schlueter
>> Yes, an identifier is required.  It would not be possible to define an
>> unnamed function in this way.
>
>
> Why not express an anonymous function, though? Definition != expression. As
> usual, an expression *statement* could not start with ( and consist entirely
> of a function-keyword-free anonymous function expression.

The use of a compulsory identifier is a bright idea. Having an
identifier guarantees that we always have a function name in the stack
trace, and keeps open the possibility of recursion.

Besides, it is unambiguous, and, as I pointed out earlier, we can
still use something like "lambda".
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: optional "function" keyword

[Thaddee Tyl]

On Tue, Mar 6, 2012 at 6:50 PM, Isaac Schlueter  wrote:
> A great many letters have been typed regarding the number of letters in the
> word "function".
>
> What if we just made the keyword "function" entirely optional, dart-style?
>
> ShortNamedFunctionDeclaration :Identifier  ( FormalParameterListopt )
>  { FunctionBody }
> ShortNamedFunctionExpression :Identifier  ( FormalParameterListopt )
>  { FunctionBody } Note that the identifier is no longer
> optional, and that no linebreak is allowed between the parameter list and
> the body, unlike current function decl/exprs.
> myList.forEach(x (item) {
>   item += 2
>   doSomethingElse(item)
>   assert(typeof x === "function")
> })

An interesting property of this syntax is that anonymous functions can
be written this way:

myList.forEach(λ (item) { doWith(item) })

(it can also be `lambda (item) { ... }`)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: What should Map iteration do?

[Thaddee Tyl]

Related:

I cannot find the reason why sets and maps were harmoni'ed with
classes[1]. They do support `mySet["foo"]` for `mySet.has("foo")` and
`for (something of mySet)` for iteration, do they not? Classes don't
have operator overloading, so using classes makes it harder to see the
usual syntax form.

Shouldn't we use proxies instead?

  [1] http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Native Assertion module?

[Thaddee Tyl]

(I am sorry that I mistakenly sent this only to Rick Waldron. I
intended it for es-discuss.)

On Mon, Feb 13, 2012 at 5:04 PM, Rick Waldron  wrote:
> I was wondering if a native Assertion module had ever been discussed or
> proposed - I searched[1] and found nothing. If anyone can point me to
> existing discussion or proposals that I might have missed, I was be greatly
> appreciative. The simplest explanation of my thinking is something closer to
> a "standard lib" module, similar to Globalization or "Iter".


If you do a native Assertion module, maybe it should be similar to node's.



This being said, the node authors only added the "assert" api because
they use it in node. I find no compelling reason to have that in JS.

Citation from Isaac Shlueter:
> There are two reasons to put something in core:
>
> 1. It is an established core internet technology with a clearly correct 
> approach that is difficult to do properly. In those cases, we provide a 
> low-level binding. Tcp, http, zlib, and udp are good examples of this. Http 
> is probably the highest-level API we have, but http is batshit insane and 
> difficult, and the most important internet protocol.
>
> 2. It is something that is used internally in node-core. We use assert in the 
> node-core tests. We're not going to bundle a more robust test framework than 
> we need. We use util.inherits in node core. We're not going to add a class 
> system with more features than we need.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Two kinds of [] (was: Re: shortcuts for defining block-local private names, plays nicely with @foo syntax)

[Thaddee Tyl]

On Sat, Jan 28, 2012 at 1:10 AM, Brendan Eich  wrote:
>> Tom Van Cutsem 
>> January 27, 2012 10:53 AM
>>
>>
>>    Off-topic: What is the recommended style for naming modules?
>>    Capitalized and camel-cased? It’s nothing I couldn’t get used to,
>>    but it seems like the naming precedent would be JavaScript
>>    packages. Or is Reflect capitalized, because it is a built-in module?
>>
>>
>> I have been using @reflect as the name of the module, and Reflect as the
>> name of the module instance object, as in:
>>
>> module Reflect from "@reflect";
>
>
> I believe that the latest (not yet in wiki) syntax uses 'at' not 'from' for
> the out-of-line module body case:
>
>  module M { ... }
>  module N at "U";
>  import P from M;
>  import P from "U";
>
> P is a pattern, in general. It could be * or an identifier if not a full
> destructuring pattern.

Related: this syntax doesn't prevent the user from naming its variable
"at", does it?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Block lambda is cool, its syntax isn't

[Thaddee Tyl]

On Wed, Jan 18, 2012 at 10:28 AM, Gavin Barraclough
wrote:

> Just a thought, has a prefix ^ been considered?
>
> A lambda that takes no arguments could be:
> ^{ /*...*/ }
> And a lambda with some arguments:
> ^(x,y){ /*...*/ }
>
> I just find this really readable, the syntax for lambdas that take no
> arguments is delightfully minimal (just one extra character!), my brain is
> well trained to expect argument lists to be delimited by parentheses so I
> find this much easier to understand, and I find the ^ character pleasingly
> evocative of λ. :-)
>

This is really a matter of taste.

{ (a, b) ... }

^(a, b) { ... }

{ |a, b| ... }

Of course, some characters are easier to type than others, especially in
non-qwerty keyboards (I'm thinking about the pipe "|").

But what matters most is readability, since code is more often read than
written. So far, people seem to think that pipes are more readable.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Block lambda is cool, its syntax isn't

[Thaddee Tyl]

2012/1/13 Quildreen Motta :
> I have an obvious bias towards 1 because I think Unicode symbols
> describe much better the underlying intentions and semantics than
> their ASCII alternatives (usually), however not many people creates
> mappings for these symbols on their .XCompose (or even have a compose
> key handy).
>
> I remember you mentioning that the Haskell-ish alternative `\x, y {
> body }' or `.\x, y { body }' was not practical, because \ is already a
> valid escaping character in identifiers (?)
>
> Given those above, despite my usual disliking of Ruby syntax, I prefer
> the pipes over parenthesis, given the latter has an already too
> overloaded semantics, such that `{ (foo, bar) (2) }' would look pretty
> confusing, at least to me. However, what about `{x, y: body}'? Granted
> we don't allow labels immediately following a lambda block (and I'm
> not sure labels are used much in the language, I could be wrong
> however).

That would mean that a block lambda with no parameters is

{: body}

Don't you think it looks odd?

Plus, parentheses are what JS uses for parameters.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Block lambda is cool, its syntax isn't

[Thaddee Tyl]

On Thu, Jan 12, 2012 at 11:23 PM, François REMY
 wrote:
> Am I wrong if I say there not a bigger issue with block lambda than with the
> current object notation on the matter?
>
> I mean, does that code mean anything useful?
>
>   function() {
>       {|a,b| a+b};
>   }
>
> If not (as it seems to me), it means that a block lambda will not be used as
> a statement by itself. If it's the case, it should defined as an Expression
> only, where there's no anonymous block to conflict the syntax. That solution
> has been chosen for object notation in the past. That way,
>
>   function() {
>       {
>           (a, b)
>           a.add(b)
>       }
>   }
>
> would still be an anonymous block where
>
>   function() {
>       asyncAction(..., { (a, b) a.add(b); } }
>   }
>
> would be a block lambda as an argument of an async function. No semantic
> change for an identical syntax, in regards to strict ES5.
>
> The case where you would like to use a block lambda as a stament can be
> resolved by adding parenthesis, like with the current object notation. And
> since I still continue to hope we'll ditch the unprefixed anonymous block in
> some future revision of ES, that very small edge case could vanish at the
> same time.
>
> Does it seems possible/acceptable?

Looks like a great idea to me!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Block lambda is cool, its syntax isn't

[Thaddee Tyl]

I have heard many fellow programmers say that, while block lambdas
would be welcome, Ruby's |a, b| syntax is ugly.
I thought I was the only one feeling this way, but since I am not, I
would like to ask why the parentheses cannot be used there.

{ (a, b) a + b }

cannot conflict with any existing program; at least I don't see how it can.

This is a reaction to the following tweet:
https://twitter.com/#!/tabatkins/status/156813490785492992
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Octal literals have their uses (you Unix haters skip this one)

[Thaddee Tyl]

On Thu, Jan 12, 2012 at 9:57 PM, Axel Rauschmayer  wrote:
> If we were willing to add octal with a clear prefix I would be fine with
> that, for consistency with hex, I'd lean towards 0o<...>, but I'm open to
> any suggestions that people may wish to add.  Personally I'd also like a
> binary form, a la 0b
>
>
> +1 to both. Then we have three kinds of non-decimal literals, for example:
> 0b1011, 0o732 and 0x.
>
> For long literals, Java has started to make "_" as a separator legal, that
> would be nice to have, too:
>      let aLotOfMoney = 120_327_756_228;

+1 to that, too. It does make things easier to read. Ruby has had that
for decades.

It is a very specific use-case, but I feel like we shouldn't disregard
non-generic use-cases. 0644 (used in node.js in a unix environment) is
a non-generic use-case, and as such I feel it shouldn't just die. That
is why I would like 0644 and 0o644 to co-exist.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Octal literals have their uses (you Unix haters skip this one)

[Thaddee Tyl]

Can't we just have free competition between "0o644" and "0644"?

Add the former, and we'll see which wins in real code!

If "0o644" wins, and if people like Doug Crockford advocate the drop of
"0644", we may then consider including this in a new version of Strict Mode.

Furthermore, I'd like to weigh in with Herby Vojčík and ask for 8r644
support.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Thaddee Tyl]

> From: Axel Rauschmayer 
>> On the other hand people may find Point.new(x, y) as intuitive, as they will 
>> think of ruby instead of java.
>
> As an aside, you can see API code for the above functionality here:
> - https://github.com/Gozala/selfish [Irakli, updated]
> - http://dl.2ality.com/dl/2011/06/Proto.js [me]
>
> --
> Dr. Axel Rauschmayer

I wish to assert my support for the
http://dl.2ality.com/dl/2011/06/Proto.js syntax. It looks very clean
to me.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: May 24-26 rough meeting notes

[Thaddee Tyl]

On Mon, May 30, 2011 at 6:55 AM, Brendan Eich  wrote:
> On May 29, 2011, at 2:58 PM, Thaddee Tyl wrote:
>> ... I believe that, given the fact that browsers will implement
>> ES.next incrementally, we should find a way to allow graceful
>> fallback, rather than version-driven conditionals.
>
> This is trivial for new global object properties, but such additions in the
> past, even including JSON, have been breaking changes for some web sites.

They have coped with that by using polyfills such as:

  if (!this.JSON) {
this.JSON = {};
...
  }

> With the module system in ES.next we are probably instead going to add
> standard modules named by anti-URI module resource locators such as "@name",
> and thereby avoid polluting the global object, or even the Object
> constructor.
> But say we do add, e.g. Object.createPrivateName(name, visible). That will
> be detectable using good old "object detection" -- no need for a "features"
> object as you show.
>
>
>> The fact that Harmony features are already batched up makes this easy;
>> maybe we can use a different use-pragma that already defined.
>> Something like an object literal. Object literals are so cool.
>> if (features.es6.proxies) {
>
> How is this better or different from any version-driven conditional? It's
> not, at least not up until the second dot.
>
> Authors will want to object-detect APIs expressed as built-in objects, but
> other features including new syntax cannot be handled easily or at all that
> way, and many authors will want the whole pie.
>
> /be


In the current Harmony proposals, there are as many "syntax breakers"
(with which current js parsers fire a syntax error) as there are "soft
breakers" (which allow graceful degradation). Syntax breakers include
things like "let", "const", destructuring, parameter default values,
rest parameters, spread, modules and generators. Those are the syntax
errors. Soft breakers include proxies, weak maps, egal, proper tail
calls, binary data, Number, String, Function and Math improvements,
typeof null and completion reform. These, on the other hand, can be
feature-detected.

For most of the soft breakers, people will *definitely* want to check
for implementation backing. For things like proper tail calls, feature
detection can mean performance tuning; for typeof null it means that
we can make sure that, in all cases, our code won't break.

For the syntax breakers, however, browsers will, indeed, have to
implement all those features in one shot. They cannot do it
incrementally, or else ES.next-only code may very well break.

What do you think? Should we force browser vendors to implement
soft-breakers in one shot too, even though we could let them do it one
feature at a time via feature detection?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: May 24-26 rough meeting notes

[Thaddee Tyl]

On Sun, May 29, 2011 at 10:00 PM, Brendan Eich  wrote:
> On May 29, 2011, at 12:55 PM, Thaddee Tyl wrote:
>
>> Don't be upset!
>
> Not at all, I'm simply skeptical (and saucy in saying so) about 
> jurisdictional fights this early in thinking creatively about cross-cutting 
> solutions. Seems kind of silly to call process police, doesn't it?

No fight intended.

>> I just believe that new HTML syntax would be better off in the HTML
>> living standard. More people read it, more people contribute to
>> correcting its bugs. Getting involved in it can only be beneficial.
>
> Yes, I agree, and public-script-co...@w3.org is read by all the best 
> HTML5/HTML/W3C/WHATWG people, whatever their w3.org, whatwg.org, or other 
> affiliations.

Does it mean that I should not discuss this here?

If not, I believe that, given the fact that browsers will implement
ES.next incrementally, we should find a way to allow graceful
fallback, rather than version-driven conditionals.

The fact that Harmony features are already batched up makes this easy;
maybe we can use a different use-pragma that already defined.
Something like an object literal. Object literals are so cool.

var features = Object.features || {};
features.es6 = features.es6 || {};
...
if (features.es6.proxies) {
 Object.createHandled = function(proto, objDesc, noSuchMethod) {
   var handler = {
     get: function(rcvr, p) {
       return function() {
         var args = [].slice.call(arguments, 0);
         return noSuchMethod.call(this, p, args);
       };
     }
   };
   var p = Proxy.create(handler, proto);
   return Object.create(p, objDesc);
 };
} else {
 Object.createHandled = function(proto, objDesc, noSuchMethod) {
   var p = Object.create(p, objDesc);
   p.__noSuchMethod__ = noSuchMethod;
   return p;
 };
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: May 24-26 rough meeting notes

[Thaddee Tyl]

Don't be upset!

I just believe that new HTML syntax would be better off in the HTML
living standard. More people read it, more people contribute to
correcting its bugs. Getting involved in it can only be beneficial.

On Sun, May 29, 2011 at 9:25 PM, Brendan Eich  wrote:
> On May 29, 2011, at 6:45 AM, Thaddee Tyl wrote:
>
>>>>> Consensus on moving some form of versioning into Harmony.  The strawman 
>>>>> is a
>>>>> bit light at this time, so no specifics yet.
>>>>
>>>> A lot of the above looks like HTML. Isn't versioning that depends on
>>>> HTML out of scope for the ECMAScript standard?
>>>
>>> Yes, so? Call the jusdiction police :-P. We were talking about a "systems" 
>>> problem, which requires looking across layers and considering the big 
>>> picture.
>>>
>>> At the meeting, Mark Miller suggested we take the idea of  to 
>>> the public-script-coord mailing list. I'll do that next week.
>>
>>
>> It really needs to be discussed by the whatwg however.
>
>
> Oh really? Why exactly is that? Note that I'm a founder of whatwg.org.
>
> The plan of record that I cited and plan to use regarding this kind of 
> JS/HTML/DOM cross-cutting concern is to mail to public-script-co...@w3.org. 
> That ought to be enough to start engaging the several interested groups.
>
> /be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: May 24-26 rough meeting notes

[Thaddee Tyl]

> Date: Sat, 28 May 2011 12:57:04 -0700
> From: Brendan Eich 
> http://www.mail-archive.com/es-discuss@mozilla.org/msg05005.html had the 
> example I was trying to reconstruct from memory at last week's meeting:
>
> 
>  // new.js inline-exanded here
> 
>  
>  
> 
>
>>> Consensus on moving some form of versioning into Harmony.  The strawman is a
>>> bit light at this time, so no specifics yet.
>>
>> A lot of the above looks like HTML. Isn't versioning that depends on
>> HTML out of scope for the ECMAScript standard?
>
> Yes, so? Call the jusdiction police :-P. We were talking about a "systems" 
> problem, which requires looking across layers and considering the big picture.
>
> At the meeting, Mark Miller suggested we take the idea of  to the 
> public-script-coord mailing list. I'll do that next week.


It really needs to be discussed by the whatwg however.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: arrow syntax unnecessary and the idea that "function" is too long

[Thaddee Tyl]

On Sat, May 7, 2011 at 6:31 PM, Peter Michaux  wrote:
> On Sat, May 7, 2011 at 9:16 AM, Thaddee Tyl  wrote:
>> I believe that David Bruant has a good point. We *need* a shorter syntax
>> because we advocate the use of map/reduce, etc., which require simple
>> anonymous functions.
>
> No. We don't "need" syntactic sugar. The current function syntax is
> working and we are talking a few characters difference, not hundreds.
>
> Map/reduce don't "require" syntactic sugar.

It is not a requirement, indeed. I feel like it is a need, however.
JavaScript is still seen as a badly object-oriented programming
language by those who still think it is java with a weird syntax. I do
hope it grows to be known as an outstanding functional programming
language. Thanks to ES5's strict mode, it now gets freed from the
"this" issue, for those that use it.

Huffmanization requires that we reduce the size of what we want to use
often. If we want to use more functions, then it isn't just eleven
less characters once in a while, it becomes a bigger deal!

> There are so many more important issues to address.

If you feel like addressing more important issues, I warmly beg you to do so!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: es-discuss Digest, Vol 51, Issue 5

[Thaddee Tyl]

I believe that David Bruant has a good point. We *need* a shorter syntax
because we advocate the use of map/reduce, etc., which require simple
anonymous functions.

As to why we should choose # rather than coffescript's ->, there are two points:

- The # syntax is more readable. -> is perlish. It looks like two very
much used operands, "minus" and "greater than",
without any related meaning.
Python, which has an enormous emphasis on readability,
is ready to add the ':' at the end of the line before each block to
make it readable.
Here, greater readability is on par with a decrease in the number of
characters needed.
- I talked to Alex Russell about this, and his answer was:
"Arrow requires recursive descent, fat arrow just passes the buck on
bind. Not settled."
This seems like an interesting issue that makes the # syntax even more
agreeable.

As to comment on Kyle Simpson's raised issue, it is true that this
channel lacks web developers' intervention.
I am a simple web developer myself. I must admit most developers don't
sign up to this mailing list
because it can be complex to handle (lot of stuff to read) and there
is no tl;dr. As such, the "voting poll" idea
isn't absurd. If done well, on the ecmascript's webpage, and with ads
on Mozilla's mdn, it can give an interesting
estimate of how popular it would be...
On the other hand, it cannot be safe. People would vote without
digging deep enough into why such proposal is
nice to have. As a result, we can't promise that the result of the
poll will be chosen by the committee.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss