[groovy-dev] Ranges
I apologize if this is a known-issue, but I couldn't find an open issue for it.
On 1.5.4., ranges don't seem to work very well for a few reasons:
1) "4.5 in (4.0..6.0)" evaluates to false, probably because non-integer ranges are ObjectRanges.
2) It seems like all the ranges create a list of iterative objects inside of them, so the above check fails. I was using a 0..1000000 range, and IntelliJ kept crashing when trying to call toString() on it (although sometimes the toString() method seems to work properly, other times it has acted like toListString(); I'm not sure why). IntelliJ's debugger showed one million java.lang.Integers in the ObjectRange.
3) Aside from memory issues, the big ranges tend to cause performance problems too. For example,
def a = 10.0..1000000.0
"2.2 in a" evaluates with a noticeable delay (although "2.0 in a" is quick). This seems to be O(n), maybe we could use a binary search on Comparable objects for better performance here?
4) It would also be really cool to have an infinite value, so ranges without upper or lower bounds could be dealt with normally and not as special cases. e.g.,
-inf..10
24..inf
...or something like that. I'm not sure exactly what is possible with DSLs, though.
5) Fractions in IntRanges also evaluate to false. e.g.,
3.0 in 2..5 == false
It seems to me that we need a range implementation for floats and BigDecimals? Or maybe something is just broken? I'd be happy to try and implement the above changes, but it would be my first time committing to any sort of programming language, so I can't make any promises on timeliness or efficacy.
-Grant
>
>> There is also another advantage and that is the usage of this kind of
>> string in expressions:
>>
>> def greeting = $"
>> hello, $name
>> "$.trim()
>>
>> The heredoc I suggested above (not the <<(<) version) does work in
>> assignments, declarations and method calls, but you can not make it
>> part of a path expression
>>
>>>> this way anything that follows $' can be used, not only identifiers.
>>>> I would also reduce the four variants to two, because we already
>>>> have ''' and """.
>>>
>>> That is reasonable but gives us reduced flexibility in that we couldn't
>>> do special first/last line handling and couldn't have ''' or """ in such
>>> strings.
>>
>> the question is if that is needed.
>
> For me, this is certainly in the diminishing returns category.
>
>>>> These two would both not support java escaping (\n is "\\n") and
>>>> would be different only in allowing GStrings or not. And then it
>>>> seems logical to do $" (with GString) and $' without.. maybe I would
>>>> use /' and /" instead to let it more look like the slashy string but
>>>> that seems not to have any value of recognition, but it is the same
>>>> for me with $' I am more used to << for here docs.... meaning <<'
>>>> and <<" or << and <<<. of course then a here doc can not be used in
>>>> a method call without parentheses, but that shouldn't be much of a
>>>> deficit.
>>>
>>> I guess all of these are possible - though some look a little
>>> troublesome
>>> to me. I guess the proposals as they currently stand try to keep the
>>> current flavor of Groovy strings as much as possible rather than try
>>> to mimic PERL (or another language) implementation of here docs.
>>
>> true, but the usage of << is very common and has a value of
>> recognition, that is very important. the $', $", $/, $< versions have
>> an optical clush with GStrings. of course they are not, but they look
>> a bit like them, especially with an identifier. Also it seems only
>> Powershell has stringsthat look a bit like that. Perl, PHP, most Unix
>> shells and Ruby do use <<. Python uses this r notation, that we can
>> not rally use, because it clashes with a method call. but again, this
>> is syntax, we need to concentrate on functionality first
>
> Yes, I certainly have no problem if we have only 1 or 2 here docs
> variations with using one of your suggestions. The previous choices
> were to mentally link back to single line variations to make it easy
> to remember what escaping and GString handling would be in place
> but if we are not going with all 4 variations, then another scheme
> makes sense.
>
>> bye blackdrag
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> 
)
>
> * I don't think it would affect JetGroovy, as they use flex and a
> custom parser, it may have
> a knock effect for the Eclipse plugin and Netbeans plugin, not sure...
>
> * APP obviously would need a good going over too...
>
>
>> so what kind of policy should we have here? Jez, your parts are affected
>> too, maybe you want to say something.
>>
>
> Well this kind of change doesn't affect the usage of the groovy grammer by our
> beloved users, it also is hidden (mostly) from the runtime once it has
> been laundered
> and mutated by the AntlrParserPlugin into the AST, so it is fairly
> clean at both ends.
>
Not anymore when there is a new ParenthesisedExpression. This might be a
disadvantage.
> I'd certainly suggest we add these features to the CST one at a time,
> and ensuring we
> catch all the ripples in CST traversals, visitors and APP.
>
>
We agree to that too. Is it also possible to have these features in the
AST? In this case, some visiors would need to be adapted.
martin
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
RSS Feed