> 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 fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to