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

Brendan Eich brendan at mozilla.com
Sat Jan 14 16:11:06 PST 2012


> David Bruant <mailto:bruant.d at gmail.com>
> January 14, 2012 4:04 PM
> Le 13/01/2012 19:15, Brendan Eich a écrit :
>> Lasse Reichstein:
>>> It might be changed if there was an actual advantage for the 
>>> programmers in using strict mode, which there hasn't been
> I heard some got burnt by a missing "var" [1]. Strict mode and a bit 
> of testing could have prevented this blog post from existing.
> If strict mode only had introduced this change, I would consider it 
> worthwhile.

Yes, that alone is worth a lot. But strict mode has a bad rep and these 
folks did not use it. We should look directly at why.
>
>>> it's not faster, it's not simpler, and it's not what they are used to
> I recently suggested a newcomers to the language to always be in 
> strict mode ;-)

Great. Not happening enough at scale to matter, AFAICT. I could be 
wrong, it's early yet. But we can't use strict-mode adoption as an 
argument against default version (unversioned script, new syntax as its 
own opt-in) being the norm.
>
>>> and being more compatible between ECMAScript implementations makes 
>>> no difference when writing for just node.js.
>>
>> This part I agree with. Strict mode did some good things we like (all 
>> the early errors, basically). The runtime meaning shifts and their 
>> implications for performance (at least, without new optimization 
>> effort on the part of implementors, who face little incentive without 
>> adoption -- which won't be forthcoming without performance) were not 
>> good.
> Regarding performance, I'm not sure I understand what the big deal is. 
> It's always possible to develop in strict mode and deploy as 
> non-strict if the performance difference really matters.
> Code written with in strict mode and with decent discipline (not 
> assuming anything on the 'this' value of a function used as a 
> function, for instance, etc.) should run fine in non-strict, no?

It's not just |this| coercion. If you write code that assumes no 
arguments aliasing and assign to a formal parameter or arguments[i] that 
aliases it in non-strict mode, and do not get the aliasing (as you 
expect), but fail to test your non-strict deployed code, you have a 
subtle and possibly nasty bug.

People won't take such risks without better-communicated incentives, 
even though the cases are "corner cases". The main selling point as you 
note is assigning to a free variable is a runtime error. That's good but 
not great. Harmony (however opted-in) makes it an early error, which is 
the real deal.

/be
>
> David
>
> [1] 
> http://blog.meloncard.com/post/12175941935/how-one-missing-var-ruined-our-launch
> Brendan Eich <mailto:brendan at mozilla.com>
> January 13, 2012 10:15 AM
>> Lasse Reichstein <mailto:reichsteinatwork at gmail.com>
>> January 13, 2012 1:30 AM
>> I'd like having 0o777 (and 0b1111!) but I thought the reason for 
>> removing the existing octal literals was that they were surprising 
>> and error-prone (and behaving erratically in different settings, so, 
>> e.g., 0100 != +"0100").
>> That reasoning still stands.
>
> Are there bug reports or other skidmarks from mistakes of this kind? 
> I've never seen one.
>
> https://bugzilla.mozilla.org/buglist.cgi?field0-0-5=content&am 
> p;type0-0-4=substring&type0-0-5=matches&value0-0-5=%22octal%22&list_id=2058643&short_desc=octal&field0-0-0=product&type0-0-1=substring&field0-0-1=component&type0-0-6=substring&field0-0-4=status_whiteboard&classification=Components&value0-0-2=octal&field0-0-6=cf_crash_signature&query_format=advanced&type0-0-3=substring&field0-0-3=short_desc&value0-0-3=octal&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&value0-0-4=octal&short_desc_type=allwordssubstr&field0-0-2=alias&value0-0-1=octal&type0-0-0=substring&value0-0-6=octal&value0-0-0=octal&component=JavaScript%20Engine&product=Core&type0-0-2=substring
>
> Indeed we made bugs for our users in the course of implementing and 
> finalizing ES5. Here's a particularly time-killing exercise:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=601262
>>
>> I don't think people writing non-strict code as their default for 
>> node.js is a problem solved by changing strict mode.
>
> Harmony is based on strict mode. V8 is implementing Harmony proposals 
> for ES.next. The recent version-free opt-in thinking in concert with 
> these facts suggest Node.js people will be writing ES.next code at 
> some point. Will octal permission literals work then? It's a small 
> point but I say they ought to.
>
>> It might be changed if there was an actual advantage for the 
>> programmers in using strict mode, which there hasn't been - it's not 
>> faster, it's not simpler, and it's not what they are used to, and 
>> being more compatible between ECMAScript implementations makes no 
>> difference when writing for just node.js.
>
> This part I agree with. Strict mode did some good things we like (all 
> the early errors, basically). The runtime meaning shifts and their 
> implications for performance (at least, without new optimization 
> effort on the part of implementors, who face little incentive without 
> adoption -- which won't be forthcoming without performance) were not good.
>
> /be
>>
>> /L
>>
>>
>> Brendan Eich <mailto:brendan at mozilla.com>
>> January 12, 2012 10:47 PM
>> The API in question takes a string and does parseInt if necessary. 
>> That's not the issue. There is real code using octal and it won't 
>> change to quote the numeric literal, and it won't adopt strict mode. 
>> Meanwhile CoffeeScript is trying to target strict mode. It  can cope, 
>> but we're left with non-strict Node.js JS source code as default, 
>> with no incentive to change.
>>
>> What was the good, what benefit was achieved, by banning octal from 
>> strict mode? Since it is required for web compatibility, it is 
>> already in the spec. Adding 0o is not adding an unnecessary feature 
>> if there are valid use cases for octal. Or would you be ok if we 
>> simply allowed 0-prefixed octal in strict mode?
>>
>> /be
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>> Lasse Reichstein <mailto:reichsteinatwork at gmail.com>
>> January 12, 2012 10:15 PM
>> Seems like a library interface that isn't well thought through:
>> Accepting a number as input, but it's only reasonably written in one
>> base. Then it's not really a number, but rather a formatted string, so
>> the chmod function should take a string as argument and do its own
>> parseInt(_,8) on it (and accept other formats too, like "a+rw" or
>> "rwxr--r--").
>>
>> Don't try to fix a single broken interface by adding unnecessary
>> features to the language!
>> /L 'not a Unix hater, but probably a chmod hater'
>>
>> Wes Garland <mailto:wes at page.ca>
>> January 12, 2012 11:51 AM
>> I'll chime in with my vote - I would LOVE to be able to use octal 
>> literals again in GPSEE for setting file permissions.
>>
>> chmod("filename", parseInt("777", 8))
>>
>> ^^^^ just looks stupid when  chmod("filename", 0777) would work just 
>> fine.
>>
>> Wes
>>
>>
>>
>>
>>
>> -- 
>> Wesley W. Garland
>> Director, Product Development
>> PageMail, Inc.
>> +1 613 542 2787 x 102
>> Brendan Eich <mailto:brendan at mozilla.com>
>> January 12, 2012 11:11 AM
>> [Resending reply with elaboration. /be]
>>
>> Yes, the ability to quote the octal literal with Node's APIs came up 
>> on the gist, but it's not enough.
>>
>> Quoting is easy to forget, and making the runtime convert string 
>> (literal) to number is inefficient compared to having JS do it at 
>> compile-time, and making the runtime (even via a call to parseInt) do 
>> it also increases bug habitat ever so slightly.
>>
>> Mainly, users don't have to shun octal in non-strict mode, and they 
>> do not in Node code I have seen. They won't be adopting strict mode 
>> as far as I can tell. Banning octal is just one more reason for those 
>> who *might* adopt strict mode to reject it.
>>
>> Agree on parseInt. Old dog, hard to change (runtime-only errors are 
>> migration- and user-hostile). Not sure what to do there.
>>
>> /be
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Lasse Reichstein <mailto:reichsteinatwork at gmail.com>
> January 13, 2012 1:30 AM
> I'd like having 0o777 (and 0b1111!) but I thought the reason for 
> removing the existing octal literals was that they were surprising and 
> error-prone (and behaving erratically in different settings, so, e.g., 
> 0100 != +"0100").
> That reasoning still stands.
>
> I can't say whether removing them from strict mode was really a 
> benfit. It made strict mode more compatible across browsers than 
> non-strict mode ever was, but it might also have made moving code from 
> non-strict to strict slightly harder.
> Personally, I'd go for strict mode to be sure that my numbers were 
> *not* interpreted as octal.
> But that's what's being argued here - converting existing code (or 
> existing programmers) to strict mode is hampered by them not 
> being able to use the octal numbers they are used to.
>
> Well, these are obviously not programmers that want strict mode to 
> begin with (since it requires very little effort to change the octal 
> literal to a string). It's people that would choose strict mode only 
> if it was trivial or they had a compelling reason for doing it.
>
> I don't think people writing non-strict code as their default for 
> node.js is a problem solved by changing strict mode.
> It might be changed if there was an actual advantage for the 
> programmers in using strict mode, which there hasn't been - it's not 
> faster, it's not simpler, and it's not what they are used to, and 
> being more compatible between ECMAScript implementations makes no 
> difference when writing for just node.js.
>
> /L
>
>
> Brendan Eich <mailto:brendan at mozilla.com>
> January 12, 2012 10:47 PM
> The API in question takes a string and does parseInt if necessary. 
> That's not the issue. There is real code using octal and it won't 
> change to quote the numeric literal, and it won't adopt strict mode. 
> Meanwhile CoffeeScript is trying to target strict mode. It  can cope, 
> but we're left with non-strict Node.js JS source code as default, with 
> no incentive to change.
>
> What was the good, what benefit was achieved, by banning octal from 
> strict mode? Since it is required for web compatibility, it is already 
> in the spec. Adding 0o is not adding an unnecessary feature if there 
> are valid use cases for octal. Or would you be ok if we simply allowed 
> 0-prefixed octal in strict mode?
>
> /be
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Lasse Reichstein <mailto:reichsteinatwork at gmail.com>
> January 12, 2012 10:15 PM
> Seems like a library interface that isn't well thought through:
> Accepting a number as input, but it's only reasonably written in one
> base. Then it's not really a number, but rather a formatted string, so
> the chmod function should take a string as argument and do its own
> parseInt(_,8) on it (and accept other formats too, like "a+rw" or
> "rwxr--r--").
>
> Don't try to fix a single broken interface by adding unnecessary
> features to the language!
> /L 'not a Unix hater, but probably a chmod hater'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120114/c2044c00/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120114/c2044c00/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1290 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120114/c2044c00/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1242 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120114/c2044c00/attachment-0005.jpg>


More information about the es-discuss mailing list