Re: Re: Inline ES Modules

[Peter van der Zee]

I actually quite like the idea.

- Extend the import syntax to allow an identifier instead of a string.
Such identifier must be match the name of a module declaration the
same file (they are hoisted and a syntax error if not
present/something else).
- Module declaration names are abstracts since they are "exposed" in
the scope through an import.
- Module declarations only allowed on the global level (like
import/export declarations)
- Maybe in the future modules could refer to their name identifier to
access meta data.
- Module bodies are for all intentions and purposes treated as if they
were independent js module files
- Module identifiers are hoisted

Bonus points for making the end token easier to scan for
(realistically speaking I'm pretty sure a regular block is preferred).
This could help browsers parse large bundle files by fast scanning
past module blocks.

```
import foo from bar;
module bar {#
  log('I'm a module!');
#}
```

The downside to inline modules is that I'm not sure whether this has
more real use beyond webpack/metro/rollup/etc bundlers that put all
modules in one bundle file. However, that might still help js envs in
some way.

This kind of thing wouldn't need to be a huge tax on the spec by
reusing existing semantics.

- peter

On Mon, Jun 18, 2018 at 11:10 PM, Darien Valentine
 wrote:
> ```
> import getPersonType from 'data:text/javascript,\
>   export default function getPersonType(person) {\
> switch (person) {\
>   case \'Teacher\': return \'A teacher\';\
>   case \'Director\': return \'A director\';\
> }\
>   }';
> ```
>
> okay, not a serious suggestion, but it does technically work :)
>
> ___
> 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: try/catch/else

[Peter van der Zee]

>> On Thu, Feb 8, 2018 at 10:13 AM, Claude Pache 
>> wrote:
>>>
>>> What about the following pattern (labelled block + break)?
>>>
>>> ```js
>>> processSuggestions: {
>>> let suggestions;
>>> try {
>>>   suggestions = await fetchSuggestions();
>>> } catch (e) {
>>>   alert('Failed to load suggestions');
>>>   break processSuggestions;
>>> }
>>> showSuggestions(suggestions);
>>> }
>>> ```

I don't mean to hijack this tread. I'm mostly curious why you opt or
even suggest for that over putting it in a function and an early
return? Like;

```
function processSuggestions() {
  let suggestions
  try {
suggestions = await fetchSuggestions();
  } catch (e) {
return alert('Failed to load suggestions');
  }
  showSuggestions(suggestions);
}
```

This is almost identical, especially the way the example was written.
I understand the differences, I don't think they're a problem for by
far most cases where you'd want this.

That said I wouldn't mind seeing try/catch/else/finally because the
pattern(s) above still leads to awkward code in the real world.

One could bikeshed on how "else" implies the attempt ("try") to have
failed rather than succeeded. On the other hand making it
try/then/catch/finally is also going to be confusing so whatever :)

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

Re: Mixing grammars

[Peter van der Zee]

> Sorry, but your message looks very opinionated and I can't seem to find any
objective reasoning in there.

Nah, you might be thrown off by the different grammar ;)

Ok.

Thing is, `|>` would introduce a new way of calling a function in a
way that is not at all in line with how functions are called in JS.
That means JS devs won't easily recognize `a |> b` as easily as they
do `b(a)`. (Also consider less text-book-y examples here please...)

You might argue that this will be a transitional period and I will
counter you with an existential question; Why at all? What does this
solve? And is it worth the cognitive overhead?

I think this is a bad addition to the language. One that doesn't "fit"
with how the language currently works. And one that will lead to many
devs being thoroughly confused when confronted with this.

But, I'm not asking you to take my opinion on it. Research it. Please
do some research on this. Reach out to devs of all types (not just
react devs, not just functional programmers, not just vanilla JS
coders, not just code golfers, and definitely not just people on the
TC39) and figure out how they will respond when confronted with
additions like this. And please post those results here. I don't mind
being wrong. As long as you can back those claims up when introducing
something like this.

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

Mixing grammars

[Peter van der Zee]

I want quickly a point to make. I have a while ago of the, well, I
know actually not how that thing is called, but the "|> operator"
heard. I ignored it as "funny but a very different paradigm than JS".

Now see I today a tweet pass by that somebody a draft of a propasal
has created [1] to this really to JS to add.

I think that it a bad idea is and hope really that the TC39 first a
good research does to the desirability and repercussions of the adding
of similar syntax to the language.

For me is it just like you the Dutch grammar apply on the English.
Like this message tries to show. You.

- peter


1; https://github.com/tc39/proposal-pipeline-operator/issues/52


===

(Dutch)

Ik wil even een punt maken. Ik heb een tijdje geleden van de, tja, ik
weet eigenlijk niet hoe dat ding heet, maar de "|> operator" gehoord.
Ik deed het af als "grappig maar een heel ander paradigma dan JS".

Nou zag ik vandaag een tweet voorbij komen dat iemand een draft van
een proposal heeft opgesteld [1] om dit daadwerkelijk aan JS toe te
voegen.

Ik denk dat het een slecht idee is en hoop echt dat de TC39 eerst een
goed onderzoek doet naar de wenselijkheid en gevolgen van het
toevoegen van dergelijke syntax aan de taal.

Voor mij is het net alsof je de Nederlandse grammatica toepast op het
Engels. Zoals dit bericht probeert aan te tonen.

- peter


1; https://github.com/tc39/proposal-pipeline-operator/issues/52
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Arrow function followed by divide or syntax error?

[Peter van der Zee]

Oh, so subtle. You're right, the missing semi makes it a syntax error.
Thanks for clearing that up :)

- peter

