[prev in list] [next in list] [prev in thread] [next in thread] 

List:       groovy-dev
Subject:    RE: [groovy-dev] Maths / Math, literals and boxing
From:       "LARSON, BRIAN \(SBCSI\)" <bl7385 () sbc ! com>
Date:       2005-01-25 14:02:13
Message-ID: 497F0C480CE3674192730F81E792441970C6F6 () MOSTLS1MSGUSR15 ! ITServices ! sbc ! com
[Download RAW message or body]

Russel Winder said:
>I hope you are now getting over the infection.
Almost, thanks.

On why Integer instead of BigInteger:
>I can see where this is going and I have to admit it seems fair and
>reasonable.  I think perhaps this rational needs to be made more
>explicit in the documentation.  I will try altering the pages to
achieve
>this.

Ok.  I was thinking that I might document the "why" in the JSR decisions
page.  I'm not sure it would be helpful to a typical user trying to
learn
The language.  It seems that it might just make it harder to find what
they really need.  Maybe a link on the GLS page to the decisions page.

> >The literal modifier G is used for both BigInteger and BigDecimal
...
>Hummmm.... I still think there should be two modifiers, one for
>BigInteger and one for BigDecimal.  Would it be outrageous to propose
>reopening the debate on this one point which is small but shouldn't
take
>up much time.

I don't mind discussing an alternative to G for both.
For me, probably the most important thing is making it natural and
easy to remember.  If you have a proposal, I think it should probably
be on the jsr list.

>> I used the "(optional)" syntax because of the limitations of
formatting
>> with the wiki and to be similar to the JLS (on which it is based).
>>=20
>> I think any grammar confusion will be solved by the effort to define
it
>> in antlr.  I'm trying to learn antlr now and analyze the new groovy.g
>> that jez and john rose put all their hard work into.

>Hummm..... I'll have a think about this.  I do not find the (optional)
>annotation particularly easy to read.  The JLS uses subscript
>annotations which is a lot better but I take it that subscripts are not
>possible using the wiki markup.

I agree it's a little hard to read. It was, AFAIK, a limitation of
the old wiki.  It looks like it could be improved with the new wiki
which does support subscript (although not within {code}).
At the time (in March-April), I was pleased with myself for documenting
a
semi-formal grammar for the tiny scope of numeric literals.

I'm guessing that antlr will be able to produce something which looks
much nicer.

[prev in list] [next in list] [prev in thread] [next in thread]