These are chat archives for evhub/coconut

11th
Aug 2016
Chuck Daniels
@chuckwondo
Aug 11 2016 10:34

@evhub Regarding addpattern, I read through the discussion on #125. Would using a Coconut keyword (either existing or new) help? For example, to eliminate the explicit use of the parameterized addpattern decorator, would something like the following allow the compiler to do the necessary work under the covers (following on from the previous example above)?

pattern size(Empty()) = 0
pattern size(Leaf(_)) = 1
pattern size(Node(left, right)) = size(left) + size(right)

Although this example uses only shorthand function notation, I would expect regular function notation to be supported as well. This, however, does not account for the behavior of the prepattern decorator, but at the moment I don’t see why that’s necessary. If you want to use a different ordering, just reorder them, unless of course you’re adding a pattern to a pattern defined by a separate library, but I would think that could also be handled without the use of prepattern.

Evan Hubinger
@evhub
Aug 11 2016 21:47
@chuckwondo Yes, a keyword would resolve the problem. However, I'm wary to add a new keyword without very good reason, and I don't think having to use the decorator is bad enough that it justifies that. Maybe if there was a good way to leverage an existing keyword?