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/
-~----------~----~----~----~------~----~------~--~---
