oldk1331 wrote:
>
> It will be a big change so it will get into next release
> if this idea get approved. Before that, I'd like some
> comments first.
>
> There are data structure categories that explicitly supports
> cyclic data structure, namely UnaryRecursiveAggregate.
>
> That means the domains from this category will have
> to support cyclic data structure. But for List, the most
> basic data structure, for performance reasons, doesn't
> support cyclic well. And it's possible to have a data structure
> that it's recursive but not cyclic.
>
> So it's reasonable to split cyclic-related functions into
> its own category, and make domains non-cyclic by defalut.
> And implement new domains that support cyclic data
> structure properly.
>
> Comments?
I do not think making List non-cyclic is feasible. Namely
once you allow in-place modification you can create
cyclic structures. Testing that modification does not
create cycles is prohibitivy expensive (after all we
use in-place modification mostly in cases when we care
about speed). Also, if you create new domain for
cyclic lists there will be trouble sharing code with
default case.
Consider for example Streams: they use possibly cyclic
lists as representation. Having two separate functions
which create streams from lists (one from cyclic, the
other from non-cyclic list) looks clumsy.
--
Waldek Hebisch
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
