From schwern at pobox.com Sun Apr 1 12:26:47 2001 From: schwern at pobox.com (Michael G Schwern) Date: Tue Aug 3 23:54:03 2004 Subject: DNA.pm Message-ID: <20010401182646.Q779@blackrider.aocn.com> Not to be outdone by the Brits (see Leon's Buffy.pm http://www.astray.com/Buffy/), American innovation brings us DNA.pm! Did I say American? I ment Irish. http://www.pobox.com/~schwern/src/ if it hasn't made it to CPAN yet. NAME DNA - Encodes your Perl program into an Amino Acid sequence SYNOPSIS use DNA; CCAA CCAA AAGT CAGT TCCT CGCT ATGT AACA CACA TCTT GGCT TTGT AACA GTGT TCCT AGCT CAGA TAGA ACGA TAGA TAGA CAGA TAGA CAGA CAGA CAGA TAGA CAGA CAGA CAGA TAGA ATGA TAGA TAGA GTGA CAGA TAGA CTGA CAGA TAGA CAGA CAGA CAGA TAGA TTGA CAGA TAGA CTGA TAGA CAGA CTGA TAGA TCGA CTGA ATGA TAGA TAGA TAGA CAGA TAGA ACGA TAGA ACGA TAGA TAGA TAGA TAGA TAGA TAGA TAGA CTGA CAGA CAGA TTGA TAGA CAGA ATGA CAGA TAGA TAGA GAGA TAGA GTGA CAGA CAGA GTGA TAGA TAGA TTGA TAGA CAGA TAGA CAGA TCGA TTGA CAGA AGCT AACA TACT AGCT AGCT AACA TTGT GAGT TTCT AACA GTTT TCCT CGCT ATCT GGCT GTGT CAGA CAGA TAGA TAGA GAGA TAGA TAGA GAGA TAGA CAGA TAGA GTGA GTGA TAGA GTGA GAGA ATGA TAGA TAGA CAGA TAGA TAGA CAGA TAGA TAGA CAGA TAGA CAGA TAGA CAGA TAGA TAGA TAGA CAGA CTGA GAGA CAGA TCGA GTGA TAGA ATGA TAGA TAGA CAGA ATGA TAGA TTGA TAGA CAGA TAGA TAGA TAGA CAGA CAGA TAGA TAGA ATGA CTGA TAGA ATGA TAGA ATGA ATGA TAGA TAGA TAGA TAGA TAGA CAGA TAGA CAGA TAGA TAGA CAGA TAGA ACGA ACGA TAGA CAGA TAGA GAGT TACA AGTT CGCT CACA GCGA CCAA CCAA DESCRIPTION So you say you're a rabid Perl programmer? You've got a Camel tattooed on your arm. You took your wife to TPC for your second honeymoon. But you're worried about your children, they might not be such devoted Perl addicts. How do you guarantee the continuation of the line? Until now, there was no solution (what, do you think they teach Perl in school?!) Through the magic of Gene Splicing, now you can encode your very genes with the essense of Perl! Simply take your best one-liner, encode it with this nifty DNA module and head on down to your local sperm bank and have them inject that sucker in. As the encoding of programs on bacterial DNA will soon revolutionize the data storage industry, I'm downloading the necessary forms from the US patent office as I write. Imagine, all of CPAN on an airborne bacteria. You can breathe Perl code! When you use the DNA module on your code, the first time through it will convert your code into a series of DNA sequences. Of course, most of the DNA is simply junk. We're not sure why... someone spilled coffee on the documentation. There's also a slight chance on each use that a mutation will occur... or maybe its a bug in perl, we're not sure. Of course, this means your code may suddenly fall over dead... but you made a few million copies, right? POD will, of course, be preserved. God made the mistake of not writing docs, and look at all the trouble we've had to go through to figure out his code! NOTES The tests are encoded in DNA! But it sometimes introduces bugs... oh dear. BUGS There were only a few flipper babies. SEE ALSO the Sex manpage, the Morse manpage, the Bleach manpage, the Buffy manpage, a good psychiatrist. AUTHOR Michael G Schwern -- Michael G. Schwern http://www.pobox.com/~schwern/ Perl6 Quality Assurance Kwalitee Is Job One Maybe they hooked you up with one of those ass-making magazines. -- brian d. foy as misheard by Michael G Schwern From mwk at stray-toaster.co.uk Sun Apr 1 13:08:33 2001 From: mwk at stray-toaster.co.uk (Stray Toaster) Date: Tue Aug 3 23:54:03 2004 Subject: DNA.pm References: <20010401182646.Q779@blackrider.aocn.com> Message-ID: <3AC76EA0.CA6218A3@stray-toaster.co.uk> Michael G Schwern (noise polluter extordinaire) wrote: > Not to be outdone by the Brits (see Leon's Buffy.pm > http://www.astray.com/Buffy/), American innovation brings us DNA.pm! > Did I say American? I ment Irish. The most amazing thing here is that I thought of something similar (after Morse), but abandoned it for two reasons: a) I don't know any biology to produce the codes b) It seemed a bit off-the-wall even for me (among the many reasons etcetc) c) I could never write pod like *that*! m. but hey, as soon as it hits cpan, I will get it. I wonder if I could hack the morse audio code to play back the sound of my code in dna form............. -- I'm immune to your consultation I'm quite aware of what I'm going through From acme at astray.com Sun Apr 1 13:11:02 2001 From: acme at astray.com (Leon Brocard) Date: Tue Aug 3 23:54:03 2004 Subject: DNA.pm In-Reply-To: <3AC76EA0.CA6218A3@stray-toaster.co.uk>; from mwk@stray-toaster.co.uk on Sun, Apr 01, 2001 at 07:08:33PM +0100 References: <20010401182646.Q779@blackrider.aocn.com> <3AC76EA0.CA6218A3@stray-toaster.co.uk> Message-ID: <20010401191102.D27273@ns0.astray.com> Stray Toaster sent the following bits through the ether: > but hey, as soon as it hits cpan, I will get it. I wonder if I could hack the > morse audio code to play back the sound of my code in dna form............. Stave.pm? MIDI.pm? Something which converts your Perl code to music, which you can then play... and run. Hmmmm. Leon -- Leon Brocard.............................http://www.astray.com/ yapc::Europe............................http://yapc.org/Europe/ ... Go Lemmings, go!!! From acme at astray.com Sun Apr 1 13:14:42 2001 From: acme at astray.com (Leon Brocard) Date: Tue Aug 3 23:54:03 2004 Subject: DNA.pm In-Reply-To: <20010401191102.D27273@ns0.astray.com>; from acme@astray.com on Sun, Apr 01, 2001 at 07:11:02PM +0100 References: <20010401182646.Q779@blackrider.aocn.com> <3AC76EA0.CA6218A3@stray-toaster.co.uk> <20010401191102.D27273@ns0.astray.com> Message-ID: <20010401191442.E27273@ns0.astray.com> Leon Brocard sent the following bits through the ether: > Stave.pm? MIDI.pm? Something which converts your Perl code to music, > which you can then play... and run. Hmmmm. Link for those interested: http://www.gre.ac.uk/~c.walshaw/abc/ Leon -- Leon Brocard.............................http://www.astray.com/ yapc::Europe............................http://yapc.org/Europe/ ... Every time I've built character, I've regretted it From mwk at stray-toaster.co.uk Sun Apr 1 13:20:49 2001 From: mwk at stray-toaster.co.uk (Stray Toaster) Date: Tue Aug 3 23:54:03 2004 Subject: DNA.pm References: <20010401182646.Q779@blackrider.aocn.com> <3AC76EA0.CA6218A3@stray-toaster.co.uk> <20010401191102.D27273@ns0.astray.com> Message-ID: <3AC77181.B5D73AD2@stray-toaster.co.uk> > . > > Stave.pm? MIDI.pm? Something which converts your Perl code to music, > which you can then play... and run. Hmmmm. > > Leon > wow. cool. I was unaware of either of these modules. I go get now. Cheers! I will make the room rock (literally) to Perl Marc, have you been reading the wrong lists again? m. -- I'm immune to your consultation I'm quite aware of what I'm going through From schwern at pobox.com Sun Apr 1 13:49:26 2001 From: schwern at pobox.com (Michael G Schwern) Date: Tue Aug 3 23:54:03 2004 Subject: DNA.pm In-Reply-To: <20010401191102.D27273@ns0.astray.com>; from acme@astray.com on Sun, Apr 01, 2001 at 07:11:02PM +0100 References: <20010401182646.Q779@blackrider.aocn.com> <3AC76EA0.CA6218A3@stray-toaster.co.uk> <20010401191102.D27273@ns0.astray.com> Message-ID: <20010401194926.T779@blackrider.aocn.com> On Sun, Apr 01, 2001 at 07:11:02PM +0100, Leon Brocard wrote: > Stave.pm? MIDI.pm? Something which converts your Perl code to music, > which you can then play... and run. Hmmmm. Yes, run. Run very far away. -- Michael G. Schwern http://www.pobox.com/~schwern/ Perl6 Quality Assurance Kwalitee Is Job One Our business in life is not to succeed but to continue to fail in high spirits. -- Robert Louis Stevenson From schwern at pobox.com Sun Apr 1 13:50:00 2001 From: schwern at pobox.com (Michael G Schwern) Date: Tue Aug 3 23:54:03 2004 Subject: Meeting when? Message-ID: <20010401195000.U779@blackrider.aocn.com> Is there a meeting on Monday? Am I supposed to be talking about something? -- Michael G. Schwern http://www.pobox.com/~schwern/ Perl6 Quality Assurance Kwalitee Is Job One That which stirs me, stirs everything. -- Squonk Opera, "Spoon" From mwk at stray-toaster.co.uk Sun Apr 1 13:57:09 2001 From: mwk at stray-toaster.co.uk (Stray Toaster) Date: Tue Aug 3 23:54:03 2004 Subject: Meeting when? References: <20010401195000.U779@blackrider.aocn.com> Message-ID: <3AC77A05.7E2BA718@stray-toaster.co.uk> Michael G Schwern wrote: > Is there a meeting on Monday? Am I supposed to be talking about > something? > I refer the honourable gentleman to http://belfast.pm.org where is clearly states you are a special guest on the 9th. Which is monday week. So you are in work, and the thought struck you that you were to give a talk tomorrow, and you haven't prepared. Well, ease up dude. You can have the same feeling all over again next Sunday!! m. -- I'm immune to your consultation I'm quite aware of what I'm going through From schwern at pobox.com Sun Apr 1 14:00:07 2001 From: schwern at pobox.com (Michael G Schwern) Date: Tue Aug 3 23:54:03 2004 Subject: Meeting when? In-Reply-To: <3AC77A05.7E2BA718@stray-toaster.co.uk>; from mwk@stray-toaster.co.uk on Sun, Apr 01, 2001 at 07:57:09PM +0100 References: <20010401195000.U779@blackrider.aocn.com> <3AC77A05.7E2BA718@stray-toaster.co.uk> Message-ID: <20010401200006.V779@blackrider.aocn.com> On Sun, Apr 01, 2001 at 07:57:09PM +0100, Stray Toaster wrote: > I refer the honourable gentleman to http://belfast.pm.org where is > clearly states you are a special guest on the 9th. Which is monday > week. So you are in work, and the thought struck you that you were > to give a talk tomorrow, and you haven't prepared. Well, ease up > dude. You can have the same feeling all over again next Sunday!! Lovely. What is it I'm talking about again? -- Michael G. Schwern http://www.pobox.com/~schwern/ Perl6 Quality Assurance Kwalitee Is Job One But I wore the juice! From schwern at pobox.com Tue Apr 3 13:44:04 2001 From: schwern at pobox.com (Michael G Schwern) Date: Tue Aug 3 23:54:03 2004 Subject: Fwd: [Apocalypse 1 from Larry] Message-ID: <20010403194404.M32409@blackrider.aocn.com> Larry Wall's first solid commentary on the Perl 6 RFCs. Haven't read it myself yet. ----- Forwarded message from Nathan Torkington ----- From: Nathan Torkington Reply-To: gnat@oreilly.com Organization: O'Reilly and Associates To: perl6-announce@perl.org Subject: Apocalypse 1 from Larry Larry's approaching perl6 through the Programming Perl book (the Camel). He's going chapter by chapter through the Camel, writing documents about the perl6 equivalent concepts. These missives are known as "Apocalypses", for reasons best known to Larry. :-) He's churning through the RFCs, looking through them to deeper issues. He hopes to emit Apocalypses more-or-less weekly, although some chapters have fewer RFCs and issues than others. Enjoy! Nat ----- Apocalypse 1: The Ugly, the Bad, and the Good by Larry Wall Apr. 2, 2001 Table of Contents o RFC 141: This Is The Last Major Revision o RFC 28: Perl should stay Perl o RFC 16: Keep default Perl free of constraints such as warnings and strict o RFC 73: All Perl core functions should return objects o RFC 26: Named operators versus functions People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing. An Apocalypse is supposed to reveal good news to good people. (And if it also happens to reveal bad news to bad people, so be it. Just don't be bad.) What I will be revealing in these columns will be the design of Perl 6. Or more accurately, the beginnings of that design, since the design process will certainly continue after I've had my initial say in the matter. I'm not omniscient, rumors to the contrary notwithstanding. This job of playing God is a little too big for me. Nevertheless, someone has to do it, so I'll try my best to fake it. And I'll expect all of you to help me out with the process of creating history. We all have to do our bit with free will. "If you look at the history of Perl 6 up to this point, you will see why this column is subtitled The Ugly, the Bad, and the Good. The RFC process of last year was ugly, in a good sense. It was a brainstorming process, and that means it was deliberately ugly-not in the sense of incivility, since the RFC process was in fact surprisingly civil, but in the sense that there was little coherent design to the suggestions in the RFCs. Frankly, the RFCs are all over the map, without actually covering the map. There are contradictory RFCs, and there are missing RFCs. Many of the RFCs propose real problems but go off at funny angles in trying to propose solutions. Many of them patch symptoms without curing the underlying ailments. I also discovered Larry's First Law of Language Redesign: Everyone wants the colon. That was the Ugly part. The Bad part was that I was supposed to take these RFCs and produce a coherent design in two weeks. I starting out thinking I could just classify the RFCs into the good, bad, and ugly categories, but somehow most of them ended up in the ugly category, because the good ones typically had something wrong with them, and the even the bad ones typically indicated a problem that could use some thought, even if the solution was totally bogus. It is now five months later, and I've been mulling over coherence the whole time, for some definition of mulling. Many of you know what happens when the size of your Perl process exceeds the size of your physical memory-you start thrashing. Well, that's basically what happened to me. I couldn't get enough of the problem into my head at once to make good progress, and I'm not actually very good at subdividing problems. My forte is synthesis, not analysis. It didn't help that I had a number of distractions in my life, some of them self-inflicted, and some of them not. I won't go into all that. Save it for my unauthorized autobiography. But now we come to the Good part. (I hope.) After thinking lots and lots about many of the individual RFCs, and not knowing how to start thinking about them as a whole, it occurred to me (finally!) that the proper order to think about things was, more or less, the order of the chapters in the Camel Book. That is, the Camel Book's order is designed to minimize forward references in the explanation of Perl, so considering Perl 6 in roughly the same order will tend to reduce the number of things that I have to decide before I've decided them. So I've merrily classified all the RFCs by chapter number, and they look much more manageable now. (I also restructured my email so that I can look at a slice of all the messages that ever talked about a particular RFC, regardless of which mailing list the message was on. That's also a big help.) I intend to produce one Apocalypse for each Chapter, so Apocalypse 1 corresponds to Chapter 1: An Overview of Perl. (Of course, in the book, the Overview is more like a small tutorial, not really a complete analysis of the philosophical underpinnings of Perl. Nevertheless, it was a convenient place to classify those RFCs that talk about Perl 6 on that level.) So today I'm talking about the following RFCs: RFC PSA Title --- --- ----- 16 bdb Keep default Perl free of constraints such as warnings and strict. 26 ccb Named operators versus functions 28 acc Perl should stay Perl. 73 adb All Perl core functions should return objects 141 abr This Is The Last Major Revision The PSA rating stands for ``Problem, Solution, Acceptance''. The problem and solution are graded on an a-f scale, and very often you'll find I grade the problem higher than the solution. The acceptance rating is one of a Accepted wholeheartedly b Accepted with a few "buts" c Accepted with some major caveats r Rejected I might at some point add a ``d'' for Deferred, if I really think it's too soon to decide something. [22]RFC 141: This Is The Last Major Revision I was initially inclined to accept this RFC, but decided to reject it on theological grounds. In apocalyptic literature, 7 is the number representing perfection, while 6 is the number representing imperfection. In fact, we probably wouldn't end up converging on a version number of 2*PI as the RFC suggests, but rather on 6.6.6, which would be rather unfortunate. So Perl 7 will be the last major revision. In fact, Perl 7 will be so perfect, it will need no revision at all. Perl 6 is merely the prototype for Perl 7. :-) Actually, I agree with the underlying sentiment of the RFC-I only rejected it for the entertainment value. I want Perl to be a language that can continue to evolve to better fit the problems people want to solve with it. To that end, I have several design goals that will tend to be obscured if you just peruse the RFCs. First, Perl will support multiple syntaxes that map onto a single semantic model. Second, that single semantic model will in turn map to multiple platforms. Multiple syntaxes sound like an evil thing, but they're really necessary for the evolution of the language. To some extent we already have a multi-syntax model in Perl 5; every time you use a pragma or module, you are warping the language you're using. As long as it's clear from the declarations at the top of the module which version of the language you're using, this causes little problem. A particularly strong example of how support of multiple syntaxes will allow continued evolution is the migration from Perl 5 to Perl 6 itself. See the discussion of RFC 16 below. Multiple backends are a necessity of the world we live in today. Perl 6 must not be limited to running only on platforms that can be programmed in C. It must be able to run in other kinds of virtual machines, such as those supported by Java and C#. [23]RFC 28: Perl should stay Perl. It is my fond hope that those who are fond of Perl 5 will be fonder still of Perl 6. That being said, it's also my hope that Perl will continue trying to be all things to all people, because that's part of Perl too. While I accept the RFC in principle (that is, I don't intend to go raving mad), I have some major caveats with it, because I think it is needlessly fearful that any of several programming paradigms will ``take over'' the design. This is not going to happen. Part of what makes Perl Perl is that it is intentionally multi-paradigmatic. You might say that Perl allows you to be paradigmatic without being ``paradogmatic''. The essence of Perl is really context sensitivity, not just to syntactic context, but also to semantic, pragmatic, and cultural context. This overall philosophy is not going to change in Perl 6, although specific context sensitivities may come and go. Some of the current context sensitivities actually prevent us from doing a better job of it in other areas. By intentionally breaking a few things, we can make Perl understand what we mean even better than it does now. As a specific example, there are various ways things could improve if we muster the courage to break the ``weird'' relationship between @foo and $foo[]. True, we'd lose the current slice notation (it can be replaced with something better, I expect). But by consistently treating @foo as an utterance that in scalar context returns an array reference, we can make subscripts always take an array reference, which among other things fixes the botch that in Perl 5 requires us to distinguish $foo[] from $foo->[]. There will be more discussion of this in Apocalypse 2, when we'll dissect ideas like RFC 9: Highlander Variable Types. [24]RFC 16: Keep default Perl free of constraints such as warnings and strict. I am of two minds about this debate-there are good arguments for both sides. And if you read through the discussions, all those arguments were forcefully made, repeatedly. The specific discussion centered around the issue of strictness, of course, but the title of the RFC claims a more general philosophical position, and so it ended up in this Apocalypse. I'll talk about strictness and warnings in a moment, and I'll also talk about constraints in general, but I'd like to take a detour through some more esoteric design issues first. To my mind, this RFC (and the ones it is reacting against), are examples of why some language designer like me has to be the one to judge them, because they're all right, and they're all wrong, simultaneously. Many of the RFCs stake out polar positions and defend them ably, but fail to point out possible areas of compromise. To be sure, it is right for an RFC to focus in on a particular area and not try to do everything. But because all these RFCs are written with (mostly) the design of Perl 5 in mind, they cannot synthesize compromise even where the design of Perl 6 will make it mandatory. To me, one of the overriding issues is whether it's possible to translate Perl 5 code into Perl 6 code. One particular place of concern is in the many one-liners embedded in shell scripts here and there. There's no really good way to translate those invocations, so requiring a new command line switch to set ``no strict'' is not going to fly. A closely related question is how Perl is going to recognize when it has accidentally been fed Perl 5 code rather than Perl 6 code. It would be rather bad to suddenly give working code a brand new set of semantics. The answer, I believe, is that it has to be impossible by definition to accidentally feed Perl 5 code to Perl 6. That is, Perl 6 must assume it is being fed Perl 5 code until it knows otherwise. And that implies that we must have some declaration that unambiguously declares the code to be Perl 6. Now, there are right ways to do this, and wrong ways. I was peeved by the approach taken by DEC when they upgraded BASIC/PLUS to handle long variable names. Their solution was to require every program using long variable names to use the command EXTEND at the top. So henceforth and forevermore, every BASIC/PLUS program had EXTEND at the top of it. I don't know whether to call it Bad or Ugly, but it certainly wasn't Good. A better approach is to modify something that would have to be there anyway. If you go out to CPAN and look at every single module out there, what do you see at the top? Answer: a ``package'' declaration. So we break that. I hereby declare that a package declaration at the front of a file unambiguously indicates you are parsing Perl 5 code. If you want to write a Perl 6 module or class, it'll start with the keyword module or class. I don't know yet what the exact syntax of a module or a class declaration will be, but one thing I do know is that it'll set the current global namespace much like a package declaration does. Now with one fell swoop, much of the problem of programming in the large can be dealt with simply by making modules and classes default to strict, with warnings. But note that the default in the main program (and in one liners) is Perl 5, which is non-strict by definition. We still have to figure out how Perl 6 main programs should distinguish themselves from Perl 5 (with a ``use 6.0'' maybe?), and whether Perl 6 main programs should default to strict or not (I think not), but you can already see that a course instructor could threaten to flunk anyone who doesn't put ``module Main'' at the front each program, and never actually tell their pupils that they want that because it turns on strictures and warnings. Other approaches are possible, but that leads us to a deeper issue, which is the issue of project policy and site policy. People are always hankering for various files to be automatically read in from various locations, and I've always steadfastly resisted that because it makes scripts implicitly non-portable. However, explicit non-portability is okay, so there's no reason our hypothetical class instructor could not insist that programs start with a ``use Policy;'' or some such. But now again we see how this leads to an even deeper language design issue. The real problem is that it's difficult to write such a Policy module in Perl 5, because it's really not a module but a meta-module. It wants to do ``use strict'' and ``use warnings'' on behalf of the student, but it cannot do so. Therefore one thing we must implement in Perl 6 is the ability to write meta-use statements that look like ordinary use statements but turn around and declare other things on behalf of the user, for the good of the user, or of the project, or of the site. (Whatever. I'm not a policy wonk.) So whether I agree with this RFC really depends on what it means by ``default''. And like Humpty Dumpty, I'll just make it mean whatever I think is most convenient. That's context sensitivity at work. I also happen to agree with this RFC because it's my philosophical position that morality works best when chosen, not when mandated. Nevertheless, there are times when morality should be strongly suggested, and I think modules and classes are a good place for that. [25]RFC 73: All Perl core functions should return objects I'm not sure this belongs in the overview, but here it is nonetheless. In principle, I agree with the RFC. Of course, if all Perl variables are really objects underneath, this RFC is trivially true. But the real question is how interesting of an object you can return for a given level of performance. Perl 5's objects are relatively heavyweight, and if all of Perl 6's objects are as heavy, things might bog down. I'm thinking that the solution is better abstract type support for data values that happen to be represented internally by C structs. We get bogged down when we try to translate a C struct such a struct tm into an actual hash value. On the other hand, it's rather efficient to translate a struct tm to a struct tm, since it's a no-op. We can make such a struct look like a Perl object, and access it efficiently with attribute methods as if it were a ``real'' object. And the typology will (hopefully) mostly only impose an abstract overhead. The biggest overhead will likely be memory management of a struct over an int (say), and that overhead could go away much of the time with some amount of contextually aware optimization. In any event, I just want to point out that nobody should panic when we talk about making things return objects that didn't used to return them. Remember that any object can define its stringify and numify overloadings to do whatever the class likes, so old code that looks like print scalar localtime; can continue to run unchanged, even though localtime might be returning an object in scalar context. [26]RFC 26: Named operators versus functions Here's another RFC that's here because I couldn't think of a better place for it. I find this RFC somewhat confusing because the abstract seems to suggest something more radical than the description describes. If you ignore the abstract, I pretty much agree with it. It's already the case in Perl 5 that we distinguish operators from functions primarily by how they are called, not by how they are defined. One place where the RFC could be clarified is that Perl 5 distinguishes two classes of named operators: named unary operators vs list operators. They are distinguished because they have different precedence. We'll discuss precedence reform under Apocalypse 3, but I doubt we'll combine the two kinds of named operators. (As a teaser, I do see ways of simplifying Perl's precedence table from 24 levels down to 18 levels, albeit with some damage to C compatibility in the less frequently used ops. More on that later.) _________________________________________________________________ Do you begin to see why my self-appointed job here is much larger than just voting RFCs up or down? There are many big issues to face that simply aren't covered by the RFCs. We have to decide how much of our culture is just baggage to be thrown overboard, and how much of it is who we are. We have to smooth out the migration from Perl 5 to Perl 6 to prevent people from using that as an excuse not to adopt Perl 6. And we have to stare at all those deep issues until we see through them down to the underlying deeper issues, and the issues below that. And then in our depths of understanding, we have to keep Perl simple enough for anyone to pick up and start using to get their job done right now. Stay tuned for Apocalypse 2, wherein we will attempt to vary our variables, question our quotes, recontextualize our contexts, and in general set the lexical stage for everything that follows. References 22. http://dev.perl.org/rfc/141.html 23. http://dev.perl.org/rfc/28.html 24. http://dev.perl.org/rfc/16.html 25. http://dev.perl.org/rfc/73.html 26. http://dev.perl.org/rfc/26.html ----- End forwarded message ----- -- Michael G. Schwern http://www.pobox.com/~schwern/ Perl6 Quality Assurance Kwalitee Is Job One WOOHOO! I'm going to Disneyland! http://www.goats.com/archive/980805.html From mwk at stray-toaster.co.uk Fri Apr 6 09:44:34 2001 From: mwk at stray-toaster.co.uk (Stray Toaster) Date: Tue Aug 3 23:54:03 2004 Subject: Meeting reminder!! Message-ID: <3ACDD652.6ACFA9AD@stray-toaster.co.uk> Hi all. Just a quick reminder about the meeting on Monday night. And after a quick conflab with the ace Schwern, it seems he is willing to be coereced into talking about something we all want to her about!! (In other words, he doesn't know what he is going to say to us, and is desperately reaching out. In desperation.) So any suggestions? Anything you specifically want to hear? I remember the shambles that was the pod talk from YAPC::Europe, but it was funny. Kwallittee. Or something. I quite fancy something on optimization/solid coding, but then that is just me. Or regualr expressions. *shudder*. Feel free to throw ideas into the melting pot. And if there anything else you want brought up, let me know and I will make an agenda. (I seem to have volunteered myself for something here..........) See you all then!! m. From russell at futureless.org Fri Apr 6 10:40:26 2001 From: russell at futureless.org (Russell) Date: Tue Aug 3 23:54:03 2004 Subject: Meeting reminder!! In-Reply-To: <3ACDD652.6ACFA9AD@stray-toaster.co.uk>; from mwk@stray-toaster.co.uk on Fri, Apr 06, 2001 at 03:44:34PM +0100 References: <3ACDD652.6ACFA9AD@stray-toaster.co.uk> Message-ID: <20010406154025.A25707@futureless.org> Hi, On Fri, Apr 06, 2001 at 03:44:34PM +0100, Stray Toaster wrote: > Feel free to throw ideas into the melting pot. And if there anything > else you want brought up, let me know and I will make an agenda. (I seem > to have volunteered myself for something here..........) I'd be interested to hear about OO programming in Perl, although not necessarily at Monday's meeting. Thanks, Russell -- Computers are useless. They can only give you answers. -- Pablo Picasso -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://mail.pm.org/archives/belfast-pm/attachments/20010406/4667355b/attachment.bin From wesley at blackstar.co.uk Fri Apr 6 13:07:27 2001 From: wesley at blackstar.co.uk (Wesley Darlington) Date: Tue Aug 3 23:54:03 2004 Subject: Meeting reminder!! In-Reply-To: <3ACDD652.6ACFA9AD@stray-toaster.co.uk>; from mwk@stray-toaster.co.uk on Fri, Apr 06, 2001 at 03:44:34PM +0100 References: <3ACDD652.6ACFA9AD@stray-toaster.co.uk> Message-ID: <20010406190727.A23844@blackstar.co.uk> Howdy,l On Fri, Apr 06, 2001 at 03:44:34PM +0100, Stray Toaster wrote: > So any suggestions? Anything you specifically want to hear? I'd quite like to hear about perl's soft, gooey internals. Perl! Soft on the inside, hard on the outside. The surprising alternative to ... um ... shells? awks? snakes? seas? ATB, Wesley. From schwern at pobox.com Sat Apr 7 07:19:58 2001 From: schwern at pobox.com (Michael G Schwern) Date: Tue Aug 3 23:54:03 2004 Subject: Meeting reminder!! In-Reply-To: <20010406190727.A23844@blackstar.co.uk>; from wesley@blackstar.co.uk on Fri, Apr 06, 2001 at 07:07:27PM +0100 References: <3ACDD652.6ACFA9AD@stray-toaster.co.uk> <20010406190727.A23844@blackstar.co.uk> Message-ID: <20010407131957.A548@blackrider.blackstar.co.uk> On Fri, Apr 06, 2001 at 07:07:27PM +0100, Wesley Darlington wrote: > On Fri, Apr 06, 2001 at 03:44:34PM +0100, Stray Toaster wrote: > > So any suggestions? Anything you specifically want to hear? > > I'd quite like to hear about perl's soft, gooey internals. > > Perl! Soft on the inside, hard on the outside. The surprising > alternative to ... um ... shells? awks? snakes? seas? Oddly enough, about all I really know about Perl's guts are pseudohashes (fairly dubious information) and something about the basic way that the basic data types are implemented. And maybe bits about the opcode tree. Nothing you can't already get from "Advanced Perl Programming" and the perlillguts man page. And yes, I am not a C programmer. * PS If anyone is good with X 4 configuration, I need help tweaking my laptop so it gets the sync rate right with the monitors at BlackStar so we're not all crowded around a 14" screen. Alternatively, someone could drag along a projector. * Incidentally, while Perl may have at some point in its history been written in C, it is actually now written almost entirely in a jumble of C preprocessor macros. -- Michael G. Schwern http://www.pobox.com/~schwern/ Perl6 Quality Assurance Kwalitee Is Job One Sometimes these hairstyles are exaggerated beyond the laws of physics - Unknown narrator speaking about Anime From mwk at stray-toaster.co.uk Sat Apr 7 07:23:25 2001 From: mwk at stray-toaster.co.uk (Stray Toaster) Date: Tue Aug 3 23:54:03 2004 Subject: agenda for monday. Message-ID: <3ACF06BD.3343C1B2@stray-toaster.co.uk> Just so it looks organised, here is a quick outline of the way things might go on Monday night. i. Greetings and welcome ii About belfast.pm a. Who and what we are b. What we believe in (ish, as this could turn nasty!!!!) c. What we want to achieve iii. Mike Schwern speaking. At length. On something. iv. Questions/discussion with said Mr. Schwern. v. Ideas for other meetings, be they technical or social vi. aob sounds nice and wooly. Anyone anything to add? I like the idea of technical meetings. (Not that I would nick ideas from anywhere, of course....) And there are enough Perl brains in the province (and within a few metre radius of me here) to entertain us on all sorts of Perl-ish things. So how about a few ideas, leading on from 'Ask Mike on Monday' to 'Ask a PerlGuru/Monk some other time'? m. From schwern at pobox.com Sat Apr 7 07:26:29 2001 From: schwern at pobox.com (Michael G Schwern) Date: Tue Aug 3 23:54:03 2004 Subject: /home/schwern/src/devel/ Message-ID: <20010407132629.B548@blackrider.blackstar.co.uk> Listed below are the directories from /home/schwern/src/devel/ on my laptop (minus various irrelevant things) which roughly correspond to stuff I can talk about (most are on CPAN). Pick some that look interesting and I'll yammer about them on Monday. Dunce Test AnyLoader Test-Harness Email-Find Test-More ExtUtils-MakeMaker Test-Simple Bone-Easy Testing CGI-Collective Function-Override Text-Metaphone Games-AirSuperiority Tie-Cache-LRU Geo-TigerLine Tie-Lazy Carp-Assert Geo-Walkabout Tie-Math Class-Accessor HTML-Style Tie-VecArray Class-DBI Ima-DBI Tree Class-Data-Inheritable JART Tree-Base Class-False MakeMaker_Stuff Tree-Smart Class-Fields Math-Prime-Cached Tree.tar.gz Class-MethRef Math-Tie UNIVERSAL-exports Class-Virtual PGPractices URI-Find Class-WhiteHole Perl_Refactoring Why_I_Am_Not_A_Java_Programmer Crypt-Blowfish Pod-Parser-Simple foundation Crypt-CBC Pod-Tests gotmail D-oh-Year RFC-Prototype DBD-Test Refactorings loose DNA SQL-Utils par Devel-Coverage Semi-Semicolons uny2k Digest-Adler Sex Stupid-Perl-Tricks -- Michael G. Schwern http://www.pobox.com/~schwern/ Perl6 Quality Assurance Kwalitee Is Job One I've heard that semen tastes different depending on diet. Is that true? Hello? Skrewtape: Hang on, I'm conducting research. From andrew at rivendale.net Sat Apr 7 16:38:18 2001 From: andrew at rivendale.net (Andrew) Date: Tue Aug 3 23:54:03 2004 Subject: Petition against software patents Message-ID: <20010407223818.B930@rivendale.net> Hi Guys I think you will all probably find this of interest. > On http://petition.eurolinux.org/ is a petition to the European > Parliament, urging them to reconsider the plans to allow software > patents. cheers Andrew -- Yet another Andy W From schwern at pobox.com Tue Apr 10 17:29:12 2001 From: schwern at pobox.com (Michael G Schwern) Date: Tue Aug 3 23:54:03 2004 Subject: Perl5+i Message-ID: <20010410232912.G511@blackrider.blackstar.co.uk> Perl5+i is Damian's imaginary and complex vision of what he would do if he was designing Perl 6. http://www.yetanother.org/damian/Perl5+i/ Nat asked me to spend the last two weeks putting together my take on a (partial) design for a new version of Perl, based around: the RFCs, the extensive feedback I've received whilst travelling around the world, talking about Perl 6 (now to over 500 people), my own fevered imagination. So please bear in mind that it is only a very rough sketch, thrown together from scratch in 9.5 days. Expect errors and inconsistencies all through it. More importantly: This is not the design for Perl 6! Essentially, its the best bits of the Perl 6 RFCs filtered through Damian's quinine addled mind. -- Michael G. Schwern http://www.pobox.com/~schwern/ Perl6 Quality Assurance Kwalitee Is Job One BOFH excuse #124: user to computer ration too low. From russell at futureless.org Thu Apr 19 09:53:41 2001 From: russell at futureless.org (Russell) Date: Tue Aug 3 23:54:03 2004 Subject: Next meeting...? Message-ID: <20010419145341.A8174@futureless.org> Hello, Is there going to be a meeting on Monday? If so, where, when and about what? It would be handy for me if I knew what it was about in advance so I could read up and not feel like a total newbie when people talk about tying variables and such :) Even if some of it went over my head, I did find it very interesting. Cheers, Russell, off to read a few perldocs to get up to speed -- Computers are useless. They can only give you answers. -- Pablo Picasso -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://mail.pm.org/archives/belfast-pm/attachments/20010419/d83d0d09/attachment.bin From mwk at stray-toaster.co.uk Thu Apr 19 10:27:00 2001 From: mwk at stray-toaster.co.uk (Stray Toaster) Date: Tue Aug 3 23:54:03 2004 Subject: Next meeting...? References: <20010419145341.A8174@futureless.org> Message-ID: <3ADF03C4.5BF0F6A9@stray-toaster.co.uk> Russell wrote: > Hello, > > Is there going to be a meeting on Monday? If so, where, when and about > what? It would be handy for me if I knew what it was about in advance so I > could read up and not feel like a total newbie when people talk about tying > variables and such :) Even if some of it went over my head, I did find it > very interesting. > > Cheers, > Russell, off to read a few perldocs to get up to speed > -- > Computers are useless. They can only give you answers. > -- Pablo Picasso OK, so I am going to get the blame for not telling when the next meeting is, or not updating the site, blahblahblah. The original intention was to have it on Mon 7th, but this is May Day, so I don't want to have to travel to Belfast needlessly. (Not that the meeting is needless, but hey), as if I was in work then I wouldn't have to go as far. If you see what I mean. So the next meeting will be on the 14th May. Hope that suits all and sundry! Included in that meeting will be the now infamous 3 hour talk that the Schwern will be giving at this years TPC. Wahey! I *will* update the site. honest. soon. m. From mwk at stray-toaster.co.uk Fri Apr 20 14:59:11 2001 From: mwk at stray-toaster.co.uk (Stray Toaster) Date: Tue Aug 3 23:54:03 2004 Subject: Next meeting...? References: <20010419145341.A8174@futureless.org> <3ADF03C4.5BF0F6A9@stray-toaster.co.uk> Message-ID: <3AE0950F.1B791811@stray-toaster.co.uk> Stray Toaster wrote: > I *will* update the site. honest. soon. > > m. hmm, it is updated. but only if you do http://belfast.pm.org/index.html Anyone any ideas why this does load when you go http://belfast.pm.org? Some sort of weird apache caching? Or something else? Should I have not opened my mouth? OK, so it is back to the fun project thing then. Anyone want to collaborate on something odd? Like who can write the most bizarre encryption algorithm? (It don't have to be hard to break, just fun! I vote for my ord-pack-unpack sort routine for the most mental thing done in a long time......don't ask....) Or someone to tell me I am not mad for using Inline::ASM.... m. -- perl -le '$_="6110>374086;2064208213:90<307;55";tr[0->][ LEOR!AUBGNSTY];print' From mwk at stray-toaster.co.uk Fri Apr 20 15:01:09 2001 From: mwk at stray-toaster.co.uk (Stray Toaster) Date: Tue Aug 3 23:54:03 2004 Subject: Next meeting...? References: <20010419145341.A8174@futureless.org> <3ADF03C4.5BF0F6A9@stray-toaster.co.uk> <3AE0950F.1B791811@stray-toaster.co.uk> Message-ID: <3AE09585.F842F667@stray-toaster.co.uk> > > > hmm, it is updated. but only if you do http://belfast.pm.org/index.html > > Anyone any ideas why this does load when you go http://belfast.pm.org? Some sort > of weird apache caching? Or something else? Should I have not opened my mouth? > No, I knew I shouldn't have opened my mouth.......it is fine now........... m. -- perl -le '$_="6110>374086;2064208213:90<307;55";tr[0->][ LEOR!AUBGNSTY];print' From mwk at stray-toaster.co.uk Fri Apr 27 17:24:21 2001 From: mwk at stray-toaster.co.uk (Stray Toaster) Date: Tue Aug 3 23:54:03 2004 Subject: tee-shirts Message-ID: <3AE9F195.85931150@stray-toaster.co.uk> Heyheyhey! This has been mentioned to me before, and I thought I would post about it while I am feeling, erm, jolly. Not the best time to post, but hey, I am not a Graham Norton fan, and Val is, so I use the machine. c'est la whatsit. Anyhow. Belfast.pm needs tee-shirts. To wear to the next YAPC::Europe. Which we can talk about during one of our meets, to see who wants to go. (I will be, but don't let that put you off.) And all wear our tee-shirts proclaiming who we are. btw it is in Amsterdam, if that entices you. Last year it was in London, and was pretty funky. I can extrapolate on that if anyone ever asks. Or ask Schwern why he was hoarse the next morning. :-) Oh, teeshirts. Right. I fancy a range. Then our own store........but that is getting ahead of myself. First the shirt, then the world....... I want suggestions. Front and back print. My go first. Front: 'Free the unreferenced scalars!' (slanted, poss 45 deg, in jailbreak sorta font.) Back: 'Republic of perl camel logo with Belfast.pm slashed across it.' any refinements? comments? other ideas? ....... monkey tennis? m. -- q/ever since I could talk i was ordered to listen/; From schwern at pobox.com Fri Apr 27 17:39:31 2001 From: schwern at pobox.com (Michael G Schwern) Date: Tue Aug 3 23:54:03 2004 Subject: tee-shirts In-Reply-To: <3AE9F195.85931150@stray-toaster.co.uk>; from mwk@stray-toaster.co.uk on Fri, Apr 27, 2001 at 11:24:21PM +0100 References: <3AE9F195.85931150@stray-toaster.co.uk> Message-ID: <20010427233931.Q545@blackrider.blackstar.co.uk> On Fri, Apr 27, 2001 at 11:24:21PM +0100, Stray Toaster wrote: > Front: 'Free the unreferenced scalars!' (slanted, poss 45 deg, in > jailbreak sorta font.) > Back: 'Republic of perl camel logo with Belfast.pm slashed across it.' > > any refinements? comments? other ideas? ....... monkey tennis? 'Attempt to free unreferenced scalar during global destruction' has a nice apocalyptic theme. 'Bad free() ignored during global destruction' -- Michael G. Schwern http://www.pobox.com/~schwern/ Perl6 Quality Assurance Kwalitee Is Job One You will feel tremendous pain at the area where foreign materials are inserted. I usually don't recommend anyone to insert artificial materials. Keep everything natural is best! --Alex Chiu, Immortality Guy From tony at blackstar.co.uk Sat Apr 28 09:49:00 2001 From: tony at blackstar.co.uk (Tony Bowden) Date: Tue Aug 3 23:54:03 2004 Subject: tee-shirts In-Reply-To: <3AE9F195.85931150@stray-toaster.co.uk>; from mwk@stray-toaster.co.uk on Fri, Apr 27, 2001 at 11:24:21PM +0100 References: <3AE9F195.85931150@stray-toaster.co.uk> Message-ID: <20010428154900.A19691@blackstar.co.uk> On Fri, Apr 27, 2001 at 11:24:21PM +0100, Stray Toaster wrote: > Front: 'Free the unreferenced scalars!' (slanted, poss 45 deg, in > jailbreak sorta font.) I like " during global destruction". But I can't think what the first bit would be. Best contender so far might be "unbalanced string table ...", but that's still not quite there ... FWP had "too late for regrets during global destruction" which I like, but it was too contrived[1]. Perhaps "Can't find during global destruction", where is something good? We could go with a whole series of error messages. I also quite like "useless use of time in a void context" Tony [1] Although a much more obfuscated version would make a good .sig: perl -e 'sub DESTROY { warn "Too late for regrets" } $_=bless []' -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://mail.pm.org/archives/belfast-pm/attachments/20010428/a9f0b1f5/attachment.bin From mwk at stray-toaster.co.uk Sat Apr 28 11:09:02 2001 From: mwk at stray-toaster.co.uk (Stray Toaster) Date: Tue Aug 3 23:54:03 2004 Subject: tee-shirts References: <3AE9F195.85931150@stray-toaster.co.uk> <20010428154900.A19691@blackstar.co.uk> Message-ID: <3AEAEB1D.C22657D0@stray-toaster.co.uk> Tony Bowden wrote: > We could go with a whole series of error messages. > Yes!! > > I also quite like "useless use of time in a void context" > or 'useless use of constant time in a void context'? > perl -e 'sub DESTROY { warn "Too late for regrets" } $_=bless []' > This is *do* like! m. From sleepy_uk at hotmail.com Sun Apr 29 07:59:45 2001 From: sleepy_uk at hotmail.com (Scott McWhirter) Date: Tue Aug 3 23:54:03 2004 Subject: tee-shirts Message-ID: >Perhaps "Can't find during global destruction", where >is something good? "Can't find $chocolate during global destruction"??? -- -Scott- _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From duggie-belfast-pm at blackstar.co.uk Mon Apr 30 07:18:45 2001 From: duggie-belfast-pm at blackstar.co.uk (duggie-belfast-pm@blackstar.co.uk) Date: Tue Aug 3 23:54:03 2004 Subject: tee-shirts In-Reply-To: <20010428154900.A19691@blackstar.co.uk>; from tony@blackstar.co.uk on Sat, Apr 28, 2001 at 03:49:00PM +0100 References: <3AE9F195.85931150@stray-toaster.co.uk> <20010428154900.A19691@blackstar.co.uk> Message-ID: <20010430131845.A1541@blackstar.co.uk> On (28/04/01 15:49), Tony Bowden wrote: > Perhaps "Can't find during global destruction", where > is something good? An appropriate one for Amsterdam... "Can't find hash during global destruction" Duggie