Add partial applicative typeclass functions

[lmbollen]

We currently have functions like .==. that can operate on Signals. However, I find myself often writing .foo. pure bar when comparing signals to constants.

With these changes(inspired by @gergoerdi's retrocomputing lib) we can write .foo bar instead.

Still TODO:

• Determine if there are more operators we'd like to add signal functions for.
• Write a changelog entry (see changelog/README.md)
• Check copyright notices are up to date in edited files

[martijnbastiaan]

This makes sense to me. Can we also get (.&&), (&&.), (.||), (||.)? That seems to cover all the operators we export. Are you interested in moving this out of draft @lmbollen?

Edit: What does bother me a little bit is that we use both . for signal lifting (like in this PR) and for BitVector operations (like +>>.).

[DigitalBrains1]

The commit details for the first commit say:

We already have the ' .foo.' pattern for these typeclasses.
However, you often have to use '.foo . pure bar' if 'bar' is a constant.
After this change, you can use '.foo bar' instead.

Note the stray space between .foo and . pure bar.

And a bit nitpicky, the commit summary goes over the 50-char limit of the 50/72 rule. I didn't count the characters, I noticed the GitHub website UI cut off the summary: 24d7979

[edit]
I also suspect you were going for Markdown formatting when you included single quotes in the commit message, but in that case you probably meant backticks. All these formatting languages... :-S
[/edit]

[edit 2]
According to this blogpost the ellipsis only shows when the summary goes over 72. I feel more than 72 truly is too long.
[/edit 2]

[lmbollen]

Are you interested in moving this out of draft @lmbollen?
Yeah I'd really like to have these operators. I hope to be able to update the PR soon.

Edit: What does bother me a little bit is that we use both . for signal lifting (like in this PR) and for BitVector operations (like +>>.).

Yes, though I feel the . is more useful as a lifting indicator since it can be applied a lot more..
For BitVector we only have .<<+ and +>>. which are derived from their Vector counterparts <<+ and +>>

[martijnbastiaan]

Yeah, I guess my comment wasn't really directed at this PR. I was merely pointing out the fact that +>>. is ambiguous: is it +>> lifted over Signal, or is it the BitVector version? We should probably think of an alternative notation for the latter..

[DigitalBrains1]

I agree in principle, but the whole problem with these comic book swear words is that even if you think of a rigorous structure and apply it, it will always feel random without a full explanation of why . means A and ^ means B because the common real-world meaning of the glyph is usually not in any way connected to how you use it. The meaning of the dot punctuation, in most Roman languages, is that it ends a sentence. Three of them form an ellipsis... and so on. We just lift it to mean lifting. Heh.

[DigitalBrains1]

We could just call them bitShiftInL and bitShiftInR and use them as

x `bitShiftInR` y

[martijnbastiaan]

LGTM modulo missing exports and a CI breakage :)