return when desugaring to closures
Brendan Eich
brendan at mozilla.com
Sat Oct 11 15:16:51 PDT 2008
On Oct 11, 2008, at 2:24 PM, Mark S. Miller wrote:
> On Sat, Oct 11, 2008 at 1:36 PM, Peter Michaux
> <petermichaux at gmail.com> wrote:
>> Simplifying
>>
>> (lambda (x = 3, y = x) (x+y))()
>>
>> to just
>>
>> let (x = 3, y = x) (x+y)
>>
>> makes it much more clear when reading code what the intention of the
>> programmer was.
>
> If the need for this case were common, that would be something. But
> how often do cases come up for which the letrec-like let declaration
> is not adequate? In hand written source, I think it's very rare.
One easily inspected source repository search (there are other
repositories) is
http://mxr.mozilla.org/firefox/search?string=let+(
yielding the results appended at the bottom of this message (mxr is
slow, so I thought I'd include them and save others the wait).
The reason people like let blocks and expressions as opposed to let
declarations, from what I can tell, is precisely the lack of hoisting
to top of block done for let declarations, and the greater clarity of
head-scoped initialization (possibly using outer names that will be
shadowed in the block or expression, but usually not) of the 'let
(head) ...' syntax.
Of course everything could be lambda-coded, but that's not harmonious
or usable. Just let as new var is agreed upon, and let blocks and
expressions could be let coded if there is no name shadowing (else
they'd need lambda-coding). But we should not dismiss the use-cases
for let blocks/expressions out of hand. There is experience in JS1.7
and 1.8 to consider here, not just hypothetical arguments about how
often hand-written cases come up.
Based on the lambda proposal, we could unify let expressions with
blocks, avoiding two forms. That is, you could use let (x = y) { /*
statements here */ } as an expression or in a statement context. TC
would want return, etc. to work as for lambda. Thus let with a head
would become lambda-call sugar (a bit more than a spoonful when you
add up the three more letters and the () to call).
(This is incompatible with JS1.7+ but if standardized, JS1.x would
track the standard and carry compatibility costs under the old
versions.)
/be
-----
/toolkit/mozapps/downloads/src/DownloadUtils.jsm (View CVS log or CVS
annotations)
* line 103 -- let ([n, v] = [name, value])
* line 178 -- let (transfer =
DownloadUtils.getTransferTotal(aCurrBytes, aMaxBytes)) {
* line 184 -- let ([rate, unit] =
DownloadUtils.convertByteUnits(aSpeed)) {
* line 192 -- let ([timeLeft, newLast] =
DownloadUtils.getTimeLeft(seconds, aLastSec)) {
* line 271 -- let (diff = aSeconds - aLastSec) {
/toolkit/mozapps/downloads/content/downloads.js (View CVS log or CVS
annotations)
* line 438 -- let (sb =
document.getElementById("downloadStrings")) {
* line 946 -- let (stateSize = {}) {
* line 1127 -- let (empty = gDownloadsView.cloneNode(false)) {
* line 1190 -- let (referrer = gStmt.getString(7)) {
/toolkit/content/widgets/autocomplete.xml (View CVS log or CVS
annotations)
* line 1268 -- regions = regions.sort(function(a, b) let (start =
a[0] - b[0])
/browser/base/content/browser.js (View CVS log or CVS annotations)
* line 6695 -- let (bundle =
document.getElementById("bundle_browser")) {
/browser/components/preferences/applications.js (View CVS log or CVS
annotations)
* line 1848 -- let (preferredApp =
aHandlerInfo.preferredApplicationHandler) {
/js/src/xpconnect/tests/mochitest/test_wrappers.html (View CVS log or
CVS annotations)
* line 32 -- let (obj = { a: 3 }) {
* line 50 -- let (obj = {}) {
/netwerk/test/unit/test_bug414122.js (View CVS log or CVS annotations)
* line 39 -- let (rest = line.substring(2))
/content/xbl/test/test_bug389322.xhtml (View CVS log or CVS annotations)
* line 17 -- let (x=1) (x);
* line 28 -- let (x=1) (x);
* line 37 -- let (x=1) (x);
* line 48 -- let (x=1) (x);
* line 60 -- let (x=1) (x);
* line 75 -- let (x=1) (x);
* line 109 -- let (x=1) (x);
* line 117 -- let (x=1) (x);
More information about the Es-discuss
mailing list