EC symbolic

[echatav]

Change the Point type and friends so that they may support Symbolic computation.

Resolves #400

[vks4git]

Awesome! RebindableSyntax is such a nice touch

[TurtlePU]

Why did this instance have to be moved?

[echatav]

Hmmm, it might not have to have been. I had a cycle at one point but not sure if this in fact solved it or something else.

[TurtlePU]

Really like the way elliptic curve API changed! So clean and polymorphic now

Hope we will sort the stuff with Conditional/Eq/Ord out so that modules in Base do not depend on Symbolic, just rubs me the wrong way...

[echatav]

Hope we will sort the stuff with Conditional/Eq/Ord out so that modules in Base do not depend on Symbolic, just rubs me the wrong way...

I agree. Conceptually the BoolType/Conditional/Eq/Ord hierarchy I believe belong in Base since they are "polymorphic" across Haskell & Symbolic. I don't know if all dependencies can be cut (it may be possible) but at least organizationally, it makes sense to move/reorganize these modules.

[TurtlePU]

(Though I still believe that we should have Symbolic-specific versions of Eq and Ord classes for a cleaner API for Symbolic users who are not involved in language-polymorphic stuff)

[echatav]

^ I think this is best handled by re-exporting and properly documenting in friendly ways these terms and others in a Symbolic.Prelude. The logical classes are similar to the algebraic classes in that users of Symbolic should be able to use them seamlessly whether they know they also work in Haskell too.

[TurtlePU]

Well, I'm only concerned about Symbolic functions which are polymorphic in datatypes. Take an example like this:

find :: a -> Vector n a -> Maybe c (UInt k r c)

What should the constraints look like?

With language-agnostic Eq

find :: (Symbolic c, SymbolicData a, Context a ~ c, Support a ~ Proxy c, Eq a, BooleanOf a ~ Bool c) => a -> Vector n a -> Maybe c (UInt k r c)

With Symbolic-specific Eq

class SymbolicData a => Eq a where
  (==) :: a -> a -> Bool (Context a)

find :: (Eq a, Context a ~ c) => a -> Vector n a -> Maybe c (UInt k r c)

P.S. We can introduce type aliases however we want, sure, but the real interface the user is going to interact with are compiler errors, and usually type aliases are not present there

P.P.S. Also good point about similarity to algebraic classes, though I think algebraic classes have advantage of behaving pretty much the same as usual Haskell, and BooleanOf a is not usual Haskell