Ralf Hemmecke wrote:
>
> As I said above, since there is a simple workaround, I can live with the
> restriction for the moment.
>
> I don't, however, think that this restriction of the SPAD compiler
> should stay forever. I am not aware that any language specification says
> that having two implementations of functions with the same name (and
> different type) and exporting only one of them should be impossible.
>
I made a little investigation and the result is: currently
overloading of local functions is not supported (it sometimes
works by accident). Given that it is natural to insist that
there is no overloading between exported functions and local
ones.
IIRC I have noticed this lack of overloading in the past and
it did not look for me as big deal (after all, in most cases
renaming local functions is not problematic). Recently I met
cases where overloading for local functions would help. So
now I think that it would be good to support it. Once
such overloading of local functions is implemented current
local or exported restriction could be lifted. However,
this does not look like small change to Spad compiler and
will take some time.
--
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.