Ralf Hemmecke wrote:
>
> Waldek,
>
> > I think we need to look at the problem more carefuly. Basic question
> > is why the tests worked before your change. It is possible (and in
> > fact quite likely) that interpreter got it right "by accident", then
> > adding package calling is a resonable solution. But it is also
> > possible that your change broke some of assumptions hardcoded in
> > the interpreter, then adding package call would just mask deeper
> > problem.
>
> I hope, you agree, that my commits *fixed* a bug in the source code.
>
> Now whether package calling masks or doesn't mask a problem in the
> interpreter or of some assumption, is a matter of putting a link to this
> thread into the bugtracker. The interpreter problem is there with or
> without my commits.
>
> My suggestion is to also commit the package-calling patch and don't let
> the release be delayed by a long search in the interpreter details. I
> think that search must be done carefully and will probably cost you more
> time than you planned for 1.1.6.
I have now resonably good idea what the problem is: basically
interpreter support for functions in type parameters is very
limited, basically intepreter can not see that the type
with concrete values (which is obtained after evaluation)
is equal to type containing functions inside. The second
case case occurs naturally during typechecking. Bad news
is that it will take some time to fix. OTOH the breakege
is that instead of type that interpreter can handle we
got type which is unhandled. Given that there is workaraund
using package call I think that we can keep your fixes and
update ideal.input.pamphlet to use package call (so that
test pass). But we also need a test for this kind of call,
that is new bugs2012 file and a short test marked as
expected failure.
More generaly, if a fix triggers a problem we need to think
twice before commiting a fix, even if core reason of the new
problem is outside of the fix. Simply, type discipline is
to get more reliable code at the end. If we allow breakage
to get in at the end of day it may happen that our "better"
code actually works worse than original. Note also that
broken code is harder to test, so more breakage is likely
to follow because of limited testing.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
