koopman@a.gp.cs.cmu.edu (Philip Koopman) (07/05/90)
Now that we all seem to be talking about /, NOT, and compromises again, here is a point to consider: When I was looking for a minimal kernel to port to a new stack CPU design, I got a copy of cmForth to evaluate. I liked the fact that it was small and (probably) easy to port. Then I noticed the following definition: : < - 0< ; This definition only works when the input data are closer than $8000 apart! (I speculate that Chuck did this because the Novix doesn't have an overflow flag, and a "correct" implementation of < is complex). The circumstances of finding the same bug in another Forth cost me a day or so of debugging. Consequently, I rejected out-of-hand cmForth because it had at least one case of correctness determined by input data values (and I didn't want to spend the time to try and find all the others that might be there). My current gut reaction is to reject without further examination any language, system, or implementation that does not work correctly when fed reasonable data sets (especially if not documented to do so for extremely important reasons). I find definitions of the form "works with positive numbers only" scary. How many outsiders share my fears? Remember, even if C does not specify division at a very detailed level, common practice is to use hardware-supplied division, and most (if not all) machines do it the same way. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior scientist at Harris Semiconductor, and adjunct professor at CMU. I don't speak for them, and they don't speak for me.
dwp@willett.UUCP (Doug Philips) (07/13/90)
In <9811@pt.cs.cmu.edu>, koopman@a.gp.cs.cmu.edu (Philip Koopman) writes: > > My current gut reaction is to reject without further examination > any language, system, or implementation that does not work > correctly when fed reasonable data sets (especially if not > documented to do so for extremely important reasons). I am tempted to agree with you here. When you see a system where something as fundamental as < isn't right, it doesn't do much for your confidence in other parts of the system. > I find definitions of the form "works with positive numbers only" > scary. How many outsiders share my fears? Remember, even if > C does not specify division at a very detailed level, common > practice is to use hardware-supplied division, and most (if not > all) machines do it the same way. I think that it is a very honest thing for the language documentors to tell you what the "underlying assumptions" are. That way you stand a much better chance of writing code that won't violate them. In this sense I agree with your decision about cmForth. You had to intuit the brokenness of < by looking at the code. This is just the thing that I also despise. Curiously, though, you seem to find the remedy of specifying the domain and range of the functions to be as bad? This confuses me. Certainly one wants to know that < will simply work, but I would find it much less scary if it were explicitly documented to work for ALL signed numeric arguments, rather than leaving that as an unsupported assumption to be made by the user. Violated assumptions are the hardest things to spot when debugging (at least for me). If they are written down they aren't really assumptions anymore and it is easier to spot the violations. Is it that "works with positive numbers only" is scary because you think that the author is lying, or is it scary because you didn't think it should be necessary to put such a restriction on it? Or am I missing some other reason? -Doug --- Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
koopman@a.gp.cs.cmu.edu (Philip Koopman) (07/14/90)
In article <1326.UUL1.3#5129@willett.UUCP>, dwp@willett.UUCP (Doug Philips) writes: > Is it that "works with positive numbers only" is scary because you > think that the author is lying, or is it scary because you didn't think > it should be necessary to put such a restriction on it? Or am I missing > some other reason? The caveat "works with positive numbers only" is much preferable to undocumented limitations. So, this restriction is not nearly as bad as the cmForth "< bug". However, as an outsider (say, a C programmer) I would not be accustomed to things as basic as division having data restrictions not taught in grade school. If you bought a calculator for $5, would you be upset if it said in the instruction manual that division with negative operands gave unspecified results? Would you even think to look for such a thing? Of course you could try it out and see what it did. But wouldn't such a limitation (if you happened to see it in the manual in the store) make you shy away from purchase out of anxiety over what other limitations (documented or not) you didn't think to look for? I have had several email conversations with Mitch Bradley in which we seem to agree that /MOD should have "reasonable" behavior for negative inputs. For example, one could place restrictions on allowable remainders and quotients. Or, one could simply say that it is equivalent to one of the fully defined divisions (which one might be implementation dependent). BUT, leaving it undefined translates to "broken" in my book. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior scientist at Harris Semiconductor, and adjunct professor at CMU. I don't speak for them, and they don't speak for me.
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/18/90)
In <9898@pt.cs.cmu.edu>, koopman@a.gp.cs.cmu.edu (Philip Koopman) writes: > If you bought a calculator for $5, would you be upset if it said > in the instruction manual that division with negative operands gave > unspecified results? Would you even think to look for such a thing? > Of course you could try it out and see what it did. But wouldn't > such a limitation (if you happened to see it in the manual in > the store) make you shy away from purchase out of anxiety over > what other limitations (documented or not) you didn't think to > look for? Your analogy, while amusing, is flawed. You are implying that the BASIS says *only* that / on negative operands gives unspecified results. You fail to account for the fact that the BASIS *does* give you alternatives. I can't give you a quick come-back calculator analogy for that, but perhaps there just isn't one? > BUT, leaving it undefined translates to "broken" in my book. I get the feeling that "undefined" is being equivocated about here: {/} does something, but we don't know what that is! :-) {/} does what you expect with positive arguments. See vendor's manual for what it does with negative arguments. *OR* use one of the following fully specified words... (Perhaps the complaint is with the structure of the BASIS? I haven't seen it, but I would assume that there would be cross references. (Like the 'SEE ALSO' section of unix man pages)) -Doug ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu