one might consider a script provide with parse-on-use semantics
Sounds like yet another use strict to me. Experience tells that this is
not working very well. Either an optimization is worth and is enforced by
default, or it isn't used in most cases. Asking the developer to mark his
code
Oliver Hunt wrote:
I still don't understand this desire to delay semantic analysis, where are the
examples of sema being a performance bottleneck? Just basic parsing already
requires us to do a reasonable amount of analysis anyway, and while parsing
shows up as being a problem, the bulk of
On Sep 27, 2012, at 10:54 PM, Brendan Eich bren...@mozilla.org wrote:
Oliver Hunt wrote:
I'm generally against error on first call -- in the general case if you're
able to determine a function should fail on first execution you can
determine that it could fail during parsing and semantic
Oliver Hunt wrote:
On Sep 27, 2012, at 10:54 PM, Brendan Eichbren...@mozilla.org wrote:
Oliver Hunt wrote:
I'm generally against error on first call -- in the general case if you're able
to determine a function should fail on first execution you can determine that
it could fail during
On Sep 27, 2012, at 10:54 PM, Brendan Eich wrote:
Oliver Hunt wrote:
I'm generally against error on first call -- in the general case if you're
able to determine a function should fail on first execution you can
determine that it could fail during parsing and semantic analysis.
Ok, to
Allen Wirfs-Brock wrote:
I see a potential benefit to implementor in the deferred early error concept
and there are implementation alternatives that would be lost without it. I see a minor
negative impact to developers. They would need to take an extra pre-deployment action in
order to be
On Sep 28, 2012, at 9:54 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I see a potential benefit to implementor in the deferred early error
concept and there are implementation alternatives that would be lost without
it. I see a minor negative impact to developers. They would need to
The size of the average JS program is increasing in size faster than
machines are getting faster from where I sit. Adding startup overhead
should be something TC39 is actively working against.
The early errors/first run errors can be caught by other tools as well
(linters, in browser developer
Allen Wirfs-Brock wrote:
It isn't clear to me that there is much difference between an invocation-fused explosive
function-level and a similarly fused script file or module. The triggering of each of
these normally occurs at some point after some application code has executed to even if
we
John Lenz wrote:
The size of the average JS program is increasing in size faster than
machines are getting faster from where I sit.
Ahem, gmail, cough. :-/
Adding startup overhead should be something TC39 is actively working
against.
I take a different view, since as you say machines
On Fri, Sep 28, 2012 at 11:14 AM, Brendan Eich bren...@mozilla.org wrote:
John Lenz wrote:
The size of the average JS program is increasing in size faster than
machines are getting faster from where I sit.
Ahem, gmail, cough. :-/
Spreadsheets, document editor, photo editor, games,
John Lenz wrote:
The best thing I see for the future is if the Browser vendors didn't
reparse JavaScript when loading from cache, this would help the best
case scenarios, but doesn't help the worse case where it harder to
find wins.
Yes, why hasn't this happened? We had a Mozilla intern
On Sep 28, 2012, at 20:58, Brendan Eich bren...@mozilla.org wrote:
John Lenz wrote:
The best thing I see for the future is if the Browser vendors didn't reparse
JavaScript when loading from cache, this would help the best case scenarios,
but doesn't help the worse case where it harder to
* Error on first call to a function, where the function contains what
would be an early error but for the supposed cost of early error analysis.
As I understand it, this goes back to lazy parsing
http://ariya.ofilabs.com/2012/07/lazy-parsing-in-javascript-engines.html
which, in turn, seems to
As a user, not implementer, I really want early errors. Perf costs of startup
are negligible especially long-term. By the time ES6 is in browsers computers
and phones should be faster by enough of a factor to mitigate any costs,
whereas omitting early errors hurts developers indefinitely into
Domenic Denicola wrote:
As a user, not implementer, I really want early errors. Perf costs of startup
are negligible especially long-term. By the time ES6 is in browsers computers
and phones should be faster by enough of a factor to mitigate any costs,
whereas omitting early errors hurts
I'm generally against error on first call -- in the general case if you're able
to determine a function should fail on first execution you can determine that
it could fail during parsing and semantic analysis.
--Oliver
On Sep 27, 2012, at 9:01 PM, Brendan Eich bren...@mozilla.org wrote:
Oliver Hunt wrote:
I'm generally against error on first call -- in the general case if you're able
to determine a function should fail on first execution you can determine that
it could fail during parsing and semantic analysis.
Ok, to play fair I should ask how you feel about any analysis
18 matches
Mail list logo
