> Sorry that I did not comment earlier: this kind of change is
> very dangerous. Namely, it can work quite nice in testing
> and then lead to error say 3 years later. The point is
> that there is correspondence between FriCAS types and
> Lisp representation. Part of this correspondence are
> known to Spad compiler and (via declarations) transmited to
> Lisp compiler. So Lisp compiler is told that effectively
> Record never is NIL. Breaking this can lead to nasty
> errors when valid optimization is breaking "working" code.
Another way to look at this "use NIL to represent empty tree"
problem:
We disallow the existence of empty tree.
1. Empty tree is not required by the definition of tree.
2. You can not construct an empty tree from existing
and future operations of Tree:
For example, "delete a node from tree" is not well defined:
you can not delete the root node (you can delete a child though).
So for the domain Tree, we can avoid this problem by
empty() == error "There is no empty aggregate in domain Tree"
empty? t == false
Can I commit the patch that uses this approach?
--
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.
