::double-facepalm:: On Mon, Jul 9, 2012 at 12:54 PM, Russell Leggett <[email protected]>wrote:
> ::faceplam:: > > > On Mon, Jul 9, 2012 at 12:36 PM, Andreas Rossberg <[email protected]>wrote: > >> I agree with almost everything you said. But just to clarify, I think you >> actually meant "refutable" everywhere you said "irrefutable". >> >> /Andreas >> >> >> On 9 July 2012 18:19, Russell Leggett <[email protected]> wrote: >> >>> >>> >>> On Fri, Jul 6, 2012 at 1:37 PM, Brendan Eich <[email protected]>wrote: >>> >>>> Andreas Rossberg wrote: >>>> >>>>> >>>>> We should talk more at this month's TC39 meeting, but I see a >>>>> sharp divide ahead: >>>>> >>>>> 1. Choose (A), possibly with modification, either rejecting useful >>>>> pattern matching decisively, or else making its pattern language >>>>> differ by making prefix-! implicit. But you rejected splitting >>>>> pattern meaning across destructuring and future pattern-matching, >>>>> in the last sentence cited above. >>>>> >>>>> XOR >>>>> >>>>> 2. Choose (B) because future-proofing for pattern matching wants >>>>> prefix-?, and impose a compatibility break from what we and others >>>>> implemented, and what most JS users might expect based on JS's >>>>> carefree imputing of undefined. >>>>> >>>>> >>>>> Agreed. >>>>> >>>>> >>>>> Comments from es-discuss peanut gallery welcome. >>>>> >>>>> I could go for 1/A, except for two facts. First, I believe there >>>>> is a non-trivial body of Firefox JS that depends on imputing >>>>> undefined. Second, and what is more important: we haven't >>>>> usability-tested 2/B at all. >>>>> >>>>> >>>>> Did you mean "could go for 2/B" there? >>>>> >>>>> >>>> Evidently! >>>> >>>> I rearranged and renumbered but missed this one. Clearly I meant 2/B. >>>> I'm a bit unhappy about making such a change so long after implementing 1/A >>>> (without prefix-!). But never mind me -- what do others think? >>> >>> >>> I would love to see 2/B. A lot of that is likely because I would love to >>> see pattern matching, though, I'll admit. I think that the ? on refutable >>> portions of the pattern would work well with the new default and >>> existential operators, while I think ! will not have a good analog. If I >>> were to throw out another reason based on destructuring assignment alone, >>> and not pattern matching later, I would say that if parts of the >>> destructuring are likely to fail, it would be better to know upfront. If >>> there are optional fields, ? clearly expresses that. If there are wildly >>> unknown structures, destructured assignment is probably not the best >>> approach, or at least there should be some structural testing upfront >>> (pattern matching would of course be ideal). >>> >>> As for usability testing, while it obviously is not done irrefutably in >>> spidermonkey now, I think we can at least look to other languages. Looking >>> over several languages, all of the ones I have seen are irrefutable. Some >>> are strongly typed languages, but not all. Python does not have complete >>> patterns, it can basically just destructure list, but even it requires that >>> the number of elements be correct. Erlang, OCaml, and F# all allow full >>> pattern assignments, and they will all throw errors if not correctly >>> matched. Obviously, it is a little different than what it would be in ES, >>> they have full on patterns not just destructuring, but it would clearly be >>> all the more consistent when patterns *hopefully* get added. I know that JS >>> users have come to expect a certain amount of carefree imputing, but >>> destructuring is new (outside of FF), and I think it is certainly an area >>> which has options. I haven't exactly done a formal survey of languages, but >>> from what I've seen JS would be the first to be so lenient. Allowing ? in >>> portions of a pattern, I actually think would be the perfect compromise. >>> People who write very loose code will either have to put ?s on their >>> patterns or keep working the same way they have been, but if there isn't a >>> reasonable amount of checking by default, I think we're going to be seeing >>> some more WATs in presentations. JS gets picked on for how much coercion >>> and silent errors it will chug along with. Best practices of always using >>> === and avoiding 'with' are just a couple of examples. >>> >>> Finally, I would like to take the approach of looking at the best way to >>> handle the different use cases. >>> >>> 1. Really simple destructuring with expected results: >>> let {x,y} = getPoint(); >>> In my opinion, this should throw if x or y are not available. It is >>> unlikely that the coder is checking properties here, they are just going >>> to >>> call other functions passing through x or y. It would probably be better >>> to >>> get the error as soon as possible. Much easier to debug that way. In many >>> cases, I think these types of destructuring assignments will lead to >>> effortless checking that would previously have been missed because of the >>> extra effort to add those checks in as if statements. >>> 2. Options type objects: >>> let {url,callback,?errback} = options; >>> This lets you very clearly decompose an object and declaratively >>> show which values are optional and which ones are not. If all of them are >>> optional, the ? would just go to the left of the brace, but really this >>> should be the minority case for most situations. >>> 3. A disparate list of possible types of matches. This is common in >>> "overloaded" functions where the number and type of arguments can be >>> wildly >>> different. This is probably the strongest case against irrefutable >>> matching, because it is so likely to result in mismatches which should >>> have >>> logic performed on them instead of having an error thrown. However, it is >>> also the strongest case for pattern matching. There is nothing wrong with >>> wanting to accept differently shaped things, but right now there is not >>> really a great facility for acting on them. Pattern matching would be >>> ideal. I think it would be such a powerful addition to the language as it >>> is used right now, that it honestly pains me that we would cut out the >>> possibility. I would love to see patterns now, but I can understand >>> waiting. Making a decision which would close it off though would be >>> extremely disappointing. >>> >>> I know that full blown patterns are out of scope (though I'm hoping >>> maybe this discussion might change that), but even if we can't have it now, >>> I think irrefutable destructuring would really make people see the >>> potential. Even if no facility was provided for it, a hypothetical match >>> function could be created which would take function and execute them in >>> sequence in a try catch until one did not fail. I think we can do better >>> than that and should probably try if we go with irrefutable destructuring, >>> but just knowing it would be possible for the community to take and run >>> with is nice. >>> >>> - Russ >>> >>> >>>> >>>> >>>> /be >>>> >>>> ______________________________**_________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >>>> >>> >>> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