On Wed, May 24, 2017 at 11:10 AM, Andreas Rossberg <rossb...@google.com> wrote:
> Note that the arrow function can only form an ExpressionStatement, which
> requires a terminating semicolon. There is none in this example, nor a line
> break that would allow one to be inserted implicitly. So when reaching the
> first `/` a syntax error is apparent, since there is no way the input can
> still form a well-formed statement at that point.
>
> On 24 May 2017 at 10:32, Peter van der Zee <e...@qfox.nl> wrote:
>>
>> > Unlike an ordinary function expression, which is a PrimaryExpression, an
>> > arrow function is merely an AssigmentExpression, so has much lower
>> > precedence than any arithmetic operator.
>>
>> I'm curious how this should be parsed so let's break this down.
>>
>> Given the following "Script" (I don't think the actual goal matters much
>> here):
>> ```
>> x=x=>{}/alert(1)/+alert(2)//
>> ```
>>
>> Script :
>>   ScriptBody opt
>>
>> ScriptBody :
>>   StatementList
>>
>> StatementList [Yield, Return] :
>>   StatementListItem [?Yield, ?Return]
>>   StatementList [?Yield, ?Return] StatementListItem [?Yield, ?Return]
>>
>> StatementListItem [Yield, Return] :
>>   Statement [?Yield, ?Return]
>>   Declaration [?Yield]
>>
>> Statement [Yield, Return] :
>>   BlockStatement [?Yield, ?Return]
>>   VariableStatement [?Yield]
>>   EmptyStatement
>>   ExpressionStatement [?Yield]
>>   ... (trunced)
>>
>> ExpressionStatement [Yield] :
>>   [lookahead ∉ { { , function , class , let [ }] Expression [In, ?Yield] ;
>>
>> Expression [In, Yield] :
>>   AssignmentExpression [?In, ?Yield]
>>   Expression [?In, ?Yield] , AssignmentExpression [?In, ?Yield]
>>
>> AssignmentExpression [In, Yield] :
>>   ConditionalExpression [?In, ?Yield]
>>   [+Yield]
>>   YieldExpression [?In]
>>   ArrowFunction [?In, ?Yield]LeftHandSideExpression [?Yield] =
>> AssignmentExpression [?In, ?Yield]
>>   LeftHandSideExpression [?Yield] AssignmentOperator
>> AssignmentExpression [?In, ?Yield]
>>
>> I hope we can agree that the leading `x=` is consumed by
>> "LeftHandSideExpression [?Yield] AssignmentOperator" in the very last
>> rule above. Proceeding with "AssignmentExpression" from the arrow arg.
>>
>> Note that there is no other rule that applies up to this point.
>>
>> ArrowFunction [In, Yield] :
>>   ArrowParameters [?Yield] [no LineTerminator here] => ConciseBody [?In]
>>
>> ArrowParameters [Yield] :
>>   BindingIdentifier [?Yield]
>>   CoverParenthesizedExpressionAndArrowParameterList [?Yield]
>>
>> Here "CoverParenthesizedExpressionAndArrowParameterList" will consume
>> the second `x` and then the only rule in "ArrowFunction" will consume
>> the arrow (`=>`). Continueing to parse the remainder
>> `{}/alert(1)/+alert(2)//` starting at "ConciseBody".
>>
>> ConciseBody [In] :
>>   [lookahead ≠ {] AssignmentExpression [?In]
>>   { FunctionBody }
>>
>> Obviously only the second rule applies so we parse the function body
>> and the curlies. We parse greedy but the function body is empty so
>> only the next two chars are consumed (`{}`). Parser has
>> `/alert(1)/+alert(2)//` left to parse and the "Statement" rule has
>> depleted it's options. So we go back to "StatementList" and parse
>> another statement. This should result in a regular expression, a plus
>> operator, a call expression, and a single line comment.
>>
>> I don't think there's a rule here that allows parsing operators after
>> an explicit arrow function body as being part of the arrow function.
>> In fact, I remember that this was explicitly designed this way to
>> prevent this ambiguity. Beyond that I agree that it parses similar to
>> function expressions.
>>
>> If this was wrong I'd love to know the right way to parse this.
>>
>> - peter
>>
>>
>>
>> On Wed, May 24, 2017 at 9:18 AM, Andreas Rossberg <rossb...@google.com>
>> wrote:
>> > On 24 May 2017 at 08:57, Gareth Heyes <gareth.he...@portswigger.net>
>> > wrote:
>> >>
>> >>
>> >>>
>> >>> you'll get a SyntaxError in all browsers but Edge, which interprets it
>> >>> as
>> >>> `(x => {}) * alert(1)`.
>> >>>

Re: Arrow function followed by divide or syntax error?

[Peter van der Zee]

> Unlike an ordinary function expression, which is a PrimaryExpression, an 
> arrow function is merely an AssigmentExpression, so has much lower precedence 
> than any arithmetic operator.

I'm curious how this should be parsed so let's break this down.

Given the following "Script" (I don't think the actual goal matters much here):
```
x=x=>{}/alert(1)/+alert(2)//
```

Script :
  ScriptBody opt

ScriptBody :
  StatementList

StatementList [Yield, Return] :
  StatementListItem [?Yield, ?Return]
  StatementList [?Yield, ?Return] StatementListItem [?Yield, ?Return]

StatementListItem [Yield, Return] :
  Statement [?Yield, ?Return]
  Declaration [?Yield]

Statement [Yield, Return] :
  BlockStatement [?Yield, ?Return]
  VariableStatement [?Yield]
  EmptyStatement
  ExpressionStatement [?Yield]
  ... (trunced)

ExpressionStatement [Yield] :
  [lookahead ∉ { { , function , class , let [ }] Expression [In, ?Yield] ;

Expression [In, Yield] :
  AssignmentExpression [?In, ?Yield]
  Expression [?In, ?Yield] , AssignmentExpression [?In, ?Yield]

AssignmentExpression [In, Yield] :
  ConditionalExpression [?In, ?Yield]
  [+Yield]
  YieldExpression [?In]
  ArrowFunction [?In, ?Yield]LeftHandSideExpression [?Yield] =
AssignmentExpression [?In, ?Yield]
  LeftHandSideExpression [?Yield] AssignmentOperator
AssignmentExpression [?In, ?Yield]

I hope we can agree that the leading `x=` is consumed by
"LeftHandSideExpression [?Yield] AssignmentOperator" in the very last
rule above. Proceeding with "AssignmentExpression" from the arrow arg.

Note that there is no other rule that applies up to this point.

ArrowFunction [In, Yield] :
  ArrowParameters [?Yield] [no LineTerminator here] => ConciseBody [?In]

ArrowParameters [Yield] :
  BindingIdentifier [?Yield]
  CoverParenthesizedExpressionAndArrowParameterList [?Yield]

Here "CoverParenthesizedExpressionAndArrowParameterList" will consume
the second `x` and then the only rule in "ArrowFunction" will consume
the arrow (`=>`). Continueing to parse the remainder
`{}/alert(1)/+alert(2)//` starting at "ConciseBody".

ConciseBody [In] :
  [lookahead ≠ {] AssignmentExpression [?In]
  { FunctionBody }

Obviously only the second rule applies so we parse the function body
and the curlies. We parse greedy but the function body is empty so
only the next two chars are consumed (`{}`). Parser has
`/alert(1)/+alert(2)//` left to parse and the "Statement" rule has
depleted it's options. So we go back to "StatementList" and parse
another statement. This should result in a regular expression, a plus
operator, a call expression, and a single line comment.

I don't think there's a rule here that allows parsing operators after
an explicit arrow function body as being part of the arrow function.
In fact, I remember that this was explicitly designed this way to
prevent this ambiguity. Beyond that I agree that it parses similar to
function expressions.

If this was wrong I'd love to know the right way to parse this.

- peter



On Wed, May 24, 2017 at 9:18 AM, Andreas Rossberg  wrote:
> On 24 May 2017 at 08:57, Gareth Heyes  wrote:
>>
>>
>>>
>>> you'll get a SyntaxError in all browsers but Edge, which interprets it as
>>> `(x => {}) * alert(1)`.
>>>
>>> Given how confusing that expression is, I think that the SyntaxError is
>>> the right choice.
>>
>>
>>  Well it is a function expression. So IMO Edge is right. It's equivalent
>> to:
>> x=function(){} * alert(1)
>
>
> Edge is wrong. Unlike an ordinary function expression, which is a
> PrimaryExpression, an arrow function is merely an AssigmentExpression, so
> has much lower precedence than any arithmetic operator. The rationale is
> that its body doesn't necessarily have braces, so `x => x * 1` would be
> ambiguous.
>
> ___
> 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: Function constants for Identity and No-op

[Peter van der Zee]

>> What's the issue with document.createElement('object')?

> It's a callable exotic object.

>> Function.isFunction? :D

> typeof is what you are looking for.

There is precedent (at least in IE [1]) for exotic functions where
`typeof` returned "unknown". Could happen for any exotic value unless
the spec changed on that. An `isFunction`, or rather, a simple
`isCallable`, may not be that far off the mark and is in line with the
existing `isArray`. Though I'd much rather have callables invariantly
locked down to being "typeof function". Even if that means explicit
exceptions to some legacy cases.

- peter

PS. Regexes in firefox were "callable" and had typeof function, but I
think that's so far back [2] it's not super relevant here. Of course
the same could be said about the IE case.

[1]; one of many examples:
http://stackoverflow.com/questions/10982739/typeof-returning-unknown-in-ie
[2]; https://bugzilla.mozilla.org/show_bug.cgi?id=61911
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES7 - the standard

[Peter van der Zee]

On Thu, Jun 16, 2016 at 11:54 PM, Raul-Sebastian Mihăilă
 wrote:
> I see that es7 is now a standard.
> http://www.ecma-international.org/ecma-262/7.0/index.html

Nice, thanks for the heads up.

Could the spec next time have a non-normative section with the main
changes compared to the previous? Something like section D and E but
without the compatibility reasons, just a quick overview of the new
features.

Can anyone point me in the direction of a resource that contains these
changes now?

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

Pseudo headless arrows

[Peter van der Zee]

There are two ways of writing argument-less arrows;

() => x;
_ => x;

(Where `_` can be any identifier, of course.) I understand why we
can't drop the head entirely so if we're forced to type anything at
all, anyways, why not at least make it simpler by pressing two
different keys instead of three/four:

==> x;

I don't believe this leads to syntactical problems anywhere, not even
with arrow functions themselves and it's future proof for at least the
cases I'm aware of.

It's a minor addition but I think it's much nicer than either of the
two alternatives we currently have, which lead to a lot of
inconsistencies (it's spaces and tabs all over again).

Semantics are the same otherwise as `() => x` would be.

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

Re: Swift style syntax

[Peter van der Zee]

On Mon, Oct 12, 2015 at 10:12 AM, Mohsen Azimi  wrote:
>> Your syntax is ambiguous: Should your code be interpreted as:
>>
>>let passed = objs.filter($0 => $0.passed)
>>
>> or:
>>
>>let passed = $0 => objs.filter($0.passed)
>
> I don't understand why you parsed it in the second way Claude?

It's not about the "why". He's trying to tell you this code _is_
ambiguous. The parser cares not about the why.

Look at the generic case; how could the parser know how `#0` is scoped?

There is an ambiguity and you'll need some way of telling JS what the
scope is of that `#0`. This is why there's an arrow. This is why you
need to wrap arguments in parenthesis: Disambiguation. Basically; try
to think of ways how your example should be translated. Then try to
see if they _can_ be translated differently. If they can, then you
need to think of a way to disambiguate. In the above, having no
"function offset marker" (like what the arrow is) means you cannot
know where it starts.

On a personal two cents; ugh, changes in this proposal would only lead
to even worse illegible code.

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

Re: please add orEqual operator

[Peter van der Zee]

On Mon, Aug 10, 2015 at 3:50 AM,  myemailu...@gmail.com wrote:
 Isn't
 prop ||= 0;
 better than
 prop = prop || 0;
 and it can be even defined like this.
 prop ||= var1 ||= var2 ||= 0;
 but then i dont know how we can use it ike this
 if (num == 3 ||=4 ||=6)

Sounds like you want two operators; `||=` for the compound assignment
case and `||==` and `||===` for the compare the RHS to the LHS of the
last `===` or `==` op, or something like that. Defining a single op
for both of these cases is likely to lead to ambiguity.

The `||=` (and `=`) case has been discussed a couple of times, look
in the esdiscuss archives.
I'm sure something like `||==` has been discussed too though I don't
recall it myself. I tend to use switches myself for this in case perf
is an issue.

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

Re: Named Paramters

[Peter van der Zee]

(A minifier that breaks your code is a broken minifier and should
never be a valid argument for these cases)

On Sun, Jul 12, 2015 at 10:29 AM, Denis Pushkarev zloir...@zloirock.ru wrote:
 1. It would break backwards compatibility:

 ```js
 var bar = 1;
 if(baz(bar))foo(bar = 5);
 console.log(bar); // 5 in some cases
 ```

 2. Code with this feature will be broken after minification.
 ___
 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: Reflect.hasOwn() ?

[Peter van der Zee]

On Sat, Jul 26, 2014 at 5:14 PM, Mark S. Miller erig...@google.com wrote:
 Hi Peter, what is the security issue you are concerned about?

Unless `Reflect` is completely sealed out of the box, you can never
know whether properties on it are the actual built-ins. That's all.

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

Re: Reflect.hasOwn() ?

[Peter van der Zee]

On Sun, Jul 27, 2014 at 1:57 PM, David Bruant bruan...@gmail.com wrote:
 You can deeply freeze it yourself before any other script accesses it.

That's already assuming you are first. You may not be without your
knowledge (ISP injection, virus hijack, garden gnomes, etc). At this
point you'll be too late.

 My point being that there are ways to prevent any non-trusted scripts from 
 modifying Reflect

And I guess I'm saying, no, there isn't.

It'd be nice if there was some kind of mechanic of detecting/ensuring
that some built-in is indeed a built-in. That would take away all of
this pain. Maybe including a system module could fix this issue. I
doubt I'm the first here to mention that though.

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

Re: Reflect.hasOwn() ?

[Peter van der Zee]

On Sun, Jul 27, 2014 at 6:14 PM, Mark S. Miller erig...@google.com wrote:
 Although there is some interesting work in trying to obtain security
 relevant guarantees from a script that isn't first, where a malicious script
 may instead have been first (link please if anyone has it), this work did
 not seem practical to me.

I'm not familiar with actual deep research in this area for JS.

Seems to me like a syntactic way of including a module that's
guaranteed to be a system module (completely sealed of the shelf)
would circumvent a lot of these problems. For example, a module that
gives you a fresh default global object with all the built-ins
guaranteed unchanged. Since the syntax can't really be affected by an
earlier script and the language could define a hardcoded system
module, this kind of approach seems viable to me. But we're digressing
from the topic.

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

Re: Reflect.hasOwn() ?

[Peter van der Zee]

On Sat, Jul 26, 2014 at 5:43 AM, Axel Rauschmayer a...@rauschma.de wrote:
 The only exception that comes to my mind is `{}.hasOwnProperty.call(obj,
 key)` (which is the only safe way to invoke this method). Would it make
 sense to provide that as a tool function, e.g. as `Reflect.hasOwn()`?

That would make it unsafe again. Not so much from random people
polluting the global Object, but certainly unsafe from a security
perspective.

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

Re: Trailing comma for function arguments and call parameters

[Peter van der Zee]

On Fri, Jul 4, 2014 at 12:52 AM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
 Will it makes sense to standardize a trailing comma for function arguments,
 and call parameters?

Fwiw, it also makes sense in AMD, where the set of dependencies can
grow and the desire to put every module on its own line becomes
desirable. I tend to do it for the array since you can be consistent
with the leading/trailing comma there, but not so much for the func
args.

Allowing an empty comma after the param list could fix that. Also
allowing one before for the comma-first people would be nice.

 But again, I already think that for the language itself, it won't be super 
 useful just yet, since backward-incompatible syntax won't allow using it 
 anyways for a long amount of time

This argument doesn't hold for server side approaches like node, or
build-step approaches like you use yourself.

Also, if you apply this argument to any new syntax the language never
changes, for better or worse ;)

Anyways, +1 from me. I'm tired of irrelevant diff lines...

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

Re: BNF grammar in specification license

[Peter van der Zee]

Dear Kalinni Gorzkis,

I'm curious to what you're hoping to achieve here. This is not your
first email to this thread, and by searching on the web, I see you're
sending a lot of related messages to various other language groups and
what not. This makes me doubt you're actually interested in using the
content in any way, or at least in a way that this becomes relevant
for you. It might help us understand your goal. What are you trying to
achieve?

Are you OCD-ing over licensing? That's fine, we all have our pet peeves.
Maybe you have different views on licenses? Great, though this is
probably not the best place for these discussions.

I'm curious, so please explain.

- peter

On Wed, Jul 2, 2014 at 12:51 PM,  musicdenotat...@gmail.com wrote:
 Does the BNF grammar for ECMAScript in the specification licensed under BSD 
 license? The license says that software (code) is BSD-licensed. BNF grammar 
 is machine-readable and -executable, is it software?
 ___
 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: Multiline Strings

[Peter van der Zee]

On Fri, Mar 7, 2014 at 8:56 AM, Florian Bösch pya...@gmail.com wrote:

 There's two complications with that. A string doesn't carry the line number
 it comes from. Also, myfile.js might get concated with other files. And
 lastly strings might get pasted together from smaller snippets.

I think you want to take a look at source maps. They're specifically
designed to deal with this problem.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array detection (was Re: Final iterator spec)

[Peter van der Zee]

 Depends upon what you mean by Array detection.  If you mean is obj an 
 exotic array object (ie, an object that automatically updates the length 
 property value as integer indexed properties are added or deleted) then 
 Array.isArray(obj) detects exactly that.

Okay cool. Is there merit in consistency for this? Iterators getting
an `isIterator()` method perhaps?

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

Re: what kind of problem is this fat arrow feature trying to solve ?

[Peter van der Zee]

(In all fairness, Andrea was merely, and quite explicitly so, asking for
the rationale behind the fat arrow, not a scrutiny of his examples. Tab's
sarcastic response was unnecessary on a whole different level, too.)


On Wed, Oct 2, 2013 at 1:14 PM, Benjamin (Inglor) Gruenbaum 
ing...@gmail.com wrote:

 There are two things here:

  - In JS I (as well as most code in libraries I read) tend to use function
 expressions a lot. The arrow notation is easier to read in my opinion. It's
 shorter and more concise. That's a weak argument for it, but I think just
 making the language more concise is an argument on its own.

  - While we're making function expressions shorter, let's fix `this`
 function expresisons. Pretty much every host environment be it node, the
 web browser or embedding uses deferred execution and event loop driven
 concurrency at some level.

 While there is nothing in JavaScript itself that dictates this sort of
 concurrency in practice events are used extensively when coding JavaScript.
 Using an object and adding handlers that need a reference to that object is
 very common in the browser and in node.

 It's very common in practice and having lexical this in arrow functions
 seems very useful. An indicator might be that in languages that support it
 like CoffeeScript you see it used all the time, and the fact you see people
 using the `this=that/self/_this` pattern all the time. That pattern
 introduces its own set of problems - for example it creates a closure scope
 where one might not be needed and it's boilerplate.

 Having fat arrow lets us solve that.

 Benjamin Gruenbaum

 -- Forwarded message --
 From: Andrea Giammarchi andrea.giammar...@gmail.com
 To: Tab Atkins Jr. jackalm...@gmail.com
 Cc: es-discuss@mozilla.org es-discuss@mozilla.org
 Date: Tue, 1 Oct 2013 19:35:28 -0700
 Subject: Re: what kind of problem is this fat arrow feature trying to
 solve ?
 setTimeout accept extra arguments ... I write JavaScript that uses this
 feature.

 `setTimeout(callback, delay, arg1, arg2, argN, evenAnObject);`

 so fat arrow does not solve much here, I can use self as first argument
 and I am good.

 `forEach` and all other arrays accept a second argument

 `array.forEach(doStuff, boundContextObject);`

 so fat arrow does not solve a thing in mostly all Array extras.

 for **DOM** I use handlers as specified by **W3C** so that `{handleEvent:
 function () {this}}` works better than any mess I could create with
 callbacks that I won't be unable to remove later on (as I've said) ... so I
 can use `removeEventListener(this)` in every method handled by that object.

 So I actually wonder what kind of JavaScript **you** write because this
 was a honest question but probably ... people not familiar with JS are the
 answer: since developers ignore part of JS specs available since every then
 we need a fat arrow to break old syntax to make the creation of self bound
 function easier.

 This would be already an answer so thanks for participating.

 br

 ___
 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: f() = x de facto standard

[Peter van der Zee]

On Wed, Aug 7, 2013 at 6:21 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:

 I'm not sure where that analysis came from? As far as I know there were no
 such changes in ES5.1 and the ES5.1 grammar clearly allows a function call
 to appear on the LHS of an assignment.


I got it from https://code.google.com/p/esprima/issues/detail?id=81#c19,
maybe I should have dug deeper to confirm it...


 In addition, functions are no longer allowed to return Reference values.
  I don't see us changing the latter, so it comes down whether the error is
 reported as an early syntax error or a runtime TypeError.


Probably what the bug is about.

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

Re: Identifying ECMAScript identifiers

[Peter van der Zee]

Norbert, for the sake of completeness;

ZeParser (http://github.com/qfox/zeparser) does support complete
unicode identifiers
ZeParser2 (http://github.com/qfox/zeparser2) doesn't (I simply didn't bother)

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

Array method ranges

[Peter van der Zee]

What about adding specific range arguments to the es5 array methods
(forEach, map, etc)? Currently the start (inclusive) and stop
(exclusive) is always 0 ... length, but what if you only want to map
over a sub range of the array? Or maybe I want to traverse the array
in reverse? I'd either have to slice it or .reverse it, neither are
something I would want. So I fall back to `for` or `while` loops.

As for the context parameter, I believe undefined won't change the
context opposed to omitting it, right?

arr.forEach(function(){ ...});
// same as
arr.forEach(function(){ ...}, undefined, 0, arr.length);

arr.slice(10,10).forEach...
arr.slice(80,20).reverse().forEach...
=
arr.forEach(function(){ ...}, undefined, 10, 20);
arr.forEach(function(){ ...}, undefined, 100, 80); // run from 100 to
80, backwards

Negative numbers could behave the same as in slice (offsets from the
last item, rather than the first).

arr.forEach(function(){ ...}, undefined, -20); // run from length-20 to length
arr.forEach(function(){ ...}, undefined, -20, -10); // run from
length-20 to length-10 (so, forward)
arr.forEach(function(){ ...}, undefined, -20, -30); // run from
length-20 to length-30 (so, backwards)

Of course, it would still skip the holes in sparse arrays.

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

Re: Reduce context parameter

[Peter van der Zee]

On Mon, Jan 7, 2013 at 11:59 PM, Rick Waldron waldron.r...@gmail.com wrote:
 The initialVal argument is _optional_ and undefined is valid — how would you
 decide if what was passed should be initial value or thisArg?

I see. Well, ship has sailed. Thanks.

- peter

...(Could have specced the context parameter to be second, to be
ignored if undefined, and the accumulator third.)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reduce context parameter

[Peter van der Zee]

Mostly out of curiosity; why do Array#reduce and reduceRight have no
context parameter?

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

Re: Arrow functions and return values

[Peter van der Zee]

On Thu, Nov 29, 2012 at 10:32 AM, Brendan Eich bren...@mozilla.com wrote:
 You would need a second ; after b * c; to spell the empty statement.

Interesting fact actually, it would mean the empty statement is no
longer a NOOP. It can actually alter a program. I can't think of a
situation where this is the case in es5, not counting preventing
syntactical errors. But with implicit return values, the empty
statement could make the difference.

Not sure if this is a problem, just noting that it seems to be a
change, one that'll be hard to debug for once implicit returns are
heavily used. OTOH people might be tempted to optimize functions by
adding an empty statement at the end. Or something.

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

Re: Subclassing basic types in DOM - best method?

[Peter van der Zee]

On Tue, Nov 20, 2012 at 10:31 PM, Rick Waldron waldron.r...@gmail.com wrote:
 On Tue, Nov 20, 2012 at 2:45 PM, Tab Atkins Jr. jackalm...@gmail.com
 wrote:

 On Mon, Nov 19, 2012 at 9:46 PM, Brendan Eich bren...@mozilla.com wrote:
  Tab Atkins Jr. wrote:
  If we did this, the only reason to continue subclassing Map is to get
  instanceof checks to work.  Is this acceptable?
 
  I think it's either irrelevant (no one tests 'aUrlQuery instanceof Map')
  or else a potential problem (cross-frame instanceof).

 People *do* perform those checks, though.  For example, in a method
 that accepts either an array or other things, a quick foo instanceof
 Array check is a clear, easy way to check what you've got.


 Be careful there, it's incredibly rare to see code that does that—which is

I don't agree. I see often see instanceof, both with Array and with
other objects. This danger you and everybody speaks of only applies to
cross-frame scripts. And while this danger is real (and I don't mean
to make it sound like it isn't), I think you should first consider the
amount of people actually doing cross frame scripting because it's not
something most people touch frequently, if at all. Any studies to get
such numbers?

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

Re: let and strict mode

[Peter van der Zee]

On Fri, Nov 16, 2012 at 1:35 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:

 On Nov 15, 2012, at 4:17 PM, Brendan Eich wrote:

 Of course, 'let' short for 'letter' :-|.

 Contextual keyword with [no LineTerminator here] after sounds like the plan. 
 I'm curious whether you have already implemented this in Traceur?

 /be

 I wonder if the [no LineTerminator here] is really need in practice?

 How often does

 /* whatever*/  ;
 let
   x = abc;

 actually occur in real code??

Um, if that's a concern, I often see multiple var declarations start
with a newline after var, to line up all the variable names (including
the first)...

var
  foo=1,
  bar=2,
  zee=...;
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why are non-method properties in a prototype an anti-pattern?

[Peter van der Zee]

On Wed, Nov 7, 2012 at 6:27 PM, Kevin Smith khs4...@gmail.com wrote:
 This footgun:

 function MyClass() {

   this.value = 1;  // OK
   this.list.push(0);  // Modifying the list for every instance -
 probably not intended.
 }

 MyClass.prototype.value = 0;
 MyClass.prototype.list = [];


Thing is, this is not initialization. That would be setting it to null.

I do realize what you mean, and for new people it might look the same,
but it just is not.

I always explicitly declare all instance properties (method but also
non-method) in the prototype, never in the constructor. More often
than not, they won't even occur in the constructor if they're not used
there (yes, I know about jit class stuff, but in most apps it really
doesn't matter). Declaring them on the proto makes it easy to look-up
what instance properties an object/class might have and is a good
point for documentation (imo, better than doing so inside the
constructor).

And in that regard; not being able to specify them in a class
definition is an error (but I have no idea about the current state of
the proposal, so feel free to ignore this).

I know many people (here) don't use, or even are against, initializing
all instance properties on proto, but I still stand by it. Just my two
cents.

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

Re: Sandboxing and parsing jQuery in 100ms

[Peter van der Zee]

On Wed, Nov 7, 2012 at 5:53 PM, gaz Heyes gazhe...@gmail.com wrote:
 Hi all

 Check this out:
 http://www.thespanner.co.uk/2012/11/07/sandboxing-and-parsing-jquery-in-100ms/

How would you deal with cases like `foo(/)/);` and `foo(5//)/g);` ?
So how would you deal with combinations of regular expressions and
divisions in awkward places? Or are you already using a tokenizer and
hardcoded rules on when to parse for regex/div?

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

Re: Sandboxing and parsing jQuery in 100ms

[Peter van der Zee]

On Thu, Nov 8, 2012 at 12:05 AM, gaz Heyes gazhe...@gmail.com wrote:
 Both your cases are invalid javascript in the browser. So they will never

D'oh. I meant escaped parensthesis, didn't think about capturing
groups. For the second example, there was supposed to be a space to
prevent the line comment.

But that doesn't really matter. I think I've got my answer. Thanks.

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

Re: thoughts the (re)organization of the specification?

[Peter van der Zee]

+1

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

Re: Convergence options for Ecmascript/Actionscript?

[Peter van der Zee]

On Wed, Aug 29, 2012 at 2:30 AM, Brendan Eich bren...@mozilla.org wrote:
 You really should read back in es-discuss if you have time (understand if
 you don't!). We covered what made ES4 fail. The main problem was namespaces,
 upon which packages were built.

 Unfortunately, AS3 uses namespaces and packages heavily. Mozilla's Shumway
 project includes an AS3 bytecode recompiler that generates JS, and we cannot
 lower namespaces to anything native and JIT-optimized in JS itself. Cc'ing
 Tobias in case he can comment.

Fwiw, in our as3vm we solved the namespace problem by prefixing all
properties with a namespace and an arbitrary separator (that would be
illegal in regular identifiers). But there are more issues in as3 vs
es than namespaces. For example: implicit instance closures (x=a.foo;
implicitly binds x to a) and that pesky `foo === new String(foo)`
rule (true in as3, false in es). There are more obviously, these are
the ones that blew my mind when I encountered them. The implicit bind
is really annoying to cover completely in js :/

So I agree with the sentiment that ES won't easily (re)connect with
as3. Especially when Adobe is working on an as4 that's even more
disconnected (as Avik mentioned above). And that's their prerogative,
obviously.

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

Re: Consistency in The Negative Result Values Through Expansion of null's Role

[Peter van der Zee]

On Thu, Aug 16, 2012 at 12:02 AM, Erik Reppen erik.rep...@gmail.com wrote:
 So for the sake of consistency/sanity in future methods, at least, how about
 establishing the following guidelines somewhere on the usage of these
 values?

 * More specific negative-result values are reserved for simple statements
 and very simple one-arg methods that operate directly on the value of your
 argument
 * Just about anything else returns null for non-positive-result scenarios
 where more specific returns don't necessarily clarify and could confuse
 things.
 * Ditch consistent typing approaches if that's not a lower-level perf thing.

Could introduce a fail primitive type whos primitive value is the
(possibly empty) message explaining why it/what went wrong. The value
would always behave as false except for toString() cases and strict
comparison. Could even return `false` for typeof and use a .isFail()
to detect. Probably some more semantics to hash out, but I think you
get the gist of it.

I'm sure nobody wants to add another type to the language though ;)
It's just an idea.

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

The Error type

[Peter van der Zee]

I was jesting a bit in the other thread
(https://mail.mozilla.org/pipermail/es-discuss/2012-August/024602.html)
but the more I think about it, the more it makes sense. JS should have
an Error primitive type. It would make the failed return type for
most actions more consistent. The word consistent is not without a bit
of irony, due to the nature of the Error type, which you can read
below.

Tl;dr the Error type would be instanceof the Error object (like
strings are to String). It would have an internal property containing
an error message, which can be empty. Comparison and coercion would be
very special, in that it should be able to mimic all the fail values
currently used in JS. This includes -1 when coercing to a number, null
when coerced to an object, and false when coerced to a boolean. It
always compares equal to itself (like the different NaNs do) and could
only be distinguished from one another by checking the result of
error.toString(). An Error type value would be created through
Error.primitive('foo'). There would also be Error.isError() that works
like isNaN().

Inconsistent

JS has various ways of letting the user know that an operation has
failed. Some examples include str.indexOf(), regex.exec(str), and
delete(window.eval). There is no single way of handling these errors
and there's no way to get a more specific reason from these failures
because the returned values are primitives. So unless a method throws
explicitly, you're just stuck with a computer says no.

New type

So let's introduce a new type; the Error type. A value that's
indistinguishable from exisitng error denoting values, but that still
holds a special semantic value. It would also be able to hold a
message interally, one you could only get by calling .toString() on
it.

Backwards compat

Of course, introducing a new type this late in the game is a problem.
The JS language does not have the luxery of simply introducing
language breaking features when moving to a new major version. I don't
think that needs more explaining, we all know this. However, I think
this Error type could be introduced while keeping virtually all
language semantics as they are. This does mean the type will have some
very ugly semantics. But those should not really bother the user that
does not want to use them.

We don't want to change the API for these existing mechanics because
that would be too breaking. So instead we could introduce a type that
wouldn't. It just so happens to be that for the various types of
errors JS might know about, it always returns at least the same
primitive value for any type. Meaning NaN or -1 for number, false for
boolean, undefined and null for ... well, undefined and null. (The
only one I'm not sure about is zeroes. I think all the API's that
might return a number, return -1 for failure or NaN for computational
issues, but maybe I'm missing one that returns zero...?) So let's make
this Error type match and coerce to all these types...

In other words, when comparing (weak, strict, or relative), always
convert the Error type to the other type explicitly according to this
table:

Undefined - undefined
Null - null
Boolean - false
NaN - NaN
non-NaN Number - -1
String - the error message? there's no fail return value that returns a string
Object - null
Error - error

I'm not sure about String, but since there's currently no API that
returns a string in case of errors, this could just return the
internally stored error message. Could allow one to compare error
messages easily... Individual errors should be indistinguishable from
one another in comparisons. They'd behave like NaN in that regard (in
the sense that there are different NaN values but in JS we can't
distinguish them).

Error

I don't want to bog down the syntax with a literal for this Error type
and I don't think that's even necessary. The fact that error might
be a pretty common keyword only adds to this. But I think it'd be
quite elegant to create Error type values through
Error.primitive(msg). (Ok, I started this with `fail` as the name of
the type, so `primitive` is not as elegant, but feel free to bikeshed
that into something better ;)) In fact, I think it would make very
much sense to make error an instance of Error. We can add special
cases for calling Error(primitiveError) to behave like String(foo)
would. Error.prototype.toString would also become a special case for
Error type. Or rather, it would probably be extended to first check
for an internal [[ErrorMessage]] property before checking an own
message property.

(We could make Error('foo') return a primitive instead of a new Error
object, but I think there's too much legacy usage of calling Error to
make that change now)

So the built-in Error object would get two new properties;
.primitive(msg:string) and .isError(val:any). Luckily the Error object
is not as popular to extend as String or Number are, so I think the
chances on collisions for these methods are small (though I don't have
any actual data on 

Spec feedback on rev 6

[Peter van der Zee]

Hi,

I've read pretty thoroughly through rev 6 of the spec (offline, with a
pen and a printed spec) and seem to have written down at least
something on pretty much every page.

It'll take me some time to put it all together digitally, but here are
some high level comments (in no particular order):

- String as code point values is not consistently propagated yet
- Would suggest to go a step beyond the code point value and leave out
unicode where not absolutely required (will explain in followup mail)
- The double point unicode characters (and the \u{x*} extension) smell
a lot like the mb_ mess php left when moving to utf (not sure
whether this could be solved easily though)
- Completion reform has the same problem of inconsistently being
propagated in old parts of the spec, i dont think all return values
are properly handled yet
- typeof null still object (personal disappointment :)
- Make undefined, NaN, and Infinity a literal (I don't see what issues
that might cause, please tell me if any); they're locked down anyways
- Many inconsistencies (different ways of doing the same thing in
algorithms, explaining things, and even the grammar)
- Quite a bit of duplication that could be prevented
- The term exotic does not seem fitting to this spec, but even if
that bikeshed is not reverted; host and native have still _many_
occurrences
- Likewise for character (also inconsistently replaced with one of
code point, code point value, element, and code unit)
- Missing some of the interesting parts I was looking forward to
reading specced (WeakMaps, Proxies, etc)
- I think many of the built-in functions and methods could do with a
short description (more than func, when called, does this algo:)
- Many, many of the algorithms, notes, and rules could do with one or
more examples and the rationale behind them.
- The new way of doing static semantics are really annoying to read
(especially offline) when split up like this
- When referring to certain abstract (-like) functions, like static
semantics, it's really hard to detect this while reading (example:
contains), style issue
- Large chunk of the parsing theory seems to be irrelevant (spec would
be useful even without it)
- The new additions seem to take a few shortcuts wrt the grammar.
Especially re-parsing rules look a bit weird over just one grammar
- Making new parts of the spec (modules, using let, using const, etc)
auto strict mode is really disappointing and will confuse users, new
and experienced

I'm sure there's one or two more. So I've got two questions before I
start digitization of my notes...

1: For what kind of audience does the TC39/ECMA target this spec? To name a few:
- Academics (proofs, formalization, background theory)
- Implementors (edge casing, exact algorithms, no need for formal
proof or background theory)
- Advanced coders wanting to jump to the next level (how does it work,
rationales, examples)
- Coders wanting to learn (ok, probably not)
I think it's either 1, 2, or both. But while reading the spec I could
not really get a good feeling and it seems to be a mix between the
first, second, and maybe even the third type. An answer to this
question helps me to determine which items I might ignore :)

2: How would you like me to do this?
I can write a single email to this list for every (bigger) issue I
found, but I don't want to spam the list. A single email will make
individual points get lost in messy comments very fast though. I could
add every point to a github-gist for people to comment on, but that
would require a github account for people to comment there (not sure
how big of an issue this is). I could go through the list with
somebody to filter out the smaller points, through irc or skype? Could
make typo-part quicker to do. Please let me know :)

Learned a few new things while reading the spec (including some things
I think I actually missed/forgot while reading the es5 spec a few
years ago), so it's not been in vain regardless :)

Cheers,

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

Re: Spec feedback on rev 6

[Peter van der Zee]

On Tue, Jul 31, 2012 at 10:19 PM, Peter van der Zee e...@qfox.nl wrote:
 Hi,

 I've read pretty thoroughly through rev 6 of the spec (offline, with a

Sorry, I may have been confused. I read the July 8th revision of the
draft. Fwiw.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

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

[Peter van der Zee]

On Tue, Jun 12, 2012 at 5:29 PM, T.J. Crowder t...@crowdersoftware.com 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?).


 Would it be possible to use ||| instead? E.g.:

 a = b ||| 5;

If the above is this, absolutely and such a feature, I favor this as
well because it resembles the `a = b || 5` expression better.

 [1] http://wiki.ecmascript.org/doku.php?id=strawman:default_operator

(Read that before posting, did not see anything compelling)

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

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

[Peter van der Zee]

 If the above is this, absolutely and such a feature, I favor this as

Wow, something messed up big time.

If the above answer is this, absolute and such a feature is
seriously considered ...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

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

[Peter van der Zee]

On Tue, Jun 12, 2012 at 10:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 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.

I believe the most common case for an undefined argument is to either
provide undefined OR null. I prefer null because it's not a global
look up and because it's shorter. So when I _have_ to write a function
call with empty parameter I supply null as the argument.

Where I'm going with that is to point out that the specific undefined
(only) case doesn't feel to be a de facto standard in the js world
to validate special syntax for it. And even if it did, please let it
take null into account as well. In these cases, who really does `x ===
undefined` opposed to just `x == null`?

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

Re: catch vs function scope; var declaration vs initialization

[Peter van der Zee]

On Mon, May 14, 2012 at 11:57 AM, Claus Reinke claus.rei...@talk21.com wrote:
 What should be the output of the following code?

 (function(){

 try {
  throw hi;
 } catch (e) {
  var e = ho;
  var o = hu;
  var u;
  console.log(e);
 }
 console.log(e,u,o);

 }());

 It seems clear that the first console.log should output 'ho'.
 Implementations seem to disagree on the second console.log, though.

 From my current understanding of the spec, I expected:
   undefined undefined 'hu'


Inside the catch, the catch-scope is first for reading and writing.
But the catch scopes are ignored for declaring new variables. So your
expectation seems to be the correct one. `e` is created in the scope
of the anonymous function. Likewise, `o` and `u` are created in that
scope too (so neither throw at the second console.log). ho is
assigned to the catch-scope `e`, since that's the first scope in the
scope traversal lookup at that point. Catch scopes are weird, yo.

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

Even simpler lambdas

[Peter van der Zee]

Why can't lambda's be a simple case of a lexically scoped `return`
keyword with any arguments implicitly defined and accessible through a
predefined identifier/keyword (much like `arguments` works now)?

arr.map(return ''+arguments[0]+'
class='+this.getClassName(arguments[1])+'/');

arr.map(return ''+$0+' class='+this.getClassName($1)+'/');

arr.map(return ''+$[0]+' class='+this.getClassName($[1])+'/');

Or maybe the hash sign...

arr.map(return ''+#0+' class='+this.getClassName(#1)+'/');

It's going to be hard to come up with a solid grammar for allowing
statements this way though (return {foo:bar} would be an objlit, not a
block with label). Is that why it's not being considered?

You could work around that by restricting grammar for `return` and
`{`. So `return{` would always start a block. I'm aware that this is
also currently valid syntax for returning an object literal, but I
think objections over introducing more restricted grammar rules trumps
that anyways... :)

Anyways, I like it because it's short, consise, and it feels very
intuitive to me. We'd basically overload the return keyword much like
the function keyword is right now. As a statement it'd remain the
same. As an expression it becomes shorthand notation for a function.

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

Re: Even simpler lambdas

[Peter van der Zee]

On Tue, Apr 17, 2012 at 10:11 PM, Brendan Eich bren...@mozilla.org wrote:
 François REMY wrote:

 I kinda like it.


 I don't, but what's more, Tab's point has come up already in TC39 in similar
 settings. I doubt this will fly. It's hard to see 'return' in an expression
 as different from 'return' at statement level. That's a readability problem
 that I suspect would sink this if it were to get to TC39.

I don't agree. The return-statement keyword is very much
distinguishable from the return-lambda keyword. How often do you make
the mistake for a function declaration vs function expression?

On Tue, Apr 17, 2012 at 6:05 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 This doesn't seem simpler than:

 arr.map((x,y)= '' + x + 'class=' + this.getClassName(y) + '/');

 Your other variants that shorten the 'arguments' name are better, but
 don't appear to offer much of a win.  They also prevent you from using
 the argument list to good effect, such as by giving them descriptive
 names or using destructuring and rest args.

I can see that point. However, as François points out, we very often
use lambdas in contexts where the arguments don't really need a name
in simple expressions, and could be named if you need slightly more
complex lambdas. As for spread, you'll still have access to the
arguments array (or $ or whatever you wanna end up with). A simple
slice will suffice.

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

Re: Even simpler lambdas

[Peter van der Zee]

On Tue, Apr 17, 2012 at 10:11 PM, Brendan Eich bren...@mozilla.org wrote:
 ... That's a readability problem
 that I suspect would sink this if it were to get to TC39.

On the subject of readability; I believe that a worded keyword;
map(return $1+$2) gives a much stronger emphasis to HEY, I'M DOING
FUNCTION STUFF OVER HERE than map((a,b)=a+b) would. Of course that
could just be a matter of getting used to it.

I'm not against the current proposal, I just still fear that it's very
parenthesized. It doesn't immediately make obvious what's going on.
Douglas had a good word for it the other day. I've forgotten it. That
fear might be unjust though and just come down to a matter of
acquaintance.

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

Re: undefined being treated as a missing optional argument

[Peter van der Zee]

Fwiw, arguments.length is currently the _only_ way of properly
detecting the correct number of explicit variables of _any_ type. I
would hate for that behavior to change in the case of explicitly
passing on undefined.

Default values of course do need to be set in the arguments array so
it's length will depend on that. Can we maybe set an extra property on
the arguments array that tells us how many arguments were explicitly
passed on, counting any type? I don't see how we could otherwise
figure that out, especially not after default values clobber this
count.

- peter

On Fri, Apr 13, 2012 at 8:27 AM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
 This is covered on the wiki too.

 http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values

 On Thu, Apr 12, 2012 at 20:38, Russell Leggett
 russell.legg...@gmail.com wrote:
 The examples cited are arguably cases where the built-in behaviour is
 unintuitive to many JavaScript developers, because it doesn't match their
 expectation with user code functions and most other built-ins.  I don't view
 any of the cases listed as validation that we would *want* that behaviour by
 default, just that there are a non-zero number of cases where it exists
 today.

  I suggest that the appropriate way to think of about the current
  behavior, in the context of ES6, is that function f(a) {...} is equivalent
  to function f(a=undefined) {...}
  In other words, there is a default initialization expression, if one is
  not specified. So, f() and f(undefined) appear to produce the same result.

 This is a good way of explaining the proposed semantics, but...

  But I see why somebody calling a function defined as function(a={
  }){...} explicitly as f(undefined) would expect to trigger the default
   value initializer.

 Right.  This is exactly the sort of thing I'm worried about, and seems
 like the practical common case for default values.



  2) The fact that JavaScript (at least for user objects) currently
  doesn't differentiate between missing arguments and undefined arguments 
  is a
  nice simplifying rule in the language that is easy to understand..

  It does differentiate, at least in regard to the arguments object.

 True.  But this is uncommon enough as to not be something most developers
 deal with.  Default values aim to be a much more commonly used tool.



   3) The example above, of wanting to have an API that allows explicitly
   passing in undefined to override a default value, seems outside of the
   common case (out of curiosity - are there any realistic example of 
   this?).
    If truly desired, it is easy to not use default values.  But the common
   case seems more likely to be to emulate what is done today - and avoid
   having any undefined values flow into the API call.

  Why is the example, outside of common sense.  It is a straightforward
  function to fill every element of an array with a common value. Undefined 
  is
  certain something that can be stored in arrays so why wouldn't there be
  situations where where you would want to pass undefined.  Particularly if
  the fill function was written by an unreformed Java programmer who used a
  peculiar default fill value.

 The last point was why I considered it outside of the common case.  It
 seems unusual to intentionally want to fill with null by default, but still
 allow overriding with an undefined fill.  Not impossible, but I would expect
 this to be rare enough that I don't mind making it the one case where
 default values can't be used.

  I agree that there is some confusion among some JS programmer about the
  current missing argument default value rules.  However, I don't think what
  you are suggesting is going to reduce that confusion.  I think it will
  increase it.

 At the end of the day - I see value in enabling the patterns developers
 are using today to be refactorable into default values.  I worry that the
 current proposed semantics are too far away from what is used today to make
 that practical.

 Of course, there is enough inconsistency in what is used currently anyway
 - so this may be a difficult goal to achieve fully.  But I suspect that
 treating undefined the same as not present at least keeps things close
 enough the common forms below could reasonably consider migrating to default
 values.

 // All fairly common..
 if(!param) { param = 3; }
 if(param == null) { param = 3; }
 if(typeof param == 'undefined') { param = 3; }
 param = param || 3;
 var param = arguments[1] || 3;

 // Not sure I've ever seen this... which seems to be the proposed default
 value semantics
 if(arguments.length  f.length) { param = 3; }



 At first the answer to this didn't really matter to me, because how often
 does someone pass undefined to a function like foo(undefined). I know I
 don't, though I'm sure it happens occasionally. Then I thought about it and
 realized that it happens in my code all the time, just not like that. A much
 more common case is a pass through of 

Re: Fun impossible Firefox JS challenge

[Peter van der Zee]

On Thu, Apr 12, 2012 at 4:12 PM, Andreas Rossberg rossb...@google.com wrote:
 Haha nice try even with unicode escapes it still refers to true the
 boolean not the function.

 That's another FF deviation from the standard, though.

Identifiers with unicode escapes have the meaning of their canonical
value. So wouldn't that (tru\u0065 referring to the bool) be valid and
according to the spec?

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

Re: Fun impossible Firefox JS challenge

[Peter van der Zee]

On Thu, Apr 12, 2012 at 6:13 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
 At this point I think we need to do two things:

Add a third to that, because I don't think Gaz was talking about
unicode escapes (Haha nice try). I'm still curious to the answer :)

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

Re: Terminology: “non-method function”

[Peter van der Zee]

On Wed, Apr 11, 2012 at 1:01 AM, Axel Rauschmayer a...@rauschma.de wrote:
 What is a good term for functions that don’t have/use dynamic `this`?

A bound function?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Should ... be suffix rather than prefix?

[Peter van der Zee]

Second...

On Tue, Apr 3, 2012 at 10:16 PM, Mark S. Miller erig...@google.com wrote:
     foo(a, b, ...rest)

 vs

     foo(a, b, rest...)

 Which is clearer?

 ES6 has currently agreed on the first. English and Scheme agree on the
 second.

 This question applies to both
 http://wiki.ecmascript.org/doku.php?id=harmony:rest_parameters and
 http://wiki.ecmascript.org/doku.php?id=harmony:spread.

 --
     Cheers,
     --MarkM

 ___
 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

Array#sort(prop)

[Peter van der Zee]

No idea whether this has been discussed before, but I find myself
continuously doing this when sorting arrays with objects:

arr.sort(function(a,b){ if (a.prop  b.prop) return -1; if (a.prop 
b.prop) return 1; return 0; });

Couldn't we add an optional string argument to Array#sort that does
this for us? If supplied do the above, otherwise behave as usual. If
there's already a first arg planned for .sort (I haven't kept up),
make it the second arg.

arr.sort('prop');
=
arr.sort(function(a,b){ if (a[prop]  b[prop]) return -1; if (a[prop]
 b[prop]) return 1; return 0; });

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

Re: simpler, sweeter syntax for modules

[Peter van der Zee]

On Wed, Mar 21, 2012 at 11:28 PM, David Herman dher...@mozilla.com wrote:
 * importing with renaming:

    import { draw: drawGun }    from cowboy.js,
           { draw: drawWidget } from widgets.js;


The brackets don't seem necessary (at least not from a parsing
perspective). Maybe drop them?

import draw: drawGun    from cowboy.js,
       draw: drawWidget from widgets.js;

If you fear that's too confusing with guards, replace the colon for an
arrow (=) or whatever. The bracket syntax is pretty confusing with
object literal notation imo.

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

Re: YAWSI: an identity unary operator

[Peter van der Zee]

As long as we're bikeshedding; none of your examples look as clean to
me as the original. If you're dead set on fixing this, try changing
the this keyword...

var a;
var obj = {
  get a() {return a},
  set a(v) {a=v}
};

var obj = {
  a: null,
  get a() {return this.a},
  set a(v) {this.a=v}
};

This looks much cleaner to me than any of the other examples.

(Getters and setters are non-transferable, so they'll always have a
context, right?)

- peter

On Mon, Mar 19, 2012 at 9:13 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
 (Yet Another Wacky Syntax Idea)

 Here is a relatively common coding pattern:

 var a;
 var obj = {
   get a() {return a},
   set a(v) {a=v}
 };

 Often the intent is that the variable a should only be used within the object 
 literal.  The block scoping with let and do operator will allow the variable 
 and object literal to be group in this manner:

 let obj  = do {
    let a;
    ({get a() {return a},
      set a()v) {a=v}
    })
 }

 Unfortunately, the object literal has to be enclosed in parentheses because 
 an expression statement cannot begin with an object literal.  The same would 
 be the case if a function expression was involved rather than an object 
 literal.

 Parens are annoying because you have to remember to close them and match them 
 if any additional nesting is involved.

 With completion reform, do expressions, and broader use of  blocks that 
 produce values we should expect to see more situations where an 
 ExpressionStatement needs to start with an object literal or function 
 expression. It would be nice to have some way to do this that does not 
 require parentheses.

 Prefix the expression with an unary operator is sufficient to disambiguate 
 such expression but unfortunately all of the existing unary operators perform 
 conversions that would invalidate the value.  However, a new unary operator 
 whose semantics was to simply return its operand value would do the job 
 nicely.   Both . and = seem like good candidates for such an operator but any 
 operator symbol that is not currently used in a unary form would be a 
 possibility:

 let obj  = do {
    let a;
    ={get a() {return a},
       set a(v) {a=v}
    }
 }

 let obj  = do {
    let a;
    .{get a() {return a},
       set a(v) {a=v}
    }
 }

 let obj  = do {
    let a;
    ^{get a() {return a},  //probably my favorite, but that may just be a 
 leakage from my Smalltalk background...
        set a(v) {a=v}
    }
 }

 let obj  = do {
    let a;
    |{get a() {return a},
       set a(v) {a=v}
    }
 }

 let obj  = do {
    let a;
    /{get a() {return a},
       set a(v) {a=v}
    }
 }

 let obj  = do {
    let a;
    *{get a() {return a},
       set a(v) {a=v}
    }
 }

 What about ASI?  Adding a unary form of an existing binary operator doesn't 
 introduce any new issues or break/change existing code:

 x
    ={ };

 parses as an assignment to x even if = is given a new meaning as a unary 
 operator.











 ___
 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: Math.clz()

[Peter van der Zee]

Maybe make it generic? Although that might not be very important for
the case of counting leading zeroes or ones.

I'd love a function for getting n consecutive bits (to left or
right..) from number x starting from the nth bith (from the left or
right) as a single number as if the lsb was 1. You can create masks
for this to  and , but it's not as versatile. Also, maybe a
toString function for binary with leading zero padding (or are we
getting String#pad now?).

- peter

On Sun, Mar 4, 2012 at 10:38 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
 Bit.clz() sounds just as good to me. I don't know if they need to be less
 cryptic, if someone doesn't know the abbreviation, it is highly likely (s)he
 doesn't need the functions either. :)


 On Sun, Mar 4, 2012 at 10:01 AM, Tomas Carnecky t...@caurea.org wrote:

 Wouldn't it be better to namespace these bit-operators in a different
 module?
 Bit.clz() perhaps? The Math module is getting a bit crowded.

 On Sat, 03 Mar 2012 23:21:11 -0800, Brendan Eich bren...@mozilla.org
 wrote:
  I'm open to clz/clo. The names perhaps need to be less cryptic... or
  not.
 
  Allen should weigh in.
 
  /be
 
  Jussi Kalliokoski wrote:
   We're working on JS audio decoders, and one huge performance issue atm
   is clz() [count leading zeroes], which is a very commonly used
   algorithm in decoders. We've tried several different approaches and
   benchmarked them [1], however, different approaches work better on
   different engines, so optimizing the function is a bit of a no-go,
   especially if we want to have it fast in the future as well.
  
   So, I thought I'd propose something that would go well with the
   earlier proposals to extend Math [2]:
  
   Math.clz(number)
  
   This would allow for great speed boost in our decoders if it the JS
   engine had this built-in and optimized.
  
   While at it, it might be wise to add other related functions as well,
   such as clo (count leading ones), although not as useful.
  
   Cheers,
   Jussi
  
   [1]: http://jsperf.com/read-leading-zeros/8
   [2]:
   http://wiki.ecmascript.org/doku.php?id=harmony:more_math_functions



 ___
 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 full Unicode for ES6 idea

[Peter van der Zee]

Do we know how many scripts actually rely on \u15 to produce a
stringth length of 3? Might it make more sense to put the new unicode
escape under a different escape? Something like \e for extended
unicode for example. Or is this acceptable migration tax...

On a side note, if we're going to do this, can we also have aliasses
in regex to parse certain unicode categories? For instance, the es
spec defines the Uppercase Letter (Lu), Lowercase Letter (Ll),
Titlecase letter (Lt), Modifier letter (Lm), Other letter (Lo),
Letter number (Nl), Non-spacing mark (Mn), Combining spacing mark
(Mc), Decimal number (Nd) and Connector punctuation (Pc) as
possible identifier parts. But right now I have to go very out of my
way (http://qfox.nl/notes/90) to generate and end up with a 56k script
that's almost pure regex.

This works and performance is amazingly fair, but it'd make more sense
to be able to do \pLt or something, to parse any character in the
Titlecase letter category. As far as I understand, these categories
have to be known and supported anyways so these switches shouldn't
cause too much trouble in that regard, at least.

- peter

On Sun, Feb 19, 2012 at 10:17 AM, Axel Rauschmayer a...@rauschma.de wrote:
 On Feb 19, 2012, at 9:33 , Brendan Eich wrote:

 Instead of any such *big* new observables, I propose a so-called Big Red
 [opt-in] Switch (BRS) on the side of a unit of VM isolation: specifically
 the global object.


 es-discuss-only idea: could that BRS be made to carry more weight? Could it
 be a switch for all breaking ES.next changes?

 --
 Dr. Axel Rauschmayer
 a...@rauschma.de

 home: rauschma.de
 twitter: twitter.com/rauschma
 blog: 2ality.com


 ___
 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

Fallback

[Peter van der Zee]

There's currently no way of introducing anything new into the language
that breaks syntax. I think that point has been made very clearly with
harmony/es6. Can we introduce a way to make these transitions easier
in the future?

CSS has a very simple way of gracefully ignore rules it doesn't know.
In CSS you can specify rules and features and whatever the engine
doesn't understand, it will ignore gracefully and continue. While this
obviously won't work out of the box for js. But I think we can work
around it. In CSS this is scoped to individual rules. In js there's no
notion of rules (and lines won't work either) but you could talk
about functions or modules (or blocks?) in the same way. I think
modules are a bit too big scoped for this but I'd like to discuss the
generic idea first. We can always bikeshed over the syntax later. I'll
work with function-like syntax for now.

Say a browser wanted to support a new keyword. Right now, that's
impossible to even experiment with unless you write an entire engine
in js and have a duplicate source code for fallback. You simply can't
do something like

x ||= y;

without breaking the code permanently and without exception. We can
only add stuff that fits perfectly within the existing grammar.
There's also no way for a vendor to implement this as an experiment
because it will still break in older versions of the browser or other
vendors. So what if we could do something like this?

function foo(x,y){
  if es7;
  return x ||= y;
  /es7;
} // the /directive serves as a delimiter because otherwise you'd
never know where to stop parsing when you don't support it
if (!foo) {
  var foo = function(){
x = x || y;
return x;
  }
};

So now you have a way to experiment with the new extension and a
simple way of extending the language permanently, while still having
backwards compat (at least up to the point that we introduce this
system), graceful failures and a proper way of figuring out a
fallback. If a vendor did not support the feature asked for it could
declare `foo` as null or something allowing easy support detection.

The declared function should work within the existing js language of
course and should be callable from within js with the regular
mechanics. This includes stuff like call, apply, and bind. Whatever
the function itself does with the arguments or the context is up to
the implementation. Whatever it returns should again be a proper js
value. This allows you to easily fallback to an es5 function because
the fingerprint would be the same (and besides, I have no idea how
else this could work otherwise anyways).

This also could allow introduction of vendor prefixes. However, for
now I'd like to focus on the general principle though and leave the
prefix discussion for later.

Some syntax possibilities:

function foo(){ es7; x ||= y; }
function foo(){ es7; x ||= y; /es7; }
condFunction foo(){ es7; x ||= y; }
condFunction es7 foo(){ x ||= y; }
condFunction es7 foo(){ x ||= y; } es7;

Personally, I'd prefer a function-scoped capability over a
module-scoped capability because I think I'd like to apply this to
smaller snippets rather than an entire module. Or maybe both.

Open things for me:
- How to efficiently specify the (scope of) things you want to opt-in to?
- How to limit the problem with interoperability this would
undoubtedly cause (even with prefixes).
- Proper keyword/syntax for this, would still like to keep this js-ish
- Is nesting desirable? Reasonably feasible? Especially wrt the delimiter
- This system would also allow for non-js extensions (like
coffeescript or even ruby/etc), is that a problem?

If we think such a system is viable and we can find a simple way of
introducing it to the language, we should do it sooner than later. The
sooner it's in, the less stuck we will be in the future.

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

Re: Fallback

[Peter van der Zee]

On Fri, Feb 10, 2012 at 11:51 AM, François REMY
fremycompany_...@yahoo.fr wrote:
 The idea would be that each time the parser hit an issue, it replaces the
 current block by a { throw new InvalidProgramException(); } but continue to
 parse. It may also write a warning into the console. This is roughly how CSS
 is working. The idea is not of me, but from Ian Hickson if I remember
 correctly.

I can appreciate the try-catch block (vs functions or modules). But
you can't just replace a block of unknown code because you won't know
where it ends. So you'll need some kind of delimiter, regardless.

- peter


 -Message d'origine- From: Peter van der Zee
 Sent: Friday, February 10, 2012 11:27 AM
 To: es-discuss
 Subject: Fallback


 There's currently no way of introducing anything new into the language
 that breaks syntax. I think that point has been made very clearly with
 harmony/es6. Can we introduce a way to make these transitions easier
 in the future?

 CSS has a very simple way of gracefully ignore rules it doesn't know.
 In CSS you can specify rules and features and whatever the engine
 doesn't understand, it will ignore gracefully and continue. While this
 obviously won't work out of the box for js. But I think we can work
 around it. In CSS this is scoped to individual rules. In js there's no
 notion of rules (and lines won't work either) but you could talk
 about functions or modules (or blocks?) in the same way. I think
 modules are a bit too big scoped for this but I'd like to discuss the
 generic idea first. We can always bikeshed over the syntax later. I'll
 work with function-like syntax for now.

 Say a browser wanted to support a new keyword. Right now, that's
 impossible to even experiment with unless you write an entire engine
 in js and have a duplicate source code for fallback. You simply can't
 do something like

 x ||= y;

 without breaking the code permanently and without exception. We can
 only add stuff that fits perfectly within the existing grammar.
 There's also no way for a vendor to implement this as an experiment
 because it will still break in older versions of the browser or other
 vendors. So what if we could do something like this?

 function foo(x,y){
  if es7;
  return x ||= y;
  /es7;
 } // the /directive serves as a delimiter because otherwise you'd
 never know where to stop parsing when you don't support it
 if (!foo) {
  var foo = function(){
   x = x || y;
   return x;
  }
 };

 So now you have a way to experiment with the new extension and a
 simple way of extending the language permanently, while still having
 backwards compat (at least up to the point that we introduce this
 system), graceful failures and a proper way of figuring out a
 fallback. If a vendor did not support the feature asked for it could
 declare `foo` as null or something allowing easy support detection.

 The declared function should work within the existing js language of
 course and should be callable from within js with the regular
 mechanics. This includes stuff like call, apply, and bind. Whatever
 the function itself does with the arguments or the context is up to
 the implementation. Whatever it returns should again be a proper js
 value. This allows you to easily fallback to an es5 function because
 the fingerprint would be the same (and besides, I have no idea how
 else this could work otherwise anyways).

 This also could allow introduction of vendor prefixes. However, for
 now I'd like to focus on the general principle though and leave the
 prefix discussion for later.

 Some syntax possibilities:

 function foo(){ es7; x ||= y; }
 function foo(){ es7; x ||= y; /es7; }
 condFunction foo(){ es7; x ||= y; }
 condFunction es7 foo(){ x ||= y; }
 condFunction es7 foo(){ x ||= y; } es7;

 Personally, I'd prefer a function-scoped capability over a
 module-scoped capability because I think I'd like to apply this to
 smaller snippets rather than an entire module. Or maybe both.

 Open things for me:
 - How to efficiently specify the (scope of) things you want to opt-in to?
 - How to limit the problem with interoperability this would
 undoubtedly cause (even with prefixes).
 - Proper keyword/syntax for this, would still like to keep this js-ish
 - Is nesting desirable? Reasonably feasible? Especially wrt the delimiter
 - This system would also allow for non-js extensions (like
 coffeescript or even ruby/etc), is that a problem?

 If we think such a system is viable and we can find a simple way of
 introducing it to the language, we should do it sooner than later. The
 sooner it's in, the less stuck we will be in the future.

 - peter
 ___
 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
___
es-discuss mailing list
es

Re: Deep cloning objects defined by JSON.

[Peter van der Zee]

Why can't we define a JSON.clone() or .deepClone() which would only
clone properties that are primitives, object or array. If they are
(instanceof) array, copy index properties and length value and create
new array with that information. If object, create new object and copy
all properties with the same restrictions as before.

I suppose another discussion is whether you'd want/need to copy
property attributes as well. For me, for at least JSON.clone, I would
be happy with just a clone of the primitive value of a property.

In other words, I think a JSON.clone would work as if the structure
was first serialized to a string. The serialization would drop any
value or property that's not primitive, object or array. Objects and
arrays are serialized to [] and {} notation. For arrays, only index
properties are copied (so not even length or other properties). The
resulting string would then be deserialized by JSON.parse. Of course
the serialization doesn't need to happen internally, but I think hope
that makes it clear what I mean (drops all weird stuff from structures
like getters, setters and attributes).

By putting such a method on JSON, you leave the way open for whatever
clone should be on Object and still have an intuitive feeling for what
JSON.clone would probably do (opposed to Object.clone).

Cloning functions is a dangerous sport anyways due to closures, but I
don't think anyone would expect JSON.clone to clone functions too.

- peter

On Tue, Jan 24, 2012 at 7:46 PM, Rick Waldron waldron.r...@gmail.com wrote:
 non-recursive, deep clone by John-David Dalton:

 https://github.com/bestiejs/benchmark.js/blob/master/benchmark.js#L1001-1161


 Rick


 ___
 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: Deep cloning objects defined by JSON.

[Peter van der Zee]

On Sun, Jan 29, 2012 at 7:23 PM, David Bruant bruan...@gmail.com wrote:
 Based on your description, it seems that the definition would be:

 JSON.clone = function(o){
  return JSON.parse(JSON.stringify(o));
 }

Yes. You can debate whether it should remove properties it can't
serialize completely, or define them with null. You can also debate
whether you want to treat objects that don't directly inherit from
Object as alien (right now that doesn't seem to be the case in Chrome
at least.

JSON.clone({foo:5}) - {foo:5}

These are the cases I could (easily) see debatable...

JSON.clone({foo:function(){}}) - {foo:null} or {}
function F(){}
JSON.clone({foo:new F}) - {foo:{}} or {foo:null} or {}
var f = new F;
f.x = 5;
JSON.clone({foo:f}) - {foo:{x:5}} or {foo:null} or {}
F.prototype.x = 5;
JSON.clone({foo:new F}) - {foo:{x:5}} or {foo:{}} or {foo:null} or {}

But I guess keeping the same behavior as JSON.stringify for a
JSON.clone method might be best to keep things consistent. So
something like Mark's last suggestion, to make the whole thing
customizable.

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

Re: Deep cloning objects defined by JSON.

[Peter van der Zee]

On Sun, Jan 29, 2012 at 7:50 PM, Xavier MONTILLET
xavierm02@gmail.com wrote:
 With your last two implementations, you don't keep cyclic references.

I did not intend to. In fact, my intention was to have a clean
object with just structure (objects and arrays) and primitives.
Nothing else, especially nothing invisible (like references, object
instances or attributes). You can save that fancy stuff for
Object.clone :)

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

Versioning?

[Peter van der Zee]

https://lists.webkit.org/pipermail/webkit-dev/2011-December/018924.html

``use version 6;``

In which thread on esdiscuss should I have read about that?

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

Re: with

[Peter van der Zee]

On Thu, Nov 17, 2011 at 12:53 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
 My first answer was glib, sorry. I'm proposing `with' as a replacement
 syntax for |. So the above expression evaluates to the same as



 Once again, it's absolutely the same approach which I showed yesterday with
 using `extends'
 (https://mail.mozilla.org/pipermail/es-discuss/2011-November/018478.html).

David is talking about the proposed | operator, to replace that with
`with`, initializing an object with a given object as prototype. Not
extending... anything.

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

Re: making |this| an error (was Re: for own(...) loop)

[Peter van der Zee]

The forEach method might not do what you expect it to. This can not be
statically determined.

- peter
On 9 Nov 2011 16:10, John J Barton johnjbar...@johnjbarton.com wrote:

 On Wed, Nov 9, 2011 at 3:41 AM, David Bruant bruan...@gmail.com wrote:
  Le 09/11/2011 02:26, Andrew Paprocki a écrit :
 
  On Tue, Nov 8, 2011 at 6:36 PM, Brendan Eichbren...@mozilla.com
  wrote:
 
  Ignoring performance, a lot of stylish JS hackers use
  Object.keys(o).forEach. How many run into the wrong |this|
  (arguments/break/continue/return)? Not clear. Something to study.
 
  I was curious so I did some grok-ing across my code sample and
  Object.keys() is barely used. The usage of the |for in| construct is 2
  orders of magnitude larger than the usage of hasOwnProperty(),
  supporting the thought that no one really does it the right way.
 
  The MDN page for Object.keys does not talk about |this| being wrong in
  certain situations. If you could elaborate on that, it would be
  helpful to know.
 
  The |this| differs between the body of a for-in and the argument
 callback in
  the .forEach. Nothing to do with Object.keys. .forEach has a second
 optional
  argument which is the value to be used as |this| so that you don't have
 to
  do a .bind.

 I'm sure this has been discussed before, but isn't is possible and
 desirable to make |this| illegal in using strict; when it can be
 determined from the AST alone that |this| will bind to |window|?  eg:

   Object.keys(foo).forEach(function(key) {
 // this is undefined- window
   });

 This case kind of case is because, as others have noted, incorrect
 |this| binding most often occurs in two cases: 1) mixed OO and
 functional programming (as above) and 2) callback defn.

 Perhaps it is harder to detect than I think.

 jjb
 ___
 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: Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

[Peter van der Zee]

On Wed, Nov 2, 2011 at 5:44 PM, David Bruant bruan...@gmail.com wrote:
 I agree that the second argument is a design mistake. But ES6 will fix
 this with the proto operator.

fix

It has the same kind of baggage and goes into the minor features
category, at least in terms of syntax, in my opinion.

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

Re: Another paren-free gotcha

[Peter van der Zee]

On Thu, Sep 29, 2011 at 3:43 AM, Quildreen Motta quildr...@gmail.com wrote:
 I'm not sure how this is much different from the rules you have now with
 ASI, though if this were such a problem, a block statement could be required

I'm trying to make sure we don't add another feature that we'll later
describe as yeah, wish we could take that out, but we can't, that
ship has sailed. This ship hasn't sailed yet and if it does, I'd like
it to be as clean as possible.

On Thu, Sep 29, 2011 at 3:01 AM, Brendan Eich bren...@mozilla.com wrote:
 If ASI is the culprit to focus on, I can work harder on ASI in relation to 
 paren-free. I do not want to hack on paren-free by itself. It's quite simple 
 and not in need of patching.

 My approach would be to make newlines *more* significant, not less.

What you could do here is require paren-less headers to be single
lined, on the same line as the `if` keyword, and require a newline
between the paren-less header and the body. Such newline would signify
the end of the statement header, much like ASI (API? ;). And if you
want to use a block, you may put the first curly of the block on the
same line as the paren-less header (or next line if you prefer KR
anyways). I'm not so sure if that would fix any of the raised
objections though. You'd also be introducing more restrictions in the
grammar (afaik you weren't very fond of these) and introduce another
ASI-like scheme into the language.

I worry a bit about legibility (but have nothing to back that up with).

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

Re: Another paren-free gotcha

[Peter van der Zee]

On Thu, Sep 29, 2011 at 12:38 AM, Douglas Crockford
doug...@crockford.com wrote:
 On 11:59 AM, Waldemar Horwat wrote:

 Thinking about the implications of paren-free, I see additional potential
 trouble spots in addition to the one I mentioned in the meeting yesterday:

These kind of potential confusions raise a red flag for me. Goes in
line with the ASI discussion, or the more current array hole
discussion. People are going to cause errors using this syntax,
especially when editing existing code. And when they do, they won't
have a clue why. At least not at first. I think Waldemar nailed that
with his demonstrations.

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

Re: IDE support?

[Peter van der Zee]

 I'm assuming that conclusion already because the current tools for JS
 development are so incredibly lame that wasting time on static
 analysis -- which we know does not work without changing the language

 Ok, your assumed conclusion rests on a prior assumption:

 static analysis ... we know does not work without changing the language

 Evidence?

 It seems to me you have not studied either http://doctorjs.org, which is 
 nodejs based, the code is on github (it's all JS, essentially a fork of 
 narcissus via Patrick Walton's jsctags):

 https://github.com/mozilla/doctorjs

Or just do some live coding at http://zeonjs.com

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

Re: IDE support?

[Peter van der Zee]

On Mon, Sep 12, 2011 at 1:04 AM, Brendan Eich bren...@mozilla.com wrote:
 Type Inference can do a lot. See http://doctorjs.org/.

 We do not want people adding guards all over their code, IMHO. Anyway, we 
 don't know have guards ES6.

While true, I've found that you can't really overcome the dynamic
property access unless you can somehow infer that you're operating on
an array of some fixed type or something like that. And function calls
and result types are actually far more difficult (though not
completely impossible) to do in es than in a strongly typed language.
Although I don't really see any clear way of getting around this,
without some kind of annotation (be it in the language or in
comments).

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

Re: IDE support?

[Peter van der Zee]

 There are some half dozen or more papers on Javascript type inference
 or static analysis (hmm, is there a central wiki or bibliography where
 we could record and collect such JS-related references? should I post
 here what I've found so far?).

For as far as you haven't already, I'd love to see more of them.

 That said, I think the I want to refactor automatically use-case is
 sort of over-played.

 That depends. Automatic refactoring, in the strict sense of changing
 code structure without changing code behaviour, is nearly impossible
 for Javascript, as there are hardly any valid code equivalences (none if
 you count reflection).

The Extract method is ok, if you don't count context or eval.
(Selecting a snippet of code which will be created as a function,
adding boiler plate code to make sure new/changed variables are
reflected in the original code position. You would have to make sure
that the calling context is correct, as that's pretty much impossible
to infer. Of course safe eval cases are out as well.) Granted,
that's still not absolute.

There are more transformations but they are more on a smaller scale.
Like those in uglifyjs and google closure compiler.

 Indeed. The type-system related features I use most often in Eclipse are:
 - *Safely* renaming a method or function. I do this frequently to keep the
 vocabulary used in methods etc. fresh. All JS IDEs that I have tried are
 not
 much fun in this regard.

 Surprisingly difficult, see reference above. I believe jetbrains have some

Obviously, renaming variables is very safe and relatively easy to do
outside the with or eval context. The with case becomes dreadfully
more difficult, but there are some options there. Eval is completely
out.

 It used to track object properties better (which was used for navigation
 and completion), but apparently that got broken a while ago. This is the
 part that would improve completion and navigation to methods or
 module exports.

 - Find all invocations of a method/function. Often, I just change the
 name of a method (e.g. by appending an x) and go through all the
 errors that that produces.

 Again, that is undecidable in general, due to Javascript's flexibility,
 though approximations will be useful.

What I do in Zeon is I have a scope centric tracking object for each
variable. And a tracking object centric tracking object for
properties of a variable. Dito for properties on a property. This of
course stops at dynamic access (although numbers and other literals
can be worked around with and you could also work around it with
annotations). But when you take this central tracking object and store
every reference you encounter for it in it, including marking the
point of declaration(s), you end up with a very easy navigation
structure. If you infer that tracking object to be a function, you
have your declaration, usage and invocations.

More generic, I've come up with a kind of xpath for js (jspath?) where
you can refer to specific elements in the code. (It might actually not
be new, I haven't done an exhaustive search. I'd be surprised if it
were.) Since you work with scopes and each variable in a scope is
unique, you can create reference points to variables in scopes. You
can also create reference points to specific literals like functions,
objects and arrays. If foo is a global function, /foo/bar would refer
to the variable `bar` in the function `foo`. More complex patterns are
possible of course with absolute and relative paths, this is just an
example. I'll publish an article on this soon. Anyways, you can use
this system to have a central tracking method for typing, annotation
and for navigation.

What I'm trying to say is that while there is definitely room for
improvement, it's not entirely hopeless. Although for a lot of cases
it is, as you say, not very absolute. I've found the worst cases for
js  (with respect to static analysis) to be context and dynamic
property access. I'm not counting eval because I don't think eval is
relevant in static analysis (as in, if eval, warn for the worst).
Maybe some kind of annotation could fix the eval black hole... But I'd
love some more tools to help here.

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

Re: __doc__ for functions, classes, objects etc.

[Peter van der Zee]

On Sun, Aug 7, 2011 at 6:56 PM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com wrote:
 Hi,

 What about to standardize (Python's) __doc__-umentation comments for JS?

What's the difference between that and the /** ... */ way of JSDoc?

/**
 * This function does stuff
 * @constructor
 * @param {Object} foo
 * @returns {Array}
 */
var f = function(){ ... };

What would a new language construct for this solve?

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

Re: \u0085 whitespace or a random unicode character by ES5?

[Peter van der Zee]

On Wed, Jul 6, 2011 at 7:38 PM, Dave Fugate dfug...@microsoft.com wrote:
 Several test262 test cases operate on the assumption ‘\u0085’, aka Next
 Line, is considered a whitespace character and I’d like to get some
 clarification on whether it really is or not as-per ES5.1.

 Table 3 of ES5, Line Terminator Characters, does not call out \u0085 as
 being a valid line terminator.  It does however state:

     Only the characters in Table 3 are treated as line
 terminators. Other new line or line breaking characters are treated as white
 space but not as line terminators.

 This raises two questions:

 1.   Is Next Line considered to be a ‘new line’ or ‘line breaking
 character’?  By definition, the answer seems to be yes

I would say no. 7.3 clearly states it's NOT a line terminator.

 2.   Next Line is not called out anywhere in Table 2, Whitespace
 Characters.  Does this mean Table 2 is simply missing a row for the clause
 from “Line Terminators” above, or that the clause should not even exist?

Or 7.2 should be extended with noting that any unicode line terminator
that's not listed in 7.3 is also considered (regular) white space, as
per 7.2.

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

Regex on substrings

[Peter van der Zee]

A problem I faced recently is the inability to apply regular
expressions to a substring of a string without explicitly taking the
substring first. So I'm wondering how much trouble it would be to
extend the RegExp api to this...

RegExp.prototype.test = function(string[, start=0[, stop=string.length]]){ };
RegExp.prototype.exec = function(string[, start=0[, stop=string.length]]){ };

The regular expression would only be applied to that part of the
string. It'd be (almost) the same as
regex.test(string.substring(start, stop)), except the substringing is
handled internally.

I can't think of any backward compatibility issues for this change.

My use case is that I have a set of words I want to find in a certain
input string, but almost always starting at pos0. Right now I have to
take the substring of the longest possible match (or remaining of
input) and check the results of exec/match to see the length of the
match, if any. The alternative is to compile a regular expression that
skips the first n characters.

Optionally, it might be handy to have .test return a number,
indicating the length of the (first) match. If zero, there was no
match. This would however break with scripts that explicitly check for
=== false.

It seems to me like applying regular expressions to substrings could
be optimized internally much better (using pointers) than having to do
a substring in ES every time. This should speed up the parsing of
input, for instance.

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

Re: Regex on substrings

[Peter van der Zee]

On Thu, Jun 2, 2011 at 7:17 PM, Mike Samuel mikesam...@gmail.com wrote:
 2011/6/2 Peter van der Zee e...@qfox.nl:
 A problem I faced recently is the inability to apply regular
 expressions to a substring of a string without explicitly taking the
 substring first. So I'm wondering how much trouble it would be to
 extend the RegExp api to this...

 RegExp.prototype.test = function(string[, start=0[, stop=string.length]]){ };
 RegExp.prototype.exec = function(string[, start=0[, stop=string.length]]){ };

 What do the ^ and $ assertions in non-multiline mode mean when start
 and stop are not [0, string.length)?
 Do they match at the beginning and end of the substring?

They mean exactly the same as they would do for
regex.test(string.substring(start, stop))


 Optionally, it might be handy to have .test return a number,
 indicating the length of the (first) match. If zero, there was no
 match. This would however break with scripts that explicitly check for
 === false.

 Using zero to indicate that there is no match will conflate zero
 length matches with no match.
 Consider

    /\b/.test(a-b) === true

That's a good point. It suppose could return false, but that wouldn't
be very backcompat for these cases. It could return -1 but that would
definately be backcompat breaking.

Well, it would have been nice. But if the tax on returning match
length for .test is too big I'm not feeling that strong about it
myself.

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

Re: Automatic Semicolon Insertion: value vs cost; predictability andcontrol; alternatives

[Peter van der Zee]

On Mon, Apr 18, 2011 at 3:12 AM, Oliver Hunt oli...@apple.com wrote:

 An implementation _could_ add a mode (*shudder*) along the same lines as
 strict mode:
 die in hell ASI, i hate you with the fiery passion of a thousand burning
 suns.;

 And then make it a syntax error whenever ASI would occur.  I have
 considered this in JSC (albeit with a slightly shorter opt in string).

 It wouldn't have the backwards compat problems you get by disabling ASI
 as the points where ASI being removed changes behaviour would be errors :D


All things considered, another option for vendors is simply adding a
developer setting in their browser that enables warnings (or errors) for ASI
in the console. That would help a lot of current generation developers. Of
course, this wouldn't fix anything for non-browsers (like node). So for them
a directive would be nice, even if it was just to enable warnings while
debugging.

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

Re: Automatic Semicolon Insertion: value vs cost; predictability andcontrol; alternatives

[Peter van der Zee]

On Mon, Apr 18, 2011 at 12:34 PM, Jorge jo...@jorgechamorro.com wrote:

 What am I missing ?


As far as the directive goes, they are opt-in. Old code won't be opting in.
Other than that they have the same issues as use strict might have.

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

Removing labels

[Peter van der Zee]

Can we remove labels from the next version of the spec?

Labels are only used for continue and break. I don't think I've ever had or
seen a need for them (which does not mean they're unused, btw). They can be
sugar insofar as to breaking a double loop at once. But at the same time
they promote spaghetti coding. On top of that there's a decent impact on the
specification. In fact, I'm a little surprised they were not excluded from
strict mode.

So nothing would really change for label-less `continue` and break.

Switch and iterations would not get an empty label (obviously) and the whole
label stack could be stripped.

Furthermore the grammar for continue and break would be as simple as that
for debugger. And the label statement would disappear (which is nice because
at the start of a statement, if the first token is an identifier, you need
to parse another token before being able to determine whether you're parsing
a label or an expression).

The completion type (8.9) would no longer need to have three parameters,
just two.

Am I missing anything? Or are there cases where labels allow you do
something that's impossible without labels?

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

Re: String.prototype.repeat

[Peter van der Zee]

On Tue, Mar 22, 2011 at 2:39 AM, Dmitry A. Soshnikov 
dmitry.soshni...@gmail.com wrote:

  On 22.03.2011 23:42, David Bruant wrote:

 Hi,

 About the string_repeat strawman (
 http://wiki.ecmascript.org/doku.php?id=strawman:string_repeat), one
 alternative solution could be a two argument constructor. Something like:
 String(n, pattern). So, for the example in the strawman, it would be
 String(3, '*').


 A little bit off-topic, but not so big off-topic. Recently on Twitter there
 was a question why it's not an array of zeros:


Actually I think Array.fill or Array#fill should be added for one of the
reasons for repeat: it is very likely that the host environment can iterate
(or even optimize) a repeat/fill much much faster than the es interpreter
could possibly achieve through looping. Especially with larger numbers.

(I'm happy once we can use a native String#repeat :)

Otoh, I don't think the second problem David points out (generate unique
property names) should become part of the spec. Seems to me to be a rather
obscure use case.

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

Re: Date vs Daylight Savings

[Peter van der Zee]

On Mon, Mar 21, 2011 at 6:54 PM, Peter van der Zee e...@qfox.nl wrote:

 On Fri, Mar 11, 2011 at 12:12 AM, Luke Smith lsm...@lucassmith.namewrote:

 The consistent behavior across all browsers of Date when passed a time
 made invalid by a DST jump is to roll the time *back* by an hour.
 // On a system with Pacific TZ
 new Date(2011, 2, 13, 2, 0, 0, 0);
 Sun Mar 13 2011 01:00:00 GMT-0800 (PST)

 Mainly out of curiosity, is there a thread or a simple explanation of why
 back instead of forward?  Am I incorrect in assuming most systems push the
 time forward?


 Yeah. Try comparing output for both ;)

 var date = new Date('2011-03-27')
 log(date.toString());
 // Sun Mar 27 2011 01:00:00 GMT+0100
 date.setHours(2);
 log(date.toString())
 // Sun Mar 27 2011 01:00:00 GMT+0100


Meh. Too fast.

var date = new Date('2011-03-27')
date.setHours(2);
log(date.toString());
// Sun Mar 27 2011 01:00:00 GMT+0100
date.setHours(3);
log(date.toString())
// Sun Mar 27 2011 03:00:00 GMT+0200
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Bringing setTimeout to ECMAScript

[Peter van der Zee]

On Sat, Mar 19, 2011 at 1:13 AM, Brendan Eich bren...@mozilla.com wrote:

 On Mar 18, 2011, at 5:54 AM, Peter van der Zee wrote:

 +1 to standardizing the timer family.

 I always thought this wasn't in because the specification didn't have
 any asynchronism and specifying timers would open Pandora's box.


 How so? I created JS and its run-to-completion execution model and
 setTimeout all at once in 1995. It has not changed in execution-model
 semantics since.


I can't think of a single way to simulate setTimeout in ES5. Correct me if
I'm wrong, but I don't think ES5 exposes a single way of defining a
mechanism like:

--
var x = 4;
function f(){ x = 5; print(x); }
timer(f, 1);
print(f);
--

Such that it would output 4 before 5. That's what I meant with didn't have
any asynchronism, fwiw.

There's no contradiction: programs including those eval'ed by setTimeout (or
 functions passed instead of a string to eval and called later) must and in
 fact *do not* nest or preempt any other executing JS in correct (to this
 approximation) implementations.


Ok, I never meant contradiction. Maybe Pandora's box should have been Let
the cat out of the bag ;) I just never bothered to mention it (introducing
timers) on esdiscuss. Seemed to be such an obvious miss to me that there had
to be an obvious reason.


 The issues with setTimeout have more been about core langage vs. DOM
 level 0, and the lack of a DOM level 0 standard prior to HTML5.


What do you mean by that? Why should that influence the choice of including
it in the ECMA spec? What about embedded environments or ssjs?

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

Re: Bringing setTimeout to ECMAScript

[Peter van der Zee]

On 19 Mar 2011 14:43, Breton Slivka z...@zenpsycho.com wrote:

  I can't think of a single way to simulate setTimeout in ES5. Correct me
if
  I'm wrong, but I don't think ES5 exposes a single way of defining a
  mechanism like:
  --
  var x = 4;
  function f(){ x = 5; print(x); }
  timer(f, 1);
  print(f);
  --
  Such that it would output 4 before 5. That's what I meant with didn't
have
  any asynchronism, fwiw.

 while (!programHasQuit()) {

  timers= (function () {
  var timers = [];
  var id=0;
  timer=function (f,t) {
   timers.push({func:f, interval:t, id:id++});
   return id;
  }
 return timers;
  })

  runScript(myscript.js);
  handleEvents(timers,otherevents);

 }


 and there you go, in pure JS. If this is a gui program, you may expose
 a queue of GUI events to this master script, but I believe that the
 event loop is best left to the embedding. If setTimeout etc are
 implemented in the core JS engine, the JS engine can simply expose the
 pool of timers as some data structure to the embedded C/C++ program to
 do with what you wish- The standard would presumably specify some
 guidelines for this.

That only works if the host environment isn't waiting for you to finish /
wait / sleep / yield / etc. But yeah, ok :)

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

Re: Bringing setTimeout to ECMAScript

[Peter van der Zee]

On Sat, Mar 19, 2011 at 2:49 PM, Breton Slivka z...@zenpsycho.com wrote:

 never write code on no sleep.

 that code sample should be :

  timers= (function () {
 var timers = [];
 var id=0;
 timer=function (f,t) {
  timers.push({func:f, interval:t, id:id++});
  return id;
 }
return timers;
  })

  runScript(env.js);
  runScript(program.js);
  ev=getEvents();
 while (!programHasQuit()) {

  handleEvents(timers,ev);

 }


Actually, you're right. The timer family can be abstracted like this. I
don't think it would be as convenient as the current setTimeout and
setInterval because it kind of requires your code to use an architecture
that can work with an (explicit) event loop. But that's not necessarily a
problem.

So the only thing missing from this picture is a way to yield to the host
environment. In a single thread environment (like node or the browser), you
can't indefinitely loop because you'll lock up the host environment. So if
there was some way of yielding to the host environment, I think the problem
is solved. Not saying that such a mechanism is that trivial, but I do
believe that's a missing key to building timers in the language since you
currently can't yield, without timers :)

And re: return value. Some scripts might rely on the fact that the timers
return a number (an int, even). So if backwards compat is important (and it
always is), you can't really break with `typeof token == 'number'`. So if
there was a new native type, typeof would still have to return 'number',
which is not very desirable (null anyone?...). Also, given that setTimeout
and setInterval are already implemented in browsers for a while with
returning numbers, is it really still a problem we need to solve? Will
browsers really start implementing a setTimeout that returns a special timer
object? I think any implementation that uses setTimeout and setInterval
would have to mimic the current behavior in the browser...

(Even if we implement a host-environment yield kind of thing, I'd still
prefer a built-in setTimeout abstraction built on it for convience. But I
don't know about the security or whatever involved.)

Kyle: If there was a way to determine which timers are currently queued,
would that solve your problem? That's probably the only thing I'm missing
right now from the timer api: Some array with all queued timeouts/intervals.
Maybe that's to prevent the clear attack mentioned before, looping all
numbers and clearing them. I don't know. But if you had such an array
(either with just ints, or even an object with {int,time/interval,callback})
would that suffice for you? You could check the list and block while there
are timers left.

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

Re: Bringing setTimeout to ECMAScript

[Peter van der Zee]

+1 to standardizing the timer family.

I always thought this wasn't in because the specification didn't have
any asynchronism and specifying timers would open Pandora's box.

- peter

On Fri, Mar 18, 2011 at 1:51 PM, David Bruant bru...@enseirb-matmeca.frwrote:

  Hi,

 _Foreword_
 Each time I write setTimeout, I mean setTimeout and setInterval (and
 there clear functions) (please forgive the recursive flaw)

 _Introduction_
 Before the concurrency proposal (
 http://wiki.ecmascript.org/doku.php?id=strawman:concurrency), a pure
 ECMAScript program had a start and an end, that was it. No event loop, no
 asynchronous callback, etc.
 If ECMAScript standardizes this proposal or another, there will be a need
 to standardize an event loop in a way or another. Adding a timing aspect to
 this event loop and setTimeout can be standardized in ECMAScript.

 _Current_standardization_state_
 setTimeout isn't part of ECMAScript. setTimeout is nonetheless standardized
 as part of HTML Standard (
 http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers).
 Besides the task dependency (which is part of the standardized event-loop
 in the same document:
 http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task),
 this is more or less ECMAScript.

 _Current_use_
 As anyone will have certainly noticed, setTimeout has no reason to be
 considered as client-side web specific. And, as a matter of fact, there is a
 setTimeout in node.js and in ActionScript apparently. I wouldn't be
 surprised if most (if not all) ECMAScript-based languages had a setTimeout
 function consistently.

 For all these reasons, I am wondering if setTimeout wouldn't be had being
 standardized in ECMAScript itself.

 _How?_
 I currently see two main tracks:
 * Standardize it as it is.
 * Standardize a more powerful mecanism and standardize setTimeout as an
 implementation based on this mecanism. If setTimeout had been considered as
 not flexible enough by some people, this could be an occasion to fit their
 use case (I personnally have no suggestion on the matter)
 I am not familiar with promises, but after reading a bit about it and
 seeing a presentation on the topic, I intuit that it may not be very
 difficult to add a timing aspect to it based on which setTimeout could be
 implemented.

 _Advantages_
 * As said, it could be an occasion to fix flexibility issues that people
 would find to setTimeout
 * Define a strict mode behavior to it. Currently, people can pass strings
 as first argument to setTimeout. There is currently a spec hole in what
 happens in strict mode for setTimeout.
 I would be in favor to throw an exception if people use strings in
 setTimeout in strict mode (maybe it's too late to suggest that since FF4
 ships in less than a week?). Anyway, there is room for other ideas like
 standardizing strict eval for strings as first argument in strict mode. My
 main goal is to discuss the issue.


 I haven't found any trace of previous discussion of this topic. Has there
 been any?

 David

 ___
 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: do-while grammar

[Peter van der Zee]

Fwiw I don't recall any specific cases of input accepted by browsers which
shouldn't parse according to the spec, other than functions in statements.
Even callable regular expressions are fine as far as the grammar goes. I
don't have an extensive test suite for regular expressions or strict mode
though. Not yet, anyways.

The do-while case should indeed not have ASI applied unless allowed by 7.9.1
(so the given test case should fail). I think this is assumed, but it wasn't
explicitly stated in the thread.

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

Re: New private names proposal

[Peter van der Zee]

 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 which, if
 not undefined, says which context must be set (and for protected,
 either directly or through the prototypal chain of the current
 context) to gain access to this property. And if that context is
 not found, some error is thrown. Maybe it would be
 [[EncapsulationType]] :: {private, protected, public} and
 [[EncapsulationContext]] :: ?. You could also add a simple api
 to check for these (isPrivate, isProtected, isPublic,
 hasEncapsulatedProperty, etc) depending on how it would affect
 in and enumeration.

 IMO, this is too class-oriented for JS. We should allow the
 creation of private members of arbitrary objects, not just those
 that inherit from new constructors. I think it also doesn't address
 the use case of adding new operations to existing classes like
 Object or Array without danger of name conflicts.

Ok. Indeed it doesn't address adding private properties to any object nor 
extending existing classes, although I think that might be fixable. And you're 
right, it doesn't address conflicts.


 Pro's:
 - meaning of private will be more to what people expect

 I find this a little hard to believe. It's tricky to make claims
 about what people will expect. It's true this feels somewhat
 analogous to Java, but there's a wide diversity of JS programmers.
 And a lot of them don't want us to just make it like Java and do
 their best to remind us of this fairly regularly. ;)

Ok, fair enough.

 there...) - no need to introduce a new type/class to denote
 private properties


 This last point confuses me -- it sounds like you *have* to
 introduce a class to denote private properties, because they're
 associated with a class. Or are you referring to the SoftField type?

The proposal at http://wiki.ecmascript.org/doku.php?id=strawman:private_names 
lists three changes right at the top. 1 is a new type. To me, this seems like a 
rather big impact on the language for introducing something that's already 
possible through closures.

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

Re: es5 bug, operator == and valueOf

[Peter van der Zee]

Has an operator like == ever been proposed? So the strict relational
operator that returns NaN if typeof left and right don't match.
If so, why was it shot down? Bloat? Relatively useless?

- peter

On Wed, Dec 1, 2010 at 1:45 AM, Brendan Eich bren...@mozilla.com wrote:

 On Nov 30, 2010, at 3:25 PM, Fyodorov Bga Alexander wrote:

  @apipkin have found logic bug
  `{valueOf: function(){ return 1 }} == {valueOf: function(){ return 1 }}`
  // false
  `{valueOf: function(){ return 1 }} = {valueOf: function(){ return 1 }}`
  // true, ok

 This is not a bug in ES5, although you could argue it's a design flaw in
 JS. Recall that

 typeof a == typeof b  a == b = a === b  // implies, in both directions

 Two object initialisers never evaluate to the same object reference, and
 === compares references, and == here has same-typed (object) operands, so it
 is the same as ===.

 Relational operators do convert objects. You could argue this is a design
 flaw; or that this is a win but then == should convert objects as well --
 but if that is a flaw, it's only in hindsight, since === came after == and
 without === there would be no way to distinguish object references without
 implicit conversion.

 Really, implicit conversions (not the same as operator methods) are a
 design flaw in my view. They make == (ignoring NaN) not an equivalence
 relation.

 But again, not an ES5 bug. Did you read ES1-3 on == and valueOf
 differently?

 /be

 ___
 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: Nov 18 notes

[Peter van der Zee]

On Mon, Nov 22, 2010 at 8:37 AM, David Herman dher...@mozilla.com wrote:

  for (var i : x) ...  // must be new iteration
  for (var i : T : x) ...  // iteration again, but parsed how?
  for (var i : T in x) ... // for-in with annotated var

 Bummer!

 I'm beginning to feel more strongly again that overloading for-in, as
 opposed to introducing yet another syntactic variant of `for', is the right
 way to go.

 thought experiment
 Imagine we made Harmony backwards-incompatible in the following way: for-in
 loops would *only* work on iterable objects, and would dynamically fail on
 non-iterable objects. So if you wanted the legacy keys behavior, you would
 have to explicitly call a `keys' library function.
 /thought experiment


If we're gonna go invent new keywords why not use the obvious?

iterate (var x in y) ...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Guards are now ready for discussion (was: Nov 18 notes)

[Peter van der Zee]

On Mon, Nov 22, 2010 at 9:43 AM, Brendan Eich bren...@mozilla.com wrote:

 On Nov 22, 2010, at 12:37 AM, Peter van der Zee wrote:

 On Mon, Nov 22, 2010 at 6:54 AM, Brendan Eich bren...@mozilla.com wrote:


 The ML-ish solution, which is forward compatible, is to parenthesize:

 let typedObj = { (prop1:type1): value1, (prop2:type2): value2, ... };

 The parentheses hurt too, but only this case. And it still may win to
 annotate the entire ObjectLiteral sometimes, which would avoid (or move to
 one common guard-type definition) the property-wise annotation overhead.
 Comments?


 I wouldn't want to introduce forced parens for the sake of disambiguation
 for the coder. I'd rather go with ::, # or @ ...


 Those are not all equally good, and you're again sacrificing the common
 case (especially with ::) where there's no need to parenthesize, for the
 uncommon case of property-wise type annotation in an object initialiser.

 Actually, one can use : just fine in an initialiser provided one or two
 colons are required per property initialiser. There's no need for :: or
 anything else except to avoid a confusing re-use of colon. Which is an
 issue, but :: doesn't exactly address it!


As you noted yourself in the other thread, if iterators take on the syntax
of `for (var x : y : z)`, the single colon for guards would introduce
ambiguity. (And I believe :: could fix that?)




 Fundamenally, though, you have to weight each use-case by frequency. If as
 I argue var x : T, function f(a: T, b: U): V {...}, etc. annotations
 dominate the rare var typedObj = ... case, then parens or whatever is needed
 (even a separated type annotation for the whole initialiser, as in ES4) is
 worth it.


 Actually, for object literal I'd go for an equal sign (=), but that
 obviously won't fix var declarations where the colon is fine.


 We're not changing object initialiser syntax.



 Can't the guards proposal be applied to function parameters as well? Or am
 I stepping on land mines there? :) It seems like the same logic could be
 applied. In that case the equal sign is maybe even more preferable.


 What are you proposing = be used for, if not default parameter values (see
 the wiki) or assignment? No way does = make sense for type annotation.


I'm sorry, I did mean = for guard. But reading it back, you are right; it
doesn't make sense.


 But yes: type annotation (guard, contract, whateve -- not static types but
 that's not at issue) should be possible for function parameters, return
 types, local variables, let bindings, catch vars, etc.

 /be


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

RE: Negative indices for arrays

[Peter van der Zee]

If harmony would introduce this syntax guarded under a new script type, there 
would at least be no danger of breaking the web (existing scripts).

However, negative array indexes might cause confusion when doing so 
implicitly. If you asume array indexes are just properties it'll be hard to 
debug a snippet like `while (x = arr[--i]) ...` (not my own example). While it 
wouldn't be my preferred way of doing this, it's still valid and will cause 
very 
obscure and hard to debug problems.

I guess I would like -n to map to length-n, but I'm not sure whether it's worth 
the cost described above. After all, it's just sugar.

- peter


 From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
 boun...@mozilla.org] On Behalf Of Dmitry A. Soshnikov
 ..

 Yes, I mentioned it myself several times (in articles and
 including several topics in es-discuss). Yes, Python distinguish.
 Ruby too. But from your position, ES already has some lacks then.
 E.g. Object.keys() -- what does it mean? What kind of keys you
 have found here? Or maybe `Object.getOwnPropertyNames()`?

 Object.keys and Object.getOwnProertyNames are both precisely
 defined by ES5. keys returns the names of all non-enumerable own
 properties of an object.  getOwnPropertyNames returns the names of
 all own properties.

 For example look at the results of Object.keys(new String('abc'))
 and Object.getOwnPropertyNames(new String('abc')) on an ES5
 conforming implementation.

 ..
 Still ES has concept of an array index (separating it from all
 other properties), I think a virtual array index is also good.

 Not really.  ES5 does not generally consider array elements or
 array index property names as separate or different from other
 properties or property names.  According to the ES5 spec. (15.4)
 array index  is a term used to talk about property names that
 conform to a specific requirement (ToString(ToUint32(name) ) ===
 name and ToUint32(name) !==2^32-1).

 Instances of the Array constructor has special semantics for
 defining and updating array index properties. In addition, some
 of Array.prototype functions that perform arithmetic on array
 index property names do it in a manner that ensures results are
 also array index names.  Other than that ES5 doesn't define any
 special semantics for array index properties.  Implementations
 are free to optimize how they store array index properties (and
 many implementations do) but they are also free to optimize the
 storage of any property as long as the optimization maintains the
 observable ES5 semantics.

 [from a different message]
 ES5 brought special semantics for subscription of strings, i.e.
 abc[0] is a, maybe it worth to make another sugar for arrays
 too?
 Actually, all that ES5 did was specify that String objects (not
 string values) have non-writable, non-configurable properties
 corresponding to the individual characters of the encapsulated
 string value.  abc[0] is really equivalent to (new
 String(abc))[0]

 Btw, if yes, it will touch strings too.
 Presumably, any object with a 'length' property.

 As Oliver said, this would break any code that currently uses
 property names like -1.  This isn't just syntactic sugar. It also
 has all sorts of complications relating to the basic property
 access semantics.  Getting this right would probably require a
 major redesign of ECMAScript object/property semantics in a manner
 that I wouldn't anticipate happening anytime soon.

 Allen


 ___
 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: hoisting past catch

[Peter van der Zee]

Shouldn't any var declared in the catch block be locally scoped as well?
It seems that all browsers ignore that.

try {x} catch(){ var y; } alert(y);

The above should throw an error, yet it's undefined. In fact, even if the catch 
is not thrown y still exists (but if the catch block is not processed as a 
seperate scope, I suppose that's to be expected).

- peter

 On Oct 11, 2010, at 4:40 PM, David Herman wrote:

 ES3 `catch' is block-scoped. At the last face-to-face, we talked
 about statically disallowing var-declarations from hoisting past
 let-declarations:

 function f() {
 {
 let x = inner;
 {
 var x = outer; // error: redeclaration } } }

 I just noticed a case I missed in the discussion, which has
 actually existed since ES3:

 function g() {
 try {
 throw inner;
 } catch (x) {
 var x = outer;
 }
 }

 This is allowed, and it binds a function-scoped variable x, while
 assigning outer to the catch-scoped variable x. This is pretty
 goofy, and almost certainly not what the programmer expects. And
 it's exactly analogous to the function f above, which
 SpiderMonkey currently rejects and we all agreed Harmony ought to
 reject.

 It's too late to add this case to ES5's strict mode restrictions,
 but I propose we ought to reject it in Harmony.

 Dave caught this glitch in ES5 too late to fix before Ecma
 submitted the spec to ISO. We can't change the ES5 spec now. We
 will fix the spec later, but the change won't show up in a
 normative spec for a while. Meanwhile, what implementations do has
 more teeth than what a spec says.

 Mark Miller makes a good case that implementors should future-proof
 against Harmony making this case an error by rejecting it from
 their ES5 strict implementations. For Mozilla we plan to do this.
 It would be good to get agreement from the rest of the big five, so
 I'm taking the liberty of mailing you individually, cc'ing es-
 discuss (where Mark and your avid fans await ;-).

 /be

 ___
 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

Usage for weak-maps

[Peter van der Zee]

What's the use case for weak maps? What would you do with it that currently
impossible and why is the workaround (if any) problematic enough to warrant
a weak map implementation?

There's been quite a bit of discussion because of it. Especially in the area
of covert channels and garbage collection. Yet I've missed the major cases
for wanting it in the language in the first place. Google doesn't seem to
help me much here.

I don't need an in depth explanation of what weak maps are, just practical
reasons for wanting it opposed to what's already possible... thanks :)

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

Harmony and globals

[Peter van der Zee]

In the other thread it was mentioned that Harmony would not have global at
the top of the scope chain. Was that pulled out of context or is that
something planned for any code as long as you're in Harmony? Because if it
is, I'm wondering about the semantics of built-in globals like undefined,
isNaN and the built-in objects (Array, String, etc).

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

Re: Const functions with joining is ready for discussion

[Peter van der Zee]

I really dislike the hash notation for this purpose. I have no problem with
either const(){} or const function(){}. The verbosity of using const is well
worth the legibility.

- peter

On Tue, Sep 7, 2010 at 10:23 AM, Kevin Curtis kevinc1...@gmail.com wrote:

 If const functions and 'standard' functions are available to a
 developer - what on average will a developer likely use. Will a
 security conscious dev lean towards const functions?

 If const functions are preferred then maybe the function shorthand
 notation - if it goes ahead - should map to const functions.
 Especially for anon functions - where the function keyword stands out
 as being rather verbose.

 Or with hashes:
 ##(x) {...} // const function

 ---
 ___
 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: Const functions with joining is ready for discussion

[Peter van der Zee]

Or rather, the legibility is well worth the verbosity of using const...

On Tue, Sep 7, 2010 at 2:12 PM, Peter van der Zee e...@qfox.nl wrote:

 I really dislike the hash notation for this purpose. I have no problem with
 either const(){} or const function(){}. The verbosity of using const is well
 worth the legibility.

 - peter


 On Tue, Sep 7, 2010 at 10:23 AM, Kevin Curtis kevinc1...@gmail.comwrote:

 If const functions and 'standard' functions are available to a
 developer - what on average will a developer likely use. Will a
 security conscious dev lean towards const functions?

 If const functions are preferred then maybe the function shorthand
 notation - if it goes ahead - should map to const functions.
 Especially for anon functions - where the function keyword stands out
 as being rather verbose.

 Or with hashes:
 ##(x) {...} // const function

 ---
 ___
 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: Reserved word property access and line breaks

[Peter van der Zee]

The impact seems minimal (how often would this occur in the wild). I don't like
adding restrictions to the language for the sake of protecting a possible
defect, but I don't really see this as a problem since it's not exactly a best
practice to use reserved keywords as property names anyways ;) (re: CSFLD)

- peter

 It does seem reasonable to disallow new lines in that context.

 --Oliver

 On Aug 24, 2010, at 1:53 PM, Allen Wirfs-Brock wrote:

 Consider the following JavaScript code fragment:

 var x=foo.
 if (ab)  -bar;

 If this showed up in real code, it would probably be either as a
 typo where either the actual property name for foo was left off
 or because of a mental lapse by an old Smalltalk programmer who
 was used to using . instead of ; to terminate statements.
 Regardless, it will validly parse identically to the following
 single line formulation:

 var x=foo.if(ab)-bar;

 The ES5 grammar for a dotted property access is:

 CallExpression ::
 CallExpression . IdentifierName

 Where IdentifierName includes all possible identifiers including
 reserved words.  The above confusion could have been avoided if
 we had instead defined things as:

 CallExpression ::
 CallExpression . Identifier
 CallExpression . [no LineTerminator here] ReservedWord

 Is this the grammar we should have used for ES5?  It's too late
 to make this change in the ES5 spec.  but if we had consensus
 that this is how it should be specified in Harmony we might also
 get the emerging ES5 implementations to also follow this
 interpretations.

 Thoughts?  It's kind of hooky to have semi-arbitrary restrictions
 on line terminator placement.  But we already have them in order
 to make semi-colon insertion more sane and arguably such
 restrictions reasonably go hand-in-hand with allowing context
 sensitive use of reserved words.

 Allen
 ___
 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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Leap seconds for Date.parse

[Peter van der Zee]

While 15.9.1.1 explicitly says leap seconds are ignored by ECMAscript, the ISO 
8601 timestamp format allows them. 

15.9.1.15 (used by Date.parse) does dictate ranges for months and dates (days 
of 
month), but they don't specify the range for hours, minutes and (milli)seconds 
(although a note says 00 is the same as 24, fine). On the other hand, the 
number of x passed since y can be interpreted as a range. But does this 
interpretation come through the viewport of ECMAscript (ignoring leap seconds) 
or the real world.

The last paragraph in 15.9.1.15 before the notes says to reject all dates it 
cannot parse.

Now my question is, should T23:59:60 be a valid timestamp as parsed by 
Date.parse?

Which basically comes down to the question whether Date.parse should only parse 
dates Ecmascript can produce itself or dates ISO 8601 could produce. If up in 
the air, my vote goes to allow leap second notation. The current Firefox 
implementation (for example) seems to reject it.

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

Re: revisiting shift

[Peter van der Zee]

On Thu, Apr 29, 2010 at 2:21 AM, David Herman dher...@mozilla.com wrote:

  Hm. Maybe you meant to return the function to allow access to the local
 variable
  k through a closure? And not a fingerprint
  mixed shift(function)
  as I read it at first?

 I don't know what you're saying, but I have already posted the semantics in
 this thread. I *think* it should be pretty clear. (If others are confused
 about it, please do weigh in.)

  The shift could also expose the iterated value in the continuation object
 as a
  read-only property (or getter). The shift itself would return whatever
 you give
  .send as parameters. But maybe this was what you meant in the first
 place..

 If I understand this, it still doesn't give the function that does the
 shift very much room to do anything interesting after it pops the function
 activation.

  Whatever needs to be done before or after the shift should obviously be
 done
  from within the loop. I see no problems with that myself, but maybe I'm
 missing
  something?

 I think you are. When the shift happens, it pops the activation frame,
 which means that the rest of the function after the shift stops running.
 This is what a continuation operator is all about-- suspending control and
 saving it in a value that can be called later. The purpose of calling the
 handler function is to do something *immediately* after popping the
 activation frame, not later when the activation is resumed.

  On a sidenote; continuations could be implemented much like timers are
 now. I
  mean, for timers to work, you would already have to have a way to
 preserve state
  and stack because you have to access it when the timer fires. This
 proposal
  could just extend the API using the same mechanics as the timers (I read
  something about this proposal being a possible problem for vendors). But
 rather
  than being executed when some time has elapsed, the callback would be
 fired on
  demand. After implementing setTimeout and setInterval, this should be
 quite
  easy...

 None of this is true. Closures are not the same thing as continuations.

 That said, if this is a hardship for implementers, I'd be interested in
 having them weigh in.

  I also read syntax using try{}catch(){} as some kind of continue
 mechanism and
  just wanted to say I find it really ugly and hackish.

 I'm genuinely baffled by this comment.

 Dave


Reading your original post again, more thoroughly this time, it becomes
clear to me that I've misinterpreted it. And you indeed stated the send,
throw, close api there.

I still believe that the callback is redundant, but for now I'll just shut
up.

As for the try/catch statement, I was confused with the Iterators and the
way they were implemented in JS 1.7. You used try/catch in one example and
that's how I got confused.

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

Re: revisiting shift

[Peter van der Zee]

On Tue, Apr 27, 2010 at 4:57 PM, David Herman dher...@mozilla.com wrote:


 Example:

function f() {
try {
for (let i = 0; i  K; i++) {
farble(i);
// suspend and return the activation
let received = shift (function(k) { return k });
print(received); // this will be 42
}
}
catch (e) { ... }
}

let k = f(); // starts running and return the suspended activation
...
k.send(42); // resume suspended activation


It seems to me like the callback is unnecessary overhead. What happens if
you don't supply a function but another type, or none? Would 42 still be
returned by shift? Or is it actually the returned value in k, that gets a
send method augmented to it?
It'd be cleaner if it was just shift(), no argument, which returns a
callback bound to the continuation which can simply be called without
suffix:
function x(){
  let received = shift();
}
var y = x();
y(42);

But maybe I'm knifing an entire API here I don't know about :) Otherwise the
send method seems redundant.

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

Re: revisiting shift

[Peter van der Zee]

 I don't understand this question-- do you mean whatever value the
 handler function (in the example, function(k) { return k })
 returns? Then no, there's no augmentation or mutation here. The
 continuation is represented as an object with three methods:

Ah, I didn't know that.

 It'd be cleaner if it was just shift()

 You might think so, since the semantics seems simpler-- but it
 would lead to uglier programs. You're not affording the writer of
 the function doing the shift any ability to specify what to do
 after the shift, and you're not giving them the ability to
 communicate any data to the caller. This requires them to
 coordinate with clients to save any additional action in some side-
 channel, e.g.:

 // library
 function gen(thenWhat) {
 ...
 thenWhat.action = function() { ... /* do more stuff */ ... }; let
 received = shift(); ... }

 // client
 var k = gen({ action: function() { } });

Hm. Maybe you meant to return the function to allow access to the local 
variable 
k through a closure? And not a fingerprint 
mixed shift(function)
as I read it at first? In that case sure, fine :)

The shift could also expose the iterated value in the continuation object as a 
read-only property (or getter). The shift itself would return whatever you give 
.send as parameters. But maybe this was what you meant in the first place..

Whatever needs to be done before or after the shift should obviously be done 
from within the loop. I see no problems with that myself, but maybe I'm missing 
something?

 But maybe I'm knifing an entire API here I don't know about :)
 Otherwise the send method seems redundant.

 I'm not sure what the send method has to do with it-- it sounds

That would be the API I didn't know about ;)

On a sidenote; continuations could be implemented much like timers are now. I 
mean, for timers to work, you would already have to have a way to preserve 
state 
and stack because you have to access it when the timer fires. This proposal 
could just extend the API using the same mechanics as the timers (I read 
something about this proposal being a possible problem for vendors). But rather 
than being executed when some time has elapsed, the callback would be fired on 
demand. After implementing setTimeout and setInterval, this should be quite 
easy...

I also read syntax using try{}catch(){} as some kind of continue mechanism 
and 
just wanted to say I find it really ugly and hackish. I've not seen any 
arguments that justify introducing such a mechanism (but it might not be part 
of 
this proposal, I'm sorry and happy if it wasn't :)).

- peter

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

Re: Property attributes, clarification please.

[Peter van der Zee]

On Thu, Apr 22, 2010 at 9:38 AM, Asen Bozhilov asen.bozhi...@gmail.comwrote:

 If I understand correctly specification 8.6  The Object Type
 describe semantic of native objects and does some restriction on host
 objects. For example:

 | Every object (including host objects) must implement
 | all of the internal properties listed in Table 8. However,
 | the [[DefaultValue]] internal method may, for some objects,
 | simply throw a TypeError exception.

 That quotation is regard table 8, which contains internal properties
 common to all objects.

 My question is regard 8.6.1  Property Attributes, where ECMA-262
 does not restriction on host objects. As I understand these property
 attributes are only for native objects and host objects can use
 different approaches for property attributes.


8.6.1 does not seem to mention anything about host objects., only about
named properties.
8.6.2 indeed explicitly says that all objects, native and host, should
implement the attributes from table 8. Furthermore, the first paragraph says
that any internal property that does not exist should throw a TypeException
when accessed anyways. The second paragraph states the _behaviour_ of table
8 is only required for native objects. Host objects may implement them
differently, as long as they remain to behave within the limitations of a
host object as outlined by the specification.


 For example in JScript, Object.prototype.propertyIsEnumerable (V) with
 passed host object as the `this` value throw TypeError exception. And
 that is described by Microsoft:
 URL:
 http://download.microsoft.com/download/8/4/2/8427CF1B-08B3-4557-952D-102E7A8FA64C/%5BMS-ES3%5D.pdf
 /

 |  2.1.62   [ECMA-262]
 |  Section 15.2.4.7, Object.prototype.propertyIsEnumerable (V)  page 63
 |  a.If O is a host object, throw a TypeError exception.

 And by ECMA-262 that is conformable behaviour, because specification
 does not restrict host objects to implement these property attributes.

 Does someone to make clarification on these things? Thanks.


The attributes must be implemented, and they might all be, but they can all
throw a TypeError regardless of what is being done with them. In this case,
either the attributes can be seen as getters and setters which always throw
TypeErrors, or you can't even get to them because whatever method you use to
try that will throw you out before you can reach the actual attribute.

Either way, as far as is observable, this behaviour seems in line with the
specification.

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

Re: Property attributes, clarification please.

[Peter van der Zee]

On Thu, Apr 22, 2010 at 10:42 AM, Peter van der Zee e...@qfox.nl wrote:


 The attributes must be implemented, and they might all be, but they can all
 throw a TypeError regardless of what is being done with them. In this case,
 either the attributes can be seen as getters and setters which always throw
 TypeErrors, or you can't even get to them because whatever method you use to
 try that will throw you out before you can reach the actual attribute.


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