[e-lang] for-must-match
Kevin Reid
kpreid at switchb.org
Sat Oct 22 07:00:41 PDT 2011
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/>
More information about the e-lang
mailing list