Curves and rr spaces

[HechtiDerLachs]

This is a draft branch to discuss the following.

@JHanselman suggested that it would be good to introduce further concrete types for more sophisticated schemes with extra structure, such as, for instance, elliptic curves. Since Julia does not feature inheritance, we have to find a way to mimic that. This is a prototype for a solution of this.

I introduced a new abstract type AbsSpec between our concrete type Spec and its abstract parent Scheme. We now have to discuss what precisely should be part of the minimal interface of AbsSpec.

Then, any concrete new type MyNewAffineVariety<:AbsSpec is required to implement this interface. One easy solution is, to store the underlying scheme of the basic type Spec internally and just to forward the minimal required getters; see the sample implementation in experimental/Schemes/AffineCurve.jl.

But of course, the programmer is free to choose their own solution! Using an instance of Spec internally is not mandatory, in the end. So one could also store the information (F, k, x) where k is a finite extension of QQ, F is an extension of k of transcendence degree 1, and x is a generating variable. Then its up to the programmer to fix the return type of OO via the type getter ring_type and implement the corresponding method of OO.

Do you think this will be suitable for your purposes?

CC: @fieker

Edit: The relevant changes that you should look at are in the last three commits only.

[thofma]

So, this PR here is not for comments on the code right? Because this draft here builds upon #1242?

Ok, that should be no problem. But this should better be discussed on https://github.com/oscar-system/Oscar.jl/pull/1242. Here, I would prefer to restrict to the discussion of how something like inheritance can be achieved in Oscar.

Yes, there is no inheritance. It needs to be spelled out what the interface for AbsSpec is and then it needs to be implemented. If it is just something + additional data, then yes, the functions can just be forwarded.

Or is the discussion about the specific interface for AbsSpec?

[HechtiDerLachs]

Yes. And: It's about both, spelling out the interface for the abstract type AbsSpec and the potential internal use of the accompanying 'minimal concrete type' Spec.

I am wondering: Is such a pair (AbsType, ConcreteMinimalType) common to mimic inheritance in julia? How is this solved at other places within Oscar? Does such a design lead to any severe contradiction or is it an accepted 'Oscar-way' of doing things?

[thofma]

Due to its design, julia encourages composition over inheritance (this is not something julia specific, but inhertiance vs. composition is a more general discussion, see the "COMPOSITION VS INHERITANCE" section in https://thewinnower.com/papers/9319-type-dispatch-design-post-object-oriented-programming-for-julia). So if one has a concrete type S and wants to add more things to it, one introduces S <: Sabstract and then Senhanded <: Sabstract via composition. This is idiomatic julia code. There is some boilerplate code that one has to write, but it is okayish in most cases. Whether one does composition by doing

struct Senhanced
  s::S
  z # more data
end

or by flattening

struct Senhanced
  x # corresponding to field x of S
  y # corresponding to field y of S
  z # more data
end

is a matter of taste.

This composition approach is done for example with the graded multivariate polynomial rings, which are just ordinary multivariate polynomial rings composed with the information for the grading. Then enough functionality is forwarded to satisfy the ring interface.

Since we cannot model all mathematical properties within the type hierarchy anyway, these composition/inheritance question do not pop up too often and then there is usual just one interface at the top to be satisfied (e.g. the Ring interface in the multivariate example).

Regarding the specific interface for AbsSpec, maybe it would be easier to spell it out here. Then one does not have to dig through the diff to find the proposed interface.

[HechtiDerLachs]

Thanks for the explanation.

The interface so far is spelled out in the source code here. (Sorry, I didn't find how to link a specific line of that file, but it's in the very beginning.)

So what I take from your remarks is: We are good to go with this approach?

[fingolfin]

There are 250 commits here and lots of conflicts. What's going on?