I've created a trac ticket. http://www.sagemath.org:9002/sage_trac/ticket/702
On Sep 20, 2007, at 12:43 AM, Robert Bradshaw wrote: > > On Sep 19, 2007, at 11:48 PM, Nick Alexander wrote: > >> On 19-Sep-07, at 8:09 PM, William Stein wrote: >> >>> >>> On 9/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >>>> I am rather fond of the '..' operator, though I can see why people >>>> wouldn't want to add it as an official part of sage. This got >>>> me to >>> >>> I think the decision about whether or not to include something like >>> this is definitely not decided yet. I personally also really like >>> the >>> [a..b] notation, since I really enjoyed using it in Magma, and I >>> think perhaps the complaints about 0 or 1-based are misplaced, >>> because with the [a..b] notation one is being completely explicit >>> about the lower endpoint. Also, the closed brackets very very >>> very strongly suggest "include the endpoint", like the do in >>> standard >>> mathematical notation. Also, I was not convinced that preparsing >>> [a..b] is not possible in general (though Nick was worried about >>> this).\ >> >> It's not that it's not possible, it's that soon you have to parse >> arbitrary python code, or accept that you can break the preprocessor. > > I think in this case we don't have to use any python semantics. > >>> I am going to wait a while to see what brews up, even though >>> the majority vote was against [a..b]. >>> >>> At a minimum I would like to implement that for the preparser (or >>> have somebody else do so), and see what it feels like to use in >>> practice >>> in Sage. >> >> I think tomorrow I will do this, and perhaps refactor the preparser >> slightly while I am there. > > I've actually already started doing this (almost done). Refactoring > the preparser is very needed though, and perhaps another > implementation to play with would be good. Sorry, should have posted > that I was working on this. > >> It seems like we should be able to use >> open and half open intervals, so not only >> [1..2] and (0..3) are valid but also are [0..2) and (0..2] are. > > The half-open idea is an interesting one, but unbalanced ()'s and > []'s in code hurts my eyes. > >> In >> fact, I will try to specify an encoding to range that allows for >> something like >> >> [0, 2, .. 8) which should be [0, 2, 4, 6] by my calculation. > > I was thinking this too, must be a good idea :-). > >> As for iterators versus lists, I favour distinct notations for >> distinct ideas. Perhaps <[ and )>? I don't know. > > I think using [] to specify lists is clean and pythonic. We are > basically extending the grammar > > list_display ::= > "[" [listmaker] "]" > > by making a new kind of listmaker (currently listmaker is a comma- > separated list of expressions or a list comprehension). I think the > symmetry of [1,2, .., 5] == [1,2,3,4,5] is good too. > > As for iterators, Python uses ()'s to make iterators (as well as > tuples). So (1,2,...,5) != (1,2,3,4,5), but "for i in (1,2,...,5)" > would act exactly the same as "for i in (1,2,3,4,5)". > > - Robert > > > --~--~---------~--~----~------------~-------~--~----~ 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/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
