RE: Split with negative limits, and other weirdnesses
Hmmm, my understanding was that it stopped *splitting* after the limit, but it
doesn't stop "consuming" the source; rather the entire remainder is returned as
the last item in the list, even if it contains the delimiter. A bit like this:
sub split($pat, $src, $limit) {
@r = split($pat, $src);
return @r[0..$limit-2], join($pat, @r[$limit-1..*]);
}
except of course it works where $pat isn't a string literal, and does sensible
things if $limit is 0 or 1, and is implemented more efficiently.
-Martin
> -Original Message-
> From: Mark J. Reed [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 29, 2008 8:44 AM
> To: Chris Davaz
> Cc: Carl Mäsak; Perl6
> Subject: Re: Split with negative limits, and other weirdnesses
>
> On Sun, Sep 28, 2008 at 11:40 AM, Chris Davaz
> <[EMAIL PROTECTED]> wrote:
> > Ok, so 0 returns the empty list and -1 violates the
> signature? In PIR
> > can we have such signatures that put a constraint on the range of
> > values for a given parameter?
>
> Maybe this has already been proposed and rejected, but why not simply
> define the limit parameter such that
>
> split($pat, $src, $limit)
>
> is equivalent, result-wise, to
>
> split($pat, $src)[0 .. $limit - 1]
>
> ? Of course, the limit-parameter case might be able to avoid some
> work compared to the second, which might not always be able to do its
> job lazily, but the return value would be the same. Then you don't
> have to come up with separate edge case rules for two different
> constructs... the one follows logically from the other.
>
> $limit is 0? @foo[0..-1] is the empty list. Check.
>
> @foo[0..-2] is also the empty list. So negative parameters
> don't need to Fail..
>
> --
> Mark J. Reed <[EMAIL PROTECTED]>
>
---
Have you seen our website? http://www.vodafone.co.nz
Manage Your Account, check your Vodafone Mail and send web2TXT online:
http://www.vodafone.co.nz/myvodafone
CAUTION: This correspondence is confidential and intended for the named
recipient(s) only.
If you are not the named recipient and receive this correspondence in error,
you must not copy,
distribute or take any action in reliance on it and you should delete it from
your system and
notify the sender immediately. Thank you.
Unless otherwise stated, any views or opinions expressed are solely those of
the author and do
not represent those of Vodafone New Zealand Limited.
Vodafone New Zealand Limited
20 Viaduct Harbour Avenue, Private Bag 92161, Auckland 1030
Telephone + 64 9 355 2000
Facsimile + 64 9 355 2001
Re: Split with negative limits, and other weirdnesses
On Mon, Sep 29, 2008 at 9:36 PM, Kealey, Martin, ihug-NZ <[EMAIL PROTECTED]> wrote: > Hmmm, my understanding was that it stopped *splitting* after the limit, but > it doesn't stop "consuming" the source; D'oh, you are of course correct; that is in fact the chief utility of the limit parameter, and I can't believe I misremembered. I was even indignant not too long ago when using some other language/library which had a split that behaved as I described instead of as it does in Perl. Javascript, I believe. Please excuse the cerebroflatulence. -- Mark J. Reed <[EMAIL PROTECTED]>
Re: Split with negative limits, and other weirdnesses
On Sun, Sep 28, 2008 at 11:40 AM, Chris Davaz <[EMAIL PROTECTED]> wrote: > Ok, so 0 returns the empty list and -1 violates the signature? In PIR > can we have such signatures that put a constraint on the range of > values for a given parameter? Maybe this has already been proposed and rejected, but why not simply define the limit parameter such that split($pat, $src, $limit) is equivalent, result-wise, to split($pat, $src)[0 .. $limit - 1] ? Of course, the limit-parameter case might be able to avoid some work compared to the second, which might not always be able to do its job lazily, but the return value would be the same. Then you don't have to come up with separate edge case rules for two different constructs... the one follows logically from the other. $limit is 0? @foo[0..-1] is the empty list. Check. @foo[0..-2] is also the empty list. So negative parameters don't need to Fail.. -- Mark J. Reed <[EMAIL PROTECTED]>
Re: Split with negative limits, and other weirdnesses
Ok, so 0 returns the empty list and -1 violates the signature? In PIR can we have such signatures that put a constraint on the range of values for a given parameter? On Sun, Sep 28, 2008 at 7:25 PM, Carl Mäsak <[EMAIL PROTECTED]> wrote: > Jason (>): >> It makes sense to me to go with option 1; you get what you ask for. It also >> makes sense to make to not use magical implied numbers, such as negatives, >> to accomplish things that either ranges or whatever star can accomplish. > > Aye, agreement. There's a whole lot of consensus already... reading > through the discussion once more, I don't find anyone saying anything > contradicting the above summary. > > Chris, I'm not in a position to provide a final word, but it seems > very possible already to use what has already been said here as a > basis for an implementation. > > // Carl >
Re: Split with negative limits, and other weirdnesses
Jason (>): > It makes sense to me to go with option 1; you get what you ask for. It also > makes sense to make to not use magical implied numbers, such as negatives, > to accomplish things that either ranges or whatever star can accomplish. Aye, agreement. There's a whole lot of consensus already... reading through the discussion once more, I don't find anyone saying anything contradicting the above summary. Chris, I'm not in a position to provide a final word, but it seems very possible already to use what has already been said here as a basis for an implementation. // Carl
Re: Split with negative limits, and other weirdnesses
It makes sense to me to go with option 1; you get what you ask for. It also
makes sense to make to not use magical implied numbers, such as negatives,
to accomplish things that either ranges or whatever star can accomplish.
Just my 2 cents.
-Jason "s1n" Switzer
On Tue, Sep 23, 2008 at 4:27 AM, Moritz Lenz <[EMAIL PROTECTED]>wrote:
> Today a patch to rakudo brought up the question what split() should do
> if the $limit argument is either zero or negative.
>
> In Perl 5 a negative limit means "unlimited", which we don't have to do
> because we have the Whatever star. A limit of 0 is basically ignored.
>
> Here are a few solution I could think of
> 1) A limit of 0 returns the empty list (you want zero items, you get them)
> 2) A limit of 0 fail()s
> 3) non-positive $limit arguments are rejected by the signature (Int
> where { $_ > 0 })
>
Re: Split with negative limits, and other weirdnesses
If someone wants to make the final word on what the behavior should be
I can go ahead and implement it.
On Tue, Sep 23, 2008 at 11:41 PM, Jonathan Scott Duff
<[EMAIL PROTECTED]> wrote:
> On Tue, Sep 23, 2008 at 9:38 AM, TSa <[EMAIL PROTECTED]> wrote:
>
>> HaloO,
>> Moritz Lenz wrote:
>>
>>> In Perl 5 a negative limit means "unlimited", which we don't have to do
>>> because we have the Whatever star.
>>>
>>
>> I like the notion of negative numbers as the other end of infinity.
>> Where infinity here is the length of the split list which can be
>> infinite if split is called on a file handle. So a negative number
>> could be the number of splits to skip from the front of the list.
>> And limits of the form '*-5' would deliver the five last splits.
>>
>
> As another data point, this is the first thing I thought of when I read the
> email regarding negative limits. But then I thought "we're trying to get
> away from so much implicit magic". And I'm not sure the failure mode is loud
> enough when the skip-from-the-front semantics /aren't/ what you want (e.g.,
> when the limit parameter is variable-ish)
>
>
> A limit of 0 is basically ignored.
>>
>> Here are a few solution I could think of
>> 1) A limit of 0 returns the empty list (you want zero items, you get them)
>>
>
> I think this is a nice degenerate case.
>>
>
> Me too.
>
>
> 2) A limit of 0 fail()s
>>
>
> This is a bit too drastic.
>
>
> Indeed.
>
>
>
> 3) non-positive $limit arguments are rejected by the signature (Int
>> where { $_ > 0 })
>>
>
> I think that documents and enforces the common case best. But I would
>> include zero and use a name like UInt that has other uses as well. Are
>> there pragmas that turn signature failures into undef return values?
>>
>>
>> Regards, TSa.
>> --
>>
>> "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
>> "Simplicity does not precede complexity, but follows it." -- A.J. Perlis
>> 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
>>
>
>
> my two cents,
>
> -Scott
>
> --
> Jonathan Scott Duff
> [EMAIL PROTECTED]
>
Re: Split with negative limits, and other weirdnesses
On Tue, Sep 23, 2008 at 9:38 AM, TSa <[EMAIL PROTECTED]> wrote:
> HaloO,
> Moritz Lenz wrote:
>
>> In Perl 5 a negative limit means "unlimited", which we don't have to do
>> because we have the Whatever star.
>>
>
> I like the notion of negative numbers as the other end of infinity.
> Where infinity here is the length of the split list which can be
> infinite if split is called on a file handle. So a negative number
> could be the number of splits to skip from the front of the list.
> And limits of the form '*-5' would deliver the five last splits.
>
As another data point, this is the first thing I thought of when I read the
email regarding negative limits. But then I thought "we're trying to get
away from so much implicit magic". And I'm not sure the failure mode is loud
enough when the skip-from-the-front semantics /aren't/ what you want (e.g.,
when the limit parameter is variable-ish)
A limit of 0 is basically ignored.
>
> Here are a few solution I could think of
> 1) A limit of 0 returns the empty list (you want zero items, you get them)
>
I think this is a nice degenerate case.
>
Me too.
2) A limit of 0 fail()s
>
This is a bit too drastic.
Indeed.
3) non-positive $limit arguments are rejected by the signature (Int
> where { $_ > 0 })
>
I think that documents and enforces the common case best. But I would
> include zero and use a name like UInt that has other uses as well. Are
> there pragmas that turn signature failures into undef return values?
>
>
> Regards, TSa.
> --
>
> "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
> "Simplicity does not precede complexity, but follows it." -- A.J. Perlis
> 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
>
my two cents,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Split with negative limits, and other weirdnesses
On 2008-Sep-23, at 8:38 am, TSa wrote: Moritz Lenz wrote: In Perl 5 a negative limit means "unlimited", which we don't have to do because we have the Whatever star. I like the notion of negative numbers as the other end of infinity. I think positive values and zero make sense. But I don't want to give funny meanings to negatives; it would be better to replace the int limit with a range instead. (Maybe it would be OK to accept a single Int as short for 1..$i, or *-$i as short for *-$i..*.) Then again, we could get rid of the limit arg altogether, return everything, and take a slice of the result -- assuming it can be lazy enough to calculate only what ends up getting sliced out. -David
Re: Split with negative limits, and other weirdnesses
HaloO,
Moritz Lenz wrote:
In Perl 5 a negative limit means "unlimited", which we don't have to do
because we have the Whatever star.
I like the notion of negative numbers as the other end of infinity.
Where infinity here is the length of the split list which can be
infinite if split is called on a file handle. So a negative number
could be the number of splits to skip from the front of the list.
And limits of the form '*-5' would deliver the five last splits.
A limit of 0 is basically ignored.
Here are a few solution I could think of
1) A limit of 0 returns the empty list (you want zero items, you get them)
I think this is a nice degenerate case.
2) A limit of 0 fail()s
This is a bit too drastic.
3) non-positive $limit arguments are rejected by the signature (Int
where { $_ > 0 })
I think that documents and enforces the common case best. But I would
include zero and use a name like UInt that has other uses as well. Are
there pragmas that turn signature failures into undef return values?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
