Slashdot Mirror
Exegesis 6 (Perl 6 Subroutines) Released
chromatic writes "Perl.com has just published Damian Conway's Exegesis 6 which gives practical examples demonstrating how to use the new subroutine and method semantics in Perl 6. This is the companion to Larry Wall's Apocalypse 6 which discussed the changes planned for subroutines in Perl 6."
Why would someone who is reading an article about Perl 6 Subroutines need a copy of Learning Perl?
Why did you post the Amazon review without giving credit?
Why will your post be moderated up nonetheless?
sub Fahrenheit_to_Kelvin (Num $temp is rw) {
... ; :-)
Verbosity in coding, yeah that will go over well with people who are used to
int lbn, rax,
Don't get me wrong I'm a big fan of Perl, but not for its completeness as a language but for the ability to quickly write small utils to parse text.
But I suppose whatever floats peoples boats.
Tom
Someday, I'll have a real sig.
BTW, a nondeterministic finite automaton is much less flexible than ordinary code; there are many things (checking for palindromes being the classic example) which code in a programming language can do but an NFA (and hence a regular expression) cannot. What you mean is that regexps provide a more concise syntax, and perhaps a more efficient implementation (since the regexp engine is in C).
Perl's so-called regular expressions are not true NFAs however, because they have wacky things like backreferences. In fact they are NP-complete.
-- Ed Avis ed@membled.com
He posts it on every Perl story, unchanged, without evidence of reading anything beyond the world "Perl" in the blurb. That's not insight. That's obsession.
Read the last page of Exegesis 6 to see the Perl 5 version of the code. It's astonishingly simpler and clearer in Perl 6.
See the Inline modules on the CPAN.
See Perl Design Paterns, an article on Perl.com.
See the CPAN.
I've read the Perl parser. You're right about this one.
how to invest, a novice's guide
Having a weakly typed language is not an advantage
.NET has really solved this problem, but making it strongly typed, but every typed is derived from 'object', which has a pure virtual 'ToString' which allows you to easily convert anything to a string suitable for printing. Can you see the advantage here?
.Net isn't actually a language, but a Microsoft product that encompasses the .Net runtime, which in turn encompases C#... kind of like calling Java JSP).
You're confusing variable glyphs with typing. While variable glyphs in Perl do indicate something about the typing, they are not type identifiers.
I was pointing out the advantages of glyphs, not types.
Apparently, script programmers cant deal with specifying that something is an 'int' or 'float' or whatever
Script is a misused word here, since the term litterally means a collection of commands as a user would have typed them, and while you can write Perl code that looks kind of like that, it's certainly not the way Perl is used). Shell programs aren't even always scripts (just look at your average configure program). Don't contribute to watering down the word, especially if you're just doing so to make the "what makes us real programmers special" weak assertion.
Ok, that said, Perl does offer typing, but only when you really need it. Since strong typing isn't needed in perl by default (Perl 5 and under have no real compilation mechanism, so the performance gains would be minimal), all you really need is to type *data* not *variables*.
You can type data using any number of tools in Perl including pack, unpack, sprintf and vec.
In Perl 6, there will be a just in time compiler, and eventually a stand-alone binary compiler. This introduces the need to access system types in a more rigorous way, and Perl 6 has typing features such as you would find in any other language. Of course, $x = $y will still work regardless of types (though it could cause a compile or run-time error if they are excplicitly incompatible, but that's not going to happen unless you really mean for it to).
That's the approach of about 5-10 DOZEN languages (literally) over the last 10-20 years. Let's not credit C# with the "innovation" of objects as the only first-class data types (I assume you mean C#, since
Perl 6 is going down the same route as did Python (long before C#).
Perl 5 has fairly primative roots, and given those roots its typing system made sense at the time. Perl 5 does also have a universal base-class for all objects, but not all types are objects in Perl 5. They will be in Perl 6.
That particular piece of Perl 6 functionality would have to be expressed as that particular chunk of Perl 5 code to get a comparable effect. Fine.
My personal concern is in how in the preceeding 10 pages, he describes another umpteen "simpler and clearer" ways of achieving the same effect (most of which seem to have subtle gotchas).
Anyway, it looks like *somebody* is getting defensive about being a script programmer
.NET supports... VB.NET, C#, J#, etc.
.Net also supports many languages which do not share this typing system. The .Net libraries may use that typing system internally, but that's because they are written in, or at least primarily written for C#.
Not at all. I'm simply not.
When I spend most of my day working on libraries that are used by a suite of tools, each of which is as modular and re-usable as possible, I find it hard to refer to that as "script programming".
The gulf between those two jobs is about as wide as the gulf between Web Master and C# programmer.
I meant any language that
Then you are incorrect, since
Again, you are making a broad an inaccurate comparison between vastly different scopes.
That's a fair concern.
Damian intended to demonstrate as many of the new features as possible while reusing one example and progressing through more and more powerful techniques. He thought it'd be simpler and easier to understand. It's a difficult article to write, no matter how you approach it, since it summarizes to a list of "Here's another way to do that, having these advantages and these disadvantages:" statements.
I think he suceeded, but it's also possible that I'm too close to the material to judge this accurately.
how to invest, a novice's guide
if they want to get anywhere near Lisp-level flexibility with this method they'll need to move to Unicode for the syntax!
Ok, first off... Perl 6 will use Unicode by default, of course, and yes there is some talk of using things like the dot-product symbol to mean roughly what you would expect it to mean. However, that is limited by the practicality of entering and viewing Unicode characters with modern equipment. Perhaps in another 10 years....
Now, that being said, I would argue that Perl 5 already presents 99% of Lisp's flexibility. Perl 6 leap-frogs Lisp by presenting Lisp's flexibility in a package that is far easier to use (though, as you point out, perhaps not easier to LEARN).
You already had the $,@,%,& to prefix variables with.
But in Perl 6, they are rationalized a great deal, and made simpler to use (e.g. Perl used to use the glyph to indicate the type of operation being performed on a variable, no the type of the variable. In Perl 6, that has been changed to reflect what most programmers expect, so @foo[0] is the correct notation for accessing the zeroth element of an array, not Perl 5's $foo[0]).
Perl 6 is going ot be hard for outsiders to jump into at this stage because it doesn't exist yet. If you're not steeped in the culture of Perl 6's design, you won't be able to see where it's going, so everything looks kind of scary.
However, in about 10 years, I expect Perl 6 to be seen as the starting point of a new kind of programming and a level of symbolic abstraction that allows us to start looking at code in a much more constructive way.
The old Perl way would have been to say "Look, now we have a simple parameter passing scheme like that one Python, one which has been proven to work." The Perl 6 way is to start with a series of odd little features, then keep modifying them and adding sugar to them until the end result, after a number of iterations of this, ends up being something that looks and works like Python's parameter passing scheme, but takes ten pages of explaining to fully explain,
This thought keeps occurring to me. Actually, without any intent to devolve into a Perl vs. Python flamewar, I've been thinking that a lot with quite a few of these Exegesises. Python certainly doesn't have all of what's supposed to go into Perl 6, but it has a lot of it already there, and a lot of the other stuff isn't necessary because that's just not the way things work in Python.
To be fair, Perl is letting you limit the incoming parameters via code, whereas Python limits them via philosophy ("Better to ask forgiveness")... but for all that verbiage, that's about all Perl 6 can do with parameter passing that Python can't.
(Anyone adding pipelines to code I have to subsequently maintain will be shot without trial. I don't care how nifty the feature is, you're better off writing it longhand under nearly all circumstances for maintainability.)
Some nifty ideas here, though; I'm tempted to see if I can't implement "any" and "all" in terms of Python, at least for in-program comparisions. (Although Python is clean... I wonder how many of the cute tricks would subsequently propogate correctly and work correctly as well...?)
Ok, I must clarify a few things:
(though Perl 6 comes as close as a truely compiled language reasonably can)
I can't believe I even read that. Perhaps you are just trolling, but for the sake of those who do not know better, lisp is actually more of a truly compiled language than perl. Perl is interpretted by the perl interpreter (aptly named perl). Lisp is compiled down to machine code.
Secondly, this Exegesis covered Perl6's macro capabilities. It works very much like lisps, actually. Granted, my personal feeling is that it is easier to have a program write a program that is written in s-exps than in Perl 6, but Perl 6 does provide the capability.
The options mentioned in this Exegesis point out that macros in Perl 6 can return either blocks or strings. If a block is returned, its syntax tree is injected into the place occupied by the call to the macro. If a string is returned, it replaces the macro call, and then the resulting expression is parsed and compiled. All of this is done at compile-time, of course.
Secondly, and very interestingly, macros can define their own syntax using Rules (regexps) to pull parameters from free-form program text, rather than relying in the comma-separated Perl6 expression default.
All in all, if this can be implemented as they have described, in an efficient manner, I will be impressed. It seems very lispy to me, they've just moved the parsing code from the programmer's brain (since you are effectively writing parse trees rather than syntax when programming in lisp) to a parsing module within the code.
Remember though folks, if you don't want to deal with this complexity, you don't need to. But if you do need to, its good to know that its there.
I see Perl 6 as kind of a pantheon of programming gurus, and you can subscribe to whichever you like (or tell them all to screw off). The most important thing about Perl 6 is you can use whatever programming style suits you best. In a corporate environment, that style can even be dictated down by the powers that be, too. If you're one of those people that thinks that Lisp (et all) is (or is not) understandable, or thinks Java is a brain-dead C++, or that C++ is error prone Java, then Perl 6 may not be for you. You let (percieved) flaws obscure the important benefits, and as a result you miss out. Objectively, you would be examining the trade off between learning curve and increased efficiency over the time period of the project. In many cases, it is in fact better to stick with the tool you know, even if a different tool would be twice as effecient. Since it's just not possible to learn every single tool available, as professionals, we have to pick the most effective set of tools that we care to know given our interests and other expertise. This brings us around to the great thing about Perl 6: in one cohesive, sensible framework, it gives you really broad coverage. You don't have to learn it all at once--you start out using Perl 6 like Perl 5; then when you decide you want to do some lispy type things, you don't have to learn Lisp and a whole new toolchain, you can learn to do lispy types things in Perl. If you want to do things that would be well suited for C++ templates, you can learn the Perl 6 mechanisms for it instead of undertaking C++. And what is really, amazingly cool is that Perl 6 is shaping up to be a cohesive, well considered framework; it's not a jumble of competing ideas that don't play nicely with each other.
If you've worked with C++ templates and metaprogramming, then you certainly understand the benefits being offered by a lot of the Perl 6 constructs. But the Perl 6 way is much more comprehensive, direct, clear, and intentional. Everything with blocks, anonymous subs, closures, multi methods, named parameters, operator overloading, and macors offers unbelievable oportunities for meta-programming. Once Perl 6 gets rolling and starts developing its own equivalent of Boost, then programming will never be the same. Boost changed everything already, but you've probably never heard of it; but Perl 6 will have mainstream appeal, acceptance, and use that Boost will never have.
if (is_true) parse(); else exit(0);
perl's statement if (condition) is nice, but I feel it only exists to make up for the lame if/elsif/else support.
Honestly, I wonder why if/else/elsif blocks need to be enclosed with {}. C has shift/reduce error, but perl is context-sensitive, so it can't be explained by language purity.
Do you even lift?
These aren't the 'roids you're looking for.