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
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]
S05 and S29 may conflict on behavior of $string.match(/pat/)
I'm trying to pin down what $string.match(/pat/) should be returning. From S05: Under Return values from match objects A match always returns a Match object... From S29: Under the definition of Str.comb Saying $string.comb(/pat/, $n) is equivalent to $string.match(rx:global:x(0..$n):c/pat/) [ ...and later... ] If there are captures in the pattern, a list of Match objects (one per match) is returned instead of strings. Which implies that $string.match(/pat/) should indeed return a List of Str and $string.match(/pat_with_groups/) should return a List of Match. I expected the S29 definition when first approaching $string.match I feel it is more intuitive than what happens with S05. Could someone clarify what the behavior should be? Best Regards, -Chris Davaz
Re: S05 and S29 may conflict on behavior of $string.match(/pat/)
Thanks for clarifying however I'm still unsure what a Perl 6 user should expect to get back from running $string.match(/pat/). This is the one high-level call to the .match method yes? So it should be returning a List of Str (or List of Match in case of capture groups), is this correct? I ask because in the current Rakudo implementation it returns the Match object (what I would expect from the one low-level run of the regex engine). Best Regards, -Chris On Thu, Sep 18, 2008 at 11:52 PM, Larry Wall [EMAIL PROTECTED] wrote: On Thu, Sep 18, 2008 at 06:11:45PM +0800, Chris Davaz wrote: : I'm trying to pin down what $string.match(/pat/) should be returning. : : From S05: : : Under Return values from match objects : A match always returns a Match object... : : From S29: : : Under the definition of Str.comb : : Saying : : $string.comb(/pat/, $n) : : is equivalent to : : $string.match(rx:global:x(0..$n):c/pat/) : : [ ...and later... ] : : If there are captures in the pattern, a list of Match objects (one : per match) is returned instead of strings. : : Which implies that $string.match(/pat/) should indeed return a List of : Str and $string.match(/pat_with_groups/) should return a List of : Match. : : I expected the S29 definition when first approaching $string.match I : feel it is more intuitive than what happens with S05. Could someone : clarify what the behavior should be? S05 is using a different definition of match. In S05 it means more like one low-level run of the regex engine rather than one high-level call to the .match method. In other words, the .match method can do multiple matches. Larry
Chained Modifiers
-> Chained Modifiers perl6-language -- Thread -- -- Date -- <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Chained Modifiers Chris Davaz Re: Chained Modifiers Moritz Lenz Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Chained Modifiers Chris Davaz Re: Chained Modifiers Larry Wall Reply via email to
