On 4/1/24 00:27, Waldek Hebisch wrote:
I also saw that it might be possible that fun and/or con could be NIL. I do
not yet see where that could happen, but maybe for those cases the code of
error3 should be different.
Well, the patch is just proof of concept. There are corner cases
which should be handled in reasonable way. Note that initialization of
constructors is outside functions, so there in no function name.
And initialization may signal errors. I am not sure if constructor
can be NIL, that should be investigated before commiting better
version. Also, for nested functions '$op' contains name of surrounding
function. In case of anonymous functions we have no name. That
should be handled in some way.
Honestly, I think that cases where con or fun are NIL should not count
as trouble. Even if the patch shows correct fun$con in 80% of the cases
and has some cases where it shows NIL$con or fun$NIL, I would still see
it as progress.
Note that currently there are two legal variants of error, the second
one allowing math formatting. The patch only handles first form, the
second one needs a bit more work.
What exactly do you mean by "math formatting"? The the "error" function
that we speak about allows only one argument which is of type String.
Your comment says that I do not use "error" to its full power.
Seemingly, I have not yet come across such "math formatting" option.
Can you give a pointer.
Ralf
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/c624b4ff-b86b-4da3-9c4a-7f7f0d1f4679%40hemmecke.org.
