Re: Operating with arbitrary timezones

On Sat, Aug 6, 2016 at 4:27 AM, Alexander Jones wrote: > I'm not sure I properly conveyed myself above given what you're saying. > Let me back up and explain more clearly now I have an actual keyboard in > front of me. > > Currently we have `Date.prototype.toLocaleString()`, which

Re: Operating with arbitrary timezones

On Fri, Aug 5, 2016 at 6:32 PM, Jon Zeppieri <zeppi...@gmail.com> wrote: > > > On Fri, Aug 5, 2016 at 6:21 PM, Alexander Jones <a...@weej.com> wrote: > >> Don't confuse timezones with timezone offsets. They are different >> concepts. > > > > How

Re: Operating with arbitrary timezones

On Fri, Aug 5, 2016 at 6:21 PM, Alexander Jones wrote: > Don't confuse timezones with timezone offsets. They are different concepts. How am I confusing them? You wrote: What I meant by Date+Time components was actually { year, month, day, > hours, minutes, seconds, offset }. I

Re: Operating with arbitrary timezones

On Fri, Aug 5, 2016 at 5:58 PM, Alexander Jones wrote: > What I meant by Date+Time components was actually { year, month, day, > hours, minutes, seconds, offset }. I think it makes sense to formalise this > as an expression of a time point (aka Date) *in a particular timezone*.

Re: Operating with arbitrary timezones

On Fri, Aug 5, 2016 at 5:30 PM, Tab Atkins Jr. wrote: > On Fri, Aug 5, 2016 at 1:59 PM, Kris Siegel wrote: > >> Once you endow them with a timezone offset they cease to represent > points > >> in time, but rather more points in space, which adds

Re: January 19 meeting notes

