Re: RFC 232 (v1) Replace AUTOLOAD by a more flexible mechanism
On Fri, Sep 15, 2000 at 03:11:47PM -0600, Nathan Torkington wrote:
> Perl6 RFC Librarian writes:
> > This RFC proposes two-stage autoloading: one stage may be registered
> > to act when the symbol is encountered at compile time, the other
> > when the subroutine is called. Autoloading on the second stage does not
> > I the subroutine, only I it.
>
> You have a beautiful mind, Mr Zakharevich. I'd like to frame it on my
> wall.
I can see that the nail that attaches it to my wall is already shaky...
When it is falls down, feel free to pick it...
> Actually, I think I'd like to see this extended. I'd like to be able
> to hook into the parser so that when it sees a function call:
>
> foo()
>
> I can have it call my subroutine.
>
> foo_handler( $token_stream )
>
> foo_handler can access the token stream that may or may not be part of
> the argument list, decide what is, and then return the code to be
> executed at runtime (normally just a call to foo()):
>
> sub foo_handler {
> return sub { foo() }; # *not* an infinite loop, please
> }
This is just a user-defined operator (which see on p5p). You register
foo() as a user-defined operator (with the precedence/etc of a
function call - or of a unary or nullary function). Then your handler
gets the OP trees for the arguments.
By the way, if you do not need to inspect the argument OP trees at
compile time, you may extend the discussed proposal to allow the
compile-time action to return EITHER prototype, OR a subroutine
reference.
Getting arguments at compile time is tricky: you cannot get them
unless you know the prototype already. RFC18 and user-defined
operators avoid this since they specify the prototype *before* the
call is encountered.
> Context-coercion:
>
> sub foo_handler {
> my $token_stream = shift;
> my $arg_1 = $token_stream->next; # assuming passed as strings?
> return eval "sub { scalar($arg_1) }";
This is the part of my proposal for user-defined-operators: you can
force context for your arguments. Keep in mind that UDO are at least
partially orthogonal w.r.t. RFC18: they see already compiled trees
(but can modify them if needed), and not the string arguments.
This is the problem with RFC18: you cannot "partially compile"
things. How many arguments for f() in
f($a, $b, g my $c, $d);
3 or 4? This depends on the arity of g(). But you cannot find this
arity until you compile the call frame for g(), and then lexical $c is
already introduced! So you cannot make f() to be a "comment", just
the act of determining the arguments to f() has side-effects.
Ilya
RFC 241 (v1) Pseudo-hashes must die!
=head1 VERSION Maintainer: Michael Schwern <[EMAIL PROTECTED]> Date: 16 September 2000 Mailing List: perl6-language Number: ? Version: 1 Status: Developing (Last Call) Reply-To: perl6-language @perl.org This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Pseudo-hashes must die! =head1 VERSION Maintainer: Michael Schwern <[EMAIL PROTECTED]> Date: 16 September 2000 Mailing List: perl6-language @perl.org Number: 241 Version: 1 Status: Developing (Last Call) =head1 ABSTRACT Pseudo-hashes and the associated fields pragma shoule be removed from Perl 6. =head1 DESCRIPTION There are numerous insuperable problems with pseudo-hashes, as detailed in "Object Oriented Perl" and "Programming Perl, Ed. 3". They are a noble experiment that many feel has failed. They should be removed. Pseudo-hashes have existed since at least May 28th, 1997 when they were added as patch #2 to what would eventually become 5.004_50. Two years, three months and 20 days later they're still considered experimental, incomplete and loaded with caveats. Doesn't play well with multiple inheritance Muddles the behavior of typed variables Requires significant extra documentation and complication of hash operations. Inconsistencies between typed and untyped access. Pseudo-hashes, unless used very carefully, often turn out slower than hashes. Pseudo-hashes were added to solve three problems: restrict keyspace, reduce memory usage and increase speed of hashes. There are many RFCs which address these issues with less caveats. There has been some discussion on p5p regarding the removal of pseudo-hashes (and other experimental features) should their adolescence take too long. Two major revisions of experimentation was given as a rough limit to declaring an experiment as a failure. The extensive development time, continued experimental nature, caveats and availability of better proposals lead to one conclusion: B =head1 MIGRATION Considerable. Most would be solved by a clever rejigging of the fields pragma to revert to simple hashes or other Perl 6 features. A 100% perfect conversion will not be achieved without an inorderinate amount of work. Since pseudohashes were an experimental feature, a less-than-perfect migration is acceptable. You pays your money and you takes your chances. (As a fairly extensive user of pseudohashes, I'm willing to take the hit.) =head1 IMPLEMENTATION Very simple, don't implement it. :) In Perl 5 terms, avhv functions removed from av.c, pseudo-hash code removed from pp.c, pp_hot.c, doop.c, mg.c, embed.pl etc and pseudo-hash documentation caveats removed from perlref and perlfunc. =head1 REFERENCES Discussion of experation of experimental features. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-01/msg00017.html http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-01/msg00255.html RFCs which supplant pseudohash functionality. RFC 188 - Objects : Private keys and methods RFC 200 - Objects: Revamp tie to support extensibility (Massive tie changes) RFC 163 - Automatic accessors for hash-based objects RFC 124 - Sort order for any hash RFC 122 - types and structures etc... http://us.imdb.com/Title?0165929 http://us.imdb.com/Title?0102691 http://us.imdb.com/Title?0094077 http://us.imdb.com/Title?0054474
Re: RFC 236 (v1) Change the way $SIG{__WARN__} and $SIG{__DIE__} are used
On Sat, Sep 16, 2000 at 03:36:45AM -, Perl6 RFC Librarian wrote:
> Change the way $SIG{__WARN__} and $SIG{__DIE__} are used
I don't think this is enough to repair $SIG{__WARN__} and
$SIG{__DIE__}. I know some people out there have some very strong
feelings about these pseudo-signals. It may even be that we should
kill them and replace them with something better. Has this yet been
discussed?
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Sometimes these hairstyles are exaggerated beyond the laws of physics
- Unknown narrator speaking about Anime
Re: RFC 103 (v2) Fix C<$pkg::$var> precedence issues with parsing of C<::>
On Sat, Sep 16, 2000 at 03:24:32AM -, Perl6 RFC Librarian wrote:
> Currently, trying to dynamically assign to unnamed classes is very
> difficult:
>
>$pkg::$var = $val; # error
>${pkg}::$var = $val; # nope
>${$pkg::$var} = $val; # you wish
>${${pkg}::$var} = $val;# sorry
>${"${pkg}::$var"} = $val; # works, but bleeech :-)
${$pkg.'::'.$var} = $val;
${"$pkg\::$var} = $val;
Still ugly, but not quite as bad as what you came up with.
> =head1 NOTES ON FREEZE
>
> The first part of this RFC, interpolated method calls, was superceded by
> RFC 222: "Interpolation of method calls", by Michael Schwern.
Ooop, didn't even notice and didn't see the discussion. Let me see if
I missed anything... I didn't discuss class methods as opposed to
object methods. Will ponder.
> In a perfect world, these should work in Perl 6:
>
> $var = 'RaiseError';
> $DBI::$var = 1 ; # $DBI::RaiseError = 1
Uh oh. Symbolic references!!! These carry enough caveats and are
abused so often (95% of the time you want a hash) that I'd rather they
were left amongst the "hard things possible" section of Perl.
Its a common newbie mistake to do something like this:
$var1 = "this";
$var2 = "that";
$var3 = "wibble";
foreach $num (1..3) {
print ${"var".$num};
}
Rather than use an array or hash, many people abuse symbolic
references. It happens frequently enough now, if its make simpler,
the abuses will increase.
> $pkg = 'Class';
> $var = 'DEBUG';
> ${${pkg}::$var} = 1; # $Class::DEBUG = 1
>
> $subpkg = 'Special';
> $class = $pkg . '::' . $subpkg;
> require $class;# require Class::Special
Ambiguous. Consider the following:
$class = "Class::Special";
$file = "lib/foo/bar.pl";
require $class; # want: load "Class/Special.pm" from @INC
require $file; # want: load "lib/foo/bar.pl" from @INC
The only way Perl can (currently) know if you're requiring a module or
a literal file is because of the bareword. Your proposal would
require that all requires be considered modules, which isn't feasible.
You could have require() differenciate by whether or not the EXPR
matches /::/, but that stinks of a special case.
C isn't that hard, but I wouldn't mind seeing a
more obvious way.
> $mypkg = 'Some::Package::Name';
> $ret = $mkpkg::do_stuff(@a); # is &{"${mypkg}::do_stuff"}(@a) now
This combines the problems of symbolic references PLUS busting
encapsulation. Shouldn't be easy.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Maybe they hooked you up with one of those ass-making magazines.
-- brian d foy as misheard by Michael G Schwern
Re: RFC 232 (v1) Replace AUTOLOAD by a more flexible mechanism
Nathan Torkington wrote:
> Actually, I think I'd like to see this extended. I'd like to be able
> to hook into the parser so that when it sees a function call:
>
> foo()
>
> I can have it call my subroutine.
>
> foo_handler( $token_stream )
>
> foo_handler can access the token stream that may or may not be part of
> the argument list, decide what is, and then return the code to be
> executed at runtime (normally just a call to foo()):
>
> sub foo_handler {
> return sub { foo() }; # *not* an infinite loop, please
> }
>
> The anonymous subroutine returned by the foo_handler() is then inlined
> into the optree.
The above is very, very similar to the effect of defining foo as an
"immediate" sub, per RFC 18.
> Perhaps this is no longer the point at which we think of it as
> autoloading, but rather as part of the compilation process. Just as
> we can intercept strings and regexes with overloaded strings and
> regexes, this would let us intercept functions.
That's the sense in which RFC was defined. This is one of the things that has
given FORTH so much extensibility. I'd vote for RFC 18. It would also let me
implement RFC 229 as approximately... depending on how the "parameters" to the
immediate sub are dealt with at immediate time (you called it token stream,
and that's probably the right word, or compile time parameters... I think the
need is for the text of the parameters, not the values: call by name not call
by value or reference.)
sub interpolate : immediate { return qq/eval "qq\000"/.join('',@_).qq/"\0"/; }
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_NetZero Free Internet Access and Email__
http://www.netzero.net/download/index.html
Re: RFC 236 (v1) Change the way $SIG{__WARN__} and $SIG{__DIE__} are used
> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes:
MGS> On Sat, Sep 16, 2000 at 03:36:45AM -, Perl6 RFC Librarian wrote:
>> Change the way $SIG{__WARN__} and $SIG{__DIE__} are used
MGS> I don't think this is enough to repair $SIG{__WARN__} and
MGS> $SIG{__DIE__}. I know some people out there have some very strong
MGS> feelings about these pseudo-signals. It may even be that we should
MGS> kill them and replace them with something better. Has this yet been
MGS> discussed?
i have proposed an rfc for the use signal pragma. it would allow for more
than just a simple handler like optional timeouts, private data, method
callbacks, safe delivery, etc. i need to update it and my few other
rfc's soon.
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
Richard Proctor wrote: > > Maybe I'm being too simplistic, I don't use tabs anymore. > > > > Yes you are, the problem comes with mixing editors - some use tabs for > indented material some dont, some reduce files using tabs etc etc. [I move > between too many editors]. Perl should DWIM. I think that treating tabs=8 > as the default would work for most people, even those who set tabs at other > values as long as they are consistent - a "use tabs 4" could be used by them > if they want to get the same behaviour if they mix tabs and spaces. Yes, but by being simplistic he eliminates the need to invent "use tabs 4". I have a don't care on this issue, but I lean towards Michael's assumption being valid enough... and if people don't mix tabs and spaces it works for any tab size setting, even the one true tab size setting of 8 characters. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
Certainly I could live with this set of suggestions. The complete set. Thanks Richard and Michael for developing them. Michael G Schwern wrote: > I'd say: > > 1) << does what it does now mod RFC 111 (ie. you can put whitespace in the >terminator, but it doesn't effect anything) > > 2) <<< does (e). > > 3) distribute a collection of dequote() mutations with perl. > > 4) mention the s/// tricks in the documentation (< > (d) can always be implemented as a simple Perl function (one of the > many dequote() mutations), (e) cannot. > > I think that'll make everyone happy. > > > [[there is still the tabs debate however]] > > Tabs are easy, don't expand them. Consider them as a literal > character. This assums that the code author is going to use the same > keystrokes to indent their here-doc text as the terminator, about as > safe an assumption as any for tabs. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: RFC 71 (v2) Legacy Perl $pkg'var should die
On Sat, Sep 16, 2000 at 03:20:23AM -, Perl6 RFC Librarian wrote:
> Perl used to use $pkg'var instead of the modern $pkg::var. This is still
> in Perl 5. It's gotta go.
Aside from "its old", is there any particular reason why $pkg'var
should go? The only reason I saw was that $hash{a'b} doesn't
DWIM... not exactly a stunning problem.
(Yes, I am the author of D'oh::Year ;)
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
An ice cream has its unique frequencyAre you hungry for this ice cream?
Or not? If you are, a certain part of your body is requesting to attract
chemicals from this ice cream. If you don't have the appetite, your body
doesn't need any chemical from the ice cream. Your brain is most conductive
and serves as the middleman.
--Alex Chiu, Immortality Guy
RFC 236 (v1) Change the way $SIG{__WARN__} and $SIG{__DIE__} are used
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Change the way $SIG{__WARN__} and $SIG{__DIE__} are used
=head1 VERSION
Maintainer: Chris Hostetter <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 236
Version: 1
Status: Developing
=head1 ABSTRACT
The current method in which C<__WARN__> and C<__DIE__> signal handlers are
used is limited in 2ways:
=over 8
=item It does not allow them to accept robust parameter lists.
=item It does not allow for multiple layers of handlers.
=back
=head1 DESCRIPTION
=head2 Parameter Treatment
The current behavior of C and C is to first concatenate the
parameter LIST into a single string, before checking if there is a
user specified signal handler. Then pass that string as a single
argument to any handler if it exists.
I propose, that a registered signal handler for C<__WARN__> or C<__DIE__>
should be passed the exact same LIST of arguments that the
corresponding warn or die call received. This would allow complex
programs to use the warn/die signal handling mechanism to for dealing
with complex exception handling, and still recognize low level
warnings / errors from the interpreter.
For example: It is reasonable when developing a large system to want a
mechanism for dealing with "error levels" -- one such approach would
be something like the following...
# use this function EXCLUSIVELY in your code for dealing with
# warnings or errors so that the appropraite acction is taken
sub errorHandle {
my $level = shift;
my @msgs = @_;
if ($config{abort_level} < $level) {
die "Fatal Error ($level): ", @msgs;
}
if ($config{warn_level} < $level) {
warn "Warning ($level): ", @msgs;
}
if ($config{log_level} < $level) {
# log something about @msgs
}
# etc ...
}
# want to make sure we catch things from interpreter and
# code from CPAN
$SIG{__WARN__} = sub { &errorHandler(9, @_); }
$SIG{__DIE__} = sub { &errorHandler(11, @_); }
# ...
&validateSomething($someArg) or errorHandle 9, "couldn't validate";
The problem with this, is that it requires you to use the non standard
"errorHandle" function explicitly in your code. If you are writing a
module that you plan on distributing to others, this is not ideal.
This would be far better, but would require that C<$SIG{__WARN__}>
(and C<$SIG{__DIE__}>) received the same list of parameters that warn (and
die) received...
# want to make sure we catch things from our code, the
# interpreter, or code from CPAN
$SIG{__WARN__} = sub {
my $level = $config{default_warn_level};
(1 < scalar(@_)) ? $level = shift;
my @msgs = @_;
if ($config{abort_level} < $level) {
die "Fatal Error ($level): ", @msgs;
}
if ($config{warn_level} < $level) {
warn "Warning ($level): ", @msgs;
}
if ($config{log_level} < $level) {
# log something about @msgs
}
# etc ...
}
$SIG{__DIE__} = sub { warn $config{default_warn_level}, @_; }
# ...
&validateSomething($someArg) or warn 9, "couldn't validate";
=head2 Nested Handlers
Currently, if a handler is called to deal with C<$SIG{__WARN__}> or
C<$SIG{__DIE__}> then the handler is disabled to prevent infinite
recursion if the handler itself calls C or C.
It seems only logical, that if the current handler has been localized,
and overshadows an outer handler, then calling C or C should
invoke the outer handler -- not the real C or C. For example...
#!/usr/local/bin/perl -w
$SIG{__WARN__} = sub { print "outer handler: ", @_; };
sub bar {
warn "in bar";
}
sub foo {
local $SIG{__WARN__} = sub { warn "foo: ", @_; };
&bar();
}
&foo();
... this script causes "C" to be
written to standard error. I propose that "C" is more logical output.
This would allow modules to do their own C<__WARN__> and C<__DIE__> handling,
but still propagate the messages out to an application specific
handler.
=head1 IMPLEMENTATION
Unknown.
=head1 REFERENCES
Programming Perl, 2nd Ed -- p139
Programming Perl, 2nd Ed -- p157
Programming Perl, 2nd Ed -- p241
RFC 213 (v2) rindex and index should return true/false values
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
rindex and index should return true/false values
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Sep 12 2000
Last Modified: Sep 15 2000
Mailing List: [EMAIL PROTECTED]
Number: 213
Version: 2
Status: Developing
=head1 ABSTRACT
index() and rindex() should return C if their
second argument is not a substring of their first
argument. If the substring occurs at the start of
the first argument, they should return "0 but true".
=head1 CHANGES
* added "0 but true" suggestion
=head1 DESCRIPTION
In perl5, index() and rindex() return -1 if the
substring isn't found. This seems out of step with
the rest of Perl's functions, which return C
on error. I propose changing index() and rindex()
to return C if the substring isn't found.
This would also cause warnings to be issued when
programmers use the results of index() or rindex()
assuming the substring was found.
This suggestion doesn't rely on RFC 53, "Built-ins: Merge and
generalize C and C", and works regardless
of whether 53 is accepted or not.
When the substring occurs at the start of the larger
string, the functions should return "0 but true". This
is exempt from "isn't numeric" warnings, and gives them
useful boolean return values:
if (index($big_string, $little_string)) {
print "$little_string is in $big_string";
}
without breaking their existing numeric uses.
=head1 IMPLEMENTATION
The perl526 translator could turn index($a,$b) calls into
do { my $tmp = index($a,$b);
if (defined($tmp)) { 0 + $tmp }
else { -1 }
}
=head1 REFERENCES
RFC 53: Built-ins: Merge and generalize C and C
perlfunc manpage for information on index() and rindex()
RFC 199 (v3) Short-circuiting built-in functions and user-defined subroutines
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Short-circuiting built-in functions and user-defined subroutines
=head1 VERSION
Maintainer: Garrett Goebel <[EMAIL PROTECTED]>
Date: 6 Sep 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 199
Version: 3
Status: Developing
=head1 ABSTRACT
Allow built-in functions and user defined subroutines to catch exceptions
and act upon them, particularly those emanating from control blocks. Put
another way, allow blocks to simultaneously exit early with a value.
=head1 DESCRIPTION
=head2 OVERVIEW
Currently there is not a practical and flexible way to short-circuit
built-in functions like C and C which take blocks as a parameter.
A prime example that was raised is:
my $found = grep { $_ == 1 } (1..1_000_000);
Under Perl 5, one would need to write something like:
eval { grep { $_ ==1 and die "$_\n" } (1..1_000_000) };
chomp(my $found = $@);
Under this current proposal this might be written as:
my $found = grep { $_ == 1 and return $_ && last grep } (1..1_000_000);
(or alternatively)
my $found = grep { $_ == 1 and abort grep $_ } (1..1_000_000);
It is the opinion of the author that while the proposal saves little by
way of typing, that it is minimally an improvement in clarity. Further
this proposal introduces semantics which will make other tasks easier.
=head2 DEFINITION OF THE PROBLEM
=over 4
=item 1
How do you simultaneously exit early and return a value?
reject the current element and continue
accept the current element and continue
reject the current element and abort
accept the current element and abort
reject the current element and retry
accept the current element and retry
=item 2
How do you do that *and* be consistent with existing semantics?
=back
=head2 OPTIONS AND ALTERNATIVES
There has been much discussion and ideas exchanged on the best way to
achieve this. Discussion ranging from specific solutions which would
only apply to the C and C built-ins, to more general ones
such as unifying the exception syntax for loop, code, and bare blocks.
There has also been a vocal contingent protesting that all of the
suggestions attempt to shoehorn too much new functionality into
existing semantics and that no one has yet presented any workable
solutions.
The current ideas tend to converge around the following three options:
=over 4
=item 1
Grant code blocks their names as labels, and add new keywords
for code block control: C/C/C:
# short-circuit after first acceptance...
$found = grep { ($_ == 1) and abort grep $_ } (1..1_000_000);
# short-circuit after first rejection...
$found = grep { ($_ == 1) and abort grep } (1..1_000_000);
=item 2
Grant code blocks their own names as labels, and the ability to catch
next/last/redo exceptions which explicitly use those labels.
# short-circuit after first acceptance...
@smalls = grep { ($_ == 1) and return $_ && last grep } (1..1_000_000);
# short-circuit after first rejection...
@smalls = grep { ($_ == 1) and last grep } (1..1_000_000);
=item 3
The built-in function's operation should catch exceptions thrown from
the block, where the exception thrown is true or false (alternative: 1
or false). Example:
# short-circuit after first acceptance...
$found = grep { ($_ == 1) and die 1 } (1..1_000_000);
# short-circuit after first rejection...
$found = grep { ($_ == 1) or die 0 } (1..1_000_000);
=back
=head2 INDECISIONS: BY THE PRICKINGS OF MY THUMB...
Detractors would argue:
=over 4
=item 1
First Proposal: Add code labels and new keywords: C/C/C
=over 4
=item *
Aversion to taking any more new keywords
=back
=item 2
Second Proposal: Add code labels, and let code blocks use
C/C/C syntax which explicitly use those labels.
=over 4
=item *
Too complicated, changes too much, attempts to shoehorn to too many
semantic changes into the existing syntax/keywords
=back
=item 3
Third Proposal: Extend use of C
=over 4
=item *
Built-ins shouldn't catch user-defined exceptions. How do you raise
a serious exception within a control block if you weaken C into
something that can be automatically caught by built-ins? I.e., no good
support for multi-level exceptions.
=item *
Doesn't provide a very intuitive syntax for doing the same type of
C/C/C control as is available with loop blocks.
=back
=back
The author shares much of detractors opinions for the third proposal, and
would prefer either the first or second to be implemented. The reason I prefer
one of these two is that I believe they are more intuitive, flexible, and
semantically rich. As such, the remainder of this RFC concern itself with
issues pertaining to the first two proposals.
=head2 FINER DETAILS AND OTHER ISSUES
=head3 Issues common to the first and second proposals:
=over 4
=item *
Built-ins and Subroutines automatically get their name as a label
It might therefore follow that it would be goo
RFC 195 (v2) Retire chop().
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Retire chop(). =head1 VERSION Maintainer: Nathan Torkington <[EMAIL PROTECTED]> Date: 5 Sep 2000 Last Modified: 15 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 195 Version: 2 Status: Frozen =head1 ABSTRACT Remove chop() from the core. Its purpose is better served by chomp(), so its remaining applications are few and limited. =head1 CHANGES * Added mention of how per-filehandle autochomping would affect this RFC. =head1 DESCRIPTION chop()'s original purpose was to remove trailing line terminators. However, chop() is dangerous: it always removes the last character, and it doesn't care whether the last character is a line terminator or not. So chomp() was introduced. This only removes the value of $/, and if there's no $/ at the end of the string then it doesn't remove anything. This makes it safer: if you don't know whether your string is chomp()ed or not, you can chomp() it anyway. With chop() you had to have a separate explicit test. chop() also doesn't know about $/ and the different values it might have. chop() is still occasionally used, but very rarely. Not enough, in my opinion, for chop() to stay in the core. Its functionality might be available in a library. If filehandles gain the ability to automatically remove their record separators, then chomp() will still be needed. =head1 IMPLEMENTATION The perl526 translator can simply use s/.\z//s; for a chop() action. If there were a chop() in a standard library then the conversion would simply be a matter of putting: use String::Chop; # or whatever at the top of any converted program that uses chop(). Implementation in perl6 is very straightforward: don't implement chop(). =head1 REFERENCES RFC 58: C changes. perlfunc manpage for discussion of chomp() and chop()
RFC 135 (v3) Require explicit m on matches, even with ?? and // as delimiters.
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Require explicit m on matches, even with ?? and // as delimiters. =head1 VERSION Maintainer: Nathan Torkington <[EMAIL PROTECTED]> Date: August 20, 2000 Last Modified: 15 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 135 Version: 3 Status: Frozen =head1 ABSTRACT C and C are what makes Perl hard to tokenize. Requiring them to be written C and C would solve this. =head1 CHANGES Version 2 of this RFC redirects discussion of this topic to [EMAIL PROTECTED] =head1 DESCRIPTION Damian Conway's Text::Balanced module does a pretty good job of tokenizing Perl code. However, bare C and C require semantic analyis to distinguish them from division and the hook (C) operator. To remove this hassle, and thus permit programs that analyze the source-code of other programs, I propose requiring that all matches require an explicit C. =head1 IMPLEMENTATION Remove the bare C and C from the grammar :-) When converting perl5 programs to perl6, put the C in. =head1 REFERENCES perl6-language message C<[EMAIL PROTECTED]> by Damian Conway
RFC 103 (v2) Fix C<$pkg::$var> precedence issues with parsing of C<::>
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Fix C<$pkg::$var> precedence issues with parsing of C<::>
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 103
Version: 2
Status: Frozen
=head1 ABSTRACT
Currently, trying to dynamically assign to unnamed classes is very
difficult:
$pkg::$var = $val; # error
${pkg}::$var = $val; # nope
${$pkg::$var} = $val; # you wish
${${pkg}::$var} = $val;# sorry
${"${pkg}::$var"} = $val; # works, but bleeech :-)
The precedence and parsing of the :: operator should be fixed to allow
easy access to anonymous package operations.
=head1 NOTES ON FREEZE
The first part of this RFC, interpolated method calls, was superceded by
RFC 222: "Interpolation of method calls", by Michael Schwern.
=head1 DESCRIPTION
In a perfect world, these should work in Perl 6:
$var = 'RaiseError';
$DBI::$var = 1 ; # $DBI::RaiseError = 1
$pkg = 'Class';
$var = 'DEBUG';
${${pkg}::$var} = 1; # $Class::DEBUG = 1
$subpkg = 'Special';
$class = $pkg . '::' . $subpkg;
require $class;# require Class::Special
$mypkg = 'Some::Package::Name';
$ret = $mkpkg::do_stuff(@a); # is &{"${mypkg}::do_stuff"}(@a) now
Currently, the precedence of :: does not allow these operations. Some of
the above examples may still require additional braces, but they
shouldn't require the types of contortions currently needed.
=head1 IMPLEMENTATION
Unfortunately, I don't have the time to think this part up yet. :-( I
will gladly contribute to the precedence and parsing rules discussions
that will ensue in the future if this RFC is accepted.
=head1 REFERENCES
Programming Perl, 2ed, for the ${"${pkg}::$var"} syntax
RFC 222: Interpolation of method calls
Re: RFC 230 (v1) Replace C built-in with pragmatically-inducedC function
> I loathe the indirect object syntax.
Well that makes one of us! ;-)
> Easy. Put them in a subroutine:
>
> sub format1 { format $template1, @data };
> sub format2 { print STDERR format $template1, @data };
> # etc.
Gag! Cough! Ack! :-}
Not trying to be mean, but this doesn't make things easy. As I mentioned
in my previous email, being able to say:
write STDOUT;
is a *benefit*. It seems your proposal is 90% of the way there if it
just followed suit with the other commonly-used printing functions:
print $STDERR @stuff;
printf $STDERR $fmt, @stuff;
format $STDERR $fmt, @stuff;
Looks pretty consistent to me, and makes things easy too.
Either that, or drop the printing in a void context altogether, and just
tell people they have to say
print format $fmt, @stuff;
Which I'm ok with too. But partially supporting printing, only to the
default filehandle, I don't think is a good idea. You're gonna end up
with lots of nasty code that way, which this RFC would otherwise
prevent.
-Nate
RFC 71 (v2) Legacy Perl $pkg'var should die
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Legacy Perl $pkg'var should die =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 08 Aug 2000 Last Modified: 15 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 71 Version: 2 Status: Frozen =head1 ABSTRACT Perl used to use $pkg'var instead of the modern $pkg::var. This is still in Perl 5. It's gotta go. =head1 DESCRIPTION See above. =head1 IMPLEMENTATION See above. =head1 NOTES ON FREEZE Damian worried that this would mean Klingon.pm would no longer be portable to Perl 6. He failed to convince other people on the list that this was actually a bad thing. ;-) (kidding!!) =head1 REFERENCES Camel-3 p. 60 reminded me of this.
Re: RFC 230 (v1) Replace C built-in with pragmatically-induced C function
> > prints the result to the current filehandle (in a void context).
>
> The last one I think needs to be able to work on any filehandle via
> indirect object syntax, namely:
>
>format $FILE "<<< [[[ [[",
> $title, $text1, $text2;
I loathe the indirect object syntax.
There's always:
print $FILE format "<<< [[[ [[",
$title, $text1, $text2;
> Second, I think there still needs to be a way to store these formats
> somehow. One nice thing about current Perl formats is being able to
> declare them once at the top of the script (or module) and then calling
> write at different points throughout your script.
Easy. Put them in a subroutine:
sub format1 { format $template1, @data };
sub format2 { print STDERR format $template1, @data };
# etc.
Damian
Re: RFC 226 (v2) Selective interpolation in single quotish context.
On Fri, Sep 15, 2000 at 11:25:31AM -0700, Steve Fink wrote:
> I agree. I'd like q/.../ to stick as close to giving me ... as possible.
> I can live with the current 'foo\\bar' having only one backslash in it,
> but I'd rather not have to worry about anything else. I'd vote for
> Glenn's allowing the disabling of interpolation in qq// and <<""
> instead.
>
> Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'?
Not at all. I can't count the number of times I have railed against bash
for deciding that you cannot escape ' inside ' (e.g. 'foo\'s bar'). Being
unable to escape \ would cause similar grief (e.g. 'foo bar\\').
This is incredibly annoying when doing Perl one-liners especially; one is
forced to use single quotes so that bash doesn't attempt to interpolate
variables itself. Unfortunately, one can't use single quotes internally
unless you say \047 or its equivalent (which I nearly always have to go look
up), or q{} if you're quoting something. q{} has saved my sanity more than
once.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 226 (v2) Selective interpolation in single quotish context.
On Fri, 15 Sep 2000 11:25:31 -0700, Steve Fink wrote: >Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'? It's an necessary evil. You need a way to escape the string delimiter, so that it can be included in the string, for which the backslash is used. Hence, you need to be a be to escape the backslash as well, or else you could never incorporate a backslash+delimiter sequence in the string. Note that backlash and delimiter are the *only* things for which the backslash character serves as an escape character: print q!\'\"\/\!\\!; --> \'\"\/!\ print q/\'\"\/\!\\/; --> \'\"/\!\ -- Bart.
Re: RFC 226 (v2) Selective interpolation in single quotish context.
On Thu, 14 Sep 2000 21:06:24 -0700, Glenn Linderman wrote: >However, let's look at it the other way. How about instead of trying to _extend_ >single quote semantics, that instead we find a way of _disabling_ double quote >semantics? Let's say within double quotes that \D reverts to single-quote >semantics with the extension that \E ends them again. I think I like this better. There frequently are threads on comp.lang.perl.misc on people that are opposed to double quotes around strings that don't use any interpolation, because "the double quotes are a warning flag that there is something going on in this string" (paraphrased). And they tend to be slightly disappointed if it turns out to be a false alarm. Invert this: single quotes are a flag that "this string is safe". And now, you're going to add a facility that destroys this safe image? Please, let the programmer in his peace. Let the single quotish strings remain safe. OTOH, double quotish strings already *are* intrinsically unsafe. An option to locally disable interpolation is no extra burden. -- Bart.
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
On Fri, 15 Sep 2000 08:13:26 -0400 (EDT), Eric Roode wrote: >The here-doc terminators all line up with the perl code. >The generated program is nicely indented relative to the left margin. My sentiments exaclty. I think I would compare this to normal TV programmes (the code) interruped by special news flashes (the here docs). Surely you wouldn't expect the newsreaders to adapt their news reading style to the show they are interrupting. No: news readers have their own, fixed style, which is completely independent of what's comes before or after it. In the same way, the here docs are text flashes, that are completely independent of the code around it. Text and code just happen to be interleaved. -- Bart.
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
On Thu, 14 Sep 2000 03:11:54 -0400, Michael G Schwern wrote:
>The current stumper, which involves problems 1, 2 and 3 is this:
>
> if( $is_fitting && $is_just ) {
>die Dulce et decorum est
> Pro patria mori.
>POEM
> }
>
>I propose that this work out to
>
>"The old lie\n Dulce et decorum est\n Pro patria mori.\n"
>
>and always work out to that, no matter how far left or right the
>expression be indented.
I happen to disagree, and here's why. To me, here docs are like *literal
extracts* from text documents that you want to reproduce. *Nothing* is
supposed to be changed about it: the result should be *exactly* what it
is in the here doc, apart from interpolation in double-quotish here
docs.
I very often insert (parts of) text files produced by other people, and
I don't want to be forced to indenting all of it, every single line.
However, the same does not count for the here doc terminator. This one
very often trips me up. Since this may not be randomly indented, I lose
sight of my code indentation, and as a consequence I forget closing
braces for blocks etc. Annoying.
Another problem is the trailing whitespace: invisible, yet extremeley
important: there should be none.
Being freed of these two concerns, that boil down to one thing: leading
and trailing whitespace, would be most welcome.
I do not mind having an option of loosing some leading spaces or tabs
for here docs. However, I'm already pretty sure that if this is
optional, I won't ever use it. So please, do not force it down my
throat.
--
Bart.
Re: RFC 229 (v1) Variable interpolation on demand.
Simon Cozens wrote:
> sub interpolate {eval "\"@_\""}
>
> Never say "there is no way". There's *always* a way, and 99% of the time it
> doesn't need to go in core.
Yes. Well, actually if you carefully read the thread about RFC 111 in which I got
the inspired flash that interpolation of variables might be useful, you'll see that
I knew about this way, and even suggested it. In fact, I meant to put it in the
IMPLEMENTATION section of the RFC, but sent it too soon, and already have version 2
ready with that change, but was waiting to learn the number, and read the initial
comments to see if any other changes should be made.
This fails if @_ contains ", or the other delimiter if using qq. Using \000 as a
delimiter is _pretty_ safe, but perl strings are allowed to contain it, and I have
scripts that have strings containing \000 characters. So really even this is not a
complete solution, if you have a string that happens to contain all the possible
characters, such that no delimiter is possible.
OK, you could rescan and quote the delimiter... that's harder... almost might as
well implement your own quoting.
The other problem with this being a sub is that it wouldn't handle lexical
variables correctly, not knowing their names in the sub.
> --
> "Even if you're on the right track, you'll get run over if you just sit there."
> -- Will Rogers
Thanks for bringing this quote to my attention. I may use it some.
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
NetZero Free Internet Access and Email_
Download Now http://www.netzero.net/download/index.html
Request a CDROM 1-800-333-3633
___
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
I'm happy with this solution, it seems to address everyone's needs. -Nate Michael G Schwern wrote: > > I'd say: > > 1) << does what it does now mod RFC 111 (ie. you can put whitespace in the >terminator, but it doesn't effect anything) > > 2) <<< does (e).
Re: RFC 230 (v1) Replace C built-in with pragmatically-induced C function
First off, nice proposal. :-) I haven't had a change to digest the
entire thing (although I did read it all), but I would like to add a few
things:
> returns the result as a single multi-line string (in a scalar context)
> returns the result as a list of single-line strings (in a list context)
> prints the result to the current filehandle (in a void context).
The last one I think needs to be able to work on any filehandle via
indirect object syntax, namely:
format $FILE "<<< [[[ [[",
$title, $text1, $text2;
Since many people use formats for multiple output streams, and I don't
want to be stuck with a whole bunch of:
$DEFOUT = $STDERR;
format ... ;
$DEFOUT = $STDOUT;
Stuff all over my code.
Second, I think there still needs to be a way to store these formats
somehow. One nice thing about current Perl formats is being able to
declare them once at the top of the script (or module) and then calling
write at different points throughout your script. Now, perhaps the best
way to do this is by sticking your format into a simple string which you
can use later:
my $STDOUT_FORMAT = q(<<< [[[ [[);
And then, in your loop code, calling:
for (@data) {
($a, $b, $c) = split;
format $STDOUT_FORMAT, $a, $b, $c;
}
Or, for a different filehandle:
my $STDERR_FORMAT = q(<<< [[[ [[);
for (@data) {
($a, $b, $c) = split;
format $STDERR $STDERR_FORMAT, $a, $b, $c;
}
Which would of course call $STDERR->format($STDERR_FORMAT, $a, $b, $c);
This seems to work for me, but I'd be interested in others' feedback.
-Nate
Backtracing contexts with self($n) (was Re: RFC 223 (v1) Objects: C pragma)
> I think such modules are a bad idea, because their functionality is
> typically restricted.
What, you mean like CGI.pm ?! :-)
> This is a benefit? Forcing multiple authors to use the same 'this' or
> 'self' name across modules is not the perl way
Well, from this logically follows that "forcing" people to use the same
@ARGV or chomp() is not the Perl way, which it obviously is.
This is not "forcing religion", it's Choosing An Interface. It is for
the greater good if we select one way. It changes textbooks to:
"To get the invocant, simply call self()"
From:
"The invocant is in whatever you 'use invocant' with, either a
variable
or subroutine name. By default, it's in $_[0], but this can be named
whatever you want; for the purposes of our examples we'll use $ME."
Perl is tricky enough already; we don't need even more special cases
when some simple compromise will suffice (see my P.S.).
> Migration is as easy with Damian's proposal.
That was actually my point, but just to do things in reverse: by default
have it in self() (or whatever) and allow the person to *revert* to Perl
5 behavior if they want.
To get off the religion point for a second, one thing that hasn't been
discussed but which I've been pondering heavily is the ability to
backtrace contexts like caller(). Consider how this could be used to go
up levels of chained object calls:
Apache->request->uri;
caller(1) caller(0)
self(1) self(0)
That is, self(0) (or just "self") would give you a reference pointing to
the object produced by Apache->request, whereas self(1) would give you a
reference to the original Apache class.
Consider how useful this would be in chained fileobject calls:
open("dup->readline;
self(1)self(0)
Here, self(0) would give you a reference to the dup'ed filehandle, and
self(1) would give you a reference to the original one.
This seems very useful to me, and can't be done without a function.
Comments welcome.
-Nate
P.S. And speaking of compromise, I don't think anyone is set in stone on
the name self(). If we decide this(), context(), me(), or some other
name is better, I'm fine with that. But I'm fairly certain that we need
a function given that it has to take arguments. ;-)
Re: RFC 199 (v3) Short-circuiting built-in functions and user-definedsubroutines
> The current ideas tend to converge around
While reading the current rfc199.2 version I imagined another way
to do this. Instead of adding a new escape, what if we could
fiddle with the looping condition?
Given a grep that works like so:
sub mygrep(&@){
local $index; # must be visible inside filter
my $filter = shift;
my @result;
for($index = $[; $index =< $#_; $index++){
$_ = $_[$index];
&$filter and push @result, $_
};
return @result
};
we could force an early return by altering $index from within &$filter.
I know there has been some discussion of having explicit iterator numbers
within loops, although I can't locate the RFC if there has been one.
Given an explicit iterator attribute inside loops, if that was a lvalue it
could be set to the end of the data, or set back to the beginning for
that matter, to effect a last or a redo.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=<>' ~/nsmail/Inbox
Re: RFC 213 (v1) rindex and index should return undef on failure
Chaim Frenkel writes: > I would like to have an undef returned. Ah, I see. You want subroutines to return undef if they're given it for any of their arguments. That'd break the lazy programmer practice of passing undef expecting it to become "" or 0. They don't have warnings on, of course. Nat
RFC 199 (v3) Short-circuiting built-in functions and user-defined subroutines
=head1 TITLE
Short-circuiting built-in functions and user-defined subroutines
=head1 VERSION
Maintainer: Garrett Goebel <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Version: 3
Mailing List: perl6-language
Number: 199
Status: Developing
=head1 ABSTRACT
Allow built-in functions and user defined subroutines to catch exceptions
and act upon them, particularly those emanating from control blocks. Put
another way, allow blocks to simultaneously exit early with a value.
=head1 DESCRIPTION
=head2 OVERVIEW
Currently there is not a practical and flexible way to short-circuit
built-in functions like C and C which take blocks as a parameter.
A prime example that was raised is:
my $found = grep { $_ == 1 } (1..1_000_000);
Under Perl 5, one would need to write something like:
eval { grep { $_ ==1 and die "$_\n" } (1..1_000_000) };
chomp(my $found = $@);
Under this current proposal this might be written as:
my $found = grep { $_ == 1 and return $_ && last grep } (1..1_000_000);
(or alternatively)
my $found = grep { $_ == 1 and abort grep $_ } (1..1_000_000);
It is the opinion of the author that while the proposal saves little by
way of typing, that it is minimally an improvement in clarity. Further
this proposal introduces semantics which will make other tasks easier.
=head2 DEFINITION OF THE PROBLEM
=over 4
=item 1
How do you simultaneously exit early and return a value?
reject the current element and continue
accept the current element and continue
reject the current element and abort
accept the current element and abort
reject the current element and retry
accept the current element and retry
=item 2
How do you do that *and* be consistent with existing semantics?
=back
=head2 OPTIONS AND ALTERNATIVES
There has been much discussion and ideas exchanged on the best way to
achieve this. Discussion ranging from specific solutions which would
only apply to the C and C built-ins, to more general ones
such as unifying the exception syntax for loop, code, and bare blocks.
There has also been a vocal contingent protesting that all of the
suggestions attempt to shoehorn too much new functionality into
existing semantics and that no one has yet presented any workable
solutions.
The current ideas tend to converge around the following three options:
=over 4
=item 1
Grant code blocks their names as labels, and add new keywords
for code block control: C/C/C:
# short-circuit after first acceptance...
$found = grep { ($_ == 1) and abort grep $_ } (1..1_000_000);
# short-circuit after first rejection...
$found = grep { ($_ == 1) and abort grep } (1..1_000_000);
=item 2
Grant code blocks their own names as labels, and the ability to catch
next/last/redo exceptions which explicitly use those labels.
# short-circuit after first acceptance...
@smalls = grep { ($_ == 1) and return $_ && last grep } (1..1_000_000);
# short-circuit after first rejection...
@smalls = grep { ($_ == 1) and last grep } (1..1_000_000);
=item 3
The built-in function's operation should catch exceptions thrown from
the block, where the exception thrown is true or false (alternative: 1
or false). Example:
# short-circuit after first acceptance...
$found = grep { ($_ == 1) and die 1 } (1..1_000_000);
# short-circuit after first rejection...
$found = grep { ($_ == 1) or die 0 } (1..1_000_000);
=back
=head2 INDECISIONS: BY THE PRICKINGS OF MY THUMB...
Detractors would argue:
=over 4
=item 1
First Proposal: Add code labels and new keywords:
C/C/C
=over 4
=item *
Aversion to taking any more new keywords
=back
=item 2
Second Proposal: Add code labels, and let code blocks use
C/C/C syntax which explicitly use those labels.
=over 4
=item *
Too complicated, changes too much, attempts to shoehorn to too many
semantic changes into the existing syntax/keywords
=back
=item 3
Third Proposal: Extend use of C
=over 4
=item *
Built-ins shouldn't catch user-defined exceptions. How do you raise
a serious exception within a control block if you weaken C into
something that can be automatically caught by built-ins? I.e., no good
support for multi-level exceptions.
=item *
Doesn't provide a very intuitive syntax for doing the same type of
C/C/C control as is available with loop blocks.
=back
=back
The author shares much of detractors opinions for the third proposal, and
would prefer either the first or second to be implemented. The reason I
prefer
one of these two is that I believe they are more intuitive, flexible, and
semantically rich. As such, the remainder of this RFC concern itself with
issues pertaining to the first two proposals.
=head2 FINER DETAILS AND OTHER ISSUES
=head3 Issues common to the first and second proposals:
=over 4
=item *
Built-ins and Subroutines automatically get their name as a label
It might therefore follow that it would be good to define C to
have the same semantics as C when the label referred to is a
function. Namely to pass @_.
Re: RFC 226 (v1) Selective interpolation in single quotish context.
My first preference is for overriding constant strings. My second preference is to provide a user-defined quoting operator mechanism, possibly as part of a user-defined operator mechanism. My third preference is for a new operator. I personally do not want to see q() screwed with. Nat
Re: RFC 227 (v1) Extend the window to turn on taint mode
On Fri, Sep 15, 2000 at 01:33:01PM -0700, Nathan Wiger wrote: > Michael G Schwern wrote: > > > > perl6-internals is probably the wrong forum for this, it was just > > convenient. I think Dan's got the right idea, distribute a Taint > > module with Perl. > > I'm not sure what's happened on -internals, but early on in > perl6-language I suggested something similar, and Larry dropped some > major knowledge on me about tainting: > > http://www.mail-archive.com/perl6-language@perl.org/msg00394.html > > I'd advise everyone read the above. Adding a $TAINT > variable/pragma/whatever is, basically, a Bad Idea. The hypothetical taint.pm/taint.xs that was being discussed was in a different context. The taint pragma that we were talking about is not about lexical scoping of taint mode, but rather a sensible place to add taint(), tainted() and similar functions that need specific knowledge of core internals. Of couse, if the core language contains taint() and untainted(), then this is a trivial discussion. We were looking at it from an internals perspective, with the POV that it may not be a core language feature. taint() and tainted() would work on scalars that may or may not be coming from a trustworthy source. untaint() should *not* be one of these functions, because untainting should remain hard (i.e., you should have to think about what you're doing). This is a discussion that may result in a different RFC altogether. It came up because RFC 227 discusses tainting. -language is probably not the right forum for either. I vote for starting a new thread in -stdlib. Z.
Re: RFC 232 (v1) Replace AUTOLOAD by a more flexible mechanism
Perl6 RFC Librarian writes:
> This RFC proposes two-stage autoloading: one stage may be registered
> to act when the symbol is encountered at compile time, the other
> when the subroutine is called. Autoloading on the second stage does not
> I the subroutine, only I it.
You have a beautiful mind, Mr Zakharevich. I'd like to frame it on my
wall.
Actually, I think I'd like to see this extended. I'd like to be able
to hook into the parser so that when it sees a function call:
foo()
I can have it call my subroutine.
foo_handler( $token_stream )
foo_handler can access the token stream that may or may not be part of
the argument list, decide what is, and then return the code to be
executed at runtime (normally just a call to foo()):
sub foo_handler {
return sub { foo() }; # *not* an infinite loop, please
}
The anonymous subroutine returned by the foo_handler() is then inlined
into the optree.
This would let us have constants:
sub foo_handler {
return sub { 42 };
}
Context-coercion:
sub foo_handler {
my $token_stream = shift;
my $arg_1 = $token_stream->next;# assuming passed as strings?
return eval "sub { scalar($arg_1) }";
}
This would give us the ability to have things with both compile-time
and run-time behaviours, as well as being able to remove run-time
behaviours if we wanted.
Perhaps this is no longer the point at which we think of it as
autoloading, but rather as part of the compilation process. Just as
we can intercept strings and regexes with overloaded strings and
regexes, this would let us intercept functions.
Nat
Re: RFC 227 (v1) Extend the window to turn on taint mode
Michael G Schwern wrote: > > perl6-internals is probably the wrong forum for this, it was just > convenient. I think Dan's got the right idea, distribute a Taint > module with Perl. I'm not sure what's happened on -internals, but early on in perl6-language I suggested something similar, and Larry dropped some major knowledge on me about tainting: http://www.mail-archive.com/perl6-language@perl.org/msg00394.html I'd advise everyone read the above. Adding a $TAINT variable/pragma/whatever is, basically, a Bad Idea. There's already $fh->untaint a per-filehandle OO untainting mechanism, as Tom shows here: http://www.mail-archive.com/perl6-language@perl.org/msg00442.html This may remain the best solution, judging by Larry's remarks. -Nate
Re: RFC 227 (v1) Extend the window to turn on taint mode
On Fri, Sep 15, 2000 at 04:01:11PM -0400, Dan Sugalski wrote: > >Anyhow, however these extra tainting functions are implemented is fine > >(as long as they work). The simplest thing would be to just merge and > >patch up Taint.pm and distribute it with perl6. > > Yup. I know Tom wanted an all-perl version so there wouldn't be any > dependencies on having a C compiler around. I took the XS route mainly > because I mistrust indirect methods. (Well, that and I'd written several > orders of magnitude more C code for perl than perl code at the point I > wrote that...) If we move it into the core the availablity of C compilers is no longer an issue. Having had a taste of the hacks one must do to pull off an all-perl version, XS seems the simplest route. PS I've moved this discussion to perl6-language. Reply accordingly. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Sometimes these hairstyles are exaggerated beyond the laws of physics - Unknown narrator speaking about Anime
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
On Fri 15 Sep, Michael G Schwern wrote: > On Fri, Sep 15, 2000 at 06:38:37PM +0100, Richard Proctor wrote: > > 1) << removes whitespace equivalent to the terminator (e) this is largely > > backward complatible as many existing heredocs are unlikely to have white > > space before the terminator. > > > > 2) <<< removes whitespace equivalent to the smallest whitespace (d) > > > > or are these the options that will satisfy everybody [no but its worth a > > try] > > > > 1) << Does just what it does now > > > > 2) <<< implements (d) or (e) > > > I'd say: > > 1) << does what it does now mod RFC 111 (ie. you can put whitespace in the >terminator, but it doesn't effect anything) I was assuming that the terminators changed ala RFC 111 whatever happens > > 2) <<< does (e). These are equivalent to my second set of options > > 3) distribute a collection of dequote() mutations with perl. As a module presumably > > 4) mention the s/// tricks in the documentation (< Yes. > > [[there is still the tabs debate however]] > > Tabs are easy, don't expand them. Consider them as a literal > character. This assums that the code author is going to use the same > keystrokes to indent their here-doc text as the terminator, about as > safe an assumption as any for tabs. > > Maybe I'm being too simplistic, I don't use tabs anymore. > Yes you are, the problem comes with mixing editors - some use tabs for indented material some dont, some reduce files using tabs etc etc. [I move between too many editors]. Perl should DWIM. I think that treating tabs=8 as the default would work for most people, even those who set tabs at other values as long as they are consistent - a "use tabs 4" could be used by them if they want to get the same behaviour if they mix tabs and spaces. Richard -- [EMAIL PROTECTED]
Re: RFC 227 (v1) Extend the window to turn on taint mode
At 03:43 PM 9/15/00 -0400, Michael G Schwern wrote: >On Fri, Sep 15, 2000 at 02:00:04PM -0400, Adam Turoff wrote: > > I'm kinda surfing the edge here. -T is definately an internals issue, > > but $TAINT? taint()? is_tainted()? > > > > I'm not sure if they should be exposed into the language from the > > internals, or if a superstudly taint.xs in stdlib is more appropriate. > >perl6-internals is probably the wrong forum for this, it was just >convenient. I think Dan's got the right idea, distribute a Taint >module with Perl. The only reason to do so instead of a built-in is to not snag yet more namespace. Dunno if it much matters either way, though the code is probably best left outside the really inner core code just to keep down the amount of stuff that any one person needs to stuff in their head. :) >Shall we drag this discussion on over to perl6-language? (I've CC'd >it and added a Reply-To. This is BCC'd to perl6-internals). Perhaps perl6-stdlib would be an even better place for it, if it's going in as part of the standard library. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 227 (v1) Extend the window to turn on taint mode
On Fri, Sep 15, 2000 at 02:00:04PM -0400, Adam Turoff wrote: > I'm kinda surfing the edge here. -T is definately an internals issue, > but $TAINT? taint()? is_tainted()? > > I'm not sure if they should be exposed into the language from the > internals, or if a superstudly taint.xs in stdlib is more appropriate. perl6-internals is probably the wrong forum for this, it was just convenient. I think Dan's got the right idea, distribute a Taint module with Perl. Shall we drag this discussion on over to perl6-language? (I've CC'd it and added a Reply-To. This is BCC'd to perl6-internals). -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse When faced with desperate circumstances, we must adapt. - Seven of Nine
RFC 232 (v1) Replace AUTOLOAD by a more flexible mechanism
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace AUTOLOAD by a more flexible mechanism
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 15 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 232
Version: 1
Status: Developing
=head1 ABSTRACT
This RFC proposes two-stage autoloading: one stage may be registered
to act when the symbol is encountered at compile time, the other
when the subroutine is called. Autoloading on the second stage does not
I the subroutine, only I it.
=head1 DESCRIPTION
AUTOLOAD interface was created before closures were available. Because of
this, it combines two actions into one call: it loads the subroutine,
and calls it.
This two actions should be separated. Additionally, some action may be needed
during compile time. For example, one may fetch the prototype of the function,
or even call the function, so that its (constant) value may be used in this
and other calls.
[WIth the current implementation I the prototypes should be loaded no
matter what, with significant memory and time overheads.]
When a symbol for an undefined subroutine is seen at compile time, the
C action is invoked. It should return C if no such symbol
could be autoloaded (so that the symbol may be searched further in the @ISA
tree). It should return the prototype if the symbol could be found. This
call may have arbitrary side effects, such as defining the subroutine, or even
calling it (useful for constant XSUBs).
When an undefined subroutine is about to be called, the C action is
invoked. It should return a reference to a subroutine, or C to signal
that search should be continued further in the @ISA tree.
In both cases, the argument for the action is the name of the subroutine.
If the subroutine has two different names (it was created with one name, and
was imported with a different name), both names are provided.
The C and C subroutines may be registered (both or any one) with
the pragma
use autoload ':proto' => sub {}, ':load' => sub {};
=head1 MIGRATION ISSUES
None.
[The current AUTOLOAD mechanism saves creation of a subroutine frame, since
the actual call to the subroutine may be done via C. If this is proved
to provide some advantage, AUTOLOAD mechanism may be preserved as well.]
=head1 IMPLEMENTATION
Straightforward.
=head1 REFERENCES
None.
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
On Fri, Sep 15, 2000 at 06:38:37PM +0100, Richard Proctor wrote: > 1) << removes whitespace equivalent to the terminator (e) this is largely > backward complatible as many existing heredocs are unlikely to have white > space before the terminator. > > 2) <<< removes whitespace equivalent to the smallest whitespace (d) > > or are these the options that will satisfy everybody [no but its worth a try] > > 1) << Does just what it does now > > 2) <<< implements (d) or (e) I'd say: 1) << does what it does now mod RFC 111 (ie. you can put whitespace in the terminator, but it doesn't effect anything) 2) <<< does (e). 3) distribute a collection of dequote() mutations with perl. 4) mention the s/// tricks in the documentation (< [[there is still the tabs debate however]] Tabs are easy, don't expand them. Consider them as a literal character. This assums that the code author is going to use the same keystrokes to indent their here-doc text as the terminator, about as safe an assumption as any for tabs. Maybe I'm being too simplistic, I don't use tabs anymore. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse I'm successful because I'm lucky. The harder I work, the luckier I get.
RFC 230 (v1) Replace C built-in with pragmatically-induced C function
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Replace C built-in with pragmatically-induced C function =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 15 September 2000 Mailing List: [EMAIL PROTECTED] Number: 230 Version: 1 Status: Developing =head1 ABSTRACT This RFC proposes that Perl's existing C mechanism be replaced with a standard module based on parts of the Text::Autoformat module. =head1 DESCRIPTION I can never remember how formats work. The specification syntax is confusing to me. And I usually don't want the formatted text going straight down some magical output stream. It all came to a head when I was building Text::Autoformat. The smart text recognition was easy -- trying to do the final formatting with C and $^A was just too painful. So I created the C subroutine. It uses a template specification than fits my brain better, it's deeply DWIMical, it's highly configurable, and it's re-entrant (so you can use a C to format another C's headers and footers, for example). I propose that the existing C mechanism be removed from Perl 6 and be replaced with a pragma-induced add-in function, based on the semantics of C, as described in the following sections. =head2 The C function The function itself would be called C and would be imported with a C pragma. It takes a format (or "picture" or "template") string followed by one or more replacement values. It then interpolates those values into each picture string, and either: =over 4 =item * returns the result as a single multi-line string (in a scalar context) =item * returns the result as a list of single-line strings (in a list context) =item * prints the result to the current filehandle (in a void context). =back A picture string consists of sequences of the following characters: =over 4 =item Left-justified field indicator. A series of two or more sequential <'s specify a left-justified field to be filled by a subsequent value. =item Right-justified field indicator. A series of two or more sequential >'s specify a right-justified field to be filled by a subsequent value. =item Centre-justified field indicator. A series of two or more sequential ^'s specify a centred field to be filled by a subsequent value. =item >>>. A numerically formatted field with the specified number of digits to either side of the decimal place. See L below. =item Left-justified block field indicator. Just like a < field, except it repeats as required on subsequent lines. See below. =item Right-justified block field indicator. Just like a field, except it repeats as required on subsequent lines. See below. =item Centre-justified block field indicator. Just like a field, except it repeats as required on subsequent lines. See below. =item ]]]. A numerically formatted block field with the specified number of digits to either side of the decimal place. Just like a >>>. field, except it repeats as required on subsequent lines. See below. =item ~ A single character field. Interpolates a single character from a subsequent data value. Repeats on subsequent lines as required. =item \ Literal escape of next character (e.g. C<\~> is formatted as a literal '~', not a one character wide field). =item Any other character That literal character. =back Hence a typical use of C might look like this: $formatted = format "<>", $aphorism, "page $page_num"; and might produce an output like this: page 123 Note that, because every field (except a C<~> field) must be at least two characters wide, the single C> and C> brackets in the format string are correctly interpreted as literals. =head3 Multi-line filling As the previous example indicates, any line with a block field continues interpolation of that field on subsequent lines until all block fields in the format have consumed all their data. Non-block fields on these lines are replaced by the appropriate number of spaces. For example: $title = "On The Evil That Is Spam"; $text1 = "How many times have you longed to smash..."; $text2 = "...the bedevilment that is spam?"; format "<<< [[[ [[", $title, $text1, $text2; # prints: # # On The Evil How many times...the be- # have you longed devilment # to smash... that is # spam =head3 Hyphenation As the previous example indicates, within a block field, words are wrapped whole, unless they will not fit into the field at all, in which case they are broken and hyphenated. Simple h
Re: 'eval' odd thought
On Fri, 15 Sep 2000 12:01:55 -0400, Mark-Jason Dominus wrote: >When you translate a script, the translator should translate things so >that they have the same meanings as they did before. If it doesn't >also translate eval, then your Perl 5 scripts will be using the Perl 6 >eval, which isn't what you wanted. Er... are we talking of the same thing? I should think that P5->P6 would be a one time operation. A Perl 6 eval that turns a Perl 5 code string into a Perl 6 code string every time, helps in quickly getting a working "Perl6" script out of the door, but it's fake. It's takes a pretty hefty conversion stage every single time. If your P5->P6 translator is slow, i.e. written in Perl, this would imply a pretty big performace hit. It also doesn't really help you in *really* converting the eval string to Perl6. What would help is a debugging mode that prints out the converted code string, so that the programmer can modify his script so that it does indeed directly produce this (or a similar) string. From there on, you no longer need the Perl5->Perl6 translation. -- Bart.
Re: RFC 226 (v2) Selective interpolation in single quotish context.
Nathan Wiger wrote: > > Andy Dougherty wrote: > > > > How do you turn it off? I want to keep a way to specify stuff without any > > interpolation whatsoever. I see the usefulness of this sort of quoting, > > but I also see the usefulness of being absolutely able to turn all > > interpolation off. > > Yes, I agree with this point, also raise by Glenn and others. Currently, > there is very nice semantics in shell-style quoting: > >q// == '' == *NO* interpolation I agree. I'd like q/.../ to stick as close to giving me ... as possible. I can live with the current 'foo\\bar' having only one backslash in it, but I'd rather not have to worry about anything else. I'd vote for Glenn's allowing the disabling of interpolation in qq// and <<"" instead. Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'?
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
On Fri 15 Sep, Nathan Wiger wrote: > Michael G Schwern wrote: > > So indenting the terminator and indenting the text are linked. If you > > do one, you want to do the other. > > As I and many others have said, that's not necessarily true. I like all > my code to line up, braces, parens, and all. It enhances readability, > and is easier to scan. > > Anyways, it seems both your and my needs could be met if we simply added > a <<< operator that does what you want. Otherwise we're forced to choose > between two useful alternatives that are both valid. I could see using > both your and "my" way in many different situations, so we should make > them coexistant, not mutually exclusive. > There are two current RFCs RFC 111 deals with the terminator - I dont think anyone is realy debating that at present. RFC 162 discusses the indenting of heredoc content. There are two possible operators, the existing << and the enhanced <<< There are 5 possible ways of indenting, many of them have no compatibility problems, some might and hence might benefit from the <<<. a) No Indenting (status quo - do whatever the current << does. b) Remove all leading whitespace - Not popular - no longer supported c) Remove whitespace equivalent to the first line - Not popular - no longer supported d) Remove whitespace equialent to the smallest whitespace - a Realistic option e) Remove whitespace equialent to the terminator - a realistic option. Do the following two options satisfy everybody? [no but its worth a try] 1) << removes whitespace equivalent to the terminator (e) this is largely backward complatible as many existing heredocs are unlikely to have white space before the terminator. 2) <<< removes whitespace equivalent to the smallest whitespace (d) or are these the options that will satisfy everybody [no but its worth a try] 1) << Does just what it does now 2) <<< implements (d) or (e) [[there is still the tabs debate however]] Richard -- [EMAIL PROTECTED]
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
Michael G Schwern wrote:
>
> See, I never understood this. If you're indenting the terminator, it
> implies you're also indenting the here-doc text. I mean, this doesn't
> make any sense:
>
> { { { {
> print < I don't know what their
> gripe is. A critic is
> simply someone paid to
> render opinions glibly.
> TAG
> } } } }
Sure it does, as Eric's shown:
if ( $this < $that )
while () {
chomp;
$record = quotemeta $_;
if ( $record ) {
($rec, $name, $dob, $address, $joindate, $books)
= split /\s+/, $record;
print < So indenting the terminator and indenting the text are linked. If you
> do one, you want to do the other.
As I and many others have said, that's not necessarily true. I like all
my code to line up, braces, parens, and all. It enhances readability,
and is easier to scan.
Anyways, it seems both your and my needs could be met if we simply added
a <<< operator that does what you want. Otherwise we're forced to choose
between two useful alternatives that are both valid. I could see using
both your and "my" way in many different situations, so we should make
them coexistant, not mutually exclusive.
-Nate
Re: RFC 226 (v2) Selective interpolation in single quotish context.
Andy Dougherty wrote: > > How do you turn it off? I want to keep a way to specify stuff without any > interpolation whatsoever. I see the usefulness of this sort of quoting, > but I also see the usefulness of being absolutely able to turn all > interpolation off. Yes, I agree with this point, also raise by Glenn and others. Currently, there is very nice semantics in shell-style quoting: q// == '' == *NO* interpolation If we want a quasi-interpolated environment, I say we add qs// for "Single quotes with Some interpolation". I suspect once \I and \E catch on, people are going to be asking for others, and then pretty soon q// will not be much less interpolated than qq//. I think Perl *needs* a NO interpolation quoting contruct, and q// fits the bill quite nicely, as-is. I say a new one should be proposed that can handle these new quasi-interpolated semantics. -Nate
an RFC for unbalanced parens/braces?
Since there were no objections to cleaning up the error messages on unbalanced parens and braces, can we RFC that request? -Ed _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
Re: 'eval' odd thought
> eval should stay eval. Yes, and this is the way to do that. When you translate a script, the translator should translate things so that they have the same meanings as they did before. If it doesn't also translate eval, then your Perl 5 scripts will be using the Perl 6 eval, which isn't what you wanted.
Forking multiple socket connections
My question: using IO::SOCKET, i need to connect to multiple server at once. The server side works very well; it only waits for connections over a fixed IP,port. How can i write the client-side? Please help me!
Re: RFC 102 (v2) Inline Comments for Perl.
Perl6 RFC Librarian wrote:
>
> =head1 TITLE
>
> Inline Comments for Perl.
Why was this posted again? I see no CHANGES section.
> An idea that produces a paired feeling would be to use one of the
> paired character pairs, as in "#<" and ">#".
#Oh Lord, What Have I Gotten Myself Into?
$/="";
while (
<>#paragraphs
) {
m#found it?
and print;
}
O.k, so they're kinda contrived...
> the three paired character possibilities ("<>", "()", "{}")
There are four in ASCII; and with Unicode, there will be dozens.
Approximately.
> Because "#" has been used to mean comment, it seems that something
> related to "#" should continue to be used to mean comment.
Hm, I thought the idea was to get *away* from #, so as to avoid
confusion?
> vs
> $foo = qw/foo bar/ ##;
vs
$foo = qw/foo bar/ qc##;
Uh huh.
--
John Porter
We're building the house of the future together.
Re: 'eval' odd thought
On Fri, 15 Sep 2000, Bart Lateur wrote: > On Thu, 14 Sep 2000 18:14:49 -0400, Mark-Jason Dominus wrote: > > >The perl 5 -> perl 6 translator should [recursively handle eval] > > Blech, no. eval should stay eval. People are responsible for generating > Perl6 compatible code, if they construct code as strings on the fly. I would disagree. If I'm using a program to translate my code from one version of Perl to another, I don't want to have to go in and hand-fix (possibly large) sections of it...it should just _work_. I'm with MJD on this one. Dave
Re: RFC 223 (v1) Objects: C pragma
Hildo Biersma wrote:
>
> I think such modules are a bad idea, because their functionality is
> typically restricted.
Oh? Where do you get that idea?
> Altering the language to make that easier seems a
> bad idea to me.
On the contrary: altering *anything* about Perl to make
something easier is quite in keeping with Perl's philosophy.
> >1. By default, pass the invocant via a special var or sub,
> > either self(), this(), $ME, $THIS, $SELF, or whatever.
>
> Forcing multiple authors to use the same 'this' or
> 'self' name across modules is not the perl way,
Well then, forcing multiple authors to use the same C is a
bad idea too.
Look, it's only the difference wbetween
sub meth {
my $self = shift;
and
sub meth {
my $self = this;
No, I think Nathan has nailed it, spot on, with this proposal.
--
John Porter
We're building the house of the future together.
Re: RFC 223 (v1) Objects: C pragma
On 14 Sep 2000, at 14:18, Nathan Wiger wrote: > Before you balk at #1 in favor of religious flexibility, please consider > how unmaintainable Perl code would be if @ARGV, or $AUTOLOAD, or STDERR, > or @INC, or chomp(), or split(), or any other widely-used variable or > function was renameable. If you don't shudder at this, I would argue you > probably don't maintain enough of others' code. *ANNOYNATE = *ARGV; use English; I remember reading a bit of example code somewhere from someone who religiously used English. It was fairly annoying seeing functions operate on $ARG instead of $_, and subroutine were passed @ARG Cheers, Philip
Re: RFC 223 (v1) Objects: C pragma
Graham Barr wrote: > > One of the benefits I was hoping to get from having a variable hold > the invocant is the ability for the invocant to be undef if the sub > was not called as a method. Um, functions can return undef too, ya know. :-) -- John Porter
Re: RFC 229 (v1) Variable interpolation on demand.
On Fri, Sep 15, 2000 at 05:56:36AM -, Perl6 RFC Librarian wrote:
> $foo = 'def';
> $bar = 'ghi';
> $x = "abc$foo$bar";
> $y = 'abc$foo$bar';
>
> There is no way to turn obtain the value of $x from the value of $y.
> In other words, while $foo and $bar were interpolated into $x, they
> were not interpolated into $y. It would be nice to get Success! from:
>
> $z = interpolate ( $y );
> print 'Success!" if $z eq $x;
sub interpolate {eval "\"@_\""}
Never say "there is no way". There's *always* a way, and 99% of the time it
doesn't need to go in core.
--
"Even if you're on the right track, you'll get run over if you just sit there."
-- Will Rogers
Re: RFC 226 (v2) Selective interpolation in single quotish context.
> Perl6 should allow scalars and arrays to be tagged such that they are > interpolated in single quotish context. How do you turn it off? I want to keep a way to specify stuff without any interpolation whatsoever. I see the usefulness of this sort of quoting, but I also see the usefulness of being absolutely able to turn all interpolation off. This seems mostly an issue in heredocs (though I appreciate your generalization to all single quotish contexts.) I wonder if perhaps it might be possible to combine some of the ideas from the white-space heredoc discussion and join them to this one and come up with a nice syntax for a sort of modified here-doc. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
Michael Schwern wrote:
>See, I never understood this. If you're indenting the terminator, it
>implies you're also indenting the here-doc text. I mean, this doesn't
>make any sense:
>
>{ { { {
>print gripe is. A critic is
>simply someone paid to
>render opinions glibly.
>TAG
>} } } }
>
>Right? You're not going to just indent the terminator because you
>can. Its going to go along with indenting the text.
>
>So indenting the terminator and indenting the text are linked. If you
>do one, you want to do the other.
Don't tell me what I want to do :-)
$chunk1 = <
text that's in the table cell
CHUNK1
$chunk2 = <
text that's in another table cell
CHUNK2
$chunk3 = <
CHUNK3
The here-doc terminators all line up with the perl code.
The generated program is nicely indented relative to the left margin.
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 226 (v2) Selective interpolation in single quotish context.
On 14 Sep 2000, at 21:06, Glenn Linderman wrote: > I _like_ the conceptual idea, here. But I think we need a different kind of > quoting, not extend single quote semantics. Single quote semantics are really, > really, good for exact quoting. I'm sure you (since you mention VMS) find single > quote semantics good for escaping all those $ VMS requires. Well, we who are > forced to use Windoze find single quote semantics good for escaping all those \ > used in NT file names. So this proposal as now written blows that away: > > $x = 'C:\IN\MY\DIRECTORY\THERE\IS\A\FILE\NAMED\$FOO'; This becomes fun with UNC names, which have two backslashes at the beginning. But \\ in a single-quoted string becomes one backslash, so the filename is 'SERVER\SHARE\ONLY\ONE\SLASH\NOW' :-) Cheers, Philip
Re: RFC 226 (v2) Selective interpolation in single quotish context.
On 15 Sep 2000, at 1:10, Perl6 RFC Librarian wrote:
> With this proposal, the scalar C<$filename> can be tagged to be interpolated
> by the C<\I...\E> pair and the double quotish context replaced by single
> quotish context resulting in the following:
Definitely with this change, you should include a section on
COMPATIBILITY, noting that people might be using \I in single-quoted
strings already -- this would break. For example, some misguided
DOS user with a filename such as C:\INCLUDE\SYS$HEADER\ERRNO.H
(horribly contrived, I know -- not even sure whether $ is legal in a
DOS path, but I think it is) might be surprised if he got an error
message about $HEADER being undef.
What about \Itext\E, where text does not contain a scalar? Is this the
same as "text"? How about \Ibefore${var}after\E -- is that the same
as "before${var}after"? Does @foo interpolate inside \I...\E? (With
join $"?) What about backslashes inside \I...\E (as in the above funny
filename)?
Cheers,
Philip
Re: RFC 223 (v1) Objects: C pragma
On Thu, Sep 14, 2000 at 08:10:54PM -, Perl6 RFC Librarian wrote: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Objects: C pragma > > =head1 VERSION > > Maintainer: Damian Conway <[EMAIL PROTECTED]> > Date: 14 September 2000 > Mailing List: [EMAIL PROTECTED] > Number: 223 > Version: 1 > Status: Developing > > =head1 ABSTRACT > > This RFC proposes that, as in Perl 5, the invocant of a method should be > normally available to the method as $_[0], but that it can be > automaticaly stripped from @_ and accessed via either a subroutine > or a variable, using the C pragma. One of the benefits I was hoping to get from having a variable hold the invocant is the ability for the invocant to be undef if the sub was not called as a method. Sadly this proposal does not address that :( Graham.
Re: 'eval' odd thought
On Thu, 14 Sep 2000 18:14:49 -0400, Mark-Jason Dominus wrote: >The perl 5 -> perl 6 translator should replace calls to 'eval' with >calls to 'perl5_eval', which will recursively call the 5->6 translator >to translate the eval'ed string into perl 6, and will then eval the >result. Blech, no. eval should stay eval. People are responsible for generating Perl6 compatible code, if they construct code as strings on the fly. Warning people when converting a script from perl5 to perl6, that a eval STRING has been found, is a good idea. -- Bart.
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
On Thu, Sep 14, 2000 at 03:36:10PM -0700, Nathan Wiger wrote:
> See, this is just too inflexible. The main complaint that I've heard has
> been "You can't have leading or trailing whitespace around your
> terminator". This is a very common error made by everyone, and *this* is
> where Perl should DWIM.
See, I never understood this. If you're indenting the terminator, it
implies you're also indenting the here-doc text. I mean, this doesn't
make any sense:
{ { { {
print
Re: RFC 223 (v1) Objects: C pragma
Nathan Wiger wrote: > > > > and this may, indeed, be sufficient. > > Remember, this still won't solve the problem of a module whose functions > can handle both OO and function-oriented calls - and yes, I have many > that do this. :-) I think such modules are a bad idea, because their functionality is typically restricted. Altering the language to make that easier seems a bad idea to me. > > Instead, I believe a more sensible approach is the following: > >1. By default, pass the invocant via a special var or sub, > either self(), this(), $ME, $THIS, $SELF, or whatever. > >2. Allow this to be reverted to the old Perl 5 way ($_[0) > via the "use invocant" (or some similar) pragma. > > This gives you the following benefits: > >1. Code is consistent. You can be assured that whatever the > function or variable is named is the same across code. This is a benefit? Forcing multiple authors to use the same 'this' or 'self' name across modules is not the perl way, and it won't help you unless we also demand naming conventions for methods, classes, variables, parameters, etc. And then you end up with Java. > >2. Perl 5 to Perl 6 transition is easy - just insert a > "use invocant" at the top of the code and it's passed > in $_[0] just like it always has been. Migration is as easy with Damian's proposal. > > Before you balk at #1 in favor of religious flexibility, please consider > how unmaintainable Perl code would be if @ARGV, or $AUTOLOAD, or STDERR, > or @INC, or chomp(), or split(), or any other widely-used variable or > function was renameable. If you don't shudder at this, I would argue you > probably don't maintain enough of others' code. That's not a valid argument. Perl already has multiple different names for the 'this' or 'self' variable in object methods, and that has not been a problem so far. If you go to the trouble of studying somebody another programmer's object module, picking up whether she uses $ME, self, or this will take a few seconds at most. Understanding the rest of the module will take far longer... As for maintaining other people's code, I do that a lot - and, typically, indentation, comments and brace style cause me far more trouble than variable names. Hildo
