At some point we will need a summary, or to use something better than
mailing lists to discuss this.
Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 9:46 PM, Paul-Olivier Dehaye <
paul-olivier.deh...@math.uzh.ch> wrote:

> >  - Nathann is arguing that no empty methods/classes should be present.
> I think he is, and add Vincent too (cf. previous email of his).
>
> Absolutely noone wants unefficient code. If there is a clear way to
> improve, let's do it. But burden is on all of us.
>
> To be clear, I want to have this semantic information in the code.
>
> There are many reasons for this, here is one more: it provides an
> intermediate step for a person joining sage between a typo fix and
> implementing their first function, welcoming microcontributions. I think
> decorators would be very suitable for this, but am open to alternate
> suggestions.
>
> > Would this be a short-term solution?
> Sure!
>
> Paul
>
>
>
>
>
> Paul-Olivier Dehaye
> SNF Professor of Mathematics
> University of Zurich
> skype: lokami_lokami (preferred)
> phone: +41 76 407 57 96
> chat: pauloliv...@gmail.com
> twitter: podehaye
> freenode irc: pdehaye
>
>
> On Wed, May 28, 2014 at 8:47 PM, Simon King <simon.k...@uni-jena.de>wrote:
>
>> Hi Paul,
>>
>> On 2014-05-28, Paul-Olivier Dehaye <paul-olivier.deh...@math.uzh.ch>
>> wrote:
>> > Two comments:
>> >  - Nathann is arguing that no empty methods/classes should be present.
>>
>> Is he? Sorry, then this is a point where Nathann and I do not agree. I
>> find abstract methods useful. I thought that his main point was: Don't
>> be intrusive! Do not make code of some people slower just because other
>> people care about the mathematical properties of some methods. And from
>> my perspective, the discussion is (or should be) only about the
>> question: How to care about the mathematical properties without slowing
>> down other peoples code.
>>
>> >  - They are not building a database. They are putting tags in the code
>> that
>> > allow them at runtime to build something that amounts to a database.
>> It's
>> > not that different to the category framework in some way, which is
>> encoding
>> > a lot of data via code constructions
>>
>> There was in fact some discussion at #10963 about the question whether it
>> is
>> a good idea that the new category-with-axiom framework encodes a
>> fully-grown
>> would-be-database (by this, I mean something that amounts to a database)
>> by
>> purely local data and naming conventions.
>>
>> I'd say: If they are putting tags in the code then they *do* create a
>> (would-be-)database, whether they want it or not.
>>
>> > I am not arguing that what findstat does with a decorator is the best. A
>> > flagged decorator that does nothing most of the time is better than what
>> > they do. But a full-on database is, as a short term solution, heading in
>> > the wrong direction.
>>
>> Do I understand correctly: You would not like that the
>> @combinatorial_map decorator constructs a database at startup time? I
>> think that's a valid concern.
>>
>> We could try to be clever and introduce an environment variable (or
>> commandline argument) such that @combinatorial_map creates a database
>> when this variable is set, and otherwise does nothing at all.
>>
>> Hence, people who care about the implicit would-be-database encoded in
>> the flags could obtain them by explicit request, and all other people
>> would not be affected at all.
>>
>> Would this be a short-term solution? Also from Nathann's perspective?
>>
>> Cheers,
>> Simon
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-combinat-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sage-combinat-devel+unsubscr...@googlegroups.com.
>> To post to this group, send email to sage-combinat-de...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/sage-combinat-devel.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.

Reply via email to