> Indexing on list has it good uses and we should not forbid
> it because abuse may lead to slow programs.
We can still have "elt" from elsewhere, like EltableAggregate.
In C++, for std::list, they have "advance", instead of "ls[n]".
> Well, I against tying complexity to types. Types will not
> prevent writing inefficient code. Actually, unnecessary restrictions
> may lead to workarounds which decrease efficiency.
Having complexity constraint is like axioms in catdef.spad,
and those axioms do not prevent writing wrong code. I think
these restrictions will discourage unoptimal usage and lead
to "the right way".
> And any extra type distincion means less opportunity to
> share code, so works against generic coding.
Have you seen my other mail about leftTrim/rightTrim? These
generic functions should have 2 implementations, the default
one is O(n^2) for lists.
And do you think OneDimensionalArrayAggregate should have
UnaryRecursiveAggregate to promote "generic coding"?
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.