Re: for-must-match
Kevin Reid <kpreid-M/[email protected]> Sat, 22 Oct 2011 10:00:41 -0400
| Newsgroups | gmane.comp.lang.e.general |
|---|---|
| Message-ID | <[email protected]> |
On Oct 22, 2011, at 8:17, Thomas Leonard wrote: > Here's a patch to add list comprehensions: > > ? def list := [1, 2, 3] > ? [2 * x for x in list] > # value: [2, 4, 6] > > http://gitorious.org/repo-roscidus/e-core/commit/9bfacc4f748b4ea6a7cf64dc40d7bc9dd1890d38 > > And for map comprehensions: > > ? def map := ["alice" => 50, "bob" => 60] > ? [v => k for k => v in map] > # value: [50 => "alice", 60 => "bob"] > > http://gitorious.org/repo-roscidus/e-core/commit/980c8c93d41a69f242acdb5b83c9faccf918f4c3 > > They don't currently support the 'match' keyword, so you can't use > them to filter (every item must be mapped to something). I reject this proposal. 1. I am uncomfortable with it because I suspect it of violating E's syntactic conventions about scoping and evaluation order, though I would have to consult MarkM to be more precise. 2. Furthermore, we already have the accumulator syntax which covers these use cases. I recognize that the accumulator syntax is ugly; its problem is that it is both too general and not general enough. This proposal is not general enough. I would rather see additional functional operations and use of lambda-args than additional syntax for operations on lists and maps; especially if they are part of a system which solves the parallel iteration problem. As to your previous for-must-match pragma: I doubt its appropriateness for the language. However, it is entirely appropriate to add it as a pragma as an *experiment* -- that's why we have pragmas. You may commit for-must-match, provided that the documentation and *EVERY* code addition which supports it is marked as experimental and part of for-must-match. One of the reasons I don't like it is that explicit testing in 'for' (especially with the ? such-that pattern) is often useful. Have you considered instead adding syntax which makes a pattern "must match", i.e. converts failure into an exception (like Haskell's @ "irrefutable patterns")? The default would be the opposite of what you have, but the syntax would make it easy to express that case where it currently isn't. -- Kevin Reid <http://switchb.org/kpreid/>