Slash Boxes
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

use Perl Log In

Log In

[ Create a new account ]

masak (6289)

  (email not shown publicly)

Been programming Perl since 2001. Found Perl 6 somewhere around 2004, and fell in love. Now developing November (a Perl 6 wiki), Druid (a Perl 6 board game), pls (a Perl 6 project installer), GGE (a regex engine), and Yapsi (a Perl 6 implementation). Heavy user of and irregular committer to Rakudo.

Journal of masak (6289)

Thursday April 29, 2010
10:01 AM

GSoC, contextuals, and intolerance (three posts in one)

[ #40333 ]

This is three thirds of a post. The three parts will simply have to combine into one big mechbot in order to pass as a whole post.

I'm a GSoC 2010 student

I sent in a proposal, and it got accepted. Yay!

Use contextuals for "process data", not attributes

Sometimes you both want do subdivide methods into small manageable parts, all the while keeping some sort of data between them. Most people reach for the instance attributes to do this, since these shared between all the methods of one object.

But this can also be done with contextuals, as is now done in Yapsi. This keeps the lifetime of the variables as short as possible, and keeps the objects light-weight. And it still works with inheritance.

I like how Perl 6 allows me to mix OO and contextuals this way. And I really like that it works in Rakudo already.

The mechanics of intolerance

I've blogged before about how #perl6 is a small, friendly community which turns even flame wars into interesting discussions and which works on being kind and open. We've had a bit of troll activity since I wrote those posts, as well as a few borderline trolls.

The other day I treated someone with undue impatience. The whole episode ended well, and I've apologised. In short, what looked like nagging questioning may simply have been someone's slightly different means of communicating.

Mean and evil acts are often committed by people convinced that they're actually doing good. mst++ writes about the reasons for being harsh, and I thought this was one of those times when that was called for. It wasn't.

It taught me to look out for situations when I might be mistaking variations in personality and communication skills for truly annoying behaviour. In many ways, that's a refreshing reminder: a really open community requires that we recognize that everyone doesn't operate exactly the same as we do. That sounds terribly clichéd, I know; but forgetting it is also far too easy.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I don't mean to be a troll or anything like that and I haven't really looked at the how the Perl 6 syntax has evolved over the years.

    So, out of curiosity I decided to take a look at the commit and I was bewildered by code such as:

    %*pads{$*current-block} = {};
    for $ -> $statement {
        self.find-vars($statement, 'statement');

    I mean, I can see the point in Perl 5 sigils. They're not pretty, but they're acceptable and they didn't bother me in these almost 10 years I've been programming in Perl.


    • Thank you for writing your comment. You're fears of being a troll are quite unfounded. You're quite frank, and your intention is clearly not to cause ire but to air your own distress. Let me try to help allay it.

      It's nice to be the one putting some Perl 6 code in the way of a Perl 5 programmer with ten years of experience. I'm not surprised that your first reaction to twigils is one of slight... unease. Perl 6 syntax is different, and not just in minor details.

      Things look like line noise when you don't know

      • I think I understand the motivation behind the twigils. In other programming languages you can't immediately tell if a variable name is a local variable or an object attribute, for instance.

        And while I can't think of a better solution, twigils just don't seem to be the best solution to me. Maybe always requiring the object to be explicit is a better solution (e.g. $self.attribute). But then you'll hit me with a TIMTOWTDI hammer since that probably also works. :)

        I don't agree that "line-noise appearance" com

        • I can assure that if Perl 5 people thinks the syntax is a little awkward... well, the rest of the world will find it, at least, *very* awkward.

          I can imagine that idiomatic Perl 6 is difficult for people to understand if they've never learned any Perl 6. I care more about how easy a language is to learn and to use once you've learned it than how difficult it is to guess at meanings if you don't know how to lex it. I don't mean to sound harsh, but the metric of "intuitive to the uninitiated" is irrelevant

          • I agree that the "intuitive to the uninitiated" metric shouldn't be considered a major thing (although, I think it is desirable if it doesn't get into the way of other features).

            To be honest, I'm just worried that typing all these "shift characters" everywhere will make programming in Perl 6 actually a tiring experience which results in a bad aesthetic result. I mean, pre-"syntax sugar revolution" Perl 5 was already at the limit for me.

            • I understand that concern, especially for people with keyboard layouts where typing symbols is more difficult than shift-eight, for example. I don't have a good solution for that. Certainly I'll never argue in favor of Perl 5 reference syntax.

        • And while I can't think of a better solution, twigils just don't seem to be the best solution to me. Maybe always requiring the object to be explicit is a better solution (e.g. $self.attribute). But then you'll hit me with a TIMTOWTDI hammer since that probably also works. :)

          Sorta, kinda, yes and no. :) Even considering what you say in your self-counterattack, many people will use the twigils anyway. Especially if they're the recommended default. Which they are.

          But these are very specific situations and you can even argue that it's a feature - these constructs should only be used by those who know what they're doing.

          Hm. Twigils as a shibboleth for tricky features. ("You have unlocked the '*' twigil and can now use... contextuals!") Yes, I guess so. But I still maintain that they're not as spooky as you imply, especially not the OO ones. The twigils make them fittingly stand out as "almost, but not quite, ordinary variables".

          Trying t

          • Well, I just looked at the new periodic table and if by "gorgeous" you meant "scary", I agree with you. :)

            If you think about it, I guess this discussion wouldn't even exist if Perl 6 wasn't called Perl 6. This implies it's a successor of Perl 5 and thus, eventually, Perl 5 will be obsoleted by Perl 6.

            Being completely honest, what goes through my mind when I read about Perl 6 these days is something like: "Oh shit, I will need to go through all this madness sometime in the future when Perl 6 is completed".


            • In the interests of mutual understanding, I tried to look at the periodic table (which is here [], by the way), and tried to instill a measure of fear in myself. The closest I got was "huh, that's quite a lot of them, isn't it?".

              I think one of the big dividing points between the Perl languages on the one hand and other programming languages on the other, is that Perl embraces complexity -- often quite fearlessly. Language designers are known to talk about minimalism and orthogonality. Perl, in contrast, seems

              • I've actually read all these these references before posting here. I don't usually actively participate in discussions, though.

                "Scary" was the least offensive adjective I could think of to express my general disapproval of it. "Batshit fucking insane" sounds more like my thoughts. :)

                Anyway, the whole periodic table of operators sounded novel when I first looked at it a few years ago. These days, I just feel like such things could be the last nail in the coffin for Perl in general.

                I'm a bit more optimistic l

                • Ask these people if they have a periodic table of standard libraries. Have you ever tried even skimming the full reference of all the Java classes?

                  Just because the complexity isn’t in the operators doesn’t mean it’s not there anywhere.

                  Of course, these people will immediately respond that they don’t use all of that every day, and what they don’t know they can look up. Which of course is just how it is with the operator table too.

                • I can relate to what you're saying about "Perl Survival Mode" and about Perl 6 getting in the way and creating negative PR for Perl 5 users in the business.

                  I wish I could do more to help counteract such negative effects. None of us can change the past, which does contain its fair share of failed dreams and dead ends for Perl 6. With a bit of luck, we can learn a bit from it, and find ways of working which do produce results, and not just important lessons.

                  From my perspective, Perl 6 is bringing important (i

                • Masak and his homies won't acknowledge it, but having few and well-defined operators is a GOOD thing for a language. Operators are akin to prepositions and should be kept to a minimum, in my very humble opinion. I'm pretty sure chromatic/masak/lwall/etc don't think so, though.
                  • I'm pretty sure chromatic/masak/lwall/etc don't think so, though.

                    Very true, because operators are verbs. Prepositions in programming languages are rare. Perhaps regex modifiers count.

                    As for the larger question, parsimony of primitives leads directly towards dialectization, in the case of Forth-like languages; top-down standardization of APIs, in the case of Java; or oscillating periods of expansion and contraction towards contentious compromises, in the case of CLOS or Scheme. Each has disadvantages.

                    • Again, I'm pretty sure you think that - after all, you guys see no downside in crap like "twigils" :D Oh, Mr. Christopher, what are we going to do with you? How you love writing! So, your name is Chromatic (one word!) sort of like Cher? What's wrong with your real name?
                    • "parsimony of primitives leads directly towards dialectization"

                      You are missing the point entirely. Firstly, minimising the number of operators, especially in perl 6's case, would be positive. Secondly, what you are saying, in plain English (I have my pretentiousness filter on) is "if we have very little primitives, we will get into a mess like lisp" and that's simply false - there are many programming languages in the middle of the spectrum that have not been (as you say) "dialectised" (which, according

                    • Firstly, minimising the number of operators, especially in perl 6's case, would be positive.


                      No, seriously. Why?

                      It's obvious you have a target number in mind. Quantify it. If there are facts, discoverable facts, for the design of an ideal programming language, let's be engineers about it. Be specific. "Too many" is not specific. "Fewer" is not helpful. "I know it when I see it" is opinion, not science. Be bold; back up your assertions.

                      I cheerfully ignore the reductio ad lambda calculus argument

                    • Because the operators are not obvious. Not even for Perl 5 programmers. They should be as obvious as +, or -. I'm not against introducing a couple of operators, if they make sense. In this day and age, the engineering goal of a programming language should be to make multithreading and object plurality as easy as possible. I think it's right to make operators smarter so they can operate on arrays or sole elements, but it seems to have gone to a confusing extreme in perl 6.

                      One small case, just looking at th

                    • One small case, just looking at the periodic table of perl 6 operators. I see a whole bunch of string comparison operators (leg, lt, lg, eq, ge, gt, ne) and a whole bunch of numeric comparison operators (<=>, >, <, etc etc) plus cmp plus eqv. Now, I haven’t had time to look at perl 6 deeply in years, but at first glance, that’s even worse than common lisp’s 5 different notions of equality.

                      You are aware that Perl 5 has almost all of these already, right?

                    • You are aware that Perl 5 has almost all of these already, right?


                    • So, are you not going to post my comments on your blog, Mr. Christopher (aka chromatic)?

                      Since you and your friend Ovid seem to be only interested in what you two have to say to each other, I've started posting my comments in my own blog, [].

                      Granted, I didn't expect such unwarranted censorship. I guess it's only okay to talk about whatever you decide, huh? -- ank

                    • I'd rather discuss the Dick Grune research to which you alluded months ago. Did you ever find it? (I'm not Mr. Grune, nor Mr. Pierce, nor Mr. Carlyle, nor Mr. Romata either. What bizarre assertions.)

                    • No, your name is Shane Warden, and you've published a couple of books as S. Christopher. As for the rest - my Pierce books are laughing at you. I'm sure you want to be them, but it's obvious to everyone you fail (as for Romata, I think you should have said Tomita - he has nice parsers that are porbably the only ones that can parse your perl 6 monstrosity.) Also, I'm tired of you editing my comments, so I am still cross-posting this to my blog []
  • Either I didn't think of it at the time of blogging, or I forgot about it, but another nice thing about using contextuals rather than instance attributes is that the class becomes thread-safe. In other words, you can suddenly use the same instance of Yapsi::Compiler to compile two different sources simultaneously. The contextuals will be local to each thread and not interact; instance attributes would have been shared and cause a bit of trouble.

    Yapsi::Compiler currently only has one instance attribute: @.wa