Alpha 2 available
Larry Wall
New in Alpha 2:
Many bug fixes from Alpha 1.
Several compiler optimizations installed.
New ref function to return a reference's type.
Anonymous associative array reference constructor {} to go with [].
First cut at object-oriented features.
Like the Alpha 1 prerelease, this is an unsupported code. It is
expected to work only on a Sparc architecture machine. No Configure
support is provided. In fact, if you succeed in configuring and making
a new makefile, you'll probably overwrite the only makefile that
works. (Note that a Sparc executable comes with the kit, so you may
not need to compile at all.)
There is no list of new features yet, but if you look at t/op/ref.t
you'll see some of them in use. perl -Dxst is also fun.
The kit is located on ftp.netlabs.com, in pub/outgoing/perl5.0/perl5a2.tar.Z.
Here's t/op/ref.t for your perusal. Newer stuff is at the bottom.
#!./perl
print "1..37\n";
# Test glob operations.
$bar = "ok 1\n";
$foo = "ok 2\n";
{
local(*foo) = *bar;
print $foo;
}
print $foo;
$baz = "ok 3\n";
$foo = "ok 4\n";
{
local(*foo) = 'baz';
print $foo;
}
print $foo;
$foo = "ok 6\n";
{
local(*foo);
print $foo;
$foo = "ok 5\n";
print $foo;
}
print $foo;
# Test fake references.
$baz = "ok 7\n";
$bar = 'baz';
$foo = 'bar';
print $$$foo;
# Test real references.
$FOO = \$BAR;
$BAR = \$BAZ;
$BAZ = "ok 8\n";
print $$$FOO;
# Test references to real arrays.
@ary = (9,10,11,12);
$ref[0] = \@a;
$ref[1] = \@b;
$ref[2] = \@c;
$ref[3] = \@d;
for $i (3,1,2,0) {
push(@{$ref[$i]}, "ok $ary[$i]\n");
}
print @a;
print ${$ref[1]}[0];
print @{$ref[2]}[0];
print @{'d'};
# Test references to references.
$refref = \\$x;
$x = "ok 13\n";
print $$$refref;
# Test nested anonymous lists.
$ref = [[],2,[3,4,5,]];
print scalar @$ref == 3 ? "ok 14\n" : "not ok 14\n";
print $$ref[1] == 2 ? "ok 15\n" : "not ok 15\n";
print ${$$ref[2]}[2] == 5 ? "ok 16\n" : "not ok 16\n";
print scalar @{$$ref[0]} == 0 ? "ok 17\n" : "not ok 17\n";
print $ref->[1] == 2 ? "ok 18\n" : "not ok 18\n";
print $ref->[2]->[0] == 3 ? "ok 19\n" : "not ok 18\n";
# Test references to hashes of references.
$refref = \%whatever;
$refref->{"key"} = $ref;
print $refref->{"key"}->[2]->[0] == 3 ? "ok 20\n" : "not ok 20\n";
# Test to see if anonymous subarrays spring into existence.
$spring[5]->[0] = 123;
$spring[5]->[1] = 456;
push(@{$spring[5]}, 789);
print join(':',@{$spring[5]}) eq "123:456:789" ? "ok 21\n" : "not ok 21\n";
# Test to see if anonymous subhashes spring into existence.
@{$spring2{"foo"}} = (1,2,3);
$spring2{"foo"}->[3] = 4;
print join(':',@{$spring2{"foo"}}) eq "1:2:3:4" ? "ok 22\n" : "not ok 22\n";
# Test references to subroutines.
sub mysub { print "ok 23\n" }
$subref = \&mysub;
&$subref;
$subrefref = \\&mysub2;
&$$subrefref("ok 24\n");
sub mysub2 { print shift }
# Test the ref operator.
print ref $subref eq CODE ? "ok 25\n" : "not ok 25\n";
print ref $ref eq ARRAY ? "ok 26\n" : "not ok 26\n";
print ref $refref eq HASH ? "ok 27\n" : "not ok 27\n";
# Test anonymous hash syntax.
$anonhash = {};
print ref $anonhash eq HASH ? "ok 28\n" : "not ok 28\n";
$anonhash2 = {FOO => BAR, ABC => XYZ,};
print join('', sort values %$anonhash2) eq BARXYZ ? "ok 29\n" : "not ok 29\n";
# Test bless operator.
package MYHASH;
$object = bless $main'anonhash2;
print ref $object eq MYHASH ? "ok 30\n" : "not ok 30\n";
print $object->{ABC} eq XYZ ? "ok 31\n" : "not ok 31\n";
$object2 = bless {};
print ref $object2 eq MYHASH ? "ok 32\n" : "not ok 32\n";
# Test ordinary call on object method.
&mymethod($object,33);
sub mymethod {
local($THIS, @ARGS) = @_;
die "Not a MYHASH" unless ref $THIS eq MYHASH;
print $THIS->{FOO} eq BAR ? "ok $ARGS[0]\n" : "not ok $ARGS[0]\n";
}
# Test automatic destructor call.
$string = "not ok 34\n";
$object = "foo";
$string = "ok 34\n";
$main'anonhash2 = "foo";
$string = "not ok 34\n";
sub DESTROY {
print $string;
# Test that the object has already been "cursed".
print ref shift eq HASH ? "ok 35\n" : "not ok 35\n";
}
# Now test inheritance of methods.
package OBJ;
@ISA = (BASEOBJ);
$main'object = bless {FOO => foo, BAR => bar};
package main;
# Test arrow-style method invocation.
print $object->doit("BAR") eq bar ? "ok 36\n" : "not ok 36\n";
# Test indirect-object-style method invocation.
$foo = doit $object "FOO";
print $foo eq foo ? "ok 37\n" : "not ok 37\n";
sub BASEOBJ'doit {
local $ref = shift;
die "Not an OBJ" unless ref $ref eq OBJ;
$ref->{shift};
}
Some notes about the OO stuff. Unlike certain languages we could name,
I've tried to minimize the amount of new syntax needed. An object is
simply a reference to a value that knows what package it belongs to.
Object methods are simply subroutines in that package. The only
difference between ordinary subroutine calls and method invocation is
that with method invocation the package name is supplied by the
object. The object comes into a method as an explicit first argument,
which you'd typically pull out as in the BASEOBJ'doit routine above.
You make an ordinary reference into an object reference by "blessing"
it with the bless operator. Ordinarily you'd call this as the last
thing in a constructor subroutine, but you don't have to. I didn't
in the tests above. When you bless an object, all references to it
change their type to the name of the package it was blessed in. The
type of a reference is available with the new ref function. (You may
bless an object that was already blessed, though I may limit that
to objects that were blessed by a base class.)
Since all objects are references, and since Perl 5 knows when the
reference count goes to zero, it'll call a destructor for your object
at the appropriate moment, presuming you've defined one. The destructor
for a package is named DESTROY. (I haven't implemented inheritance of
destructors yet, so please don't complain about that.) Currently
an object comes into the destructor already "cursed", so there's
no explicit curse operator to go with the bless operator. As the
apostle Paul says: "Bless, and curse not." :-)
Inheritance is implemented without any new syntax. Any package that
wants to inherit from another package does so by putting a list of
package names into its @ISA array. Only method names are inherited.
All methods are automatically "virtual" in the C++ sense--they'll call
the most derived version available. Efficiency is maintained by
caching the looked-up subroutine, though I haven't implemented that
optimization yet. Multiple inheritance is done by putting multiple
package names into the @ISA array. They are prioritized by that
ordering.
OO specialists are free to comment. And I'm free to ignore them... :-)
Well, that's all I can think of for now. Have some amount of fun.
Larry
Randal L. Schwartz
Larry> New in Alpha 2:
Larry> Many bug fixes from Alpha 1.
Larry> Several compiler optimizations installed.
Larry> New ref function to return a reference's type.
Larry> Anonymous associative array reference constructor {} to go with [].
Larry> First cut at object-oriented features.
Well, now I can see why Perl5.0 isn't done yet. Larry's been having
too much fun. :-)
Looks like Camel5 will have a significant chunk of new stuff, and
the manpage will go to 120 pages. :-)
Now, if I can just hold off Llama enough so that I get some of these
nifty 5.0 features in there. :-)
print "Just another [nervous] Perl [4.0 book] hacker,"
--
Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
mer...@ora.com (semi-permanent) mer...@kandinsky.intel.com (NEWSREADING ONLY)
Quote: "Welcome to Portland, Oregon, home of the California Raisins!"
Bill Middleton
>Okay, I'm going away on a trip again, so here's the next installment... :-)
>
Available here again.
Bill
--
Bill Middleton - NewsMeister
Texas Metronet - Internet for the Individual
will hack perl for Texas BBQ
Joseph Hall
>>>>>> In article <1993Aug16....@netlabs.com>, lw...@netlabs.com (Larry Wall) writes:
>Larry> New in Alpha 2:
>
>Well, now I can see why Perl5.0 isn't done yet. Larry's been having
>too much fun. :-)
Oh, cool, ooperl, an incremental compiler, an ooperl class browser ...
<dimming fantasy goggles>
Maybe I will give up C++ pretty soon.
Can we build in grid files or quadtrees?
--
Joseph Nathan Hall|"Cost is irrelevant. Floppy drives are irrelevant.
Software Architect| Applications are irrelevant. Compatibility is irrelevant.
Gorca Systems Inc.| You will be assimilated into our systems."
(on assignment) | (602) 732-2549 jnh...@sat.mot.com (work)
Larry Wall
New in Alpha 3:
Many bug fixes from Alpha 2.
The caller function now returns a false value in a scalar context if there
is no caller. This lets library files determine if they're being required.
m//g now attaches its state to the searched string rather than the
regular expression.
The -w switch is much more informative.
Subroutines may now be called as list operators if they've already
been declared.
BEGIN subroutines now execute the moment they're parsed, and can thus
be used to require things before the rest of the script is parsed.
This has at least three benefits. You can use required subroutines
as if they were built-in list operators. These requires are done before
the -w typo check, so there are fewer false alarms. And you can write
an infinitely long script by writing a sequence of BEGIN{} blocks--each
will be thrown away as soon as it has executed.
Lexical scoping available via "my". eval can see the current lexical
variables. The debugger knows about "my".
Saying "package;" requires explicit package name on global symbols.
The debugger works now. Hmm. I take that back. I must have busted it
with the BEGIN changes. Darn. Remove the "BEGIN" from toke.c if you
want it to work.
Like the Alpha 2 prerelease, this is an unsupported code. It is
expected to work only on a Sparc architecture machine. No Configure
support is provided. In fact, if you succeed in configuring and making
a new makefile, you'll probably overwrite the only makefile that
works. (Note that a Sparc executable comes with the kit, so you may
not need to compile at all.)
Look in the Changes file for a more complete list of everything that's
new in Perl 5.
The kit is located on ftp.netlabs.com, in pub/outgoing/perl5.0/perl5a3.tar.Z.
Enjoy.
Larry
Henk Penning
>The Alpha 3 prerelease version of Perl 5 is now available.
>The kit is located on ftp.netlabs.com, in pub/outgoing/perl5.0/perl5a3.tar.Z.
Also on ftp.cs.ruu.nl: /pub/PERL/perl5.0/perl5a3.tar.Z
________________________________________________________________________
We, Computer Science department, Utrecht University, are running an
anonymous FTP server on one of our systems. In addition to the FTP
service we're also running a mail server, for those of you without
direct Internet access.
--> How to get 'perl5a3' via anonymous FTP:
Site: ftp.cs.ruu.nl [131.211.80.17]
Login: "anonymous" or "ftp"
Password: your own email address (you@your_domain)
file:
/pub/PERL/perl5.0/perl5a3.announce
/pub/PERL/perl5.0/perl5a3.tar.Z
--> How to get 'perl5a3' via e-mail from our mail-server:
NOTE: In the following I have assumed that your mail address is
"fred_fl...@stone.age.edu"; of course you must substitute
your own address for this.
| Please use a VALID DOMAIN ADDRESS.
| Use 'hip!hop!user' if you must.
| Never use an address which has both '!' and '@' in it.
| Bitnetters use us...@host.bitnet
Send the following message to
mail-...@cs.ruu.nl
or the old-fashioned path alternative
uunet!mcsun!sun4nl!ruuinf!mail-server
begin
path fred_fl...@stone.age.edu (SUBSTITUTE _YOUR_ ADDRESS)
send PERL/perl5.0/perl5a3.announce
send PERL/perl5.0/perl5a3.tar.Z
end
The path command can be deleted if we receive a valid from address in your
message. If this is the first time you use our mail server, we suggest you
first issue the request:
send HELP
A complete "ls-lR" listing of the archive is kept in the top-level
directory, it will be updated every night. To get it, issue the command:
send ls-lR.Z
or
send ls-lR.gz
That's all for now. If you encounter problems using the FTP service
and/or the mail-server, feel free to drop me a line (by e-mail, please).
--
Henk P. Penning, Dept of Computer Science, Utrecht University. __/ \__/ \__/
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. \__/ \__/ \
Telephone: +31-30-534106, fax: 51379, NIC-handle: HPP1. \__/ \__/ \__/ \__/
e-mail : he...@cs.ruu.nl (uucp to sun4nl!ruuinf!henkp) _/ \__/ \__/ \__/ \
Bill Middleton
>The Alpha 3 prerelease version of Perl 5 is now available.
>
Available here as:
metronet.com:/pub/perl/source/perl5a3.tar.Z
I am assuming Larry's continued permission.
Bill
--
Bill Middleton - CyberMeister
Texas Metronet - Internet for the Individual
Will hack perl for Texas BBQ
Ian Phillipps
>The Alpha 3 prerelease version of Perl 5 is now available.
Thanks Larry. This features a new approach to dealing with the
numbering of pre-release versions. Try "./perl -e 'print $]'" so see
what I mean :-)
The kit-included binary SEGVs with this traceback:
strlen() at 0x81b0c
sv_setpv(sv = 0xc7b48, ptr = 0x24524353 ""), line 880 in "sv.c"
gv_fetchpv(name = 0xbd8e8 "]", add = 1), line 303 in "gv.c"
ck_rvconst(op = 0xc81c8), line 2386 in "op.c"
newUNOP(type = 15, flags = 0, first = 0xc8188), line 1124 in "op.c"
newSVREF(o = 0xc8188), line 2253 in "op.c"
yyparse(), line 531 in "perly.y"
perl_parse(sv_interp = 0xbd808, argc = 1, argv = 0xf7fffe24, env = 0xf7fffe2c), line 404 in "perl.c"
main(argc = 3, argv = 0xf7fffe1c, env = 0xf7fffe2c), line 17 in "main.c"
When releasing Alpha1 you said you didn't want to know about coredumps.
Does that still apply? This one appears to be new to alpha3.
Ian
--
---
Ian Phillipps. Tech support manager, Unipalm. If you ask me, all conspiracy
Phone +44 223 250103, Fax 250101 theories are put about by the
Pipex phone +44 223 250120. Internic: IP4. same bunch of people.
Larry Wall
: lw...@netlabs.com (Larry Wall) writes:
:
: >The Alpha 3 prerelease version of Perl 5 is now available.
:
: Thanks Larry. This features a new approach to dealing with the
: numbering of pre-release versions. Try "./perl -e 'print $]'" so see
: what I mean :-)
Oops.
: When releasing Alpha1 you said you didn't want to know about coredumps.
: Does that still apply? This one appears to be new to alpha3.
I said I didn't want to know about mysterious coredumps. This one isn't
all that mysterious, sigh...
Other things that folks have pointed out: because of the new bareword
subroutines, sort subroutines are busted if you define them before the
sort in question. And perl -w gives spurious warnings on assignment
operators. There are certainly other breakages as well. But hey,
that's why it's an alpha. (Not that the betas are much stabler. Or
the "real" releases, for that matter.)
Larry
John Macdonald
|
|New in Alpha 3:
| The caller function now returns a false value in a scalar context if there
| is no caller. This lets library files determine if they're being required.
Neat. Does this also allow the debugger to use the "n" and "r"
statements to skip across or out of (respectively) and require?
It's been slightly annoying to have to list the next lines to try
and find a line number that can be continued to so that you can
skip over a require when you haven't really pinned done exactly
where it is that you want to start looking closely at what is going
on in a script so you do want to browse through how it gets to
somewhere that seems worth analysing closely. (I tend to use a
mixture of "n" and "s", with some continues and explicit breakpoints
tossed in for this sort of thing.)
--
That is 27 years ago, or about half an eternity in | John Macdonald
computer years. - Alan Tibbetts | j...@Elegant.COM
Stephen O. Lidie
>
> In <1993Oct10.0...@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
>
> >The Alpha 3 prerelease version of Perl 5 is now available.
> >The kit is located on ftp.netlabs.com, in pub/outgoing/perl5.0/perl5a3.tar.Z.
>
Is alpha 3 still basically a SunOS Makefile release only? (i.e. how much
work to try it on AIX?)
Take care,
SOL
Tim McDaniel
Larry Wall <lw...@netlabs.com> wrote:
>Other things that folks have pointed out: because of the new bareword
>subroutines, sort subroutines are busted if you define them before the
>sort in question.
I'm beginning to think that bareword subroutine calls are not a
noticable improvement.
- Current Perl has a somewhat consistent use of "grammatical" markers.
- The location of a sub definition (above or below use) now matters.
Is this true in all bareword calls, or just for sort and BEGIN?
- To make
print ctime time;
work, the semantics of "sub BEGIN" have to differ from other subs:
- if defined multiple times, the last definition doesn't override
the rest.
- its location matters.
Would
$foo = &ctime time;
or
print &ctime time;
cause parsing problems?
--
Tim McDaniel, Convex Computer Corporation, Richardson, TX (near Dallas)
If mcda...@convex.com fails, try mcda...@convex.convex.com or
mcda...@mozart.convex.com
Tim McDaniel
We have a new version of trn, so I can't cancel my previous article. My
apologies for making sweeping declarations and jumping to conclusions.
I have forgotten the usage and benefits of bareword sub calls. Would
someone please explain them again? From what I gather,
$r->foo(1, 2, 5)
(if $r is blessed) would call the subroutine package_of_r'foo; true?
If that example is OK, would
$r->&foo(1, 2, 5)
be a synonym for the above in Perl 5?
I understand that the expression
print ctime time;
would require that ctime be declared above lexically, but
sort timesort ...
would require that timesort be declared below lexically. This seems to
me to be counter to previous Perl practice, and not completely
intuitive. Would it be possible to instead keep "&" as the sub call
indicator? What would the implications be?
What are the benefits of having sub BEGIN differ from normal subs in
that it is executed immediately upon seeing the "}"? I was expecting
the implementation to be an implicit "&BEGIN();" at the start of program
execution. (As a minor effect, if it is defined multiple times, the
last doesn't override the rest.) Is it possible to have package-
specific BEGINs, and is the reason for these semantics related to this?
Bill Middleton
>
>I have forgotten the usage and benefits of bareword sub calls. Would
>someone please explain them again? From what I gather,
Hey, I haven't even read Tom's "Recursive Data Types, Structures, and
Classes" completely yet. But it was my code that broke the sort subroutine
first. So I'll just note that most of what's been said by Larry, and
others about perl5 is archived here. If you use a gopher client the
article's Subject: will show up as menu item, although it's not always
descriptive of the info-content of the article.
If you're an old ftp-head, use ftp.metronet.com:/pub/perl/perl5/*
Here's the .names file for that area:
Name=Perl 5 alpha available
Type=0
Path=./perl5.alpha.announce
Name=Re: Printing a reference in perl 5a2
Type=0
Path=./ref.call.perl5.info
Name=Alpha 2 available
Type=0
Path=./perl5.alpha2.announce
Name=Opening perl5 filehandles
Type=0
Path=./opening.perl5.filehandles
Name=Using the "my" lvalue
Type=0
Path=./perl5.MY.lvalue.info
Name=Re: Perl5 object instantiation (blessing)
Type=0
Path=./blessing.question.and.answer
Name=Re: Perl5 object instantiation (more on blessing
Type=0
Path=./perl5.blessing.question.and.answer
Name=Re: Variable suicide (passing references)
Type=0
Path=./perl5.passing.references
Name=Re: comp.lang.perl FAQ (part 1 of 2) [ADDENDUM]
Type=0
Path=./lwall.faq.comments
Name=Re: perl 5 features (Larry's current Changes file)
Type=0
Path=./perl5.changes
Name=Re: perl 5 features (Tom's tutoring)
Type=0
Path=./perl5.features
Name=Re: perl5 usub interface ?
Type=0
Path=./perl5.usub.info
Name=Re: rewrite this 7-liner in perl? (c2ph possibilities)
Type=0
Path=./c2ph.perl5.possibilities
Name=de-cluttering Perl subroutine calls
Type=0
Path=./perl5.bewilderment
Name=Re: perl/awk challenge (BEGIN and END Autoroutines)
Type=0
Path=./BEGIN.and.END.autoroutines.perl5
Name=an inheritable constructor for p5a
Type=0
Path=./inherit.construct.perl5
Name=Re: Case-insensitive String Compare ( uc() and lc() fn's )
Type=0
Path=./uc.and.lc.internal.fns
Name=Alpha 3 available
Type=0
Numb=1
Path=./alpha3.announcement
--
Bill Middleton - Former CyberMeister (Bloodless Coup)
Tom Christiansen
:In article <1993Oct11....@netlabs.com>,
--
Tom Christiansen tch...@cs.colorado.edu
"Will Hack Perl for Fine Food and Fun"
Boulder Colorado 303-444-3212
Tom Christiansen
:apologies for making sweeping declarations and jumping to conclusions.
You just need to get chummier with the news system.
:I have forgotten the usage and benefits of bareword sub calls. Would
:someone please explain them again? From what I gather,
: $r->foo(1, 2, 5)
:(if $r is blessed) would call the subroutine package_of_r'foo; true?
Yes. That's not the real problem. The real problem is t hat
foo $r 1,2,5;
should also work. It's especially scary in that
print foo;
sub foo;
foo 1,2,5;
calls something else, and that the bearword 'foo' changed its meaning over a
couple lines.
Basdically, you may either have bearwords as strings, or as functinos, but to
mix them is really problematic. Especially since folks don't want to use
parens.
:If that example is OK, would
: $r->&foo(1, 2, 5)
:be a synonym for the above in Perl 5?
Not yet. Maybe it should be. I'd like runtime indirect methods,
like $r->$meth(1..5).
:
:I understand that the expression
: print ctime time;
:would require that ctime be declared above lexically, but
: sort timesort ...
:would require that timesort be declared below lexically. This seems to
:me to be counter to previous Perl practice, and not completely
:intuitive. Would it be possible to instead keep "&" as the sub call
:indicator? What would the implications be?
:
:What are the benefits of having sub BEGIN differ from normal subs in
:that it is executed immediately upon seeing the "}"? I was expecting
:the implementation to be an implicit "&BEGIN();" at the start of program
:execution. (As a minor effect, if it is defined multiple times, the
:last doesn't override the rest.) Is it possible to have package-
:specific BEGINs, and is the reason for these semantics related to this?
Well, yes, but that's usually not needed. You have a BEGIN to make the
compiler get the requires in order to change the dang bearwords into subroutine
calls instead of strings. require is runtime not compile time so it has to get
done before compilation of stuff beelow it.
package ENDs are really nice for global destructors.
--tom
Larry Wall
: Neat. Does this also allow the debugger to use the "n" and "r"
: statements to skip across or out of (respectively) and require?
Not yet, but we're getting closer.
Larry
Larry Wall
: We have a new version of trn, so I can't cancel my previous article. My
: apologies for making sweeping declarations and jumping to conclusions.
Just so you don't jump your declarations and sweep to conclusions.
: I have forgotten the usage and benefits of bareword sub calls. Would
: someone please explain them again? From what I gather,
: $r->foo(1, 2, 5)
: (if $r is blessed) would call the subroutine package_of_r'foo; true?
Yes,
$r->foo(1, 2, 5)
is the same as
&package_of_r'foo($r, 1, 2, 5)
But method calls are syntactically distinguished from subroutine calls.
: If that example is OK, would
: $r->&foo(1, 2, 5)
: be a synonym for the above in Perl 5?
Not currently, but it could be made synonymous.
: I understand that the expression
: print ctime time;
: would require that ctime be declared above lexically, but
: sort timesort ...
: would require that timesort be declared below lexically. This seems to
: me to be counter to previous Perl practice, and not completely
: intuitive.
It's not required that the sort subroutine be declared below--you can
declare it anywhere. The sort operator is a little funny for
historical reasons, in that it wants to interpret a following bareword
as the name of a subroutine rather than a filehandle. And that
subroutine isn't supposed to be called before the sort begins. So
sort is definitely an anomoly if we want to be backward compatible.
: Would it be possible to instead keep "&" as the sub call
: indicator? What would the implications be?
We are keeping "&" as the sub call indicator (or perhaps more properly,
the subroutine type indicator, since you can use it in places like
"undef &foo"). The "&" has merely become optional for pseudo-builtin
subroutines, primarily so you can pretend that "required" subroutines
are built-ins if you want to.
: What are the benefits of having sub BEGIN differ from normal subs in
: that it is executed immediately upon seeing the "}"?
It lets you do requires at compile time in order to get predefined
subroutines defined early enough to affect the syntax of the rest of
the compilation unit. It has some other benefits, one of which is that
you can now write an arbitrarily long Perl script without running out
of memory, since it can be compiled and exectuted in chunks, and the
chunks discarded.
: I was expecting the implementation to be an implicit "&BEGIN();" at
: the start of program execution.
That's what the implementation was in the first two alphas.
: (As a minor effect, if it is defined multiple times, the
: last doesn't override the rest.)
True.
: Is it possible to have package-specific BEGINs, and is the reason for
: these semantics related to this?
BEGIN and END are currently package-specific. I'm thinking of them
more as package constructors and destructors than as real subroutines.
Making BEGIN execute as soon as it's parsed gives BEGIN a Meaningful
Existence. Previously it was redundant with ordinary package init
code, and its only purpose in life was the awk BEGIN {} emulation.
It now has a higher purpose in life (or lower, depending on your moral
orientation).
Larry
Larry Wall
: But it was my code that broke the sort subroutine first.
Yeah, though it turns out that wasn't related to the subroutine call
syntax relaxation effort. [Ain't noun modifiers wunnerful?] I simply
hadn't made the oddball sort subroutine linkage [There's some more of
'em.] deal with explicit return statements.
Larry
Gary Benson
> It's been slightly annoying to have to list the next lines to try
> and find a line number that can be continued to so that you can
> skip over a require when you haven't really pinned down exactly
> where it is that you want to start looking closely at what is going
> on in a script so you do want to browse through how it gets to
> somewhere that seems worth analysing closely.
I nominate this sentence as the perl newsgroup entry in the Bulwer-Lytton
contest.
--
Gary Benson-_-_-_-_...@tc.fluke.com_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Aaron Sherman
Tom Christiansen <tch...@cs.Colorado.EDU> writes:
It's especially scary in that
print foo;
sub foo;
foo 1,2,5;
calls something else, and that the bearword 'foo' changed its
meaning over a couple lines.
Basdically, you may either have bearwords as strings, or as
functinos, but to mix them is really problematic. Especially since
folks don't want to use parens.
I have no problem with &, as it stands. Why this sudden urge to go
back to un-identified subroutine calls? If anything I think Perl
should move FORWARD by having a way to identify filehandles.
Also, I see only one way to make bareword subroutines work cleanly,
and that would be to overhaul the interpreter (AGAIN) and make all
operators be nothing more than pre-defined subroutines. This could be
optimized around, but you would still lose a lot of the magic that
some subroutines have (how do you deal with "split // $_"?).
:If that example is OK, would
: $r->&foo(1, 2, 5)
:be a synonym for the above in Perl 5?
Not yet. Maybe it should be. I'd like runtime indirect methods,
like $r->$meth(1..5).
I'd have to ask "why?" Is there really a lot to be gained here that
cannot already be gained from perl-5's language extensions?
When I first used perl, I was struck by the the fact that it had taken
rigidly defined single-purpose constructs (like the grep program) and
expanded them within the framework of the language to be general
purpose, but without losing the ease of use. If you can do that with
some other idea, then fine, but I don't think that most of the ideas
in your previous article fit this mold. You seem to want to change
perl's way of interacting with the user to gain some C and C++-like
constructs. While this is, perhaps, going to get us something, how
much of the simplicity of perl will we have to sacrifice?
In some sense, I think that it would be a good thing to make the
constructs in the current interpreter flexible enough to let you do
what you want in the future, and then just focus on getting perl-5 out
of alpha. I think you would find it helpful to see how people start
using the new features BEFORE you try to expand them further.
:Is it possible to have package-
:specific BEGINs, and is the reason for these semantics related to this?
Well, yes, but that's usually not needed.
I was about to argue this, and then realized that I was wrong. As long
as you "require" them from a BEGIN, you don't need any special BEGINs
in your libraries, because any code outside of subroutine declarations
will be executed ANYWAY.
You have a BEGIN to
make the compiler get the requires in order to change the dang
bearwords into subroutine calls instead of strings. require is
runtime not compile time so it has to get done before
compilation of stuff beelow it.
This will cause a LOT of confusion. To quote The Hunt For Red October,
"This business will get out of control. It will get out of control and
we'll be lucky to live through it". Just replace "we'll" with "perl
will".
package ENDs are really nice for global destructors.
YES! This is something that I think will be VERY useful, and is not so
intrusive as bare-words.
-AJS
--
Aaron Sherman I-Kinetics, Inc.
Systems Engineer "Open Systems Stepstones"
Voice: (617)661-8181 19 Bishop Allen Dr.
Fax: (617)661-8625 Cambridge, MA 02139
Pager: (508)545-0584 ashe...@i-kinetics.com