Why do you need two combining combinators?
Closed this issue · 4 comments
Why not
(</>) : : Path reference To Directory -> Path Relative To point -> Path reference To point?
Because internally absolute paths defined in reverse order to able to run context-dependent calculations. So, for absolute paths we have parent function.
Hmm.. I'm not sure I understand. You are talking about the implementation, which has to be different because of the different representation. But my point was mainly about the type: types of both operations can be unified, and they essentially do the same thing, so maybe it should be one operation after all. Then, of course, you will have to be able to somehow define different implementations... maybe using type class, or maybe making Path a GADT, so you could do case analysis on it.
PS Sorry, I've messed the notation, since I was trying to reply to your blog post (BTW, reply function in the blog seems non-functional) and then found the actual code has slightly different types...
Okay, I think I understand what are you trying to explain: why do we need many combinators instead of just one.
Imagine that you have to read some code that the other person wrote: blah <^> blablah. And you instantly understand: "Aha, here is merging two relative paths". Or: h <~/> sources: "Here is merging home path and some homeward path and the result is absolute path". It's not possible to understand such things with only one combinator.
So, the main reason to have different combinators not only in different implementation, but for readability too. Yes, you have to remember three combinators instead of one, but I hope it will reduce code ambiguity.
Ok, so that was the design choice. It's just from the blog post it looked like you actually needed two combinators to allow only reasonable combinations of Ref and Point so I wanted to point out the same can also be achieved with just one. Never mind.
I'm closing this issue then.