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: Why no "is ro"? (Re: Subroutine parameter with trait and default.)
On 2008-Sep-23, at 5:27 pm, Michael G Schwern wrote: David Green wrote: Happily, brevity often aids clarity. The rest of the time, it should be up to one's editor; any editor worth its salt ought to easily auto-complete "ro" into "readonly". Eeep! The "your IDE should write your verbose code for you" argument! For that one, I brine and roast an adorable hamster. Fair enough. As long as you remember to share with the rest of us!! That's just another way of saying that your language is too verbose for a human to write it without hanging themselves. See also Java. But the problem with Java isn't just that it's too verbose to write; it's that it's too verbose to read, too. Why shouldn't your editor help with verbosity? The amount of typing shouldn't be a main concern in language design, because your editor can mostly compensate for that; there are other, better reasons to decide how verbose something should be. Anyhow, I see where you're going, and I understand the desire for no abbvs. But man, "ro" is pretty damn easy to remember. [1] This is even sillier when you hold it up against all the magic symbols we're supposed to remember. [EMAIL PROTECTED], :name, |$arg, $arg!, $arg?, : $arg. As a bear of limited recall, I sometimes feel a bit overwhelmed by all the stuff there is to remember. I'm certainly not against all abbreviations. I have a deeply ingrained instinct to name my variables x, y, and z, and to name files... x, y, and z. My shell profile is full of one-letter aliases (I don't have time to waste typing 2-char command names!). However experience has taught me the value of more robust names for anything but one-liners. I bet we actually don't disagree much; I'm not really against "ro" -- I'm just not against "readonly" because of its length. If I were writing casually, I'd use "rw" and "ro"; formally, I'd use "read only" and "read/write" (or even "readable and writable"). At an in-between level, which is where I believe we should be aiming, I think I'd put "rw" and "read-only". I'm not entirely sure why. Maybe psychologically, "ro" looks like it could be a word, whereas the unpronounceable "rw" has to be an abbreviation? Or maybe it's just because I see "rw" every day in ls output, but "ro" not so much. At any rate, if I wanted to argue in favour of "ro", I think symmetry (which you already mentioned) is the strongest argument. You're only a beginner once, and if everything is done right for a short time. The rest of your career, you're experienced. Ooh, now that I completely agree with! Software that thinks "user- friendly" means "dumbed-down" drives me nuts. -David
Re: Why no "is ro"? (Re: Subroutine parameter with trait and default.)
On 2008 Sep 24, at 17:45, David Green wrote: On 2008-Sep-23, at 5:27 pm, Michael G Schwern wrote: David Green wrote: Happily, brevity often aids clarity. The rest of the time, it should be up to one's editor; any editor worth its salt ought to easily auto-complete "ro" into "readonly". Eeep! The "your IDE should write your verbose code for you" argument! For that one, I brine and roast an adorable hamster. Fair enough. As long as you remember to share with the rest of us!! I would argue that if you need your editor to expand verbose language constructs to make the language usable or to express common idioms, then the language has a design deficiency. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
