Re: Function length

2012-06-13 Thread Tom Ellis
I like the look of this:

 function add(a,b){
 return a + b;
 }
 
 add.matches(1,2); // = true
 add.matches(1); // = false
 add.matches(1,2,3);  = false


I've never had the need to use function.length, I probably will at some point 
though.

If you did something like this, using the rest argument:

function add( a, b, ...others ) {
...
}

Then the following should occur:

add.matches(1,2) // = true
add.matches(1) //= false
add.matches(1,3,4) //= true

Tom


On 12 Jun 2012, at 22:57, Russell Leggett wrote:

 On Tue, Jun 12, 2012 at 1:06 PM, Brendan Eich bren...@mozilla.org wrote:
 Russell Leggett wrote:
 It does bring up something else, though, that I've avoided mentioning so far, 
 which is pattern matching. I haven't mentioned it because there is clearly a 
 strawman http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching 
 for it, and that never made it to harmony, but in light of this thread I 
 wanted to reiterate how useful it would be. It would not really help 
 function.length, but would address the real underlying problem that the arity 
 dispatcher is trying to tackle. In a language without overloading, the 
 ability to do pattern matching would be an excellent solution to a very 
 common problem. We already have destructuring, it seems like such a small 
 jump to pattern matching.
 
 You are preacher, dherman and I are choir. Maybe patterns will make ES7. We 
 shall try again.
 
 
 Hard to tell from looking at the strawman why that never made it. If its a 
 matter or feature bloat, I would rate that higher than some other things like 
 default args or array comprehensions.
 
 See March 2011 TC39 meeting notes, second day.
 
 Quotes below. Note some fine specimens of TC39's future-proofing 
 fetishization on parade. I will say no more, as I think Dave agrees patterns 
 were not fully baked.
 
 The way to get refutable matching into ES7 is to work now to address all the 
 valid worries, and say why the other worries are false.
 
 This thread gave me an interesting idea on how to possibly attack pattern 
 matching in ES6 with no new syntax, and still leave room for more sugar 
 later. It actually comes from thinking about the original issue with 
 function.length and using it for arity-based dispatch. What if we just gave a 
 better method than length? What if we had something like 
 function.matches(args)? Where it would return true if all arguments were 
 bound, and no parameters resulted in an undefined binding.
 function add(a,b){
 return a + b;
 }
 
 add.matches(1,2); // = true
 add.matches(1); // = false
 add.matches(1,2,3);  = false
 
 This still suffers from the same problem as function.length, and when dealing 
 with simple arity and no destructuring/rest params, would act exactly the 
 same. However, Irakli's dispatcher utility does lay the groundwork for 
 something more interesting.
 
 function makePoint(x,y){ return {x:x,y:y}; }
 function drawLine({x:x1,y:y1},{x:x2,y:y2}){...}
 
 let p1 = makePoint(1,2), p2 = makePoint(3,4);
 drawLine.matches(p1,p2); // = true
 drawLine.matches(1,2); // = false
 drawLine.matches({x:1}, {y:2}) // = false
 //only has to be a structural subset
 drawLine.matches({x:1,y:2,z:3}, {x:1, y:2}) // = true
 
 With that simple boolean function, Irakli's dispatcher utility could be 
 rewritten to loop through the list and check for a match instead of by arity. 
 It would work correctly for rest parameters, but even more interesting, would 
 work with all of the destructuring patterns.
 
 let drawLine = dispatcher(
 (x1,y1,x2,y2) = ...,
 ({x:x1,y:y1},{x:x2,y:y2}) = ...
 );
 
 Or a more functional replacement for switch
 
 let result = match(value, 
 ({x,y,z}) = 3d
 ({x,y}) = 2d
 (...anything) = not a point
 );
 
 Its not as nice as full pattern matching with literals and wildcards, but it 
 could be pretty clean. If guards were added later, that would be an obvious 
 fit. If it became a popular pattern, we could pave the cowpath with some 
 sugar, and add the things that are missing now.
 
 One of the benefits of getting started this way is that it could be shimmed 
 to just use length.
 
 ___
 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: ||= is much needed?

2012-06-12 Thread Tom Ellis
I like the sound of ?= too. 

var a;

//later on

a ?= 15;

It goes with all the other operators that are out there too (!=, =, ==, === 
etc).

Tom

On 12 Jun 2012, at 19:04, Brendan Eich wrote:

 Brendan Eich wrote:
 Is this (A ? B) ? C : D or A ? (B ? C) : D. We can disambiguate in the 
 formal grammar but readers may rebel. 
 
 Or A ? (B ? C : D), of course.
 
 Just say no to lone ? as new operator. I'm warming up to ?= though!
 
 /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: Why not NodeList#forEach :\?

2012-06-11 Thread Tom Ellis
 ES6 draft specifies a new Array constructor called Array.from that will 
 essentially convert array-likes into arrays

This will have uses for the arguments objects too, for people that aren't using 
...rest in ES6.

Tom

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


Re: Why not NodeList#forEach :\?

2012-06-11 Thread Tom Ellis
Awesome. I've had es6-shim for a while now but I haven't used it yet. I forgot 
what its use was until now.

Tom

On 11 Jun 2012, at 14:44, Rick Waldron wrote:

 
 
 On Mon, Jun 11, 2012 at 9:09 AM, Tom Ellis tellis...@gmail.com wrote:
  ES6 draft specifies a new Array constructor called Array.from that will 
  essentially convert array-likes into arrays
 
 This will have uses for the arguments objects too, for people that aren't 
 using ...rest in ES6.
 
 Indeed - Array.from can be used with any object that has a numeric index and 
 length property whose value is a number - which covers a very wide swath of 
 Ecmascript/non-Ecmascript objects.
 
 
 Rick
  
 
 Tom
 
 ___
 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