Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • no scalar context, and no local()

    What would you propose as the new idiom for file slurping? (== read an entire small file into a scalar as quickly as possible)

    -matt
    • You could define:

      sub read_entire_file
      {
        my $filename = shift;

        my $f = open(");
        close($f);
        return $text;
      }

      I can put it in a standard module, if that is
      what bothers you.
      • Please preview your comments before submitting them. It appears that there is some text missing... you probably used literal < and > characters rather than &lt; and &gt;, causing use.perl to discard the unknown "tags"? At any rate, it looks as if $text is not assigned at all, the only thing in the parentheses of the open command is one double-quote character.
        --

        -- 
        Esli epei eto cumprenan, shris soa Sfaha.
        Aettot ibrec epesecoth, spakhea scrifeteis.

        • I did preview but perhaps I missed it. I used
          plaintext mode, but apparently I still have to
          use &lt and &gt.

          Sorry.
          • Yes, that's right. That's because even in plain text you can use tags such as bold or italic (or emphasised and strongly emphasised). I suppose the only difference is that returns are replaced with <br> in "Plain Old Text" mode while with "HTML Formatted" you have to do it yourself with <p>...</p>.
            --

            -- 
            Esli epei eto cumprenan, shris soa Sfaha.
            Aettot ibrec epesecoth, spakhea scrifeteis.

      • Re:hmmm.... (Score:2, Insightful)

        I think what bothers people is losing the freedom and ability to do it simply without going to such a function.

        What is the target audience for this new language? Do you expect people to use it instead of Perl 5 or Perl 6? That is, do you expect people to say "I hate typeglobs and scalar context so much that I am willing to use a language that has very little support instead of the very well-supported Perl 5 or Perl 6"? Or do you expect there to be a large developer following for it? Or is this mainly
    • Re:hmmm.... (Score:2, Informative)

      Well, I usually use "read FH, $data, -s FH", which is supposed to be pretty fast. That would work even without local, $/, or scalar vs. list context.

      --

      -- 
      Esli epei eto cumprenan, shris soa Sfaha.
      Aettot ibrec epesecoth, spakhea scrifeteis.

  • I too am not looking forwards to
    several Perl 6 changes, particulary
    the . operator. Nad you rougly had me
    up until #3.

    I don't much care either way for 2 or 3
    (I do little OO).

    I dislike #4, it drastically changes
    the return valuer system in place
    to no good ends. I'll grant typeglobs
    are at best weird, at worst dysfuinctional,
    but there must be a better way than this.

    As somebody else pointed out local serves
    a purpose that neither my nor our can serve.
    That is unless you allow my on special variables.
    --
    Were that I say, pancakes?
    • From `perldoc -f reverse`:

      • In scalar context, concatenates the elements of LIST and returns a string value with all characters in the opposite order.

      .g
    • Quite a long post, I say, but I address every issue in
      a separate post.

      I had a typo regarding => and , (I used = $b) would be an atomic
      key/value pair, and not the same thing as ($a,$b).

      A hash will need to be intialized with
      join(",", /($a => $b)*/) (pardon the notation). I.e:
      saying %myhash = ($a, $b); will generate a compile
      time or run-time error.
      • Please re-submit, this time with preview to make sure nothing is cut off.
        --

        -- 
        Esli epei eto cumprenan, shris soa Sfaha.
        Aettot ibrec epesecoth, spakhea scrifeteis.

    • I don't like "global" special variables one. They
      are a bit hard to understand and can wreak havoc in
      multi-threaded programs. I'd like to thing of a better
      solution that will eliminate most of them, while keeping
      the important ones of $_, $@, @_, etc. in a thread
      safe, possibly lexically-scoped manner.

      At the moment my best solution is Rindolf factories,
      which I probably did not explain too well. Here is
      a snippet of code from my "Ideas" file:

      new();
      $f->set_line_delimiter("\n\n");

      sub myfunc
      {
      • Please re-submit this text; there is something missing. Probably because you used literal less-than signs which were interpreted as beginning an HTML tag.

        At any rate, my $fh = $local_fh->open("open("readline(); looks like seriously wrong syntax to me.
        --

        -- 
        Esli epei eto cumprenan, shris soa Sfaha.
        Aettot ibrec epesecoth, spakhea scrifeteis.

      • I don't like "global" special variables one. They
        are a bit hard to understand and can wreak havoc in
        multi-threaded programs. I'd like to thing of a better
        solution that will eliminate most of them, while keeping
        the important ones of $_, $@, @_, etc. in a thread
        safe, possibly lexically-scoped manner.

        At the moment my best solution is Rindolf factories,
        which I probably did not explain too well. Here is
        a snippet of code from my "Ideas" file:

        <<<
        my $f = Rindolf::Factory->new();
        $f->set_
  • Reservations (Score:4, Interesting)

    by Ovid (2709) on 2002.02.13 19:19 (#4463) Homepage Journal

    Rindolf to Perl 5 is like Java is to C++

    Are you saying that you want to take a Byzantine language and create a dumber, slightly broken implementation? :)

    1. The -> operators and . will remain the same as in Perl 5.

    I like dropping the arrow in favor of the dot. I didn't at first, but I see no reason to raise the barrier of entry to Perl by not using what is almost an industry standard syntax. I can't think of any reason not to switch to the dot as this will help to eliminate one of the most prevalent (and ridiculous) objections about Perl.

    3. An on_destroy() primitive that calls a callback when it is garbage collected

    Well, how is garbage collection going to be handled? Perl's GC is essentially in a random order and this can cause some subtle bugs. I've had database transactions fail to commit because an object containing a reference to the db handle was reaped prior to my committing a transaction (that was using DESTROY as a fallback). Very annoying. You mention later that you want a better garbage collector, so I'm curious to see how you'll do that.

    5. local is gone. Long live my() and our().

    I hope you weren't serious about "long live ... our". I think our was a mistake. Lexically scoped globals? If that doesn't cause the occasional BrainMelt, I don't know what will. "use vars" is better.

    10. Unambiguous "x" operator:

    This is not a serious design issue that would merit the rewrite of a language. It might be an appropriate thing to change (I dunno, I have no problem with how "x" currently works), but it seems a bit trivial in comparison to what else you have here.

    11. General Depreciation of the scalar() context. scalar(@a) will be replaced by count(@a).

    I like scalar context. In fact, I sometimes use it with "x" to assign defaults to a hash:

    my %hash;
    @hash{ @array } = (1) x @array; # :)

    The question that I have to ask is: why is this better than Perl5? Further, the changes in Perl6 are so exciting (well, to me at least), that I think you're better off building on Perl6 than Perl5, if you want to clean things up. I have no problem with anyone coming along trying to create something new, but I want to be sold on why it's better than what we already have. I don't see that here, but I'd like to hear more.

    • There is no reason to prefer a dot over an arrow
      for member accesses, just because it is the
      "industry standard". I think the arrow is a
      cognitively-sound choice, because that's how
      people think about references and data-structures.

      Check the following URL:

      http://groups.yahoo.com/group/hackers-il/message/1878

      for more information
    • I'm not too familiar with our, but I heard it is the same as use vars qw( ... ). In any case, Rindolf will have a similar mechanism to usr vars qw( ... ). I make call it global(@a,$b,%hello), or something else.

      I'll probably keep use vars for compatibility , but it will be depreciated.

  • Are you going to implement all these language changes yourself?

    I'm just wondering, since the Perl5 core isn't that small, and I think it takes quite a while to wrap your head around it in order to be able to make changes.
    --

    -- 
    Esli epei eto cumprenan, shris soa Sfaha.
    Aettot ibrec epesecoth, spakhea scrifeteis.

    • At the moment, I'm not going to implement everything. I'm just going to write and present a SPEC of its changes from Perl 5. After I have a SPEC, I'll see what to do next.

      Making the SPEC is enough hard work as it is because I need to solve the small problems and inconsistencies, and make sure I like it as it is.

      • Best of luck, Shlomi. I'm going the way of Perl 6, but I keep toying with thoughts of "how I would do it." (Zero time to design or implement anything myself. Make that negative time.) Do Rindolf, but do it for yourself. Put what you want in it, and take out what you want. (It's interesting to me to compare the feature set you've chosen with what I would have chosen.)

        Don't let anyone dissuade you, because Rindolf is for you. If you do what you want, you may someday find that people who think like yo

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • No more local? (Score:2, Interesting)

    How do you propose to replace the extremely useful feature of 'local' which allows for changing single elements of hashes or lists only within the current scope. This is very useful in many places, particularly tests:

    e.g.

    my %args = (
      username => 'Foo',
      password => 'Bar',
    }

    {
      local $args{password} = 'Barr'
      # test that login fails
    }

    Tony
  • Personally I dont really think that you have through this very well. To me a number of your points strongly suggest that you havent grokked certain ideas, and that for that reason wish to remove them.

    The two most glaring examples of this are your comments about local() and scalar context.

    local is an absolutely useful feature, (albeit somewhat misnamed) that afaict cant be replaced. Or at least cant be replaced with any degree of elegance without simply renaming the thing.

    Scalar context is through be

    • Me, too. I thought it was a takeoff on Gandalf or something. (Since I haven't read LOTR, I thought it might even be a character.)

      google seems to find only this article and a posting by Shlomi on advogato. Oh, and also someone on the python email lists with an email address of rindolf2@yahoo.com . Same person as Shlomi? If so, I noted another weird intersection of space and time: the same person has posted to mailing lists for the lilypond project, something I'm interested in. (And stayed up hacking

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers