Larry Wall's Apocalypse series -- explaining what Perl 6 will look like -- is in the third installment, Operators. Read and enjoy!
Re:hyperoperators
koschei on 2001-10-05T01:07:29
Intriguing syntax you've introduced there.
Does it cope well if you introduce more operands? e.g.
@e = map ( { $d + $c } @d, map ( {$c + $b } @c, map ( {$a + $b} @a, @b ))
My apologies if I lost track of parens. It's a bit noisy compared to:
@e = @a ^+ @b ^+ @c ^+ @dmap {} will probably just provide more power. We'll see when he gets to Apocalypse 29 ("Functions"). That's assuming he doesn't skip any numbers =)Re:hyperoperators
hans on 2001-10-05T15:39:19
I don't think you need the parens here. It all depends how automatic list flattening is handled: is map {} @a,@b the same as map {} @c?? I thought of the $a and $b as similar to the ones used in sort(). Its just chance that they use the same symbols (a and b) as the argument lists.
Your example would write:
@e=map {$a+$b} @d, map {$a+$b} @c, map {$a+$b} @a,@b
One could even introduce an arbitrary number of parameter lists. In that case:
@e=map {$a+$b+$c+$d} @a,@b,@c,@d
Of course Larry knows a bit more about language design. Those are just armchair musings of somebody who regrets not having enough time to be directly involved.Re:hyperoperators
swiftone on 2001-10-05T17:05:00
(this is all my conjecture)
For one, it moves away from a functional interface to an operator interface, which may be more line-noisy, but I think is cleaner. Count the line-noise symbols in your two statements.
Two, I seem to recall reading some discussion about trying to get rid of $a and $b. (Could be wrong).
Three, it's a different way of looking at it. with map you are doing something to a set of data. Your view of that data is abstracted through map(), which makes this less intuitive to the new user. With an operator, its really the same concept as the base operator, applied over the list. Much easier for the new programmer
Re:use Perl5;
koschei on 2001-10-05T02:57:48
Just out of interest, and this leapt out at me while reading the Apocalypse, isn't the term "ternary" rather than "trinary"?Re:use Perl5;
belg4mit on 2001-10-05T03:11:07
Nope. Trinary as in triple. Ternary would seem to be an attempt at forming a quadruple.
It's in the perl 5 man pages as well, and elsewhere (JavaScript)Re:use Perl5;
Damian on 2001-10-05T04:56:15
Nope. Trinary as in triple.
...is a valid, though less common, alternative to the more widely used "ternary".
Ternary would seem to be an attempt at forming a quadruple.
Err...not in English (or Latin):
ternarius -- "Consisting of three"
quaternarius -- "Consisting of four"
"Trinary" appears to be a 15th century back-formation from "binary".Re:use Perl5;
belg4mit on 2001-10-05T05:08:18
Huh, well okay then.
Though *my* webster says ternary is from Middle English from Latin terni and trinary is straight from Latin trini.
Both trini and terni meaning "three each".Re:use Perl5;
chromatic on 2001-10-05T06:08:43
"Trinary" appears to be a 15th century back-formation from "binary".So all those old mainframe guys who had to program a database using only zeros (ones having been invented rather later) are even older than we thought? Lends credence to the Ascended Masters theory of data warehousing, anyway.
(never let the fact that 1 predated 0 in Western thought get in the way of a lame joke)
Re:use Perl5;
Matts on 2001-10-05T08:23:36
Seriously am I the only one not looking forward to many of the new "features" in Perl6?
No, you're not the only one.
Of course this is all going to be open source, so the market will choose, rather than marketing. Personally I think a fork would be a good idea here. A sort of Perl 5 with a parrot backend, but with extended syntax to make classes easier and cleaner, and maybe make XS type stuff easier (though I think that's kinda covered by Inline.pm now) and *thats all*.
These were issues that Chip was trying to solve with Topaz, and Perl6 (the language) doesn't seem to be heading in those directions. Luckily parrot does look cool, and I think it's the one part of this project that's bound to survive in some form or other, assuming converting regexps to parrot opcodes works well at some point.Re:use Perl5;
Trey on 2001-10-05T15:31:29
I heard the same rhetoric about Perl 5 when people were wedded to Perl 4 ("hopefully there'll be a fork so I won't have to use this OO crap," etc.). And, indeed, there are people to this day who insist on writing Perl 4 syntax (which is why I always throw semi-hairy Perl 5 syntax at people who are interviewing for Perl positions--I don't want to deal with reading their code).Human language evolves. And Perl, as the most human of computer languages, will evolve too. Along that line--one of the characteristics of human language change is that cumbersome expressions become elided over time (photocopier->copier, coup d'etat->coup). The hyperoperator is the first thing I've seen of Perl 6 that seems to map to that space (pardon the pun). I was kind of expecting a "Schwartzian transform" operator, myself.
:-) Re:use Perl5;
belg4mit on 2001-10-05T17:27:00
Thing is though, 4 isn't *all* that different from
5. I started with 4 and 5 together an the only thing I really ever had to bang my head against was the lack of lc and uc...Re:use Perl5;
Matts on 2001-10-05T21:26:53
The big difference here is this isn't evolution - it's rebirth. For Perl 5 Larry added a few simple keywords (e.g. bless()), and thus was born OO perl. With Perl 6, out goes the baby with the bathwater.
Sorry, but I support Simon Cozen's RFC (I hope I'm remembering it right) - leave perl as it is, barring some new syntax for better class support. And hopefully the parrot backend. If you look at the original plans for Topaz (cleaner internals, easier extensibility - keep the current syntax), those are similar goals. I *know* we needed to kickstart the community into action, and we've achieved amazing things (Parrot) in just over a year, but maybe it's time for a rethink?
PS: I really don't see a problem in fixing a syntax error in if ($x < $y <= 10) when the compiler tells you it's wrong and add in the extra && yRe:use Perl5;
swiftone on 2001-10-05T17:08:01
You aren't the only one based on the comments I've seen, but I for one am eagerly awaiting Perl6.
Yes, I'll have to relearn a lot of Perl syntax. Well worth it to get a cleaner interface. (One of my dearest wishes is for a vastly improved subroutine arg-passing interface).
Yes, it may confuse some experienced people, but remember why you came to Perl inthe first place and see if Perl6 is or is not moreso.
Re:use Perl5;
belg4mit on 2001-10-05T17:31:22
I like Perl because it doesn't tell me what to do:
loose typing
TMTOWTDI
no forced scope variables...
etc. etc. etc.
And so much of the core things happening for Perl6
seem to be in direct conflict with this.
"I'm smarter than the computer (and hence language) damnit, let me do it *my* way."
Or at least:
"I *think* I'm smarter than the computer damnit,
let me shoot myself in the foot if that's what I really want to do"
AKA
The UN*X philosophy.
As opposed to "Save me from myself".Re:use Perl5;
Trey on 2001-10-05T18:15:08
I like Perl because it doesn't tell me what to do: [...] And so much of the core things happening for Perl6 seem to be in direct conflict with this.I must disagree. The things unveiled so far seem to be if anything much DWIM-ier than previous Perls. For gossakes, why doesn't if ($x work?
Re:use Perl5;
Trey on 2001-10-05T18:17:18
Yipes, I hate it when I hit "Submit" when I mean to hit "Preview".:-)
Don't squint--that shouldn't work, I don't know what it would mean. I meant to say, why doesn't if ($x < $y <= 10) work.:-)
