On Wed, Apr 9, 2008 at 9:52 AM, Gabriel Dos Reis wrote: > ... > The Mapping domain is such that it never itself generates a > `newGoGet' -- it is an old style domain, and its functions are > always resolved when it is instantiated. That is why I was > puzzled and I'm still puzzled that you claim `newGoGet' came > from Mapping. It just does not. Someone else did. >
You are confused. I agree that 'newGoGet' does not come from Mapping. I never said that it did! Can you tell me where you got that impression? If it was from something that I wrote that was unclear, I apologize in advance. > In fact, MyReduce asked for '+' in Integer, and got a stub and passed > that around for Mapping to compare. > That is correct. My claim is that Mapping does not perform this comparison in a reasonable manner. This stub should be fully resolved before attempting a comparison. > ... > What I disagree with is the conclusion you reached. You are mistaken. You disagree with something that is *not* my conclusion. > You may hack up something by messing with replaceGoGetSlot > in Mapping, but I do not think that is right. Why do you think it is not right to resolve the stub in Mapping before comparison? > But hey, so far, we have not been doing science, just > hacking. So, I suspect everything is fair game. > I have no idea what you might or might not call "science" and I fail to see how that is relevant. It is not a game. The only "hack" I provided was applying the operation to dummy arguments, i.e. (0+0)$S to force the stub for the operator '_+$S @ (S,S)->S' to be fully resolved. Applying the operation to any argument affects the outcome of the comparison done in Mapping. This does not make any sense to me. Whether an operation is a stub or fully resolved should not affect the result. The fact that an operation is at some point in the program not yet fully resolved should be transparent to the SPAD programmer. I think the best way to make this so - at least in the case of the function equality provided by Mapping - is simply to resolve it before the comparison. Really this is no different than resolving the function before applying it. I hope you can stay focused on this issue rather than talking about "hacks and science". :-( Regards, Bill Page. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel