Change patroon helpers

[bas080]

I'm not an native English speaker but to me the naming of the pattern helpers seem off.

Currently we have typed and ref. It seems a bit off. Either the naming should improve or the API should change so these helpers don't even exist.

An idea is to only have an all helper which will check if all patterns passed to it pass. It could look like this.

To manage the errors with a value one could do:

patroon(
  all(is(Error), {statusCode: _}), 'an error with statusCode'
)

In case of the ref one could do:

patroon(
  equals(fn), 'is the function'
)

This would make patroon a little more focused/bare-bones but still play nice with other fp libraries.

EDIT:

@CrossEye suggested using arrays for each pattern-value pair. In that case an all helper would not be necessary.

patroon(
  [Error, {statusCode: _}, 'is an error with a statusCode']
)

[bas080]

Another use case I would like to cover is to allow pattern matching on values of functions with an arity greater than 1. What could that look like?

patroon(
  [args(_, {a:_}), 'function called where the second argument is an object with "a" prop']
)

So maybe have an args helper to make it easy to use the patroon patterns for this type of function.

[CrossEye]

Another use case I would like to cover is to allow pattern matching on values of functions with an arity greater than 1

Note that's how Ramda's cond works. It's signatures are something like:

cond :: [((a -> Bool), (a -> b))] -> (a -> b)
cond :: [((a -> b -> Bool), (a -> b -> c))] -> (a -> b -> c)
cond :: [((a -> b -> c -> Bool), (a -> b -> c -> d))] -> (a -> b -> c -> d)
-- ...

Of course that's all R.cond does. It does not try to do even a small fraction of what patroon does with its inputs. But when working with functions in JS, it does seem the most likely approach. It also seems to get at an incomplete but useful form of multiple dispatch. See Sanctuary for a library that does something much more disciplined and has only unary, curried functions.

[bas080]

@CrossEye, you mention this library that is a part of the Sanctuary eco-system. I'm interested to know what it is you're reffering to.

[bas080]

@CrossEye, While working on patroon the Ramda cond function did cross my mind several times. I would ask myself how certain functions would look like if you would write them using the Ramda's library. I've concluded that in most cases that using the Ramda library would be more verbose.

I would also like mention that having this DSL like library where the pattern actually looks like the input itself can improve the readability of code. You see a similar approach in erlang/elixir.

[CrossEye]

@bas080: Sanctuary itself is the library I meant. It's much more disciplined than Ramda. For instance, all its functions are fully curried.

Ramda would certainly be more verbose than patroon, in those few places they would overlap. patroon is making very different decisions than Ramda does. Ramda would never do some of the things that patroon does in terms of variable signatures. That is not at a criticism. patroon is meant for a simple, singular purpose, and trying to make that purpose quite flexible, in the normal JS manner. If I were writing this, I might do it in a different manner, something more like cond with some helpers, but I find your choices intriguing.

[bas080]

@CrossEye, when it comes to the function signature it might be worth to offer a simpler patroon function for creating predicates.

patroon :: pattern -> (x -> Bool)

patroon({a: _})({a: 20}) // => true

That way patroon would play nice with cond or other functions that take predicates.

To make patroon play nice with the existing Ramda/fp eco-system it is worth changing the function signature to improve composition and point free programming.

Currently patroon's function signature is similar to cond except for the currying and that it does not use the arrays to create pairs. I'm considering having cond and patroon to have the same function signature or changing patroon to a predicate only function.

[CrossEye]

@CrossEye suggested using arrays for each pattern-value pair. In that case an all helper would not be necessary.

 patroon(
  [Error, {statusCode: _}, 'is an error with a statusCode']
)

... except that you might then also want an any helper, and you couldn't cover them both with the same syntax.

patroon(any({code: 301}, {code: 302}, {code: 307}, {code: 308}), 'is a "moved" response');

(There's a good chance that patroon offers a better way to do this, but it should show what I mean.)

---

when it comes to the function signature it might be worth to offer a simpler patroon function for creating predicates.

I still haven't downloaded and played with this, only looked at your docs, but I thought that this was supposed to be a pattern matcher on its own. Such a predicate generator would certainly be useful in places, but that seems like a very different goal than I thought this library had.

[bas080]

If an any helper would exist you could write it more dry.

patroon({code: any(301, 302, 307, 308)}, 'is a "moved" response')

Agreed that just a predicate function would be too different to what patroon set out to be and that it is useful to offer it as a utility to play nice with fp libraries.

To sum up some of the ideas in this thread:

• Multi dispatch with something called an args helper.
• Matching when all patterns match with an all helper.
• Matching when any pattern matches.
• Make function signature of patroon similar to Ramda's cond.
• Remove typed helper because it can be replaced with Ramda's is function and an all in case of matching on properties.
• Keep ref helper but add an alias named reference.
• Patroon predicate utility.

[bas080]

So I have started a implementing some feedback and the first thing I did is to get rid of the typed helper and replace it with the every helper:

https://github.com/bas080/patroon/tree/remove-typed-helper#types

I have also added the some helper already because that seems useful too.

[bas080]

Next I want to work on the args helper and wait a little for your feedback on the before mentioned changes.

Finally I'll change the patroon function signature to better support point free programming.

[bas080]

So instead of naming it args I went for multi. It's part of the same PR but a different commit.

Although I have deviated from the summary of action points, I think it turned out just fine and has the core changes discussed in this issue.

#5