On Fri, Jan 20, 2012 at 7:25 AM, Grant Husbands esdisc...@grant.x43.net wrote: Jon Zeppieri wrote: Is there a version of this desugaring that deals with recursive bindings in the initializer expression of the loop? How about something like this? (given for (let varName = initExpr; testExpr

Re: January 19 meeting notes

On Fri, Jan 20, 2012 at 5:08 PM, Jon Zeppieri zeppi...@gmail.com wrote: It's one thing if the difference really isn't observable except in the case where a closure captures the iteration variable (as Sam suggests), since it's hard to imagine anyone wanting the current binding behavior

Re: January 19 meeting notes

On Thu, Jan 19, 2012 at 11:02 PM, Brendan Eich bren...@mozilla.org wrote: Yes kids, this means we are going with MarkM's lambda desugaring from: https://mail.mozilla.org/pipermail/es-discuss/2008-October/007819.html Is there a version of this desugaring that deals with recursive bindings in

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

On Thu, Jan 12, 2012 at 4:26 PM, Thaddee Tyl thaddee@gmail.com wrote: I have heard many fellow programmers say that, while block lambdas would be welcome, Ruby's |a, b| syntax is ugly. I thought I was the only one feeling this way, but since I am not, I would like to ask why the

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

On Thu, Jan 12, 2012 at 5:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jan 12, 2012, at 2:23 PM, François REMY wrote: Am I wrong if I say there not a bigger issue with block lambda than with the current object notation on the matter? I think you're correct.  An

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

On Thu, Jan 12, 2012 at 7:11 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jan 12, 2012, at 3:41 PM, Jon Zeppieri wrote: ... With the grammar François is suggesting, this would be a syntax error (I think), since the body of a block lambda is a StatementList_opt. The {| syntax

Re: Tennent's correspondence principle and loop-local variable capture

On Thu, Jun 30, 2011 at 7:27 PM, Mark S. Miller erig...@google.com wrote: On Thu, Jun 30, 2011 at 4:07 PM, Brendan Eich bren...@mozilla.com wrote: The old C-style for(;;) loop is a hard case. It really does want a single shared-mutable loop control variable. Making 'let' instead of var in

Re: block lambda revival

On Wed, May 25, 2011 at 11:06 AM, Brendan Eich bren...@mozilla.com wrote: One last thought: if you want to curry, always parenthesize all calls. Space-separated argument lists just do not look sufficiently high precedence when followed by (...) after, to treat   foo {|x| x} (bar) as   

Re: block lambda revival

On Wed, May 25, 2011 at 4:01 PM, Brendan Eich bren...@mozilla.com wrote: On May 25, 2011, at 8:44 AM, Jon Zeppieri wrote:   {|x| x}(bar) The new grammar forbids that, though. You must parenthesize the block-lambda to invoke it with a parenthesized argument list:   ({|x| x})(bar) Block

Re: block lambda revival

On Fri, May 20, 2011 at 8:54 PM, Brendan Eich bren...@mozilla.com wrote: As promised/threatened: http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival Sorry to take a step back here. After reading Waldemar's comments, I took a closer look at the formal grammar, and I'm puzzled

Re: block lambda revival

On Tue, May 24, 2011 at 3:29 PM, Brendan Eich bren...@mozilla.com wrote: BlockArguments : BlockLambda BlockArguments [no LineTerminator here] BlockLambda BlockArguments [no LineTerminator here] ( Expression ) The interleaved parenthesized expression worries me for two reasons:

Re: block lambda revival

On Sat, May 21, 2011 at 10:43 AM, Brendan Eich bren...@mozilla.com wrote: On May 20, 2011, at 9:55 PM, Peter Michaux wrote: On Fri, May 20, 2011 at 5:54 PM, Brendan Eich bren...@mozilla.com wrote: An essential part of this proposal is a paren-free call syntax Why is that essential? The

Re: block lambda revival

On Sat, May 21, 2011 at 8:54 PM, Brendan Eich bren...@mozilla.com wrote: On May 21, 2011, at 4:23 PM, Jon Zeppieri wrote: I'm just not clear on how that relates to the downward funargs point. It doesn't. Two separate points. Sorry, I should have used a bulleted list or something :-P

Re: Spread and non objects

On Fri, Nov 5, 2010 at 8:14 AM, P T Withington p...@pobox.com wrote: [2p. from the Lisp world, the putative inventor of the rest/spread operator.] In Lisp, arglists are lists instead of arrays, the operator is `.`, and conveniently, the empty list, `()`, and Lisp null, `NIL`, are just two

Re: Spread and non objects

On Fri, Nov 5, 2010 at 11:16 AM, Mike Samuel mikesam...@gmail.com wrote: 2010/11/5 Jon Zeppieri j...@bu.edu: To the extent that the spread operator and rest args should be symmetrical, the following function should be an identity over its domain: function id(x) { return (function

Re: Spread and non objects

On Thu, Nov 4, 2010 at 9:12 PM, Brendan Eich bren...@mozilla.com wrote: On Nov 4, 2010, at 6:07 PM, John Lenz wrote: It would seem friendlier for the spread operator to treat it them as a empty array otherwise you end up with code like: if (x!=null) { f(1,2,...x) } else { f(1,2) }

Re: Spread and non objects

On Thu, Nov 4, 2010 at 10:06 PM, Jon Zeppieri j...@bu.edu wrote: On Thu, Nov 4, 2010 at 9:12 PM, Brendan Eich bren...@mozilla.com wrote: On Nov 4, 2010, at 6:07 PM, John Lenz wrote: It would seem friendlier for the spread operator to treat it them as a empty array otherwise you end up

Re: Spread and non objects

On Thu, Nov 4, 2010 at 10:34 PM, Jon Zeppieri j...@bu.edu wrote: On Thu, Nov 4, 2010 at 10:06 PM, Jon Zeppieri j...@bu.edu wrote: On Thu, Nov 4, 2010 at 9:12 PM, Brendan Eich bren...@mozilla.com wrote: On Nov 4, 2010, at 6:07 PM, John Lenz wrote: It would seem friendlier for the spread

Re: Spread and non objects

On Thu, Nov 4, 2010 at 10:48 PM, Jon Zeppieri j...@bu.edu wrote: Spread-as-rest-arg-syntax constructs an array. Spread-as-operator splices the elements of an array into an argument list. So, if a spread operator expression: ...null splices zero values into an argument list, then its

Re: Concise functions, Nonexistent lambdas, Explicit tail calls

On Tue, Dec 9, 2008 at 5:42 PM, Michael Day [EMAIL PROTECTED] wrote: Hi Jon, This will break existing code: http://www.google.com/codesearch?q=lang%3Ajavascript+%22var+fun%22hl=enbtnG=Search+Code As will lambda:

Re: Allen's lambda syntax proposal

On Sat, Dec 6, 2008 at 11:49 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote: I don't get it. What issue is raised by return-to-label that isn't already raised by exceptions? They're practically the same thing, only return-to-label is *easier

Re: Allen's lambda syntax proposal

On Sat, Dec 6, 2008 at 2:03 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Dec 6, 2008, at 9:57 AM, Jon Zeppieri wrote: On Sat, Dec 6, 2008 at 11:49 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote: I don't get it. What issue is raised

Re: Semantics and abstract syntax of lambdas

On Fri, Dec 5, 2008 at 9:20 PM, David-Sarah Hopwood [EMAIL PROTECTED] wrote: Semantic or abstract-syntax issues that are not settled include: - how to avoid the hazard pointed out by Mark Miller where a value can be unintentionally leaked from the tail position of a lambda; Can we take a

Re: Allen's lambda syntax proposal

On Thu, Dec 4, 2008 at 3:23 PM, David-Sarah Hopwood [EMAIL PROTECTED] wrote: Jon Zeppieri wrote: And, if it is on the same line, it's still bad for a top-down parser: ^(x) { x = x * x ^(a,b,c,d,e,f,g) {x} } Same result as above. Actually, I think we're both wrong. If I'm reading

Re: Allen's lambda syntax proposal

[oops, sent from the wrong address...] 2008/12/4 Breton Slivka [EMAIL PROTECTED]: this may be a stupid question, but why? Is it really so impossible to have λ(a,b,c){} ? Last time I brought this up, Brendan made fun of me on a podcast. :( You guys seem to have no trouble typing it. It's

Re: Allen's lambda syntax proposal

On Thu, Dec 4, 2008 at 6:10 PM, Brendan Eich [EMAIL PROTECTED] wrote: On Dec 4, 2008, at 2:45 PM, Jon Zeppieri wrote: 2008/12/4 Breton Slivka [EMAIL PROTECTED]: this may be a stupid question, but why? Is it really so impossible to have λ(a,b,c){} ? Last time I brought this up, Brendan

Re: Allen's lambda syntax proposal

2008/12/2 Brendan Eich [EMAIL PROTECTED]: I think the only candidates have to be of the form ^(a, b, c) {...} (^ could be another character, but it seems to beat \ as others have noted), Was there a problem with \ other than the fact that it can't easily be turned into a binding form, à la

Re: Allen's lambda syntax proposal

2008/12/3 P T Withington [EMAIL PROTECTED]: - prefix ^ might be confused with the infix operator of the same name With semicolon insertion, isn't this a bigger problem? The opening brace will need to be on the same line as the formals, otherwise the syntax is ambiguous: ^(x) { x = x * x

Re: Allen's lambda syntax proposal

://mail.mozilla.org/pipermail/es-discuss/2008-December/008296.html - Original Message - From: Jon Zeppieri [EMAIL PROTECTED] Newsgroups: gmane.comp.lang.javascript.ecmascript4.general To: P T Withington [EMAIL PROTECTED] Cc: es-discuss [EMAIL PROTECTED] Sent: Thursday, December 04, 2008 3:09 AM

Re: Allen's lambda syntax proposal

On Wed, Dec 3, 2008 at 9:52 PM, Eric Suen [EMAIL PROTECTED] wrote: Because it is a xor expression, for lambda, it will be x = x * x ^ ^ (a,b,c,d,e,f,g) { x } I don't understand what you're getting at. That's a syntax error. My example: x = x * x ^(a,b,c,d,e,f,g) { x } is not a syntax

Re: Allen's lambda syntax proposal

On Wed, Dec 3, 2008 at 10:16 PM, Eric Suen [EMAIL PROTECTED] wrote: Yes, it doesn't contain a lambda expression, just like: a = x /x/i is not same as: a = x; /x/i they both right but has different meaning... Okay -- so we agree. In that case, it's clear that your proposed syntax:

Re: How much sugar do classes need?

On Tue, Dec 2, 2008 at 1:54 PM, Peter Michaux [EMAIL PROTECTED] wrote: On Mon, Dec 1, 2008 at 12:01 PM, David-Sarah Hopwood [EMAIL PROTECTED] wrote: var self = { method toString: {|| '' + self.getX() + ',' + self.getY() + ''}, method getX: {|| x}, method getY: {|| y}, field

Re: How much sugar do classes need?

On Tue, Dec 2, 2008 at 2:35 PM, Jon Zeppieri [EMAIL PROTECTED] wrote: ... I do want to point out, however, that one important combination is omitted in David-Sarah's proposal (modifier names aside). Private instance variables would likely be represented as non-configurable, non-enumerable

Re: How much sugar do classes need?

On Tue, Dec 2, 2008 at 1:54 PM, Peter Michaux [EMAIL PROTECTED] wrote: var self = { toString[]: {|| '' + self.getX() + ',' + self.getY() + ''}, getX[]: {|| x}, getY[]: {|| y}, pubInstVar[WE]: 4, pubInstConst[E]: -4, }; If no brackets are included then it would be equivalent to [WEC]

Re: How much sugar do classes need?

On Tue, Dec 2, 2008 at 4:58 PM, Peter Michaux [EMAIL PROTECTED] wrote: I think if there are to be modifiers than just have the modifiers and not the #{}. Having all the modifiers with the property seems like a better way to go to me. That seems fine to me, too. The #{ ... } idea just struck

Re: For Loop Desugaring (was: return when desugaring to closures)

On Mon, Oct 13, 2008 at 10:48 PM, Mark S. Miller [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 5:00 PM, Jon Zeppieri [EMAIL PROTECTED] wrote: I'm talking about a rewrite from 'for' to 'lambda' that satisfies the following properties: 1) for (var i = 0; i len; i++) ... continues to mean

Re: return when desugaring to closures

On Mon, Oct 13, 2008 at 11:43 AM, Mark S. Miller [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 8:05 AM, David-Sarah Hopwood [EMAIL PROTECTED] wrote: for (var ...) implicitly introduces a block whether or not it is a substatement. This is a wart of C++/C99/Java syntax that we have to live

Re: return when desugaring to closures

On Mon, Oct 13, 2008 at 12:47 PM, Mark Miller [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 9:13 AM, Jon Zeppieri [EMAIL PROTECTED] wrote: But then it becomes extremely awkward for the 'let' or 'const' case to use a fresh variable on every iteration. It ties the semantics of 'for' to its

Re: return when desugaring to closures

On Mon, Oct 13, 2008 at 6:34 PM, Brendan Eich [EMAIL PROTECTED] wrote: On the contrary, what's magical is when one stores i in elements of an array, or calls setTimeout (example in https://bugzilla.mozilla.org/show_bug.cgi?id=449811) , and the results are all the last value of the loop

Re: return when desugaring to closures

On Mon, Oct 13, 2008 at 7:39 PM, Brendan Eich [EMAIL PROTECTED] wrote: On Oct 13, 2008, at 4:14 PM, Jon Zeppieri wrote: Yes, and binding a fresh induction variable on every iteration makes sense for a 'for-each' loop (as in the bug report you cited), where the user is not in charge

Re: Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)

On Mon, Sep 15, 2008 at 4:18 PM, Jorge Chamorro [EMAIL PROTECTED] wrote: El 14/09/2008, a las 21:30, Mark S. Miller escribió: The arguments object itself is often passed in order for function F to give function G access to the argument list F with which was called. This seemingly innocent

Re: Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)

On Mon, Sep 15, 2008 at 5:13 PM, Jorge Chamorro [EMAIL PROTECTED] wrote: El 15/09/2008, a las 22:32, Jon Zeppieri escribió: IOW, could we have instead a ('standalone') 'callee' property (that isn't to be innocently passed on) ? ...as a property of what? The activation object

Re: local

On Thu, Aug 21, 2008 at 11:21 AM, Peter Michaux [EMAIL PROTECTED] wrote: On Thu, Aug 21, 2008 at 6:31 AM, Brendan Eich [EMAIL PROTECTED] wrote: More helpful would be comments on the utility of let blocks (a.k.a. let statements) and let expressions. Also comparisons to the several let forms in