"Bill Page" <[EMAIL PROTECTED]> writes: [...]
| I think the second form is better, but I am not sure it is good idea | to force the interpreted language to follow so closely the compiled | language. The interpreter allows a form of definition of functions | that is very different than the compiler. (You did not specify any | types at all in the above input to the interpreter so technically what | you wrote does not even define a function.) By design this is not | possible in the compiler but it is very convenient in the interactive | user interface provided by the interpreter. I agree: interactive sessions, in general, follow different patterns than fleshed out design as in libraries. That is what I referred to earlier as `programming in the small' vs. `programming in the large'. [...] | Could you explain why it is a drawback to have to define external functions? exported functions are part of the interface; sometimes one wants just local routines. Another argument, but less important to my point of view, is implementation detail: Current Spad compilers don't optimize exported functions as they should, compared to local functions. | > And since I adhere to the principle that Integer -> Integer is a type | > just as any other type, I do not see why one would want to make | > a difference there. | | I don't think this issue depends on treating 'Integer->Integer' in any | special manner. It appears that local overloading in SPAD is not | allowed in any case. I think I agree. -- Gaby ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
