Dear All,
I want to add my testimony about this as a user of the framework.
> What really bothers me with the ticket is the reliance on implicit magic
> over explicitly specifying relations between categories. From the ticket,
> this example:
> The theory here is that Sets defines a Finite axiom, and by some metaclass
> magic the inner class Cs.Finite ends up being a subcategory of Sets.Finite.
> [...]
> Nicolas thinks this amount of breverity is a desirable feature, and I think
> we should make Cs.Finite be explicit about which axiom it implements (and,
> therefore, not require that it is named Cs.Finite if you don't want
> to).
I completely second Nicolas on that point. There is a clash between Python's
"explicit is better that implicit"
and mathematical usage. I really think that what's allows us to do
mathematics, is *context*, that is implicit. Otherwise any mathematical proof,
reasoning or computation is just too verbose. I also think that this unique
point is what's makes writing mathematical software hard. Please think about
what's implicitly done for example when I write:
sage: K.<x> = PolynomialRing(PolynomialRing(QQ, 'y'), 'x')
sage: x + 1
x + 1
Hum what's the meaning of '1' here ?
Anyway, category (as its mathematical meaning) are part of this huge context
which comes with any mathematical computation.
Now going back to Sage, I really think that if we don't keep the syntax *as
short as possible* (as in math: `let's G1, G2 be a finite commutative group
and Phi be a morphism from G1 to G2`) then this will be much to verbose to be
programmed with and each user will start to makes it's own shortcut which is
much worse.
I should also note that each other CAS which developed such a similar thing
(eg. Magma, Axiom, MuPAD) relies on the Compiler/Interpreter -- that is
language magic -- to implement the feature. I think its good to be in Python
which is not a specific build language for a CAS but which should also add the
necessary magic to Python to be able to do maths easily without the burden of
syntax. As soon as sufficiently developers know the inside magic, my
experience tells me that the user doesn't care.
> We've explored various ways to implement this syntax, either through
> inheritance or a class attribute, but Nicolas doesn't like any. Nicolas
> keeps saying that we can change the syntax later, but I think that should be
> done right or not at all on this ticket (one can easily implement the axiom
> functionality without introducing the subclass syntax).
The only drawback I personally see with this subclass syntax is the
documentation.
So I'm really tempted to vote for inclusion right now. I think people *other
than the one involved in the ticket* should express themselves before we start
counting votes.
Cheers,
Florent
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
