oldk1331 wrote:
>
> On Sun, Dec 16, 2018 at 3:07 AM Waldek Hebisch <[email protected]>
> wrote:
> > Well, in FriCAS tree is an aggregate. And empty aggregate
> > is always legal. In fact, empty aggregate is a generic
> > way to start building an aggregate. So disallowing it
> > does not look right.
>
> For Tree, can I commit the patch with:
>
> empty_tree := [NIL$Lisp, []]
> empty() == empty_tree
> empty? t == eq?(t, empty_tree)
Well, the 'empty_tree' still has representation which does not
agree with type. Admitedly, it is unlikely to cause trouble
due to optimizations, but for example means that we can not
tighten typechecking. For me still looks like bad deal:
unclean code for improvement in memory use of rarely used type.
> I still don't think "empty()" is essential to aggregate.
> It is useful sometimes to define aggregate with fixed size,
> for such aggregate, "empty()" is illegal.
Well, FriCAS tries to have uniform view of various data
structures. No wonder that in specific cases fit is not
so great. I take it as resonable price for generality.
Now in more detail: clearly empty list is essential to lists.
Empty vectors are also essential. In recursive fromulation
of binary trees empty tree is essential (it give base for
recursion). So clearly 'empty()' should be at level of
aggregates. One could try to split things like having
MaybeEmptyAggregate which exports 'empty()' and general
Aggregate without 'empty()'. But such splits tends to
cascade, so there is work in working out consequences,
adapting code and so on.
--
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.
