Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
On Mon, Aug 07, 2000 at 04:43:32PM -, Perl6 RFC Librarian wrote: >This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > >=head1 TITLE > >Proposal to utilize C<*> as the prefix to magic subroutines > >=head1 VERSION > > Maintainer: Jonthan Scott Duff > Date: 7 Aug 2000 > Version: 1 > Mailing List: [EMAIL PROTECTED] > Number: 59 Should this be on the -subs sublist? K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
Peter Scott <[EMAIL PROTECTED]> writes:
> At 09:28 AM 8/8/00 +0100, Piers Cawley wrote:
> >Peter Scott <[EMAIL PROTECTED]> writes:
> >
> > > At 12:07 AM 8/8/00 +0200, Bart Lateur wrote:
> > > >On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote:
> > > >
> > > > >I meant that BEGIN, END, and INIT aren't declared as subs at present but
> > > > >named blocks. I was surprised to discover that they're put in the
> > symbol
> > > > >table anyway though.
> > > >
> > > >Check the docs again. [snip]
> > > > Four special subroutines act as package constructors and
> > > > destructors. These are the `BEGIN', `CHECK', `INIT', and `END'
> > > > routines. The `sub' is optional for these routines.
> > >
> > > Drat. I propose making it non-optional for
> > P6. ETOOMANYSPECIALCASES. Any
> > > objections?
> >
> >But what happens if you want multiple BEGIN blocks?
>
> Same as now:
>
> $ perl -le 'sub BEGIN{print "one"} sub BEGIN{print "two"}'
> one
> two
>
> It's a bit of a white lie to suggest that they're just plain ol'
> subroutines, but at least we're getting closer to the truth.
Woohoo but that's butt ugly. I definitely vote for removing the 'sub
BEGIN {}' syntax rather than making 'BEGIN {}' become 'sub BEGIN {}'
--
Piers
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
At 09:28 AM 8/8/00 +0100, Piers Cawley wrote:
>Peter Scott <[EMAIL PROTECTED]> writes:
>
> > At 12:07 AM 8/8/00 +0200, Bart Lateur wrote:
> > >On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote:
> > >
> > > >I meant that BEGIN, END, and INIT aren't declared as subs at present but
> > > >named blocks. I was surprised to discover that they're put in the
> symbol
> > > >table anyway though.
> > >
> > >Check the docs again. [snip]
> > > Four special subroutines act as package constructors and
> > > destructors. These are the `BEGIN', `CHECK', `INIT', and `END'
> > > routines. The `sub' is optional for these routines.
> >
> > Drat. I propose making it non-optional for
> P6. ETOOMANYSPECIALCASES. Any
> > objections?
>
>But what happens if you want multiple BEGIN blocks?
Same as now:
$ perl -le 'sub BEGIN{print "one"} sub BEGIN{print "two"}'
one
two
It's a bit of a white lie to suggest that they're just plain ol'
subroutines, but at least we're getting closer to the truth.
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
Jonathan Scott Duff wrote: > > But what happens if you want multiple BEGIN blocks? > > The same thing that happens now. As I understand it, perl compiles > and executes the BEGIN block then detroys it so that you may have as > many BEGIN blocks as you want and each time perl thinks it's the first > one. That's sort of a special case. What happens with multiple END blocks? perl must compile them and stash them in the END symbol, chained somehow. -- John Porter
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
On Tue, Aug 08, 2000 at 09:27:24AM +0100, Piers Cawley wrote: > > Proposal to utilize C<*> as the prefix to magic subroutines > > I freely accept that this is not anything approaching a reasoned > critique but: > > Yecch! That comment is as good as any :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
On Tue, Aug 08, 2000 at 09:28:17AM +0100, Piers Cawley wrote: > Peter Scott <[EMAIL PROTECTED]> writes: > > > At 12:07 AM 8/8/00 +0200, Bart Lateur wrote: > > >On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote: > > > > > > >I meant that BEGIN, END, and INIT aren't declared as subs at present but > > > >named blocks. I was surprised to discover that they're put in the symbol > > > >table anyway though. > > > > > >Check the docs again. [snip] > > > Four special subroutines act as package constructors and > > > destructors. These are the `BEGIN', `CHECK', `INIT', and `END' > > > routines. The `sub' is optional for these routines. > > > > Drat. I propose making it non-optional for P6. ETOOMANYSPECIALCASES. Any > > objections? > > But what happens if you want multiple BEGIN blocks? The same thing that happens now. As I understand it, perl compiles and executes the BEGIN block then detroys it so that you may have as many BEGIN blocks as you want and each time perl thinks it's the first one. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
On Tue, 08 Aug 2000 13:03:16 +0200, Bart Lateur wrote:
>If you mean that you MUST use "sub", I object. If you mean that the
>"sub" may not be used, I agree.
Addendum. I would propose that
BEGIN {
...
}
would be what it is now, and that
sub BEGIN {
...
}
would be just a plain user defined sub.
That's what it looks like to ordinary users unfamiliar with Perl's
current behaviour, IMO.
--
Bart.
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
On Mon, 07 Aug 2000 15:19:00 -0700, Peter Scott wrote:
>>Check the docs again. [snip]
>> Four special subroutines act as package constructors and
>> destructors. These are the `BEGIN', `CHECK', `INIT', and `END'
>> routines. The `sub' is optional for these routines.
>
>Drat. I propose making it non-optional for P6. ETOOMANYSPECIALCASES. Any
>objections?
If you mean that you MUST use "sub", I object. If you mean that the
"sub" may not be used, I agree.
The whole thing with reminds me of FORTH's [ ... ] syntax, which
temporarily stops compilation, and the code between the square brackets
is executed instead of compiled. It maps directly to Perl's
BEGIN { ... }. To me, it is not a sub that gets compiled and immedialy
executed.
OTOH, for END { ... }, you could say it is.
The possibility of multiple BEGIN and END blocks do distinguish it from
ordinary callback subs, though.
--
Bart.
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
Peter Scott <[EMAIL PROTECTED]> writes: > At 12:07 AM 8/8/00 +0200, Bart Lateur wrote: > >On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote: > > > > >I meant that BEGIN, END, and INIT aren't declared as subs at present but > > >named blocks. I was surprised to discover that they're put in the symbol > > >table anyway though. > > > >Check the docs again. [snip] > > Four special subroutines act as package constructors and > > destructors. These are the `BEGIN', `CHECK', `INIT', and `END' > > routines. The `sub' is optional for these routines. > > Drat. I propose making it non-optional for P6. ETOOMANYSPECIALCASES. Any > objections? But what happens if you want multiple BEGIN blocks? -- Piers
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Proposal to utilize C<*> as the prefix to magic subroutines I freely accept that this is not anything approaching a reasoned critique but: Yecch! -- Piers
RE: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
From: Peter Scott [mailto:[EMAIL PROTECTED]] >At 12:07 AM 8/8/00 +0200, Bart Lateur wrote: >>On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote: >>Check the docs again. [snip] >> Four special subroutines act as package constructors and >> destructors. These are the `BEGIN', `CHECK', `INIT', and `END' >> routines. The `sub' is optional for these routines. >Drat. I propose making it non-optional for P6. ETOOMANYSPECIALCASES. Any >objections? Yeah, I have to object on the basis that it seems Perlish (and perlish, as far and I get that) to me for me to be able to skip a word here and there where what's happening (ie, I'm creating a set of instructions, or subrutine.) -Corwin
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
At 12:07 AM 8/8/00 +0200, Bart Lateur wrote: >On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote: > > >I meant that BEGIN, END, and INIT aren't declared as subs at present but > >named blocks. I was surprised to discover that they're put in the symbol > >table anyway though. > >Check the docs again. [snip] > Four special subroutines act as package constructors and > destructors. These are the `BEGIN', `CHECK', `INIT', and `END' > routines. The `sub' is optional for these routines. Drat. I propose making it non-optional for P6. ETOOMANYSPECIALCASES. Any objections? -- Peter Scott Pacific Systems Design Technologies
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote:
>I meant that BEGIN, END, and INIT aren't declared as subs at present but
>named blocks. I was surprised to discover that they're put in the symbol
>table anyway though.
Check the docs again. Although not the habit, it IS allowed to use:
sub BEGIN {
}
instead of just:
BEGIN {
}
>From perlmod:
Package Constructors and Destructors
Four special subroutines act as package constructors and
destructors. These are the `BEGIN', `CHECK', `INIT', and `END'
routines. The `sub' is optional for these routines.
--
Bart.
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
At 12:55 PM 8/7/00 -0500, Jonathan Scott Duff wrote:
>On Mon, Aug 07, 2000 at 10:04:15AM -0700, Peter Scott wrote:
> > At 04:43 PM 8/7/00 +, Perl6 RFC Librarian wrote:
> > > sub *BEGIN { ... }
> > > sub *END{ ... }
> > > sub *INIT { ... }
> > > sub *AUTOLOAD { ... }
> > > sub *TIESCALAR { ... }
> > > sub *FETCH { ... }
> >
> > Only half of those are subs.
>
>What do you mean?
I meant that BEGIN, END, and INIT aren't declared as subs at present but
named blocks. I was surprised to discover that they're put in the symbol
table anyway though. But they're definitely in a different class,
syntactically if nothing else.
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
On Mon, Aug 07, 2000 at 10:56:40AM -0700, Peter Scott wrote: > I meant that BEGIN, END, and INIT aren't declared as subs at present but > named blocks. I was surprised to discover that they're put in the symbol > table anyway though. But they're definitely in a different class, > syntactically if nothing else. Ah, but they *are* subs and you've stated my point exactly. They're different beasts. They're special. Make them look special. Radically special. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
On Mon, Aug 07, 2000 at 10:04:15AM -0700, Peter Scott wrote:
> At 04:43 PM 8/7/00 +, Perl6 RFC Librarian wrote:
> > sub *BEGIN { ... }
> > sub *END{ ... }
> > sub *INIT { ... }
> > sub *AUTOLOAD { ... }
> > sub *TIESCALAR { ... }
> > sub *FETCH { ... }
>
> Only half of those are subs.
What do you mean?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
At 10:29 AM 8/7/00 -0700, Nathan Wiger wrote:
> > With the proliferation of special subroutine names (BEGIN, END, INIT,
> > CHECK, etc.) the all capital subroutine names available to the
> > programmer has steadily shrunk. Rather than stealing subroutines from
> > the programmer, we should create a space just for Perl.
> >
> > sub *BEGIN {
> > # do compile-time stuff
> > # Perl-special
> > }
>
>I think this is a very valid point, but I don't think a special
>character should be chewed up for this. In particular, I really don't
>see typeglobs going away (they do some things you can't do otherwise).
>Besides, subs already have a magic character - the word "sub".
>
>Maybe just a convention like a leading underscore or two + CAPS?
>
>sub _TIESCALAR {}
>sub _FETCH {}
>sub _STORE {}
>sub _DESTROY {}
If you're going to use a convention, rather than a syntax, then the current
convention of all CAPS reserved to Perl is easier to understand, more
pleasing to the eye, and backwards compatible.
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
> If you're going to use a convention, rather than a syntax, then the current > convention of all CAPS reserved to Perl is easier to understand, more > pleasing to the eye, and backwards compatible. Good point. Maybe we're getting a little "fix-happy". :-) -Nate
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
> With the proliferation of special subroutine names (BEGIN, END, INIT,
> CHECK, etc.) the all capital subroutine names available to the
> programmer has steadily shrunk. Rather than stealing subroutines from
> the programmer, we should create a space just for Perl.
>
> sub *BEGIN {
> # do compile-time stuff
> # Perl-special
> }
I think this is a very valid point, but I don't think a special
character should be chewed up for this. In particular, I really don't
see typeglobs going away (they do some things you can't do otherwise).
Besides, subs already have a magic character - the word "sub".
Maybe just a convention like a leading underscore or two + CAPS?
sub _TIESCALAR {}
sub _FETCH {}
sub _STORE {}
sub _DESTROY {}
-Nate
Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t
At 04:43 PM 8/7/00 +, Perl6 RFC Librarian wrote:
> sub *BEGIN { ... }
> sub *END{ ... }
> sub *INIT { ... }
> sub *AUTOLOAD { ... }
> sub *TIESCALAR { ... }
> sub *FETCH { ... }
Only half of those are subs.
--
Peter Scott
Pacific Systems Design Technologies
RFC 59 (v1) Proposal to utilize C<*> as the prefix t
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Proposal to utilize C<*> as the prefix to magic subroutines
=head1 VERSION
Maintainer: Jonthan Scott Duff
Date: 7 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 59
=head1 ABSTRACT
Perl has always claimed the ALL-CAPS names for itself, I propose we
give them back to the programmer.
=head1 DESCRIPTION
Perl steals subroutine names from the programmer. By prefixing the
Perl-special subroutines with a character that is not a valid prefix
for Perl programmers, we separate what belongs to Perl and what
belongs to the user.
With the proliferation of special subroutine names (BEGIN, END, INIT,
CHECK, etc.) the all capital subroutine names available to the
programmer has steadily shrunk. Rather than stealing subroutines from
the programmer, we should create a space just for Perl.
sub *BEGIN {
# do compile-time stuff
# Perl-special
}
sub BEGIN {
# No relation to the former. Purely user space.
# The user may have his/her own reasons for naming his
# subroutines this way. (e.g., it fits the conception model
# that the software is build upon/around/through)
}
The visual distinction lets the programmer know that something special
is happening here and that this is not your average run-of-the-mill
subroutine.
Another area where could be useful is in conjunction with Damian
Conway's C proposal. As his proposal currently stands, the
programmer can not name a package LIST or SCALAR and use it with the
proposed C.
=head2 Examples
switch ([want]) {
case '*LIST'{ return @array; }
case '*SCALAR' { return $foo; }
case 'LIST' { return $MyListObj; }
}
sub *BEGIN { ... }
sub *END{ ... }
sub *INIT { ... }
sub *AUTOLOAD { ... }
sub *TIESCALAR { ... }
sub *FETCH { ... }
=head2 Potential problems
Makes Perl-special subroutines different from user subroutines. This
implies yet another special case.
=head1 IMPLEMENTATION
Um ... that's up to the internals people.
=head1 REFERENCES
Perl 5.6.0 documentation
RFC 21 (v1): Replace C with a generic C function
