Larry's Apocalypse 1
Not a comment at all on it? Was I accidentally unsubscribed to perl6-language? *tap* *tap* is this thing on? Nat
RE: Larry's Apocalypse 1
I think we were all just stunned by the sheer brilliance. :^) That package
thing is pretty damn clever...
--Brent Dax
[EMAIL PROTECTED]
This e-mail is a circumvention device as defined by the Digital Millennium
Copyright Act.
#qrpff
s''$/=\2048;while(){G=29;R=142;if((@a=unqT="C*",_)[20]48){D=89;_=unqb24,q
T,@
b=map{ord
qB8,unqb8,qT,_^$a[--D]}@INC;s/...$/1$/;Q=unqV,qb25,_;H=73;O=$b[4]9
|256|$b[3];Q=Q8^(P=(E=255)(Q12^Q4^Q/8^Q))17,O=O8^(E(F=(S=O147
^O)
^S*8^S6))9,_=(map{U=_%16orE^=R^=110(S=(unqT,"\xb\ntd\xbz\x14d")[_/16%8]
);E
^=(72,@z=(64,72,G^=12*(U-2?0:S17)),H^=_%64?12:0,@z)[_%8]}(16..271))[_]^((D
=8
)+=P+(~FE))for@a[128..$#a]}print+qT,@a}';s/[D-HO-U_]/\$$/g;s/q/pack+/g;eva
l
-Original Message-
From: Nathan Torkington [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 04, 2001 23.46
To: [EMAIL PROTECTED]
Subject: Larry's Apocalypse 1
Not a comment at all on it? Was I accidentally unsubscribed to
perl6-language?
*tap* *tap* is this thing on?
Nat
Re: Larry's Apocalypse 1
Nathan Torkington [EMAIL PROTECTED] writes: Not a comment at all on it? Was I accidentally unsubscribed to perl6-language? *tap* *tap* is this thing on? Using module/class instead of package is exactly the same route that LaTeX took in the transition from 2.09 to 2e. It works quite well, and has also meant that because of the automatic triggering of the compatibility code, there are still lots of 2.09 documents out there, what, 10 years later? that still process just fine with current versions of LaTeX. The rest of what Larry said included little that wasn't about what I expected, so I didn't have much additional response, apart from saying that that was rather more Perl 5 compatibility than I was expecting. Interesting. Oh, and I wholeheartedly approve of the approach to handling objects. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Perl culture, perl readabillity
Piers Cawley wrote: be "If it's a word for a concept we don't actually have a word for, and it's not a complete and utter bastard to pronounce/spell then nick it." s/not//; s/nick/bastardize/; :-) -- John Porter
Re: Larry's Apocalypse 1
In his Apoc, he talks about thrashing, and not being able to get his brain around things. I'm dealing with that now. Give me a little more time to divide it into smaller portions and chew it up. JJ * Nathan Torkington ([EMAIL PROTECTED]) [010405 02:50]: Not a comment at all on it? Was I accidentally unsubscribed to perl6-language? *tap* *tap* is this thing on? Nat -- J. J. Horner [EMAIL PROTECTED] Apache, Perl, mod_perl, Web security, Linux PGP signature
Re: Larry's Apocalypse 1
I tried to comment on "apocalypse" in Larry's most likely sense, but there was a mail flub (now corrected). Apocalypse is a greek word meaning that which comes out from (apo- eq away from) hiding, i.e., revelation. In the biblical sense, it refers to revealing that which was previously unseen or unheard, hidden behind a veil of worlds or time, as John used it. In social english, it refers to "the time of tribulation", which is not precisely relevant, not precisely biblical, but it's good to make sure that it's not interpreted in this way, since it is not Larry's intention to declare these things as "the last and final" or as something horrible and trying. I assumed that Larry's use was more of "reading the book and letting the ideas flow out, from their hiding place between the lines, in a natural order", i.e., "ordered brainstorming", for a loosely translated oxymoron. Anyway, you were wondering about Larry's choice of words. I just thought it was neat and wanted to share. I like like Larry's linguistic plays on words. As a linguist (philologist) myself, they usually make sense to me, and he tends to pop in little jokes to see who's paying attention. I can see those linguist influences in Perl too, and that's one important thing that likely attracted me to Perl in the first place. I just hope that Larry and the Perl 6 designers don't lose this, and don't forget to have "fun" with the language while designing it (just not in the makefiles... xcopy /f /r /i /e /d indeed). p Nathan Torkington [EMAIL PROTECTED] wrote: Not a comment at all on it? Was I accidentally unsubscribed to perl6-language? *tap* *tap* is this thing on? Nat
Re: Larry's Apocalypse 1
At 11:46 PM 4/4/01 -0700, Nathan Torkington wrote: Not a comment at all on it? Was I accidentally unsubscribed to perl6-language? *tap* *tap* is this thing on? Some of us got to reading Damian's design for Perl 5+i which was announced at the same time and are suffering from blown minds after learning how fast he wrote the thing. Oh, and who put him up to that, eh? -- Peter Scott Pacific Systems Design Technologies
Re: Larry's Apocalypse 1
All I could think was, "good thing the 3rd Camel came out before Larry
used it to classify RFCs." :)
I am glad RFC 141 was rejected, even if Larry claims it was for
entertainment value. For the same reason people feel the need to explain
the use of "apocalypse", the design of Perl 6 should not focus on being
the final "thing", even if everyone believes it will be. This would rob
Jon of future tantrum opportunities.
I was very glad to see Larry address RFC 28 in the way he did; this will
be quoted often in the future, both concerning being "needlessly fearful"
of Perl adopting a different language paradigm, as well as the "essence"
of Perl being context sensitivity ("Perl culture, Perl readability"
threaders take note).
The example suggestion about breaking the @foo -- $foo[] relationship is
a perfect indicator of where he sees this going: breaking some behaviour
to gain consistency in context treatment. I think such "courage" as he
puts it is absolutely worth the benefit. I want to see more paragraphs
like this in future documents; they really give a glimpse into what he
wants to happen.
I agree with what has been said regarding the "package" vs.
"module/class/blah" 5/6 differentiation. Keep it simple. It won't be long
before we (I) scoff at a module starting with "package" the way we (I) do
now with "require cgi_lib.pl;". Kidding.
I think there is much discussion to be had concerning RFC 73, regarding
Larry's suggestion that core functions return objects that are struct
tm's. I'm wondering what Chip thinks about this. Also, I'm wondering if
the intent of the RFC was what Larry describes. References to 48 suggest
list, array, arrayref, hash, and hashref contexts, in addition to scalar
and string. Does Larry feel that all of these are important? I guess we're
not talking about 48, though. :)
Re: Larry's Apocalypse 1
Peter Scott wrote: Some of us got to reading Damian's design for Perl 5+i which was announced at the same time and are suffering from blown minds after learning how fast he wrote the thing. Consider how blown his mind is after WRITING it :-) Oh, and who put him up to that, eh? I'm sure I'd have no vested interest in giving Larry a bunch of consistent interesting suggestions. :-) Nat
Re: Larry's Apocalypse 1
On Thu, Apr 05, 2001 at 12:28:34PM -0600, Dan Brian wrote:
I was very glad to see Larry address RFC 28 in the way he did; this will
be quoted often in the future, both concerning being "needlessly fearful"
of Perl adopting a different language paradigm, as well as the "essence"
of Perl being context sensitivity ("Perl culture, Perl readability"
threaders take note).
As author of that RFC I can categorically state that Larry was not its target
audience. :)
I think there is much discussion to be had concerning RFC 73, regarding
Larry's suggestion that core functions return objects that are struct
tm's.
If it can be done *transparently*, as Larry suggests, it keeps everyone happy.
Or upsets everyone equally, at least. To make a particularly tasteless
analogy, object-oriented programming is like smoking[1]; I have no problems
with making it legal, but I do object to making it compulsory.
[1] I was going to be more tasteless, but thought better of it.
--
Feed me on TOASTIES! There's no HALL for PHILOSOPHERS ON FRIDAYS.
- Henry Braun is Oxford Zippy
Re: Larry's Apocalypse 1
On Thu, Apr 05, 2001 at 11:42:23AM +, David Grove wrote:
Apocalypse is a greek word meaning that which comes out from (apo- eq away
from) hiding, i.e., revelation. In the biblical sense, it refers to
revealing that which was previously unseen or unheard, hidden behind a
veil of worlds or time, as John used it.
Urgh. I'm not letting that go without a pedant point. :) apokalupsis is the
ordinary NT Greek word for revealing or uncovering.[1] John only uses it the
once, in the title of his book.
Amusingly, Paul uses it in the phrase "apokalupsews dikaiokrisias". ("the
pronouncement of a fair judgment".) Let's hope that Larry's Apocalypses live
up to this ideal. :)
[1]Strong's says "disclosure: appearing, coming, lighten, manifestation, be
releaved, revelation".
--
I cannot and will not cut my conscience to fit this year's fashions.
-- Lillian Hellman
Re: Larry's Apocalypse 1
On Thu, Apr 05, 2001 at 12:15:19PM -0700, Nathan Wiger wrote:
That is, every
Perl 6 program begins with "module main". Maybe there's a better way to
implement this? ("use 6.0" has much the same problem)
"IDENTIFICATION DIVISION"
--
DISCLAIMER:
Use of this advanced computing technology does not imply an endorsement
of Western industrial civilization.
[Fwd: http://dev.perl.org/rfc/73.html]
Title: http://dev.perl.org/rfc/73.html
[25]RFC 73: All Perl core functions should return objects
[...]
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.
Neil Watkiss [EMAIL PROTECTED] and Brian Ingerson [EMAIL PROTECTED] have been roughing out ideas for a Inline::Struct module which sounds similar if not related to the this. It's primary objective is simpilfying passing structured data between Perl and C/C++. It also makes a struct look like a Perl object. There is an unreleased module implementing a C++ interface which works quite well. A C version is planned as well. Others may follow. Right now, it works like this:
use Inline CPP = 'END', STRUCTS = ['Foo'];
struct Foo {
int inum;
double dnum;
char *str;
};
typedef struct Foo Foo;
END
my $o = new Inline::Struct::Foo;
$o-inum(10);
$o-dnum(3.1415);
$o-str('Wazzup?');
my %fields = %{$o-_HASH};
my @keys = @{$o-_KEYS};
my @fields = @{$o-_ARRAY};
package Inline::Struct::Foo;
sub Print {
my $o = shift;
print Foo {\n, (join \n, map { $o-$_() } $o-_KEYS), }\n;
}
__END__
Anything that is typemap'd can be used. I'm hoping Inline::Struct will evolve into the compiled complement to Class::Struct. If Perl 6 could do this without requiring a compiler on hand, it would be the perfect replacement/evolution of Class::Struct.
Garrett
Re: Larry's Apocalypse 1
At 08:25 PM 4/5/2001 +0100, Simon Cozens wrote:
On Thu, Apr 05, 2001 at 12:15:19PM -0700, Nathan Wiger wrote:
That is, every
Perl 6 program begins with "module main". Maybe there's a better way to
implement this? ("use 6.0" has much the same problem)
"IDENTIFICATION DIVISION"
For some reason that brings to mind scenes from _Brazil_. (And not the
happy ending version :) I'm not sure if that's a good thing or a bad thing...
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Larry's Apocalypse 1
At 12:15 PM 4/5/2001 -0700, Nathan Wiger wrote:
1. Breaking @foo vs. $foo[]
This is interesting, and in my gut I like it. Many people I've worked
with end up writing:
@foo[0]
Which works. But then, they're completely confused by why:
%foo{key}
Doesn't.
Or why
@foo[0] = BAR;
does really odd things...
2. package vs. module/class
Whoa. This is so simple yet so sublime. It solves so many issues in one
swoop. Cool.
Assuming Perl6 will be parsing Perl5 code? Hmmm. That's interesting.
Forget p52p6 and the whole 80/20 thing, we could potentially hit the
100% mark.
I'd really rather not, and I don't think that was Larry's intention. I
think rather it was "perl 5 warning/strict levels", not "parse as perl 5
code". At least I hope that's the case...
I'm unsure about the "module main" idea. I like that modules as a whole
are strict/-w by default. But the "module main" tag causes the same
problem Larry is opposed to with BASIC/PLUS "EXTEND". That is, every
Perl 6 program begins with "module main". Maybe there's a better way to
implement this? ("use 6.0" has much the same problem)
Most likely you'll just see the normal "use strict; use warnings;" at the
top of the main program, if that's what folks want.
3. Core functions return objects (RFC73)
Woo-hoo! :-) I hope this works out.
Well, it was probably going to anyway, so this isn't a big deal from an
internals standpoint. Heck, we could do it now with perl 5, if we wanted to
write enough overloaded stuff and put it into the core. (We could even make
perl 5 completely OO if you wanted to write some code for the
SCALAR/HASH/ARRAY packages. Presumably in C, if you wanted to do:
$foo = "12";
print $foo-POK;
to retrieve the POK flag, say.)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Larry's Apocalypse 1
On Thu, Apr 05, 2001 at 03:50:04PM -0400, Dan Sugalski wrote: (We could even make perl 5 completely OO if you wanted to write some code for the SCALAR/HASH/ARRAY packages. Presumably in C, if you wanted to do: $foo = "12"; print $foo-POK; to retrieve the POK flag, say.) Guh. People should stop giving me wacky B:: module ideas. -- "Everything's working, try again in half an hour."-chorus.net tech support
Re: Larry's Apocalypse 1
At 08:54 PM 4/5/2001 +0100, Simon Cozens wrote: On Thu, Apr 05, 2001 at 03:50:04PM -0400, Dan Sugalski wrote: (We could even make perl 5 completely OO if you wanted to write some code for the SCALAR/HASH/ARRAY packages. Presumably in C, if you wanted to do: $foo = "12"; print $foo-POK; to retrieve the POK flag, say.) Guh. People should stop giving me wacky B:: module ideas. Ah, you're no fun. :) Seriously, we could easily weld in all the OO stuff folks want now into perl 5. The only two issues are memory bloat and startup time--the rest is all magic autoloading. (Well, OK, given Errno maybe we still need to work on that a little, but...) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Larry's Apocalypse 1
Whoa. This is so simple yet so sublime. It solves so many issues in one
swoop. Cool.
Assuming Perl6 will be parsing Perl5 code? Hmmm. That's interesting.
Forget p52p6 and the whole 80/20 thing, we could potentially hit the
100% mark.
I'd really rather not, and I don't think that was Larry's intention. I
think rather it was "perl 5 warning/strict levels", not "parse as perl 5
code". At least I hope that's the case...
well, personally I would rather that this *is* done, because it forces perl 6's
architecture to be solid.
If perl6 is designed correctly, then it should be *extremely easy* to target
multiple, differing syntaxes. TMTOWTDI on a grand scale..
And what would be a better way of testing this out than being able to
make perl6 parse and run perl5 code correctly? (and I think that a key component
ways of making this workable would be to promote a descendent of
Parse::RecDescent to be the mechanism that parses perl for *real* and is the
basis of micro-perl, etc.)
implement this? ("use 6.0" has much the same problem)
Most likely you'll just see the normal "use strict; use warnings;" at the
top of the main program, if that's what folks want.
well, perhaps the easiest way would be some similar tag to tell a perl6 script
from a perl5 script. A huge syntax difference between the two languages?
A different keyword for 'use'?
Ed
Re: Larry's Apocalypse 1
Nathan Torkington wrote: Not a comment at all on it? Was I accidentally unsubscribed to perl6-language? *tap* *tap* is this thing on? Nat Yes, well, my first impulse was to reply, making appropriate "Wow, that's cool" type of remarks, and then I decided to let it sink in a few days, and then make "Wow, that's cool" type of remarks. So herewith, Wow, that's cool! -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers
Re: Larry's Apocalypse 1
And what would be a better way of testing this out than being able to make perl6 parse and run perl5 code correctly? (and I think that a key component ways of making this workable would be to promote a descendent of Parse::RecDescent to be the mechanism that parses perl for *real* and is the basis of micro-perl, etc.) Regardless of the implementation, you are right on. It would be such an enjoyable thing to have a standard "Perl 5.x" lib of meta-syntax definitions that could serve as both parser logic and function mappings. The day you can execute a Perl5 test script successfully within that framework is a cool, cool day.
Re: Larry's Apocalypse 1
Thus it was written in the epistle of Michael G Schwern, I think he's saying that its annoying to have to write any sort of tag that says "Hey, I'm starting a new Perl 6 program here!" at the top of every single program, much in the same way its tiresome to write "int main(...)" in every C program. Then again, we already have to do the #! thing. Not only is it tiresome, it really gets in the way of writing perl6 one-liners. Perhaps it could be 1) If the code uses "module" or 2) If the executable called ends in 6. That way, "the #! thing" would suffice for normal code and one could just perl6 -e 'whatever;' for one-liners. Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == Mathematics is the most exact science, and its conclusions are capable of absolute proof. But this is so only because mathematics does not attempt to draw absolute conclusions. All mathematical truths are relative, conditional. -- Steinmetz, Charles P. == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: Larry's Apocalypse 1
On Thu, Apr 05, 2001 at 10:10:47PM +0100, Michael G Schwern wrote: I think he's saying that its annoying to have to write any sort of tag that says "Hey, I'm starting a new Perl 6 program here!" at the top of every single program, much in the same way its tiresome to write "int main(...)" in every C program. Then again, we already have to do the #! thing. So have "#!/usr/bin/perl6" do an implicit "module main" in the absence of any other module declaration. -- Putting heated bricks close to the news.admin.net-abuse.* groups. -- Megahal (trained on asr), 1998-11-06
Re: Larry's Apocalypse 1
Glenn Linderman wrote: New RFC ideas? Please, dear God, no. :-) Nat
RE: Larry's Apocalypse 1
From: Simon Cozens [mailto:[EMAIL PROTECTED]] On Thu, Apr 05, 2001 at 10:10:47PM +0100, Michael G Schwern wrote: I think he's saying that its annoying to have to write any sort of tag that says "Hey, I'm starting a new Perl 6 program here!" at the top of every single program, much in the same way its tiresome to write "int main(...)" in every C program. Then again, we already have to do the #! thing. There's no need save portability for a #! on Win32. So have "#!/usr/bin/perl6" do an implicit "module main" in the absence of any other module declaration. I like that, assuming that: #!perl6 and #!perl6 -s -w would work for Win32... It is strange, but in perl 5 #!perl -w turns on warnings, but #!perl -s doesn't equate to use strict;
Perl 5 compatibility (Re: Larry's Apocalypse 1)
Ted Ashton wrote: Thus it was written in the epistle of Michael G Schwern, I think [Nate]'s saying that its annoying to have to write any tag that says "Hey, I'm starting a new Perl 6 program here!" at the top of every single program, much in the same way its tiresome to write "int main(...)" in every C program. Then again, we already have to do the #! thing. Not only is it tiresome, it really gets in the way of writing perl6 one-liners. Right, exactly. Perhaps it could be 1) If the code uses "module" or 2) If the executable called ends in 6. Yep, something like this would be cool. But as Dan suggested we'll probably have to let Larry clarify his intent here. I read it as "it would be cool to assume that we're getting real Perl 5 code", rather than as just assuming Perl 5 non-strict policies, but actual Perl 6 code. I agree with Ed that, if you think about it, parsing Perl 5 in the Perl 6 detachable-lexer-parser model shouldn't (hopefully) be any harder than parsing Python (or Parrot :) syntax. Assuming this, then in one way Perl5 compatibility could be a "no-brainer". But the real question is how to distinguish Perl 5 vs 6 reliably. We could have "module main", but like Schwern, my left eye starts twitching and I get hot flashes with "int main" hallucinations. Anyways, it's probably something worth pondering, as the more compatible with Perl5 Perl6 is, the more likely it is to be accepted. The more I've been thinking about the p52p6 translator, the more it bothers me. I just think of the different Fortran versions and that whole mess. -Nate
Re: Larry's Apocalypse 1
Ted Ashton wrote: Perhaps it could be 1) If the code uses "module" or 2) If the executable called ends in 6. Huh? -- perl4.036 -- John Porter
Re: Larry's Apocalypse 1
Glenn Linderman wrote: Then it might be easier to write modules that are testable without a test driver. If you run the module directly, some distinguished block of code could be executed that wouldn't be if the module were "included" via "require" or "use" (or similar replacement constructs). You mean like Cunless caller ? (Try it.) Module also allows new semantics and/or syntax to be applied to POD directives, I would think, so it could be reworked or extended without incompatibility. New POD processors would note the module directive, and adjust accordingly. Hopefully this issue becomes too trivial to mention, by virtue of Perl being parsable by things other than perl, and by the introduction of a powerful, highly integrated preprocessor. I like POD, but it needs to be evolved to the point where it's not just about POD any more. -- John Porter
Re: Larry's Apocalypse 1
On Thu, Apr 05, 2001 at 05:15:56PM -0400, Ted Ashton wrote: 2) If the executable called ends in 6. ETOOMAGICAL. Shades of zip/unzip here. On some systems zip and unzip are just hard links to the same binary. It figures out what it supposed to do by what name is called. Very magical. Very bad. That way, "the #! thing" would suffice for normal code and one could just perl6 -e 'whatever;' for one-liners. One-liners run on a Perl 6 binary should just be Perl 6 code. Do we really have to worry about backwards compatibility with one liners? Hmm... programs that have perl one-liners inside them might be troublesome. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One What makes an animal escape from danger? When a small fish sense a big fish coming, it escapes. Who taught them to run for their lives? No one. The negative and positive charges made them advance and retreat automatically. --Alex Chiu, Immortality Guy
Re: Perl 5 compatibility (Re: Larry's Apocalypse 1)
Nathan Wiger wrote: the more compatible with Perl5 Perl6 is, the more likely it is to be accepted. I don't believe that's necessarily true. If Perl6 proves to be a significantly better Perl than Perl5, people will adopt it, especially if they're inclined toward the Perl philosophy anyway. (And at first, those are the only people we have to convince.) To this end, sacrificing the Virgin of Perlish Power to the God of Backward Compatibility would be unwise in the extreme. Put simply, I'd take Conway's Perl6 Power Extension Pack over the ability to run my existing programs (which work just fine under my (still functioning) perl5, thanks) under perl6 any day. Put abstractly, if I perceive Perl6 as a new-and-improved, yet vaguely incompatible, upgrade to Perl5, I am much less inclined to adopt it that if I perceive it as a bold stride above and away from Perl5. -- John Porter
RE: Larry's Apocalypse 1
One-liners run on a Perl 6 binary should just be Perl 6 code. Do we really have to worry about backwards compatibility with one liners? Hmm... programs that have perl one-liners inside them might be troublesome. Why not: perl -e 'perl 5 one-liner' perl --cmd 'perl 6 one-liner' i.e. maintain the "-e" switch as a backward compatibility flag, with a new cmd line flag for perl 6. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
Re: Larry's Apocalypse 1
Michael G Schwern wrote: ETOOMAGICAL. Shades of zip/unzip here. On some systems zip and unzip are just hard links to the same binary. It figures out what it supposed to do by what name is called. Very magical. Very bad. Well, the proposed trick for perl would be bad; what zip does isn't. argv[0] is just another arg, afterall. Hmm... programs that have perl one-liners inside them might be troublesome. It shouldn't be. For some reason, I suspect that VERY few sysadmins are going to install perl6 as /usr/bin/perl on any machine where that used to be perl5. Can we make a point right now of NOT having perl6's configure do that? -- John Porter
Re: Larry's Apocalypse 1
On Wed, Apr 04, 2001 at 11:46:12PM -0700, Nathan Torkington wrote: Not a comment at all on it? Was I accidentally unsubscribed to perl6-language? *tap* *tap* is this thing on? Nat Me, I've been racking my brain to figure out whether Damian is Famine, War, Plague, or Death... -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Larry's Apocalypse 1
Simon Cozens [EMAIL PROTECTED] wrote: On Thu, Apr 05, 2001 at 11:42:23AM +, David Grove wrote: Apocalypse is a greek word meaning that which comes out from (apo- eq away from) hiding, i.e., revelation. In the biblical sense, it refers to revealing that which was previously unseen or unheard, hidden behind a veil of worlds or time, as John used it. Urgh. I'm not letting that go without a pedant point. :) apokalupsis is the ordinary NT Greek word for revealing or uncovering.[1] John only uses it the once, in the title of his book. Okay, so I have a flair for the melodramatic[1]. You already knew that. ;-) Kalupsw IIRC is to hide something (the koine phrase that comes to mind is "hiding the light under the basket"). Apokalupsw is to bring it out of hiding. What struck me as interesting though was that Larry was referring to something that apparently was alredy there, between the lines, and just needed clarification. (Revealing and creating are different things.) I know that's a bit isogetical, but it works for me. It's a bit like Michelangelo's statement that he didn't carve his statues, he just freed them from the rock they were embedded in. p [1] Strongs is pure Koine. I'd think Larry would be more of the Ionic type. g
Re: Apocalypse 1 from Larry
Okay, you want comments, I got yer comments... I am, naturally, most interested in this part: [24]RFC 16: Keep default Perl free of constraints such as warnings and strict. (Keep the groans to a dull roar, please.) 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. I thought we'd made the point that we didn't expect stricture for -e. Perhaps this speaks to shell scripts that do perl ENDOFSCRIPT. I wouldn't call them one-liners but they would still suffer from unanticipated strictness. 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. Okay, but if you can tell that you're parsing Perl 6 rather than Perl 5, why not leave the default strictness the way it is for Perl 5 programs, and turn it on for Perl 6 programs? New language, new expectations, chance to make new rules. I keep coming back to the POD that says that the fact that -w is not the default is a bug. 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 of each program, and never actually tell their pupils that they want that because it turns on strictures and warnings. Sorry? It wouldn't just turn on strictures and warnings, it would change the interpretation from Perl 5 to Perl 6... and there appear to be enough clues about Perl 6 to deduce that one would know whether one was writing Perl 5 or Perl 6. And "module Main" would be a no-op except for the side effect... so might as well say "use 6.0" instead since it makes the intent clearer. I love the stuff about policy files. 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. This goes to the point. I could argue that I don't see strictures as 'morality', and I think that's just an accidental consequence of the name; suppose it had been called 'use salvation' instead? But there's no way to win a values debate. -- Peter Scott Pacific Systems Design Technologies
Re: Perl 5 compatibility (Re: Larry's Apocalypse 1)
At 02:43 PM 4/5/2001 -0700, Nathan Wiger wrote: Yep, something like this would be cool. But as Dan suggested we'll probably have to let Larry clarify his intent here. Somewhere or other Larry talked about this. Might've been in LA1, might've been somewhere else. I read it as "it would be cool to assume that we're getting real Perl 5 code", rather than as just assuming Perl 5 non-strict policies, but actual Perl 6 code. I agree with Ed that, if you think about it, parsing Perl 5 in the Perl 6 detachable-lexer-parser model shouldn't (hopefully) be any harder than parsing Python (or Parrot :) syntax. To be honest, if we lop out some of the nastier bits of perl 5 that have been contemplated, then making perl 6 grok code that uses them will be reasonably non-trivial. Besides, I really do *not* want to have perl 6 fully compatible with all perl 5 source for another reason. If we say we're not, but some perl 5 code does parse and run, then we get nice brownie points. If, on the other hand, we say we *are* perl 5 compatible, every single silly little incompatibility will be a black mark. Perl 5 is enough of a moving, poorly defined, target that I'd rather not shoot directly at it. Which isn't to say I'd be against a parser plug-in on CPAN that ate perl 5 code--that'd be rather cool. I just don't want to promise that perl 6 will eat all perl 5 code. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Larry's Apocalypse 1
At 01:33 PM 4/5/2001 -0700, Edward Peschko wrote: Whoa. This is so simple yet so sublime. It solves so many issues in one swoop. Cool. Assuming Perl6 will be parsing Perl5 code? Hmmm. That's interesting. Forget p52p6 and the whole 80/20 thing, we could potentially hit the 100% mark. I'd really rather not, and I don't think that was Larry's intention. I think rather it was "perl 5 warning/strict levels", not "parse as perl 5 code". At least I hope that's the case... well, personally I would rather that this *is* done, because it forces perl 6's architecture to be solid. If perl6 is designed correctly, then it should be *extremely easy* to target multiple, differing syntaxes. TMTOWTDI on a grand scale.. Sure. If you want to write a plugin that does it, keen. And what would be a better way of testing this out than being able to make perl6 parse and run perl5 code correctly? Well, I think it'd be easier to write a proper C parser for perl. Or an APL one. Heck, depending on what Larry does a Forth one might be easier. Perl 5 has a *lot* of little nooks in it that would require some special-case code. (Besides, what exactly is perl 5 anyway? It's a rather poorly defined thing) It's one of the reasons we're writing perl 6... (and I think that a key component ways of making this workable would be to promote a descendent of Parse::RecDescent to be the mechanism that parses perl for *real* and is the basis of micro-perl, etc.) I doubt the parser will be all in perl for perl 6. Some maybe, and it will likely use the regex engine, but I don't see it being all in perl. (And yes, I know what Larry's said) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl 5 compatibility (Re: Larry's Apocalypse 1)
OK, there's probably somthing simple I'm missing here, but... 1. Cuse 5 or Cuse 6 (and, in general, Cuse vervect) import the definitions of the language as it existed at that time (more or less), or die if they can't. (Or run through p52p6, or whatever.) Advantage: matches existing precedent. The real perl 5 won't choke on it, and will even give the right error. 2. If the name of the executable (from argv[0] or the beginning of #!) contains "perl.?[56]", then there is an implicit Cuse 5 or Cuse 6. (And why not any other version number? Just don't ship them in core, please!) Advantage: reasonably non-intrusive. 3. Otherwise, assume perl 6. Advantage: we require trivial changes in existing scripts instead of baggage we'll be carrying around forever. If you object to that much change as an admin, feel free -- install perl6 under the name "perl6", symlink perl5 to it, and make a symlink from perl to perl5. (This would work only if we had #2 follow symlinks until it saw a "perl5" or "perl6", which is probably fine). If you don't have symlinks on your system, then get a better system, use a site-policy file, or bite the bullet and change the #! lines. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Larry's Apocalypse 1
On Thu, Apr 05, 2001 at 06:12:30PM -0400, John Porter wrote: Michael G Schwern wrote: ETOOMAGICAL. Shades of zip/unzip here. On some systems zip and unzip are just hard links to the same binary. It figures out what it supposed to do by what name is called. Very magical. Very bad. Well, the proposed trick for perl would be bad; what zip does isn't. argv[0] is just another arg, afterall. Hmm. I rather fail to see the difference between the zip vs. perl. On the other hand, I don't like it when bzip2 does it either -- you can't symlink bunzip - bunzip2 and bzip - bzip2 and have it do the Right Thing. On the gripping hand, when combined with other mesures, not so bad. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Larry's Apocalypse 1
And what would be a better way of testing this out than being able to make perl6 parse and run perl5 code correctly? Well, I think it'd be easier to write a proper C parser for perl. Or an APL one. Heck, depending on what Larry does a Forth one might be easier. Perl 5 has a *lot* of little nooks in it that would require some special-case code. (Besides, what exactly is perl 5 anyway? It's a rather poorly defined thing) It's one of the reasons we're writing perl 6... right, but if we are being realistic about this whole 'being able to parse and run other languages' thing, its the best testcase I can imagine. Python has quite a few special cases itself... I don't see how we could possibly imagine targeting it without handling special case software. (and I think that a key component ways of making this workable would be to promote a descendent of Parse::RecDescent to be the mechanism that parses perl for *real* and is the basis of micro-perl, etc.) I doubt the parser will be all in perl for perl 6. Some maybe, and it will likely use the regex engine, but I don't see it being all in perl. (And yes, I know what Larry's said) well, I wasn't talking about a perl descendant, but a C descendant... Its the functionality and ease-of-use that counts. One that could be plugged into perl as well as being used to parse it.. Ed
Re: Larry's Apocalypse 1
"Nathan" == Nathan Wiger [EMAIL PROTECTED] writes: Nathan This is interesting, and in my gut I like it. Many people I've worked Nathan with end up writing: Nathan@foo[0] Nathan Which works. "Works", for some odd meaning of the word "works". Ever try this: @foo[0] = STDIN; and then wonder where all the *rest* of your input went? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Apocalypse 1 from Larry
On Thu, 5 Apr 2001, A. C. Yardley wrote: 16 bdb Keep default Perl free of constraints such as warnings and strict. 73 adb All Perl core functions should return objects ^ [...] I might at some point add a ``d'' for Deferred, if I really think it's too soon to decide something. is already in effect? No. Read again. The two first flags was an a-f "grade". - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than 70M impressions per day, http://valueclick.com
