Re: RFC 234 (v1) Data: overloading via the SECOND operand if needed
This RFC proposes a support of a situation when a more-knowledgable module may steal overloading from a less-knowledgable module or visa versa; What if both modules have this :override bit set at the same time? Does the second one still win? Or does the first one win again? Either way I'm not sure it solves the problem; if each module asserts that *they* are the smarter one then you either wind up with the same situation you have now or even worse contention. Seems like a bandaid for poor module writer collaboration, personally. :-) -Nate
Re: RFC 237 (v1) hashes should interpolate in double-quoted strings
On Sat, Sep 16, 2000 at 03:37:33AM -, Perl6 RFC Librarian wrote:
"%hash" should expand to:
join( $/, map { qq($_$"$hash{$_}) } keys %hash )
So let me get this straight...
%hash = (foo = 42, bar = 13);
print "%hash";
should come out to:
foo 42
bar 13
The idea of interpolating a hash is cool... but is seperating each
pair by $/ really useful? A comma or $" sees to make more sense.
Could you show some examples of practical usage?
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition. The idea being that in Ada
the typical infinite loop would be normally be terminated by detonation.
-- Larry Wall in [EMAIL PROTECTED]
RFC 196 (v2) More direct syntax for hashes
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
More direct syntax for hashes
=head1 VERSION
Maintainer: Nathan Torkington [EMAIL PROTECTED]
Date: 5 Sep 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 196
Status: Frozen
=head1 ABSTRACT
Cscalar(%hash) should return what Cscalar(keys %hash) currently
returns.
Creset %hash should reset the hash iterator, instead of calling
Ckeys or Cvalues as is currently the case.
The parser should special-case the variations of Csort %hash so
that it returns the keys and value, calling the comparison function
for keys.
=head1 CHANGES
* Clarified that new reset() syntax doesn't clash with existing
* Fixed braino in description of "sort %hash"
=head1 DESCRIPTION
While Perl has hashes as a built-in data type, the mechanism for
working with hashes is often built on top of list primitives. While
this is acceptable, it's not as convenient as it could be. I'm
arguing for more direct support of hashes in the language.
Proposal 1 is that a hash in scalar context evaluate to the number
of keys in the hash. You can find that out now, but only by using
the Ckeys() function in scalar context.
Currently C%hash in scalar context returns a false value if %hash
is empty, or a string like "4/8" showing how full the hash data
structure is. This string is rarely useful to the programmer.
Mostly it's just used for its true/false value:
if (%hash) { ... }
Proposal 1 would retain that use, but also make:
$count = %hash;
analogous to
$count = @array;
Proposal 2 is that the iterator in a hash be reset through an explicit
call to the Creset() function. In perl5, one must call Ckeys()
or Cvalues() to reset the iterator, an odd overloading of these
functions behaviour. I propose that the Ckeys() and Cvalues()
functions no longer have this side-effect, but instead reset() be
used:
keys %hash; # reset the iterator in perl5
reset %hash; # same but in in perl6
This function more obviously describes what is happening. reset()
also has a meaning, but that functionality does not clash
syntactically with this new meaning. In any event, the move away
from global symbol table actions will probably remove the current
functionality of reset().
Proposal 3 is to have the parser identify Csort %hash and its
variations, and automatically rewrite it.
I'd like to be able to say:
foreach ($k,$v) (sort %hash) { ... }
This would be equivalent to:
foreach ($k,$v) (map { $_ = $hash{$_}
sort
keys %hash)
{ ... }
Similarly one should be able to use a sort comparison function with
a hash. I do not expect this hash knowledge to apply to function
calls or anything else that might return key-value pairs. This is
purely when the data to be sorted is in a hash variable.
This relies on RFC 173's foreach() extensions to be useful.
=head1 IMPLEMENTATION
Proposal 1 simply changes the scalar value of a hash. The old
functionality would have to be available from a module for the perl526
program to be able to translate any program that relied on this
knowledge of the data structure (there are a few, though not many,
that do).
Proposal 2 removes the side-effects from keys() and values(), and
puts it into reset(). The reset() function is going to need a
profound overhaul anyway (given how intensely symbol-table driven
it is) and it is the obvious place for this functionality.
Proposal 3 could be done in the parser as a rewrite of the source
code. However, I suspect it would run faster if a flag on the sort()
op said "you're getting a hash structure" and sort() took care of
it all internally. That'd avoid multiple op dispatches. This is
an implementation decision for better performance, though. At the
bare minimum, source code rewriting would implement the function
with acceptable performance.
=head1 REFERENCES
RFC 173: Allow multiple loop variables in foreach statements
perlfunc manpage for keys(), values() and reset() documentation
perlsyn manpage for foreach() documentation
RFC 237 (v1) hashes should interpolate in double-quoted strings
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
hashes should interpolate in double-quoted strings
=head1 VERSION
Maintainer: Nathan Torkington [EMAIL PROTECTED]
Date: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 237
Version: 1
Status: Developing
=head1 ABSTRACT
"%hash" should expand to:
join( $/, map { qq($_$"$hash{$_}) } keys %hash )
=head1 DESCRIPTION
Hashes do not interpolate in double-quote context in perl5. They
should, because (a) scalars and arrays do, (b) it is a useful
thing.
The problem has always been: how to separate the keys and values? I
say use $" (the value that gets put between array elements in
double-quote interpolation) between key and value, and $/ between each
hash record.
A thorn is that $/ is the Binput record separator. It seems wrong
to use it for output. But $\ is not set by default, and it seems
unreasonable to have to set $\ (which affects the end of every print)
just to interpolate hashes. I didn't relish making yet another
special variable just for this, though.
When global variables like $" and $/ go away, I imagine they'll be
replaced with lexically-scoped variations. This will work then, too.
The big problem is that % is heavily used in double-quoted strings
with printf. I don't have a solution to this. In the end, this may
be Bthe definitive reason why hashes do not interpolate. And that's
fine by me.
=head1 IMPLEMENTATION
A simple change to the tokenizer.
The perl526 translator could backslash every % in a double-quoted
string.
=head1 REFERENCES
None.
Update: Wrapping up -data RFCs
Adam Turoff wrote: I didn't use Date::Parse, but I did look for all RFCs still stting at v1 status. Since they're numbered chronologically, I cut off the bottom (anything submitted after 9/7). There are 100 RFCs in the list that follows. Code and data upon request. Thanks Ziggy--very handy! There's only 3 from the list I'm looking after (-data), here's their status: RFC : 148 v1; Developing Title: Add reshape() for multi-dimensional array reshaping Maint: Nathan Wiger [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 24 Aug 2000 Nate is redrafting this as we speak--we're probably just about ready to freeze this. RFC : 191 v1; Developing Title: smart container slicing Maint: David Nicol [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 1 September 2000 There was quite a bit of discussion of various alternatives to this on list. David--could you incorporate these ideas into the RFC and see if we can get concensus. RFC : 196 v1; Developing Title: More direct syntax for hashes Maint: Nathan Torkington [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 5 Sep 2000 Discussion on this one has died down... Nat--could you incorporate the suggestions from the list and see if we can get this frozen? All other -data RFCs are still under active development, but I've asked all maintainers to have them frozen by next Wed (20/9) so that Larry has time to think about them before his release of the draft language spec.
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
At 15:55 -0400 2000.09.15, Chaim Frenkel wrote: CN * We do not know if it will always be this simple for every platform Hard to see how the three variables wouldn't cover the spectrum. Very hard to see, until we know what the disparate platforms might require. :) CN * You might need to convert from an epoch other than your native CN one, whether it is a different time zone, or a different epoch CN entirely; with a function, you can easily take care of these CN problems * Global variables suck That is beyond the scope of this problem. Depending on the solution. If we keep the situation as it is now, that time() is always system-dependent, then it is very much part of the scope of this problem, because we need to have ways for people to convert to and from other epochs. If we standardize on an epoch, then perhaps it isn't part of the problem. This new module to cover your feature would require that it know every known epoch and timesystem (or at least the useful ones.) Something this domain knowledgable shouldn't be in CORE. Why? File::Spec is in the core. So are multitudinous ExtUtils::MM_* modules. If you don't like an envar, then something in Config.pm or its replacement that is adjusted upon installation. Which is even more unreliable. One other possiblity, if Perl could determine the epoch by examination. $unixepoch = mktime( "1970..."); $machinepoch= mktime( "1970..."); Huh? CN You can only avoid breakage with current scripts if you make no changes to CN the current facilities (which is what Andy proposed). My proposal of a CN separate module for handing epoch differentials will work pretty much the CN same whether we change time() to return native or Perl epoch. I'm on the side of no change. Just enough that a user can determine how to offset the return from time, to pass to other data sinks. If you want no change, then what are you offset from? If time() remains system-dependent, then we have nothing against which to offset it. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: RFC 222 (v1) Interpolation of method calls
On Thu, 14 Sep 2000 18:37:22 -0500, David L. Nicol wrote:
print "Today's weather will be ${weather-temp} degrees and sunny.";
which would follow the "You want something funny in your interpolated
scalar's name or reference, you put it in curlies" rule.
I too feel that an approach like this would be far more generically
useful than this "$weather-temp" special case. I have said it before, I
know, but calling a generic function, not a method call, happens more to
me than this object access.
print "You have to pay " . money($amount) ." dollars.";
But sacrificing the ${...} syntax doesn't feel right. Indeed, it *does*
execute the code in curlies, but it expects a scalar reference.
MJD has a "silly module" which can tie a hash to a function:
Interpolation.pm. I think I would like a special case, a specific hash
that is *always* tied to a function that returns the arguments. Make it,
for example, %$, %@ or %?. These are not in use now, are they?
print "You have to pay $?{money($amount)} dollars.";
Implementation in Perl 5:
tie %?, Hash::Eval;
sub money {
return sprintf '%4.2f', shift;
}
print "You owe me $?{money(12)} dollars.\n";
package Hash::Eval;
sub TIEHASH {
my $self = shift;
return bless {}, ref $self || $self;
}
sub FETCH {
my $self = shift;
return "@_";
}
--
Bart.
Re: RFC 222 (v1) Interpolation of method calls
On Thu, Sep 14, 2000 at 05:31:44PM -0500, David L. Nicol wrote:
A possibility that does not appear in RFC222.1 is to put tho whole
accessor expression inside curlies:
print "Today's weather will be ${weather-temp} degrees and sunny.";
which would follow the "You want something funny in your interpolated
scalar's name or reference, you put it in curlies" rule. Since the contents
of that expression is not strictly \w+ it does not get interpreted as
the symbol table lookup ${'weather-temp'}, so that is not a problem, nor
are the whitespace situations listed in the CAVEATS section.
Could you write up some practical examples where this might be useful
(slapping whitespace between the - and method name isn't practical or
useful). I'm loathe to muddle the meaning of ${bareword}.
It did make me think of something else. What about by-variable method
calls. That is:
my $meth = 'species';
print "How much is that $pet-$meth() in the window?";
This should deparse to:
my $meth = 'species';
print "How much is that ".$pet-$meth()." in the window?";
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
I'm not cute, I'm evil.
-- Diablo www.goats.com
Re: RFC 222 (v1) Interpolation of method calls
On Fri, Sep 15, 2000 at 10:58:26AM +0200, Bart Lateur wrote:
MJD has a "silly module" which can tie a hash to a function:
Interpolation.pm. I think I would like a special case, a specific hash
that is *always* tied to a function that returns the arguments. Make it,
for example, %$, %@ or %?. These are not in use now, are they?
print "You have to pay $?{money($amount)} dollars.";
I always thought MJD's module was neat, but never had a real desire for
interpolated function calls. If it was part of the core library I may be
inclined to use it more, but I doubt it.
Or maybe an alternative, using :
"foo foo(arg, arg, arg) bar"
"foo { foo(arg, arg, arg) } bar"
I suspect this has already been discussed and discarded at some point; I
sincerely doubt I'm the only one who came up with it.
Or maybe we need a more generic solution (as someone else suggested, I
forget who). Something that allows the arbitrary execution of code, much
like @{[ ]}, but cleaner. Unfortunately, I can't think of anything
suitable.
Whatever direction this discussion takes, I don't think it should impact the
interpolation of method calls. It'd be nice to find a clean and simple
syntax for calling functions within double-quoted strings, but it's already
clean and simple to call methods.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 222 (v1) Interpolation of method calls
On Fri, 15 Sep 2000 01:36:50 -0800, Michael Fowler wrote:
Or maybe an alternative, using :
"foo foo(arg, arg, arg) bar"
"foo { foo(arg, arg, arg) } bar"
Ah, yes, {...}, I kinda like that. Unfortunately, in regexes, /{1,3}/
means matching 1 to three ampersands. There's a slight compatibility
problem, there.
Or maybe we need a more generic solution (as someone else suggested, I
forget who). Something that allows the arbitrary execution of code, much
like @{[ ]}, but cleaner.
I did, for one, including in the post you just replied to. That's what
the tied hash solution tried to emulate. Wasn't that obvious? ;-)
Unfortunately, I can't think of anything suitable.
Well, you said it yourself: "{...}".
--
Bart.
Re: RFC 222 (v1) Interpolation of method calls
Michael Fowler wrote:
Or maybe we need a more generic solution (as someone else suggested, I
forget who). Something that allows the arbitrary execution of code, much
like @{[ ]}, but cleaner. Unfortunately, I can't think of anything
suitable.
Whatever direction this discussion takes, I don't think it should impact the
interpolation of method calls. It'd be nice to find a clean and simple
syntax for calling functions within double-quoted strings, but it's already
clean and simple to call methods.
Michael
First, thanks for pointing out that ${something-something2} already
has a meaning.
Second, I think @{[ ... ]} is a plenty clean way to interpolate
absolutely anything. with tieing, we can get method calls to look
like hash lookups can we not, so why not do that if your method is
supposed to support interpolation?
"the result of f($arg) is $mytiedfunction{$arg}"
Maybe some syntax that is more direct than Ctie to allow such things
would do the trick?
Or MJD's module, does it allow this:
tie %myfunction, THAT_MODULE, {some function which will be stuck into the
FETCH method}
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=' ~/nsmail/Inbox
Re: RFC - Interpolation of method calls
The only decision, then, is to decide which context to use; if it deparses
to concatenation then it seems logical to use scalar context. This also
makes sense in that you can force list context with @{[ $weather-temp ]} if
you really wanted it.
$ perl -le 'sub w{wantarray?"WA":"WS"};print " attempt: ${\scalar(w)}"'
attempt: WS
Maybe we just need a shorter synonym for Cscalar?
Re: RFC - Interpolation of method calls
On Fri, Sep 15, 2000 at 07:24:39PM -0500, David L. Nicol wrote:
The only decision, then, is to decide which context to use; if it
deparses to concatenation then it seems logical to use scalar context.
This also makes sense in that you can force list context with @{[
$weather-temp ]} if you really wanted it.
$ perl -le 'sub w{wantarray?"WA":"WS"};print " attempt: ${\scalar(w)}"'
attempt: WS
Maybe we just need a shorter synonym for Cscalar?
Or DWIM "${\foo()}" to force scalar context. Everytime I come across that
construct I have to wonder why it's not called in scalar context. The '$'
would seem to imply it should.
Or cause the foo() method in "foo $foo-bar bar" to be called in scalar
context by default, obviating the need for a specific scalar call.
I'd actually like both solutions to be implemented.
What's even more confusing:
sub foo { wantarray ? "list" : "scalar" }
print scalar("${\foo()}") -- "list"
print scalar(${\foo()}) -- "list"
$foo = ${\foo()}; print $foo-- "list"
And yet:
sub foo { wantarray ? \"list" : \"scalar" }
print ${foo()} -- "scalar"
print ${ ("bar", foo()) } -- "scalar"
(These were all tested using 5.6.0.)
I have to assume \foo() is actually \(foo()) or some such. IMHO, this is
entirely non-intuitive. Can anyone enlighten me as to why this is as it is?
I believe there was a p5p discussion about this, but I dread delving into
the archives again..
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Fwd: [Re: [FWP] Comic goodness]
I thought you people might need a little break. The first one is particularly... yeah. - Forwarded message from Jim Monty [EMAIL PROTECTED] - From: Jim Monty [EMAIL PROTECTED] Subject: Re: [FWP] Comic goodness To: [EMAIL PROTECTED] Date: Fri, 15 Sep 2000 09:53:48 -0700 (MST) See, regular expression matter to stick people as well as humans. http://www.explodingdog.com/june11/backref.html Cf. http://www.userfriendly.org/cartoons/archives/99feb/uf000342.gif -- Jim Monty [EMAIL PROTECTED] Tempe, Arizona USA Want to unsubscribe from Fun With Perl? Well, if you insist... Send email to [EMAIL PROTECTED] with message _body_ unsubscribe - End forwarded message - -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Plus I remember being impressed with Ada because you could write an infinite loop without a faked up condition. The idea being that in Ada the typical infinite loop would be normally be terminated by detonation. -- Larry Wall in [EMAIL PROTECTED]
Re: RFC 166 (v2) Alternative lists and quoting of things
(?Q$foo) Quotes the contents of the scalar $foo - equivalent to
(??{ quotemeta $foo }).
How is this different from
\Q$foo\E
?
RFC 166 (v2) Alternative lists and quoting of things
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Alternative lists and quoting of things
=head1 VERSION
Maintainer: Richard Proctor [EMAIL PROTECTED]
Date: 27 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 166
Version: 2
Status: Developing
=head1 ABSTRACT
Expand Alternate Lists from Arrays and Quote the contents of things
inside regexes.
=head1 DESCRIPTION
These are a couple of constructs to make it easy to build up regexes
from other things.
=head2 Alternative Lists from arrays
The basic idea is to expand an array as a list of alternatives. There
are two possible syntaxs (?@foo) and just plain @foo. @foo might just have
existing uses (just), therefore I prefer the (?@foo) syntax.
(?@foo) is just syntactic sugar for (?:(??{ join('|',@foo) })) A bracketed
list of alternatives.
=head2 Quoting the contents of things
If a regex uses $foo or @bar there are problems if the content of
the variables contain special characters. What is needed is a way
of \Quoting the content of scalars $foo or arrays (?@foo).
Suggested syntax:
(?Q$foo) Quotes the contents of the scalar $foo - equivalent to
(??{ quotemeta $foo }).
(?Q@foo) Quotes each item in a list (as above) this is equivalent to
(?:(??{ join ('|', map quotemeta, @foo)})).
In this syntax the Q is used as it represents a more inteligent \Quot\E.
=head2 Comments
Hugo:
(?@foo) and (?Q@foo) are both things I've wanted before now. I'm
not sure if this is the right syntax, particularly if RFC 112 is
adopted: it would be confusing to have (?@foo) to have so
different a meaning from (?$foo=...), and even more so if the
latter is ever extended to allow (?@foo=...).
I see no reason that implementation should cause any problems
since this is purely a regexp-compile time issue.
Me: I cant see any reasonable meaning to (?@foo=...) this seams an appropriate
syntax, but I am open for others to be suggested.
=head1 CHANGES
RFC 166, v1 was entitled "Additions to regexes".
V1 of this RFC had three ideas, one has been dropped, the other is now part
of RFC 198.
V2 Expands the list expansion and quoting with quoting of scalars and
Implemention issues.
=head1 MIGRATION
As (?@foo) and (?Q...) these are additions with out any compatibility issues.
The option of just @foo for list exansion, might represent a small problem if
people already use the construct.
=head1 IMPLENTATION
Both of these are changes are regex compile time issues.
Generating lists from arrays almost works by localising $" as '|' for the
regex and just using @foo.
MJD has demonstrated implementing (?@foo) as (?\@foo) by means of an overload
of regexes, this slight change was necessary because of the expansion of
@foo - see below.
Both of these changes are currently affected by the expansion of variables in
the regex before the regex compiler gets to work on the regex. This problem also
affects several other RFCs. The expansion of variables in regexes needs
for these (and other RFCs) to be driven from within the regex compiler so
that the regex can expand as and where appropriate. Changing this should not
affect any existing behaviour.
=head1 REFERENCES
RFC 198: Boolean Regexes
RFC 212 (v2) Make length(@array) work
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Make length(@array) work =head1 VERSION Maintainer: Nathan Torkington [EMAIL PROTECTED] Date: Sep 12 2000 Last Modified: Sep 15 2000 Mailing List: [EMAIL PROTECTED] Number: 212 Version: 2 Status: Retired =head1 ABSTRACT length(@foo) should return the number of elements in @foo. =head1 DESCRIPTION Presently length() has a prototype of ($) which means it coerces its argument into scalar context. Many newbies think of the number of elements in an array as its "length", and try to use this function. Instead of the size of the array, they get a rough base-10 logarityhm of the number of elements. I propose to make length() return the number of elements in the array it is passed, if its first argument begins with @. =head1 IMPLEMENTATION The optimizer could replace length @array with scalar(@array) The perl526 converter could replace length @array with length scalar(@array) =head1 REFERENCES perlfunc for documentation on length() function
Re: RFC 238 (v1) length(@ary) deserves a warning
On Sat, Sep 16, 2000 at 04:21:15PM +1100, Damian Conway wrote: I'm surprised there hasn't be a good overhaul of the prototyping system proposeed yet. What exactly didn't you like about RFC 128??? Ummm... the fact that its title doesn't match /proto/. My bad. Okay, its a proposal to overhaul prototyping, cool. But I don't see anything to allow Clength $string and Clength @array live together. Its a big RFC, I probably missed it. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Cheating is often more efficient. - Seven of Nine
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
Dave Storrs [EMAIL PROTECTED] writes: [...] print FIRST_HERE_DOC; print SECOND_HERE_DOC; This is on the left margin. This is indented one char. FIRST_HERE_DOC This is indented one char. This is on the left margin. SECOND_HERE_DOC RFC 111 specifically disallows statements after the terminator because it is too confusing. I would say that the same logic should apply to the start of the here doc; I'm not sure, just from looking at it, if the example above is meant to be two interleaved heredocs, one heredoc after another, or what. It's two statements, separated by a semicolon. What's wrong? (Or, if you don't like that, just take 2 here docs for the same statement). This is totally unlike the here-document line. The same (without indentation, of course) works for Perl today, and confuses no-one. And just because Perl has some feature does not mean you are obligated to use it in all programs. -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: RFC 223 (v1) Objects: Cuse invocant 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
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 TAG;
I don't know what their
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.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Yet one of these kittens is not prepared to have a good time. It
stands alone, away from the crowd. Its your kind of kitten. And now
the time has come to climb into that car and shake the paw of destiny.
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 223 (v1) Objects: Cuse invocant 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: Cuse invocant 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 Cuse invocant 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: 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 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 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 TAG;
I don't know what their
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 = CHUNK1;
table
tr
td class=m1
text that's in the table cell
/td
/tr
CHUNK1
$chunk2 = CHUNK2;
tr
td class=m2
text that's in another table cell
/td
/tr
CHUNK2
$chunk3 = CHUNK3;
/table
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.
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 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 223 (v1) Objects: Cuse invocant 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 223 (v1) Objects: Cuse invocant 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: Cuse invocant 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 Ccaller() 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: '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 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 "#".
#BOh Lord, What Have I Gotten Myself Into?/B
$/="";
while (
#paragraphs
) {
mfoo#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/ #eat me#;
vs
$foo = qw/foo bar/ qc#eat me#;
Uh huh.
--
John Porter
We're building the house of the future together.
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!
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: 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
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 TAG;
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 (DATABASE) {
chomp;
$record = quotemeta $_;
if ( $record ) {
($rec, $name, $dob, $address, $joindate, $books)
= split /\s+/, $record;
print END_OF_RECORD;
Current record: $rec
Name:$name
DOB: $dob
Address: $address
The above person has been a member of the Perl 6 Book of the Month
club since $joindate, purchasing a total of $books books.
END_OF_RECORD
push @records, $record;
}
}
}
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 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
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 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 (POD =~ s/// seems dead) 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
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 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 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
Icall the subroutine, only Iloads 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 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
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 Cgrep and Cmap 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 Cgrep and Cmap 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: Ccontinue/Cabort/Cretry:
# 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:
Ccontinue/Cabort/Cretry
=over 4
=item *
Aversion to taking any more new keywords
=back
=item 2
Second Proposal: Add code labels, and let code blocks use
Cnext/Clast/Credo 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 Cdie
=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 Cdie 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
Cnext/Clast/Credo 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 Cgoto foo to
have
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
Backtracing contexts with self($n) (was Re: RFC 223 (v1) Objects: Cuse invocant 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("/etc/motd")-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 230 (v1) Replace Cformat built-in with pragmatically-induced Cformat 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
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 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)
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 POEM;
The old lie
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 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 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 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 230 (v1) Replace Cformat built-in with pragmatically-induced Cformat 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
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 Cformat built-in with pragmatically-inducedCformat 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
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
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 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
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 Cwarn and Cdie 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 Cdie or Cwarn.
It seems only logical, that if the current handler has been localized,
and overshadows an outer handler, then calling Cwarn or Cdie should
invoke the outer handler -- not the real Cwarn or Cdie. 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 "Cfoo: in bar at warn.test.pl line 6." to be
written to standard error. I propose that "Couter handler: foo: in bar
at warn.test.pl line 6." 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 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
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 Cundef 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 Cundef
on error. I propose changing index() and rindex()
to return Cundef 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 Cindex and Crindex", 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 Cindex and Crindex
perlfunc manpage for information on index() and rindex()
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 Cm?...? and Cm/.../ 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 (CA?B: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 Cm. =head1 IMPLEMENTATION Remove the bare C/.../ and C?...? from the grammar :-) When converting perl5 programs to perl6, put the Cm in. =head1 REFERENCES perl6-language message C[EMAIL PROTECTED] by Damian Conway
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 Cgrep and Cmap 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 Cgrep and Cmap 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: Ccontinue/Cabort/Cretry:
# 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: Ccontinue/Cabort/Cretry
=over 4
=item *
Aversion to taking any more new keywords
=back
=item 2
Second Proposal: Add code labels, and let code blocks use
Cnext/Clast/Credo 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 Cdie
=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 Cdie 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
Cnext/Clast/Credo 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
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
Icall the subroutine, only Iloads 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 Iall 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
Cproto action is invoked. It should return Cundef 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 Cload action is
invoked. It should return a reference to a subroutine, or Cundef 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 Cproto and Cload 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 Cgoto. If this is proved
to provide some advantage, AUTOLOAD mechanism may be preserved as well.]
=head1 IMPLEMENTATION
Straightforward.
=head1 REFERENCES
None.
RFC 230 (v1) Replace Cformat built-in with pragmatically-induced Cformat function
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Replace Cformat built-in with pragmatically-induced Cformat 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 Cformat 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 Cformline and $^A was just too painful. So I created the CText::Autoformat::form 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 Cform to format another Cform's headers and footers, for example). I propose that the existing Cformat mechanism be removed from Perl 6 and be replaced with a pragma-induced add-in function, based on the semantics of CText::Autoformat::form, as described in the following sections. =head2 The Cformat::format function The function itself would be called Cformat and would be imported with a Cuse format 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 LNumerical formatting 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 Cformat might look like this: $formatted = format "", $aphorism, "page $page_num"; and might produce an output like this: Like a camelpage 123 through the eye of a needle, so are the days of our lives Note that, because every field (except a C~ field) must be at least two characters wide, the single CElt and CEgt 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
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
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
