On Wed, Mar 11, 2009 at 12:15 PM, Georg S. Weber wrote: > On 11 Mrz., 14:06, Bill Page wrote: > >> I think the new coercion model in Sage is much too aggressive - >> especially as applied when coding. As Ralf said: perhaps it makes >> sense for interactive use. Would it be possible to enable/disable some >> features dynamically? >> > > -1 > ... > > It definitely should be in general as generously as possible. If at > some local place this is not wanted, one always can make the > local code to be stricter, e.g. by explicitly asking whether > "x.parent() = P" (4 above) or any other of the means mentioned > (points 1 - 3). > > But if the coercion model would be strict in general, it would hardly > be possible to "widen" it again by any local means, if so desired ... >
I don't see any technical problem with the idea of enabling/disabling specific kinds of coercions. One could easily add some kind of decorator to the Python code, e.g. @strict_coercions ... > From the point of view of code quality, the above story about infinite > Weyl groups sounds to me that now, that code is better than before. > I.e. it would work seamlessly whether the coercion model would be > strict or not-so-strict as it is now. This clearly is a sign of greater > robustness, and of the programmer having stated more precisely > what the code really is supposed to do (and what not). > > Yeah, this might render writing new code more time-consuming. > The point is not that it is time-consuming per se, but rather that it is error-prone, i.e. time spent debugging versus time spent coding. How much of the work of ensuring "correctness" do you want the type system to do versus how much testing will be required later? > But it is well worth the effort! I mean, as a general rule, the "sum > of all work" is always the same. If you shift away work from "local" > programming, this only means that the complexity of the general > framework would increase, and more work would have to be done > there. More precisely, one would end up in the general framework > with a jungle of if-else-cascades to catch each and every exceptional > case, where some "different-to-norm" behaviour is desired. In the end > the general framework would become unmaintainable. > I am sorry, I do not understand what you mean by the above. > ... > And also a clear "please not!" from my side to any differences in the > behaviour in "library mode" versus "interactive mode". To the contrary, > this is, and should be, a basic principle to be relied on, that the > behaviour is as identical as possible! I want to write code, too, but > without such an extra dimension of complexity to be taken care of > during testing, experimenting, and so on. > I am just talking about optionally disabling certain coercions in designated segments of Python code, thus requiring/enabling the programmer to be more explicit in certain cases and allowing the type system to catch more potential errors. Regards, Bill Page. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
