Re: RFC 308 (v1) Ban Perl hooks into regexes
On 25 Sep 2000 20:14:52 -, Perl6 RFC Librarian wrote:
Remove C?{ code }, C??{ code } and friends.
I'm putting the finishing touches on an RFC to drop (?{...}) and replace
it with something far more localized, hence cleaner: assertions, also in
Perl code. That way,
/(?!\d)(\d+)(?{$1 256})/
would only match integers between 0 and 255.
Communications between Perl code snippets inside a regex would be
strongly discouraged.
I can't believe that there currently isn't a means of killing a back-track
based on perl-code. Looking through perlre it seems like you're right. I'm
not really crazy about breaking backward compatibilty like this though. It
shouldn't be too hard to find another character sequence to perform your
above job.
Beyond that, there's a growing rift between reg-ex extenders and purifiers.
I assume the functionality you're trying to produce above is to find the
first bare number that is less than 256 (your above would match the 25 in
256).. Easily fixed by inserting (?!\d) between the second and third
aggregates. If you were to be more strict, you could more simply apply
\b(\d+)\b...
In any case, the above is not very intuitive to the casual observers as
might be
while ( /(\d+)/g ) {
if ( $1 256 ) {
$answer = $1;
last;
}
}
Likewise, complex matching tokens are the realm of a parser (I'm almost
getting tired of saying that). Please be kind to your local maintainer,
don't proliferate n'th order code complexities such as recursive or
conditional reg-ex's. Yes, I can mandate that my work doesn't use them, but
it doesn't mean that CPAN won't (and I often have to reverse engineer CPAN
modules to figure out why something isn't working).
That said, nobody should touch the various relative reg-ex operators. I
look at reg-ex as a tokenizer, and things like (?...) which optimizes
reading, and (?!..), etc are very useful in this realm.
Just my $0.02
-Michael
Re: RFC 308 (v1) Ban Perl hooks into regexes
There is, but as MJD wrote: "it ain't pretty". Now, semantic checks or
assertions would be the only reason why I'd expect to be able to execute
perl code every time a part of a regex is succesfully parsed. Simply
look at RFC 197: a syntactic extension to regexes just to check if a
number is within a range! That is absurd, isn't it? Would a simple way
to include localized tests, *any*¨test, make more sense?
I'm trying to stick to a general philosophy of what's in a reg-ex, and I can
almost justify assertions since as you say, \d, ^, $, (?=), etc are these
very sort of things. I've been avoiding most of this discussion because
it's been so odd, I can't believe they'll ultimately get accepted. Given
the argument that it's unlikely that (?{code}) has been implemented in
production, I can almost see changing it's symantics. From what I
understand, the point would be to run some sort of perl-code and returned
defined / undefined, where undefined forces a back-track.
As you said, we shouldn't encourage full-fledged execution (since core dumps
are common). I can definately see simple optimizations such as (?{$1 op
const}), though other interesting things such as (?{exists $keywords{ $1 }})
might proliferate. That would expand to the general purpose (?{
isKeyword( $1 ) }), which then allows function calls within the reg-ex,
which is just asking for trouble.
One restriction might be to disallow various op-codes within the reg-ex
assertion. Namely user-function calls, reg-ex's, and most OS or IO
operations.
A very common thing could be an optimal /(?\d+)(?{MIN $1 $1 MAX})/,
where MIN and MAX are constants.
-Michael
Re: RFC 308 (v1) Ban Perl hooks into regexes
Ban Perl hooks into regexes
=head1 ABSTRACT
Remove C?{ code }, C??{ code } and friends.
At first, I thought you were crazy, then I read
It would be preferable to keep the regular expression engine as
self-contained as possible, if nothing else to enable it to be used
either outside Perl or inside standalone translated Perl programs
without a Perl runtime.
Which makes a lot of sence in the development field.
Tom has mentioned that the reg-ex engine is getting really out of hand;
it's hard enough to document clearly, much less be understandible to the
maintainer (or even the debugger).
A lot of what is trying to happen in (?{..}) and friends is parsing. To
quote Star Trek Undiscovered Country, "Just because we can do a thing,
doesn't mean we should." Tom and I have commented that parsing should be
done in a PARSER, not a lexer (like our beloved reg-ex engine). RecDescent
and Yacc do a wonderful job of providing parsing power within perl.
I'd suggest you modify your RFC to summarize the above; that (?{}) and
friends are parsers, and we already have RecDescent / etc. which are much
easier to understand, and don't require too much additional overhead.
Other than the inherent coolness of having hooks into the reg-ex code, I
don't really see much real use from it other than debugging; eg (?{ print
"Still here\n" }). I could go either way on the topic, but I'm definately
of the opinion that we shouldn't continue down this dark path any further.
-Michael
Re: RFC 308 (v1) Ban Perl hooks into regexes
From: "Hugo" [EMAIL PROTECTED]
:Remove C?{ code }, C??{ code } and friends.
Whoops, I missed this bit - what 'friends' do you mean?
Going by the topic, I would assume it involves (?(cond) true-exp |
false-exp).
There's also the $^R or what-ever it was that is the result of (?{ }).
Basically the code-like operations found in perl 5.005 and 5.6's perlre.
-Michael
Re: RFC 308 (v1) Ban Perl hooks into regexes
From: "Simon Cozens" [EMAIL PROTECTED]
A lot of what is trying to happen in (?{..}) and friends is parsing.
That's not the problem that I'm trying to solve. The problem I'm trying
to solve is interdependence. Parsing is neither here nor there.
Well, I recognize that your focus was not on parsing. However, I don't feel
that perl-abstractness is a key deliverable of perl. My comment was
primarly on how the world might be a better place with reg-ex's not getting
into algorithms that are better solved elsewhere. I just thought it might
help your cause if you expanded your rationale.
-Michael
Re: RFC 287 (v1) Improve Perl Persistance
Many mechanisms exist to make perl code and data persistant. They should be cleaned up, unified, and documented widely within the core documentation. But doesn't this go against TMTOWTDI. :) Different people might have different requirements. Portability would want all ASCII, large apps might want compacted (if not compressed) storage, while others might want highly-efficient storage. Ideally it's a perl module, but for efficiency, it has to be a c-module. And that's just for the pickle. Shelving has a multitude of possibilities; most of which rely on OS installed libraries. Essentially, what would have to happen would be that perl has a built in DB package (or at least include the C-source for it's own implementation). This might not be a small feat. I'm not sure which DB package Python uses. Just about every language now has a form of serialization (with versioning). If any of the above would be accomplished, this would be it. Pick one of the many 'freeze/thaw'-type modules, then apply a linear and versions serialization routine. You might want to extend this RFC to include information about existing serialization techniques (which tend to be more sophisticated than raw dumping of a data-structure). Essentially in an OO design, each class needs a way of appending it's persistent data to the stream; this would have to avoid anything like a file-handle, or cached/tmp information. It's non trivial to do currently (to my knowledge). -Michael
Re: RFC 268 (v1) Keyed arrays
my/our @array :hashsyntax;
would hide the definition of %array in the same way that
my/our %array
would hide a prior definition of %array. And references to %array
would thenceforth actually be references to the keyed array @array.
I can see massive confusion from this. It's bad enough that globbing allows
multiple data-types with the same name, and it's really bad that the casual
observer has to stretch their mind like crazy to interpret @$sym{qw(a b c)},
which non-intuitively changes context every character (scalar to ref to
array ref to hash-slice ref, etc ). Then came pseudo-hashes, which
thankfully aren't used for too much other than objects (where there true
natures are somewhat hidden). Now you're suggesting colliding globing
name-spaces.
What I think you're saying is that hashes and arrays would be totally merged
into a singular data-type. That might work, but we'd be alienating existing
users that don't want to retrain but work along side perl6 developers. I'm
not saying it's bad, just that I know it'll affect my work environment.
The syntaxes
$foo['element']
$foo{element]
Typo. Which was it $foo{element} or $foo[element]?
So, starting with
my @foo:key; # empty array
$foo ['month'] = 10; # $#foo == 1, $foo[0] == 10
$foo ['day'] = 20; # $#foo == 2, $foo [1] == 20
$foo ['year'] = 30; # $#foo = 3, $foo [2] == 30
We achieve an array with 3 elements. There is a clear parallel between
this and
my %foo;
$foo{'month'} = 10;
$foo{'day'} = 20;
$foo{'year'} = 30;
However, the lookups for @foo are done at compile time, the lookups for
%foo are done at runtime.
Ok, implementation problem. Are you suggesting that we really implement
pseudo-hashes behind the scene? You mention name-spaces, but afaik, these
are just normal perl-hashes (with special values). This sounds more like
using pseudo-hashes behind the scenes. The difference is that now you're
requiring a new symbolic hash to be generated for each ":key" array,
where-as pseudo-hashes allow you to reuse the same old hash (as used in
perl5.005's OO).
As an alternative, use an attribute that does not interpolate the field
name. Make it more like a c-struct, where you _have_ to fully specify the
field name. With this, you could still use the dynamic generation of fields
as in the above (so you don't have to specify them ahead of time), but by
the time the compiler is finished, the references are fixed and converted to
array indexes. Moreover, you have a special type of fixed array (as opposed
to a resizable one). You get all the benifits of space / performance of
c-structures, while not totally throwing away the flexibility of hashes.
The only way you could achieve a dynamic field-name lookup would be through
an eval. This slows it's usage down, but if you really wanted to use
hashes, you'd use some other variable-name attribute. Actually, thinking
more on that, you couldn't totally fix the array size if you could 'eval'
the structure with additional field-names. The most you could say would be
that you have a unidirectionally growing array, and it might not be worth
the while of producing a whole new array structure for just this sort of
optimization.
For :key and :initialkey arrays, the syntax
$foo[$bar]
would inspect $bar to determine if it is convertable to numeric. If it
is, the value is used as the numeric index of the array. If it is not,
it is treated as a key for the array, and is looked up in the namespace
of the array.
Doesn't this conflict with the general usage of hashes? I know I've made
use of hashes as a form of sparce matrix / array. DB ID's, for example
(where you have 3 sequential values starting at 1,234,567,890 ). Basing
context on whether the number 'happens' to be numeric is bad (at least for
me in DB programming). I don't like the idea of coersing it to a string as
in $foo[ "$bar" ].
Also, if you ever mixed keys / indexes, you'd have a serious problem with
code maintanance. Try the following:
sub foo {
my @hash: bla bla;
$hash{sym2} = 5;
$hash[0]++;
$hash{sym1} = 6;
...
}
Then later we add a debug routine (for what-ever reason)
sub db
my $var = shift;
print "DEBUG: sym1 = $var-{sym1}, sym2 = $var-{sym2}";
}
sub foo {
my @hash: bla bla;
db( \@hash );
$hash{sym2} = 5;
$hash[0]++; #gotcha, idx0 == sym1 now
$hash{sym1} = 6;
}
This is obviously contrived, but you get the exact same thing in the
Database world:
my @db_results = $dbh-selectcol_array( 'select * from table' );
Here, we're at the mercy of the order that the columns were defined. If we
later add a new column anywhere other than the end, then we've invalidated
the above code. You might say that it's not our fault. But I offer that
during the development phase, the structure and contents change often (as
I've learned on my own). Instead you need to either explicitly state the
fields as in:
my @db_results =
Re: XML/HTML-specific ? and ? operators? (was Re: RFC 145 (alternate approach))
- Original Message -
From: "Jonathan Scott Duff" [EMAIL PROTECTED]
Subject: Re: XML/HTML-specific ? and ? operators? (was Re: RFC 145
(alternate approach))
How about qy() for Quote Yacc :-) This stuff is starting to look
more and more like we're trying to fold lex and yacc into perl. We
already have lex through (?{code}) in REs, but we have to hand-write
our own yacc-a-likes.
Though you can do cool stuff in (?{code}), I wouldn't quite call it lex.
First off we're dealing with NFA instead of DFA, and at the very least, that
gives you back-tracking. True, local's allow you to preserve state to some
degree. But the following is as close as I can consider (?{code}) a lexer:
sub lex_init {
my $str = shift;
our @tokens;
$str =~ / \G (?{ local @tokens; })
(?: TokenDelim(\d+) (?{ push @tokens, [ 'digit', $1 ] })
| TokenDelim(\w+) (?{ push @tokens, [ 'word', $1 ] })
)
/gx;
}
sub getNextToken { shift @tokens; }
I'm not even suggesting this is a good design. Just showing how akward it
is.
Other problems with the lexing in perl is that you pretty much need the
entire string before you begin processing, while a good lexer only needs the
next character. Ideally, this is a character stream. Already we're talking
about a lot of alteration and work here.. Not something I'd be crazy about
putting into the core.
-Michael
Re: XML/HTML-specific ? and ? operators? (was Re: RFC 145 (alternate approach))
- Original Message - From: "Jonathan Scott Duff" [EMAIL PROTECTED] Subject: Re: XML/HTML-specific ? and ? operators? (was Re: RFC 145 (alternate approach)) On Wed, Sep 06, 2000 at 08:40:37AM -0700, Nathan Wiger wrote: What if we added special XML/HTML-parsing ? and ? operators? What if we just provided deep enough hooks into the RE engine that specialized parsing constructs like these could easily be added by those who need them? -Scott Ok, I've avoided this thread for a while, but I'll make my comment now. I've played with several ideas of reg-ex extensions that would allow arbitrary "parsing". My first goal was to be able to parse perl-like text, then later a simple nested parentheses, then later nested xml as with this thread. I have been able to solve these problems using perl5.6's recursive reg-ex's, and inserted procedure code. Unfortunately this isn't very safe, nor is it 'pretty' to figure out by a non-perl-guru. What's more, what I'm attempting to do with these nested parens and xml is to _parse_ the data.. Well, guess what guys, we've had decades of research into the area of parsing, and we came out with yacc and lex. My point is that I think we're approaching this the wrong way. We're trying to apply more and more parser power into what classically has been the lexer / tokenizer, namely our beloved regular-expression engine. A great deal of string processing is possible with perls enhanced NFA engine, but at some point we're looking at perl code that is inside out: all code embedded within a reg-ex. That, boys and girls, is a parser, and I'm not convinced it's the right approach for rapid design, and definately not for large-scale robust design. As for XML, we already have lovely c-modules that take of that.. You even get your choice. Call per tag, or generate a tree (where you can search for sub-trees). What else could you want? (Ok, stupid question, but you could still accomplish it via a customized parser). My suggestion, therefore would be to discuss a method of encorportating more powerful and convinient parsing within _perl_; not necessarily directly within the reg-ex engine, and most likely not within a reg-ex statement. I know we have Yacc and Parser modules. But try this out for size: Perl's very name is about extraction and reporting. Reg-ex's are fundamental to this, but for complex jobs, so is parsing. After I think about this some more, I'm going to make an RFC for it. If anyone has any hardened opinions on the matter, I'd like to hear from you while my brain churns. -Michael
Re: RFC 185 (v1) Thread Programming Model
use Thread;
$thread = new Thread \func , @args;
$thread = new Thread sub { ... }, @args;
async { ... };
$result = join $thread;
$thread = this Thread;
@threads = all Thread;
$thread1 == $thread2 and ...
yield();
critical { ... }; # one thread at a time in this block
$mutex = newMutex;
lock $mutex;
$ok= try$mutex;
unlock $mutex;
$semaphore = new Semaphore $initial;
$ok = $semaphore-up($n);
$semaphore-down;
$event = autoEvent;
$event = manual Event;
set$event;
reset $event;
wait $event;
$timer = Timer-delay($seconds);
$timer = Timer-alarm($time);
$timer-wait;
$readable = $fh-readable;
$writable = $fh-writable;
$failure = $fh-failure;
$ok = wait_all(@objects);
$i = wait_any(@objects);
I'm not completely sure what you are trying to do with this RFC. At first
glance I had thought you were unaware of the existing option for
multi-threading since 90% of what you're asking for is already present. As
I read on, you seem to suggest that you merely want stylistic changes to the
existing proto-types for threads. Seemingly influenced by win32 (I won't
start a holy war).
I'm afraid to say anything because you obviously know what you're talking
about, but many of your changes seem pointless since they are completely
possible today. For example.
Why redo Semaphore, when we have Thread::Semaphore... I also noticed that
you neglected to mention another very useful entity, Thread::Queue (which I
use more often than semaphores). So you must not have been copying verbatum
from perl5.5+. Since you've already pointed out the style "$thread = new
Thread ...", you can't seriously be suggesting that the object/class
definition be built into perl. Though it's possible, it's just not done.
Next is the explicit use of mutex's. What's the point, when just about
anything can already be locked.. And in a much cleaner fashion than explicit
mutex's IMHO. For example:
You suggest:
critical { ... }.
Novel, and similar to java's synchronize(entity) { ... }, though not as
flexible. A better recommendation would have been critical (entity) {
... }. But you suggested that the combersome alternative would have been:
{ lock $mutex; ... unlock $mutex }
But the current threading model allows
{ lock $var; ... }
Once fallen out of scope, the lock is broken. As for the raw critical
section. You could merely perform. In general you seem to want to throw
away all scope-based threading operations, which I look at as a step
backwards.
sub foo_section { lock foo_section; ... }
foo_section();
Locks on subroutines are essentially the same as locked blocks.. The obvious
disadvantage is the scope. But again, the scoped lock of _any_ perl
variable takes care of this situation, so a new keyword is not necessary.
If that's not fine tuned enough for you, you can completely emulate Java's
method-synchronize prefix by the following:
{
package Foo;
sub method : method, locked { ... }
}
I'm not completely sold on the scrapping of cond_xxx for events. I don't
really see them as easier to read.. Granted I did a lot of head-scratching
the first time I went through them, but once you get them, they're very
powerful and intuitive.
I get the impression that you're goal is to windowfy perl's threading
model.. Shme. If this were a first pass at threads, then I might
advocate it (since win32 isn't bad at all), but we already have perl5005
threads. They work (with known limitations), so totally changing the syntax
around would break compatibility. Not that these elements were ever
sanctioned or supported in the first place, but why change things just for
the sake of changing them?
Lastly, you muddled over which of the various ways of instantiating a thread
is most desirable? Perl's all about choices; I have absolutely no problem
with the multiple interfaces.
That said, I like the timer, and file-handle signals/ events. No reason why
the current experimental threading couldn't be extended.
In summary, the existing threading model actually seems more powerful than
your proposed one. But there's plenty of room to add new features..
Especially since it's modularized and should stay that way (e.g. not
strictly part of the core). Argument being: Linux, as an example, is not
very friendly to multi-threading.. So it should only be used when actually
needed. Not that perl is focused around Linux, but this just goes as an
example of imposing a system model that is less than optimal for the general
case. (For the uninitiated, the instantiation of the first thread requires
creation of TWO heavy-weight threads (Linux treats threads as merely
processes that share the same memory page-table) ).
What I would suggest is that you reimplement the various cleanups ( like
events replacing cond_xx ) as modules. This hides the details just like
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
More functions from set theory to manipulate arrays
I'd like to use these functions in this way :
@c = union (@a, @b);
# wich is different from @c = (@a, @b) because union do not duplicate
same elements
@c = intersection (@a, @b);
@c = diff(@a, @b);
Elements of this are found in many other languages.. Pascal and python have
the built in "in" operator.
Maybe it's because of my engineering background, but I dispise inefficiency,
and these sorts of operations require scans. I've had to make use of sets
in a lot of my work, and very rarely do I use raw lists. I'm not saying
that this shouldn't be implemented, I'm just saying that it urks me.
For basic set's I mainly make use of hashes. Unfortunately, the syntax can
be somewhat combersome for the complete set-theory suite. CPAN, on the
other hand, offers several modules for use in set-theory that work very
efficiently.
In persuing this RFC, there are a couple things I can think to consider:
First is the choice of arrays verses hashes as the choice for set storage.
Arrays are obviously easier to construct, but hashes are both faster
implementations, and easier to determine membership.
Next, what subset of the set-theory should be implemented. Obviously you
refer to the basic and / or / xor, but in real practice, the other operators
can be very useful. Chaining operators (especially with array-based-sets)
can be a performance nightmare.
Next, these operations can easily be implemented as a module (written out to
C if you like), and simply distributed with the core library.. Since some of
us are working to tighten down on the core of perl and break things out into
modules, this obviously runs counter to our goal.
Even the odd form of passing two arrays to the function could still work
with a module through the use of prototypes ( sub union(\@\@) { ... } ).
Unfortunately, because of this, you would require that only true arrays can
be passed. I would much rather be able to instantiate a new set on the fly
as in:
@u_set = union( \@set_a, [ 1 ] );
It would be closer to a push, which doesn't require two arrays to be passed.
Perhaps it could be prototyped as ( sub union(\@@) { ... } ) and could
therefore allow additions to the set as in:
@u_set = union( @set_a, [ 1 ] );
As you can see, there are many ways in which this could work, and they each
have different advantages and disadvantages. From this, I am still of the
opinion that CPAN modules are the way to go (possibly making one standard).
-Michael
Re: RFC 184 (v1) Perl should support an interactive mode.
I'll be brief because windows just crashed on me.
First, the current debugger allows multi-lines if you use "\" at the end of
the line ( a la C ).
Second, lexically scoped variables will dissapear on subsequent debugger
lines since their scope is wrapped in an eval. For the most part, the
debugger is assuming that you're not using strict (and even if you did try
it, strictness would fall out of scope ). Therefore there's little reason
for lexically scoped variables, except possibly for typed variables.. But
even then, that only benifits the development cycle, since you're arguably
not going to write massive code in a debugger. Currently scalar typeing
severs no real additional purpose, since pseudo-hashes (the closest you
currently get), work fine as long as the hash-prefix is present in the
array.
Next, there's something to be said for writing an entire function / for-loop
on a single line.. And that's easy history substitution. When you're in the
debugger, you're obviously trying to debug something. Which means trial and
error... Lots of it. I can't tell you how frustrating it is when I cut and
past code into a SQL or python prompt only to be reminded that I can't make
useful use of the history mechanism. Putting lots of code on one line means
you can up-arrow, Control-arrow over to the next attempted change, then hit
enter, very efficiently. The closest you can come in the other's is to open
an emacs window and cut / paste (which has it's advantages too).
Next, learn a neat optimization:
perl -de 42
becomes:
perl -de0
You're just saying evaluate 0, or 42, or what-ever.. Which is just an
ignored op-code.
Next, it would be possible to extend the existing DBI module or create your
own (obviously a non-trivial task), then specify the new debugger on the
command line:
perl -d:debugger_name -e0
Now for the fun part. In order to achieve a truely interactive interpreter
like sh, xsql, python or lisp, you need the interpreter to be able to
understand the context of what you're typing. bash, for example, knows when
you have mis-matched quotes, or the here-document, and prompts you for more
text accordingly.
In perl, however, there is no easy way to parse perl. This has been it's
biggest hypocracy as far as I'm concerned.. I'm going to make an RFC for it.
Essentially, you have this all powerful lexer / parser that's always there..
But you can never use it.. You can only invoke eval, which isn't always what
you want. In this case, we want to be able to simply determine matched-ness
of code. This is a highly complex problem, since parenthesis, braces may be
within quotation.. And it gets even more complex because quotation could
occur within q{ ... } braces, or even worse / ... / and ... braces. It
is impossible to figure out the context of perl.. without running perl.
Hense the hack of making every line (including escaped multi-lines) it's own
expression, transparently.
You are correct in that changing this would require help from the core. But
a change such as this should really help more than just a simple debugger.
Take the following as an example.
#Config-file
$var = [ "ab[dsfsdf]]]", { a = 1, b = [ 1,2, 4 .. 8 ] }, system( "rm
/etc/passwd" ) ];
I often write configuration files for code. But I fear actually evaluating
configuration data (even in tainted mode). The end result is that I come up
with my own syntax which I parse with reg-exs. Sadly I find myself
reproducing the complexity of hashes / arrays needlessly. Ideally, I would
like to parse perl-like syntax but apply my own meaning to the parsed data.
Such an extension of the perl-parser could definately be applied to a
debugger..
This seems really complex and full of problems, so what I would probably
suggest is to write an extension of DB.pm that runs a syntax checker on the
line (in a manner similar to "perl -c"). Then it intelligently listens to
error.. If they are matching-based errors, then it should automatically
prompt a continuation line. Otherwise give up in failure, reporting
what-ever errors. Control-G/D should be available to break out if the
developer figures something is wrong with a continuation. This seems
deceptively simple.. But it's worth suggesting.
-Michael
Re: RFC 2 (v3) Request For New Pragma: Implicit
- Original Message -
From: "Perl6 RFC Librarian" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, August 29, 2000 8:59 PM
Subject: RFC 2 (v3) Request For New Pragma: Implicit
Request For New Pragma: Implicit
Good idea, but you have it backwards.. If anything, there should be an
"explicit" keyword..
Remember, we want
% perl -p -e 's/foo/bar/g' file.txt
I would reject anything that diminishes perl's basic power as a shell tool;
Programming languages be damed. It's the most powerful shell tool I've ever
encountered, and I'll fight to keep it that way.
On the other hand, I hardly ever use $_ in main-stream programming. I
always perform:
for my $var ( .. ) { .. }
or eat the cost of a local variable assignment. I do have to answer to my
co-developers after all.
Essentially "use explicit qw( tokens... )", or even "use strict
'implication'" would simply make a compiler error for implicit use of
variables. This could also be part of a more stringent perl -WW sort of
activity; just as the use of undef's have been forboden (I use to love the
default action of undef.. always worked the way I wanted.. At least until I
started assigning objects).
-Michael
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
sub do_stuff {
my $self = self;
$self-{STATE}-{something} = @_;
}
sub error {
carp @_ if self-config('VerboseErrors');
}
I've never really seen anything like this before in other languages (Is that
good or bad?). The closest is Java's odd use of the super function as the
first line of a constructor.
The first problem I see with this is in [my understanding of] how perl
handles objects currently.
func class csv;
is the same as
class-func( csv )
Which internally becomes a lookup for the proper func based on @ISA, but
ultimatly class gets unshifted onto the stack of parameters.
The only way I can see an easy way of hiding the passage of $self is by
offsetting @_ by one, making $_[ -1 ] = $self. Which is obviously
unaddressible. Self would simply make the internal c array-lookup to
[ -1 ]. Either this sort of space would always have to be available, or the
function itself would have to be flagged for it... As in:
sub do_stuff: method {
my $this = self; # I'm old fashioned, leave me alone
} # end do_stuff
All accesses to methods would then require the method function-attribute.
Otherwise self could just be an alias for shift. In this way, you maintain
compatibility (except for those poor souls that currently use method,
locked)
-Michael
Re: RFC 134 (v1) Alternative array and hash slicing
Personally, I prefer a python, or matlab implementation: array1 = array2[ start : stop ]. Of course, In perl we have the .. operator. This method has just always seemed intuitive to me. Granted an explicit function call (or gasp, another reg-ex like call), aids the newbies eyes. The trick in perl is, of course, that we are marred with demangling variables. For what-ever reason, $array[ $a .. $b ] is interpreted in scalar context, and so we had to resort to the @array[ list ] nature. This actually works out well for @hash[ list ], since $hash[ 'a', 'b' ] becomes that odd-ball multi-dimentional hash. I'd rather do away with that multi hash thing ( I have no idea what it's value is ), and make convert all array / hash accesses into slices (with optimizations for single indexes ). I think this would resolve your concerns about ambiguity. -Michael
