RFC 196 (v1) 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
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 196
=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 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.
Proposal 3 is to have the parser identify Csort %hash and its
variations, and automatically turn it into Csort keys %hash.
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
Re: RFC 39 (v3) Perl should have a print operator
On Tue, 05 Sep 2000 18:37:11 -0600, Tom Christiansen wrote: Those are not the semantics of print. It returns true (1) if successfSNIP false (undef) otherwise. You cannot change that. If I write print "0", it bloody well shan't be returning false. Oh, why not? Does anybody actually *ever* check the return value of print? Yes. I think it's not as if we'd break a lot of code. Don't worry, Mercutio, 'tis but a small wound. Problem is: if you need defined() to see if the print was succesful, you defined() is superstition. I said true and false. If I say true, I don't want you testing against 1. If I say false, I don't want you testing definedness. Most tests like this should be true or false. cannot return what was printed as well. It's one thing or the other. So you cannot have it both ways. I don't *WANT* it to return what it alleges to have printed. That's stupid, since I can always get that myself. I don't need it to tell me this! --tom
Re: RFC 159 (v1) True Polymorphic Objects
2000-08-28-18:47:06 Tom Christiansen: It strikes me as a bit reminiscent of (one reason) why Larry didn't make a+b work on strings, since then while with numbers, a+b and b+a would be the same, with strings they would not be, and we have these rather deeply held convictions about such matters. perl's internals may have distinct strings and numbers, but from the programmer's viewpoint that distinction is nowhere near so clear; by using distinct operators for string ops and arithmetic ops, Perl automatically converts as needed, and so prevents the programmer from seeing distinct strings and numbers, they're all just scalars and do the right thing. The a+b != b+a with + as string contatenation may be a happy additional justification, but I think the underlying principle is much more basic, and I don't think we can lose it without a really dramatic change being imposed on the programmer's view of the Perl language. -Bennett PGP signature
Re: RFC 188 (v1) Objects : Private keys and methods
On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
exists (sometimes causes autovivification, which affects Ckeys)
That's not technically accurate--exists never causes autovivification.
print exists $hash{foo}{bar}{baz};
use Data::Dumper;
print Dumper \%hash;
Technically correct or not, there IS some autovivification going on, and
it's due to what's tested in exists().
Wrong. You will see no "baz" element autovivaciously leap lustfully into
exists. This is the ONLY thing that exists is checking for. Notice
how the same result occurs here:
print 1 + $hash{foo}{bar}{baz};
use Data::Dumper;
print Dumper \%hash;
It's not exists(). Didn't you read what I cited? I swear I've written
this a million times.
--tom
Re: RFC 188 (v1) Objects : Private keys and methods
print keys %hash, "\n";
exists $hash{key}{subkey};
print keys %hash, "\n";
Or did that get fixed when I wasn't looking?
No, the - operator has not been changed to do lazy evaluation.
That's not required. All that is necessary is for Cexists nodes
in the op tree to propagate a special non-autovivifying context to
subordinate nodes.
E.g. exists $hash{key}{subkey}
exists
\
entry
/ \
entry "subkey"
/ \
%hash "key"
Is preprocessed to:
exists
\
entry(na)
/ \
entry(na) "subkey"
/ \
%hash(na) "key"
which prevents %hash from autovivifying, which causes the left-most
branch to fail (without autovivifying) when asked for "key", which in
turn causes the entire exists to fail without autovivifying.
I just don't like reading "exists causes autovivification" when it
doesn't.
Sorry, I was being philosophically sloppy. A call to Cexists can
*result* in autovivification (of something), though it does not itself
*cause* autovivification.
;-)
Damian
Re: RFC 188 (v1) Objects : Private keys and methods
Why can't we just apply the same warnings on hashes as we do on
variables in Perl? Maybe a new lexical pragma:
no autoviv; # any autovivification carps (not just
# hashes)
no autoviv 'HASH'; # no new keys may spring into existence on
# any hash from this point forward
I don't appose these, but I don't think they solve the problem.
For a start they're compile-time, not run-time.
no autoviv '%hash'; # same but for a specific hash
no autoviv '@array';# same but for a specific array
These won't work, since most of the hashes were interested in
controlling autovivification on are anonymous (blessed) ones.
Regardless, I feel that "no autovivification" and "private-ization"
are orthogonal and should be treated as such in the languge.
private @person{'fname','lname'}; # make these private
freeze %person; # no new keys
But that's two keywords rather than one (and the second keyword isn't
that great for those people who already use FreezeThaw ;-)
I think that would prove annoying. Though I certainly don't oppose some
separate method to shut off autovivification (which Cprivate would
then be considered to call automatically).
P.S. BTW, I used Text::Autoformat for the first time on this very email.
Thanks Damian!
You're most welcome. I note that you didn't use it on the P.S. itself,
as Autoformat would have given you:
P.S. BTW, I used Text::Autoformat for the first time on this very
email. Thanks Damian!
As, indeed, it just did! ;-)
Damian
Re: RFC 188 (v1) Objects : Private keys and methods
On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
exists (sometimes causes autovivification, which affects Ckeys)
That's not technically accurate--exists never causes autovivification.
print exists $hash{foo}{bar}{baz};
use Data::Dumper;
print Dumper \%hash;
Technically correct or not, there IS some autovivification going on, and
it's due to what's tested in exists().
--
Bart.
Re: RFC 145 (alternate approach)
I'd suggest also, that (?[) (with no specified brackets) have the
default meaning
of the "four standard brackets" :
(?['('=')','{'='}','['=']',''='')
Note also the subtle syntax change. We are either dealing with strings
or with patterns. The consensus seems to be against patterns (I can
understand that). Given that, we need to quote the right hand side of
the = operator I think. The quotes on the left side would be optional,
I think.
Richard Proctor wrote:
On Tue 05 Sep, Nathan Wiger wrote:
Eric Roode wrote:
Now *that* sounds cool, I like it!
What if the RFC only suggested the addition of two new constructs, (?[)
and (?]), which did nested matches. The rest would be bound by standard
regex constructs and your imagination!
That is, the ?] simply takes whatever the closest ?[ matched and
reverses it, verbatim, including ordering, case, and number of
characters. The only trick would be a way to get what "reverses it"
means correct.
No ?] should match the closest ?[ it should nest the ?[s bound by any
brackets in the regex and act accordingly.
Also this does not work as a definition of simple bracket matching as you
need ( to match ) not ( to match (. A ?[ list should specify for each
element what the matching element is perhaps
(?[( = ),{ = }, 01 = 10)
sort of hashish in style.
Perhaps the brackets could be defined as a hash allowing (?[%Hash)
Richard
--
[EMAIL PROTECTED]
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
[EMAIL PROTECTED]
Re: RFC 145 (alternate approach)
At 09:05 AM 9/6/00 -0400, David Corbin wrote:
I'd suggest also, that (?[) (with no specified brackets) have the
default meaning
of the "four standard brackets" :
(?['('=')','{'='}','['=']',''='')
Note also the subtle syntax change. We are either dealing with strings
or with patterns. The consensus seems to be against patterns (I can
understand that). Given that, we need to quote the right hand side of
the = operator I think. The quotes on the left side would be optional,
I think.
It would be useful (and increasingly more common) to be able to match
qr|\s*(\w+)([^]*)| to qr|\s*/\1\s*|, and handle the case where those
can nest as well. Something like
listmatch this with
list
/list not this but
/list this.
Richard Proctor wrote:
On Tue 05 Sep, Nathan Wiger wrote:
Eric Roode wrote:
Now *that* sounds cool, I like it!
What if the RFC only suggested the addition of two new constructs, (?[)
and (?]), which did nested matches. The rest would be bound by standard
regex constructs and your imagination!
That is, the ?] simply takes whatever the closest ?[ matched and
reverses it, verbatim, including ordering, case, and number of
characters. The only trick would be a way to get what "reverses it"
means correct.
No ?] should match the closest ?[ it should nest the ?[s bound by any
brackets in the regex and act accordingly.
Also this does not work as a definition of simple bracket matching as you
need ( to match ) not ( to match (. A ?[ list should specify for each
element what the matching element is perhaps
(?[( = ),{ = }, 01 = 10)
sort of hashish in style.
Perhaps the brackets could be defined as a hash allowing (?[%Hash)
Richard
--
[EMAIL PROTECTED]
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
[EMAIL PROTECTED]
XML/HTML-specific ? and ? operators? (was Re: RFC 145 (alternate approach))
It would be useful (and increasingly more common) to be able to match qr|\s*(\w+)([^]*)| to qr|\s*/\1\s*|, and handle the case where those can nest as well. Something like listmatch this with list /list not this but /list this. I suspect this is going to need a ?[ and ?] of its own. I've been thinking about this since your email on the subject yesterday, and I don't see how either RFC 145 or this alternative method could support it, since there are two tags - and / - which are paired asymmetrically, and neither approach gives any credence to what's contained inside the tag. So tag would be matched itself as " matches ". What if we added special XML/HTML-parsing ? and ? operators? Unfortunately, as Richard notes, ? is already taken, but I will use it for the examples to make things symmetrical. ? = opening tag (with name specified) ? = closing tag (matches based on nesting) Your example would simply be: /(?list)[\s\w]*(?list)[\s\w]*(?)[\s\w]*(?)/; What makes me nervous about this is that ? and ? seem special-case. They are, but then again XML and HTML are also pervasive. So a special-case for something like this might not be any stranger than having a special-case for sin() and cos() - they're extremely important operations. The other thing that this doesn't handle is tags with no closing counterpart, like: br Perhaps for these the easiest thing is to tell people not to use ? and ?: /(?p)[\s*\w](?:br)(?)/; Would match p Some stuffbr /p Finally, tags which take arguments: div align="center"Stuff/div Would require some type of "this is optional" syntax: /(?div\s*\w*)Stuff(?)/ Perhaps only the first word specified is taken as the tag name? This is the XML/HTML spec anyways. -Nate
Re: XML/HTML-specific ? and ? operators? (was Re: RFC 145 (alternate approach))
Nathan Wiger wrote: It would be useful (and increasingly more common) to be able to match qr|\s*(\w+)([^]*)| to qr|\s*/\1\s*|, and handle the case where those can nest as well. Something like listmatch this with list /list not this but /list this. I suspect this is going to need a ?[ and ?] of its own. I've been thinking about this since your email on the subject yesterday, and I don't see how either RFC 145 or this alternative method could support it, since there are two tags - and / - which are paired asymmetrically, and neither approach gives any credence to what's contained inside the tag. So tag would be matched itself as " matches ". Actually, in one of my responses I did outline a syntax which would handle this with reasonably ease, I think. If the contents of (?[) is considered a pattern, then you can define a matching pattern. Consider either of these. m:(?[list]).*?(?]/list): or m:(?['list' = '/list').*(?]):# really ought to include (?i:) in there, but left out for readablity or more generically m:(?['\w+' = '/\1').*(?]): I'll grant you it's not the simplest syntax, but it's a lot simpler than using the 5.6 method... :) What if we added special XML/HTML-parsing ? and ? operators? Unfortunately, as Richard notes, ? is already taken, but I will use it for the examples to make things symmetrical. ? = opening tag (with name specified) ? = closing tag (matches based on nesting) Your example would simply be: /(?list)[\s\w]*(?list)[\s\w]*(?)[\s\w]*(?)/; What makes me nervous about this is that ? and ? seem special-case. They are, but then again XML and HTML are also pervasive. So a special-case for something like this might not be any stranger than having a special-case for sin() and cos() - they're extremely important operations. The other thing that this doesn't handle is tags with no closing counterpart, like: br Perhaps for these the easiest thing is to tell people not to use ? and ?: /(?p)[\s*\w](?:br)(?)/; Would match p Some stuffbr /p Finally, tags which take arguments: div align="center"Stuff/div Would require some type of "this is optional" syntax: /(?div\s*\w*)Stuff(?)/ Perhaps only the first word specified is taken as the tag name? This is the XML/HTML spec anyways. -Nate -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
Re: RFC 145 (alternate approach)
On Tue 05 Sep, Nathan Wiger wrote:
"normal" "reversed"
-- ---
103301
99aa99
(( ))
+ +
{{[!_ _!]}}
{__A1( )A1__}
That is, when a bracket is encountered, the "reverse" of that is
automatically interpreted as its closing counterpart. This is the same
reason why qq// and qq() and qq{} all work without special notation.
So we can replace @^g and @^G with simple precendence rules, the same
that are actually invoked automatically throughout Perl already.
(?[( = ),{ = }, 01 = 10)
sort of hashish in style.
I actually think this is redundant, for the reasons I mentioned above.
I'm not striking it down outright, but it seems simple rules could make
all this unnecessary.
I dont think you will ever come up with a set of rules that will satisfy
everybody all the time. what about html comments !-- , -- are they
brackets? What about people doing 66/99 pairs? The best you could
achieve is a set of default rules as you have suggested AND a way
of overriding them with an explicit hash of what is the closing
bracket for each opening bracket.
The two methods depend on what follows the (?[ is it a hash or not.
For the "Default" method the list of brackets could be as has been
suggested a regex, or perhaps a simple comma separated list. For this
you should define what is the "reverse" of each character, at
least for latin-1, what do you do about the full utf-8...? An \X type
construct that covers all the common brackets might be a usefull addition
({?
If there is a hash, the hash supplies both the brackets to be matched and
their corresponding close brackets
Richard
--
[EMAIL PROTECTED]
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: XML/HTML-specific ? and ? operators? (was Re: RFC 145 (alternate approach))
I am working on an RFC
to allow boolean logic ( and || and !) to apply a number of patterns to
the same substring to allow easier mining of information out of such
constructs.
What, you don't like: :-)
$pattern = $conjunction eq "AND"
? join('' = map { "(?=.*$_)" } @patterns)
| join("|" =@patterns);
--tom
Re: XML/HTML-specific ? and ? operators? (was Re: RFC 145 (alternate approach))
Jonathan Scott Duff wrote: 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? In principle, that's a very Perlish thing to do... -Scott -- Jonathan Scott Duff [EMAIL PROTECTED] -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
Re: XML/HTML-specific ? and ? operators? (was Re: RFC 145 (alternate approach))
...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.
I've been thinking the same thing. It seems to me that the attempts to
shoehorn parsers into regex syntax have either been unsuccessful
(yielding an underpowered extension) or illegible or both.
An approach that appears to have been more successful is to find ways
to integrate regexes *into* parser code more effectively. Damian
Conway's Parse::RecDescent module does this, and so does SNOBOL.
In SNOBOL, if you want to write a pattern that matches balanced
parenteses, it's easy and straightforward and legible:
parenstring = '(' *parenstring ')'
| *parenstring *parenstring
| span('()')
(span('()') is like [^()]* in Perl.)
The solution in Parse::RecDescent is similar.
Compare this with the solutions that work now:
# man page solution
$re = qr{
\(
(?:
(? [^()]+ )# Non-parens without backtracking
|
(??{ $re }) # Group with matching parens
)*
\)
}x;
This is not exactly the same, but I tried a direct translation:
$re = qr{ \( (??{$re}) \)
| (??{$re}) (??{$re})
| (? [^()]+)
}x;
and it looks worse and dumps core.
This works:
qr{
^
(?{ local $d=0 })
(?:
\(
(?{$d++})
|
\)
(?{$d--})
(?
(?{$d0})
(?!)
)
|
(? [^()]* )
)*
(?
(?{$d!=0})
(?!)
)
$
}x;
but it's rather difficult to take seriously.
The solution proposed in the recent RFC 145:
/([^\m]*)(\m)(.*?)(\M)([^\m\M]*)/g
is not a lot better. David Corbin's alternative looks about the same.
On a different topic from the same barrel, we just got a proposal that
([23,39]) should match only numbers between 23 and 39. It seems to me
that rather than trying to shoehorn one special-purpose syntax after
another into the regex language, which is already overloaded, that it
would be better to try to integrate regex matching better with Perl
itself. Then you could use regular Perl code to control things like
numeric ranges.
Note that at present, you can get the effect of [(23,39)] by writing
this:
(\d+)(?(?{$1 23 || $1 39})(?!))
which isn't pleasant to look at, but I think it points in the right
direction, because it is a lot more flexible than [(23,39)]. If you
need to fix it to match 23.2 but not 39.5, it is straightforward to do
that:
(\d+(\.\d*)?)(?(?{$1 23 || $1 39})(?!))
The [(23,39)] notation, however, is doomed.All you can do is
propose Yet Another Extension for Perl 7.
The big problem with
(\d+)(?(?{$1 23 || $1 39})(?!))
is that it is hard to read and understand.
The real problem here is that regexes are single strings. When you
try to compress a programming language into a single string this way,
you end up with something that looks like Befunge or TECO. We are
going in the same direction here.
Suppose there were an alternative syntax for regexes that did *not*
require that everything be compressed into a single string? Rather
than trying to pack all of Perl into the regex syntax, bit by bit,
using ever longer and more bizarre punctuation sequences, I think a
better solution would be to try to expose the parts of the regex
engine that we are trying to control.
I have some ideas about how to do this, and I will try to write up an
RFC this week.
Re: XML/HTML-specific ? and ? operators? (was Re: RFC 145 (alternate approach))
On Wed, Sep 06, 2000 at 03:47:57PM -0700, Randal L. Schwartz wrote: "Mark-Jason" == Mark-Jason Dominus [EMAIL PROTECTED] writes: Mark-Jason I have some ideas about how to do this, and I will try to Mark-Jason write up an RFC this week. "You want Icon, you know where to find it..." :) Hey, it's one of the few languages we haven't yet stolen a neat feature or few from... (I don't really count the few regex thingies as full-fledged stealing, more like an experimental sleight-of-hand.) But yes, a way that allows programmatic backtracking sort of "inside out" from a regex would be nice. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
RFC 197 (v1) Numberic Value Ranges In Regular Expressions
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Numberic Value Ranges In Regular Expressions =head1 VERSION Maintainer: David Nicol [EMAIL PROTECTED] Date: 5 september 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 197 Status: Developing =head1 ABSTRACT round and square bratches mated around two optional comma separated numbers match iff a gobbled number is within the described range. =head1 DESCRIPTION =head2 the syntax of the numeric range regex element Given a passage of regex text matching ($B1,$N1,$N2,$B2) = /(\[|\()(\-?\d*\.?\d*),(\-?\d*\.?\d*)(\]|\))/ and ($N1 = $N2 or $N1 eq '' or $N2 eq '') we've got something we hereinafter call a "range." =head2 what the range matches A range matches, in the target string, a passage C(\-?\d*\.?\d*) also known as a "number" if and only if the number is within the range. In the normal agebraic sense. =head2 "within the range" Square bracket means, that end of the range may include the range specifying number, and round parenthesis means, that end of the range includes numbers ov value up to (or down to) the number but not equal to it. =head2 infinity in the event that one or the other of the range specifying numbers is the empty string, that end of the range is unbounded. In the further event that we have defined infinity and negative infinity on our numbers, the square/round distinction will come into play. =head1 COMPATIBILITY To disambiguate ranges from character sets indluding digits, commas, and parentheses, either put a backslash on the right parentheses, or the comma, or arrange things so the left hand side of the comma is greater than the right hand side, that way this special case will not apply: /(37.3,200)/; # matches any number x, 37.3 x 200 /([37,))/; # matches and saves any number = 37. /(37\,200)/;# matches and saves the literal text '37,200' /[-35,9)]/; # matches any number x, -35 = x 9; followed by a ] /[3-5,9)]/; # matches a string containing any of 3,4,5,,,9 or ) =head1 IMPLEMENTATION When applying regular expressions to numeric data, ranges may optimize away all of the digit lookahead we must currently indulge in to implement them in perl5. If we have infinity defined, we'll have to recognize it in strings. =head1 BUT WAIT THERE'S MORE It is possible that the syntax described in this document may help slice multidimensional containers. (RFC 191) =head1 REFERENCES high school algebra
RFC 118 (v2) lvalue subs: parameters, explicit assignment, and wantarray() changes
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
lvalue subs: parameters, explicit assignment, and wantarray() changes
=head1 VERSION
Maintainer: Nathan Torkington [EMAIL PROTECTED]
Date: Aug 16, 2000
Last Modified: Sep 6, 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 118
Status: Retired
=head1 ABSTRACT
RFC 107 proposed that lvalue subs should receive their rvalues as
subroutine arguments. I counter-propose that lvalue subs should
receive their rvalues as lexical variables named in a prototype
associated with the :lvalue modifier. The lvalue-ness of a given
subroutine call should be discoverable with the wantarray() function
(or its replacement), and the assignment behaviour should be written
in the subroutine rather than implicitly done by Perl.
=head1 DESCRIPTION
Subroutines may be called with multiple values. Lvalue subroutines
may be assigned multiple values. Simple passing on the argument
list conflates the two:
foo(@args) = @rvalues;
would be identical to:
foo(@args, @rvalues);
Perl's list flattening would prevent the subroutine from knowing where
one began and the other ended. Better would be if the rvalue were
passed as a last or first argument, making it equivalent to:
foo(\@rvalues, @args);
or
foo(@args, \@rvalues);
I don't think this is appropriate, either. Perl's OO tried implicit
arguments, and now we're rebelling against them. Better would be to
have the values magically appear as lexicals in the subroutine.
=head2 Prototypes
To the language it would appear as a prototype associated with the
:lvalue modifier:
sub foo (@) : lvalue ($first, $second, @rest) {
print "My first rvalue is $first\n";
print "My second rvalue is $second\n";
print "The rest of my rvalues are: @rest\n";
print "My arguments are: @_\n";
}
=head2 Explicit assignment
This would change the perl5 meaning of lvalue subroutines. Currently
you must have the lvalue as the last value before the return, and the
assignment is implicitly done by Perl. I advocate making it explicit:
# this is perl5
sub foo :lvalue {
$variable; # am I rvalue or lvalue sub? I don't know
}
foo = 5; # implicitly $variable = 5
I would now have this as:
# this is perl6
sub foo :lvalue ($new) {
$variable = $new;
}
=head2 Lvalue context discoverable
Then the wantarray() replacement, whatever it may be, can be used
to say whether you're lvalue or rvalue and what to do. That makes
an lvalue sub more like the STORE method of a tied variable, where
you can decide whether the storage is acceptable:
# still perl6
sub foo :lvalue ($new) {
if (want("lvalue")) {
if ($new = 0) {
$variable = $new;
} else {
croak "Attempt to store negative number in foo";
}
} else {
return $variable;
}
}
=head1 IMPLEMENTATION
Straightforward. Requires changes to:
=over 4
=item prototypes
Permit named function prototypes. On the lvalue modifier.
=item wantarray
Identify lvalue context.
=back
=head1 NOTES
This RFC has been retired as an historical artifiact of discussion.
=head1 REFERENCES
RFC 107: lvalue subs should receive the rvalue as an argument
RFC 57: Subroutine prototypes and parameters
RFC 21: Replace wantarray with a generic want function
$a in @b
(I sent this to horos in the first RFC format, before the language
list. I haven't got any response, so I send this agian now. I don't
have time to read the list or maintain an RFC. I just wan't to give
this suggestion.)
Does any other RFC give the equivalent to an 'in' operator?
I have a couple of times noticed that beginners in programming want to
write if( $a eq ($b or $c or $d)){...} and expects it to mean
if( $a eq $b or $a eq $c or $a eq $d ){...}.
I think it's a natural human reaction to not be repetative. An 'in'
operator will help here. It could be something like this:
$a in @b; # Has @b any element exactly the same as $a
$a == in @b; # Is any element numericaly the same as $a
$a eq in @b;
$a in @b; # Is $a bigger than any element in @b?
$a not in @b; # Yes. Make 'not' context dependent modifier for in.
...
You could even use it as a version of the ||| operator. :-)
$a = in @b; # Assign the first defined value to $a
--
/ Jonas - http://jonas.liljegren.org/myself/en/index.html
Re: $a in @b
Jonas Liljegren wrote:
Does any other RFC give the equivalent to an 'in' operator?
I have a couple of times noticed that beginners in programming want to
write if( $a eq ($b or $c or $d)){...} and expects it to mean
if( $a eq $b or $a eq $c or $a eq $d ){...}.
I think it's a natural human reaction to not be repetative. An 'in'
operator will help here. It could be something like this:
$a in @b; # Has @b any element exactly the same as $a
$a == in @b; # Is any element numericaly the same as $a
$a eq in @b;
$a in @b; # Is $a bigger than any element in @b?
$a not in @b; # Yes. Make 'not' context dependent modifier for in.
...
You could even use it as a version of the ||| operator. :-)
$a = in @b; # Assign the first defined value to $a
Quantum::Superpositions provides this in a more flexible way by adding the
'any' and 'all' keywords.
http://search.cpan.org/doc/DCONWAY/Quantum-Superpositions-1.03/lib/Quantum/
Superpositions.pm
One of Damian Conway's many promised RFCs will cover incorporating these
ideas into Perl 6.
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
On 4 Sep 2000 21:32:00 -, Perl6 RFC Librarian [EMAIL PROTECTED] wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1TITLE Here Docs Terminators (Was Whitespace and Here Docs) [...] =head1 IMPLENTATION Intentional? It's either 'IMPLANTATION', which is something that has to be done with Damian's brain into the perl6-core, so every operator is DWIM, or 'IMPLEMENTATION', something you seem to be describing here. Just nitpicking. -- H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl5.005.03, 5.6.0 516 on HP-UX 10.20, HP-UX 11.00, AIX 4.2, AIX 4.3, DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.022 and/or DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: Net::Ping problem
On Wed, Sep 06, 2000 at 02:51:03PM +0200, Willy wrote: Does anyone know how can i [snip] How can i do?? You cannot do this in perl6 because perl6 does not yet exist. Please do not abuse this mailing list with off-topic questions. Thank you. -- Tad McClellan SGML consulting [EMAIL PROTECTED] Perl programming Fort Worth, Texas
RE: $a in @b
From: Jonas Liljegren [mailto:[EMAIL PROTECTED]]
Does any other RFC give the equivalent to an 'in' operator?
I have a couple of times noticed that beginners in programming want to
write if( $a eq ($b or $c or $d)){...} and expects it to mean
if( $a eq $b or $a eq $c or $a eq $d ){...}.
I think it's a natural human reaction to not be repetative. An 'in'
operator will help here. It could be something like this:
$a in @b; # Has @b any element exactly the same as $a
$a == in @b; # Is any element numericaly the same as $a
$a eq in @b;
$a in @b; # Is $a bigger than any element in @b?
$a not in @b; # Yes. Make 'not' context dependent modifier for in.
grep { ref($a) eq ref($b) } @b) # Same type?
grep { $a == $_ } @b)
grep { $a eq $_ } @b)
grep { $a $_ } @b)
(grep { $a != $_ } @b) == @b)
Garrett
Re: $a in @b
On Wed, Sep 06, 2000 at 09:43:03AM -0500, Garrett Goebel wrote:
From: Jonas Liljegren [mailto:[EMAIL PROTECTED]]
Does any other RFC give the equivalent to an 'in' operator?
I have a couple of times noticed that beginners in programming want to
write if( $a eq ($b or $c or $d)){...} and expects it to mean
if( $a eq $b or $a eq $c or $a eq $d ){...}.
I think it's a natural human reaction to not be repetative. An 'in'
operator will help here. It could be something like this:
$a in @b; # Has @b any element exactly the same as $a
$a == in @b; # Is any element numericaly the same as $a
$a eq in @b;
$a in @b; # Is $a bigger than any element in @b?
$a not in @b; # Yes. Make 'not' context dependent modifier for in.
grep { ref($a) eq ref($b) } @b) # Same type?
grep { $a == $_ } @b)
grep { $a eq $_ } @b)
grep { $a $_ } @b)
(grep { $a != $_ } @b) == @b)
grep { $_ == 1 } 1..1_000_000
grep doesn't short-circuit.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Fwd: RE: $a in @b
The fact that something can be accomplished in Perl doesn't necessarily mean
its the best or most desirable way to do it. I respect the programming
abilities, but
grep { ref($a) eq ref($b) } @b)
is far less intuitive than the proposal. I could perhaps dig into my distant
memory and explain how to accomplish something like this with PDP-8
front-panel switches, but that doesn't mean that we should not attempt a
loftier solution.
IMHO Perl should add a plethora of higher-order functions for arrays and
hashes, and from the chatter here I think a lot of people agree. Put them
there and if people don't want to use them, fine. Give us lots of ways to do
things- we know that's Perlish.
Personally, I don't like the "in" choice- I favor symbols over words, but
its better than not having it at all. Conflicts with barewords, especially
in hash refs, can be a problem. Do away that the conflict by favoring
symbols over words.
Ed
-
From: Garrett Goebel [EMAIL PROTECTED]
To: 'Jonas Liljegren' [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RE: $a in @b
Date: Wed, 6 Sep 2000 09:43:03 -0500
From: Jonas Liljegren [mailto:[EMAIL PROTECTED]]
Does any other RFC give the equivalent to an 'in' operator?
I have a couple of times noticed that beginners in programming want to
write if( $a eq ($b or $c or $d)){...} and expects it to mean
if( $a eq $b or $a eq $c or $a eq $d ){...}.
I think it's a natural human reaction to not be repetative. An 'in'
operator will help here. It could be something like this:
$a in @b; # Has @b any element exactly the same as $a
$a == in @b; # Is any element numericaly the same as $a
$a eq in @b;
$a in @b; # Is $a bigger than any element in @b?
$a not in @b; # Yes. Make 'not' context dependent modifier for in.
grep { ref($a) eq ref($b) } @b) # Same type?
grep { $a == $_ } @b)
grep { $a eq $_ } @b)
grep { $a $_ } @b)
(grep { $a != $_ } @b) == @b)
Garrett
_
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: $a in @b
grep { $_ == 1 } 1..1_000_000
grep doesn't short-circuit.
I never did figure out why "last" {w,sh,c}ouldn't be made to do
that very thing.
--tom
Re: Fwd: RE: $a in @b
IMHO Perl should add a plethora of higher-order functions for arrays and hashes, and from the chatter here I think a lot of people agree. Make some modules, release them, and see how much they're used. Then one can contemplate sucking them into the core based upon the success of those modules. --tom
Re: $a in @b
On Wed, Sep 06, 2000 at 09:46:13AM -0600, Tom Christiansen wrote:
grep { $_ == 1 } 1..1_000_000
grep doesn't short-circuit.
I never did figure out why "last" {w,sh,c}ouldn't be made to do
that very thing.
Agreed, that would be very natural.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: the C JIT
I don't know exactly how this message got marked "unread" again,
No, here it is, the server at Sun has decided to send it again,
which is all right, since I don't think I responded before going
home last friday.
Received:
from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by
kasey.umkc.
(8.9.0/8.9.2) with ESMTP id BAA31743 for ... Wed, 6
Sep 2000 01:36:51 -0500 (CDT)
Received:
from udcsd.West.Sun.COM ([129.153.51.1]) by mercury.Sun.COM
(8.9.3+Sun/8.9.3) with ESMTP id OAA27600; Fri, 1 Sep 2000
14:52
Nathan Wiger wrote:
"David L. Nicol" wrote:
No, that would be
dog $spot;
No, it wouldn't:
$r = new CGI;# CGI-new
See?
You can have your general consensus, I'm not in his army.
Well, unfortunately I think you're doomed to fail then. You're forcing
constraints on yourself that Perl cannot fulfill, and which I can't see
Larry approving.
I really don't want to argue about this trivial point anymore. my($.02)
is that your ideas are great, but if you want any realistic chance of
getting them into Perl 6, then you have to make the syntax look like
Perl.
-Nate
Lots and lots of human languages, like, all of them, allow WORD WORD to mean
vastly different things depending on what the words are.
I believe that "tagging" theory from natural language parsing would allow
barewords to mean all kinds of different things.
$r = new CGI;
and
account_t student;
are, even without semantic tags, different instances of WORD WORD. The first
is part of a larger expression, the second is a complete WORD WORD expression.
With the introduction of semantic tags, our language knows that Caccount_t is
a defined type, so it doesn't go looking for an Caccount_t method in the Cstudent
package.
I imagine that defined types would hide methods, although more complex ambiguity
resolution schemes could certainly be created. I do not see the collision of
WORD WORD as the problem you do.
As a human being, when I am told something that does not make sense in the idiom I
have been using, I will switch idioms before giving up on finding meaning for it.
This is completely transparent to human beings, who are very good at it. If you have
ever spent any amount of time among people who are comfortably polylingual, which sadly
is a rare treat for Americans, you will notice that they will switch between languages
in the course of a conversation. When I was an exchange student in a country where
two non-english languages were spoken, I had to keep reminding my friends to stick to
the language that I partially knew instead of lapsing into the language that I did not
understand at all.
So that's my linguistical argument for allowing multiple syntaxes into perl (2PI - 2),
humans don't have any trouble context switching when they know two languages, why not
make a computer language that can do that trick? Give it python it will recognize it
(if it has had that capability installed into it) and the same with C or Fortran or
anything, the same as a person who knows English, Spanish and Tagalog will not be
confused by a sentence of good Tagalog in the middle of a conversation which is mostly
« en español ».
I think we're ready for computers that can figure out what language the user is
trying to talk to them in, in fact according to my Secret Heinlein Society Diagram
Of The Future (copyright 1952) we're somewhat behind schedule.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'@w=;for(;;){sleep print[rand@w]}' /usr/dict/words
Re: RFC 33 (v2) Eliminate bareword filehandles.
At 12:50 PM 9/6/00 -0500, David L. Nicol wrote:
I see barewords as being whatever the programmer wants them to be,
as long as he makes it clear what he expects the word to be before using
it.
So, Copen becomes a legacy constructor and the perl6 version of it would
be something like
my filehandle fh; fh-new("/tmp/appendablelog");
Ugh... How about...
my filehandle fh;
fh-open("/tmp/appendablelog");
or (using indirect object notation)
my filehandle fh;
open fh ("/tmp/appendablelog");
or even
open my filehandle fh ("/tmp/appendablelog");
with or without fh being syntactically singular, fh will from here to the
end of the enclosing block be seen as a filehandle if that makes sense in
context.
What advantage does this give over:
open my filehandle $fh ("/tmp/appendablelog");
besides the saving on one key stroke?
If it doesn't make sense, meanings from other contexts will be attempted
before
autovivification or error.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'@w=;for(;;){sleep print[rand@w]}' /usr/dict/words
Re: $a in @b
Garrett Goebel wrote:
grep { ref($a) eq ref($b) } @b) # Same type?
grep { $a == $_ } @b)
grep { $a eq $_ } @b)
grep { $a $_ } @b)
Garrett
grep doesn't short-circuit; you can't return or exit or last out
of the thing.
Maybe we could add support for Clast to Cgrep and Cmap: that
would allow a shorter Cin function without losing any flexibility.
grep { ref($a) eq ref($b) and last } @b) # Same type?
grep { $a == $_ and last } @b)
grep { $a eq $_ and last } @b)
grep { $a $_ and last } @b)
The RFC 88 lazy would work too, you can pull off the first grepped
value and if you don't go back for another the thing will get dismantled
when the current scope closes.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'@w=;for(;;){sleep print[rand@w]}' /usr/dict/words
Re: the C JIT
"David L. Nicol" wrote: s/x/5/; # this is still going to replace # all the eckses in $_ with fives. Why? This is an arbitrary decision if you've declared variables to be barewords. Anyways, I'm done harping on this issue. I think a single, simple syntax is good. You and I will have to agree to disagree on this point. -Nate
Re: RFC 33 (v2) Eliminate bareword filehandles.
Buddha Buck wrote:
my filehandle fh; fh-new("/tmp/appendablelog");
Ugh... How about...
my filehandle fh;
fh-open("/tmp/appendablelog");
Has anyone read RFC 14?
$FILE = open "/etc/motd";
@doc = $FILE;
$WEB = open http "http://www.yahoo.com";
@html = $WEB;
The next version (hopefully out this week) will clarify this syntax
further.
-Nate
Re: $a in @b
Does any other RFC give the equivalent to an 'in' operator?
RFC 22 offers:
switch ($a) {
case (@b) { ... }
}
and my forthcoming superpositions RFC will offer:
if ($a == any(@b) ) { ... }
and:
if ($a eq any(@b) ) { ... }
and:
if ($a != any(@b) ) { ... }
and:
if (any(@a) == any(@b) ) { ... }
and:
if (all(@a) eq any(@b) ) { ... }
etc.
which I think is by far the cleanest solution. :-)
Damian
Re: RFC 33 (v2) Eliminate bareword filehandles.
Has anyone read RFC #11,112,006,825,558,016? It's rather difficult to keep up with them all, or read them all retroactively when you miss a few days. It's also hard to grep them (HTML is the root of all evil). Is there an rsync server that will dole out the pods for us as needed? --tom
Re: RFC 33 (v2) Eliminate bareword filehandles.
Tom Christiansen wrote: The straightforward way to do that is quite simply: open(FH, "|foocmd thisfoo thatfoo|") or for shell avoidance: open(FH, "|-|", "foocmd", "thisfoo", "thatfoo")) Does this work now Or are you just suggesting this be added to Perl 6? Quoth Camel-3, p. 752: When starting a command with open, you must choose either input or output: "cmd|" for reading or "|cmd" for writing. You many not use open to start a command that pipes both in and out, as (currently) illegal notation, "|cmd|", might appear to indicate.
RE: the C JIT
s/x/5/; # this is still going to replace # all the eckses in $_ with fives. Why? This is an arbitrary decision if you've declared variables to be barewords. I think it's a sane decision -- IMHO barewords shouldn't be allowed to interpolate. Of course, this means that to use the value of a bareword variable in a regex, you'd have to do something like: int x = 3 ; ... # Do stuff with x, or not. my int $y = x ; s/$y/5/ ; Which seems like a roundabout way to do it. I still find this whole idea confusing, though. Just out of curiosity, though, would: #include a way for users to bail out gracefully be a syntax error? And how about: int length = 256 ; and, if that's legal, what does: print "I wonder what this is : " . length ; do? Dirk
Re: $a in @b
Damian Conway [EMAIL PROTECTED] writes:
Does any other RFC give the equivalent to an 'in' operator?
and my forthcoming superpositions RFC will offer:
if ($a == any(@b) ) { ... }
and:
if ($a eq any(@b) ) { ... }
and:
if ($a != any(@b) ) { ... }
and:
if (any(@a) == any(@b) ) { ... }
and:
if (all(@a) eq any(@b) ) { ... }
etc.
which I think is by far the cleanest solution. :-)
Yes. That's exactly what I was looking for.
=)
--
/ Jonas - http://jonas.liljegren.org/myself/en/index.html
Re: RFC 33 (v2) Eliminate bareword filehandles.
At 01:52 PM 9/6/00 -0600, Tom Christiansen wrote: Has anyone read RFC #11,112,006,825,558,016? It's rather difficult to keep up with them all, or read them all retroactively when you miss a few days. It's also hard to grep them (HTML is the root of all evil). No HTML here: $ telnet dev.perl.org 80 Trying 209.85.3.25... Connected to tmtowtdi.perl.org. Escape character is '^]'. HEAD /rfc/1.pod HTTP/1.0 Host: dev.perl.org HTTP/1.1 200 OK Date: Wed, 06 Sep 2000 21:09:56 GMT Server: Apache/1.3.9-dev (Unix) Last-Modified: Wed, 23 Aug 2000 04:42:38 GMT ETag: "1251b5-2608-39a3563e" Accept-Ranges: bytes Content-Length: 9736 Connection: close Content-Type: text/plain I think it's time for a thread subject change. -- Peter Scott Pacific Systems Design Technologies
we already have barewords as variables if we want them Re: the C JIT
Nathan Wiger wrote:
"David L. Nicol" wrote:
s/x/5/; # this is still going to replace
# all the eckses in $_ with fives.
Why? This is an arbitrary decision if you've declared variables to be
barewords.
Misstating my position, when I take one, is and will continue to be
a way to get a rise out of me. This may be a character flaw on my part.
Introspection is digression.
Regexes, unless set otherwise, interpolate
like double-quotes. Double-quotes explicitly recognizes $ to mean that
a variable starts here. A bareword inside doublequotes is not interpreted,
in Perl or C.
Anyways, I'm done harping on this issue. I think a single, simple syntax
is good. You and I will have to agree to disagree on this point.
I don't mind agreeing to disagree, but I won't do it until you can
correctly state my position, which you haven't done yet.
From my point of view it appears that you are confusing me with one of the
people (whose names I would have to look up to list) who want to remove
leading $ and @ from variables. I am not in their camp. I agree with you
that those are not workable proposals.
I do not say variables are barewords, I say that barewords may, in addition
to being function calls, be variables. Which is a behavior we can, in fact,
finess out of later versions of perl five that allow subroutines to return l-values,
although doing so requires an explicit declare($$) method, which would take its
arguments as barewords and set up the accessing method and add it to the symbol table.
sub Declare($$){
my ($type, $name) = @_;
my $atman; # a universal virtual base class
$Declared::VarRef{$name} = \$atman;
$Declared::VarType{$name} = $type;
eval ENDEVAL;
sub $name : lvalue { return \$\$Declared::VarRef{$name} };
ENDEVAL
};
And there it is, a bareword that quacks like a variable.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'@w=;for(;;){sleep print[rand@w]}' /usr/dict/words
RE: $a in @b
From: Bart Lateur [mailto:[EMAIL PROTECTED]]
On Wed, 06 Sep 2000 13:04:51 -0500, David L. Nicol wrote:
grep { $a $_ and last } @b)
So "last" should return true, or what?
The last operator doesn't return anything does it? It immediately exits the
loop/block in question.
@passed = grep { 2 $_ and last } (1, 2, 3, 2, 1);
I believe that unless used with a label, if someone were to use last within
a grep or map block, then further processing for that element of the list
which grep is working on would be skipped, and it would continue with the
next element.
would leave
@passed = (1, 2)
instead of the current behaviour which would be
@passed = (1, 2, 2, 1)
You can also do:
{
last;
}
We are already advised not to use last within eval {}, sub {}, do {}, grep
{}, and map {}, but this might break some obfuscated code which depends on
it. I'm not to sure how this could be handled in a Perl 5-6 translation...
to exit a block...
Hmm... I guess I'll submit and RFC on this...
Garrett
Re: the C JIT
"Myers, Dirk" wrote:
I still find this whole idea confusing, though. Just out of curiosity,
though, would:
#include a way for users to bail out gracefully
be a syntax error?
It is clear to us that that is a comment and not a preprocessor directive.
The #include preprocessor directive is more than match /^#include/ it is
more like (/^#include (".+")\s*\Z/ or /^#include (.+)\s*\Z/). And anything
that would be a syntax error in C, a poorly formed preprocessor directive, is
a simple Perl comment.
And how about:
int length = 256 ;
and, if that's legal, what does:
print "I wonder what this is : " . length ;
do?
I imagine the first order of business for the C JIT team would be
some conversion operators. Numeric types stringify into decimal representation,
no reason to throw that away.
Dirk
thanks for your support
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'@w=;for(;;){sleep print[rand@w]}' /usr/dict/words
Re: RFC 199 (v1) Short-circuiting Cgrep and Cmap with Clast
Just to note that RFC 76 (Builtin: reduce) also proposes this mechanism as a means of short-circuiting Creduce. Damian
RE: $a in @b
@passed = grep { 2 $_ and last } (1, 2, 3, 2, 1);
I believe that unless used with a label, if someone were to use
last within a grep or map block, then further processing for that
element of the list which grep is working on would be skipped, and
it would continue with the next element.
would leave
@passed = (1, 2)
I believe the above would leave:
@passed = ();
since on the first call to the block 2 1 is true, so the Clast is
executed, which terminates the Cgrep immediately.
instead of the current behaviour which would be
@passed = (1, 2, 2, 1)
That's not the current behaviour.
With the Clast you either get an exception or an exit from the surrounding
block (and in either case @passed is not reassigned at all).
If you meant "current behaviour without the Clast", that's still
not right. Without the Clast the current behaviour leaves (1,1)
in @passed.
We are already advised not to use last within eval {}, sub {}, do
{}, grep {}, and map {}, but this might break some obfuscated code
which depends on it. I'm not to sure how this could be handled in a
Perl 5-6 translation...
Have p52p6 name *every* block and label *every* Cnext, Clast, and Credo.
Damian
Re: we already have barewords as variables if we want them Re: the C JIT
David L. Nicol wrote: A bareword inside doublequotes is not interpreted, in Perl or C. No; a "bareword" in quotes (any kind) is not a bareword. -- John Porter
RFC 199 (v1) Short-circuiting Cgrep and Cmap with Clast
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Short-circuiting Cgrep and Cmap with Clast =head1 VERSION Maintainer: Garrett Goebel [EMAIL PROTECTED] Date: 6 Sep 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 199 Status: Developing =head1 ABSTRACT Allow functions like Cgrep and Cmap with implicit loop blocks to be short circuited with Clast. =head1 DESCRIPTION It'd be nice if one could use Cgrep to find out if a value is held in a list without having to iterate through every element of said list. I'm sure others can figure out their own uses for short-circuiting Cgrep and Cmap. Adoption of this suggestion would create problems with any Perl 5 code that is so strange as to currently use Clast within a Cgrep or Cmap block. Hmm, I don't know how this could be worked around other than to have the Perl 5-6 translation label loops and Clasts whenever Clast is found within a Cgrep or Cmap block. If someone has a better idea please suggest it. Neither Tom Christiansen nor Jarkko Hietaniemi profess to know why the suggestion with regards to Cgrep hasn't already been implemented. Perhaps it has to do with the fact that the blocks in Cgrep and Cmap are only implicitly loops, where as Cwhile, Cuntil, Cfor, and Cforeach are explicitly loops. It might therefore follow that one should also be able to lable Cgrep and Cmap statements, as they are implicit loops. Are there any other similar built-in functions? If there is strong sentiment that one or the other of Cgrep and Cmap should(n't) me allowed to short circuit with Clast, then let me know and I'll break this into 2 RFC's. =head1 IMPLEMENTATION I haven't a clue. Please feel free to suggest one for the next revision. =head1 REFERENCES Ideas that offer alternative routes to similar functionality: RFC 22: Builtin switch statement RFC ??: Damian Conway's forthcoming superpositions RFC
Re: RFC 194 (v1) Standardise Function Pre- and Post-Handling
I should have an RFC out on this by next week. Damian
Re: RFC 194 (v1) Standardise Function Pre- and Post-Handling
On Thu, Sep 07, 2000 at 06:28:25AM +1100, Damian Conway wrote: I should have an RFC out on this by next week. Feel free to hijack and/or infiltrate my RFC. Damian -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 194 (v1) Standardise Function Pre- and Post-Handling
Feel free to hijack and/or infiltrate my RFC. You Will Be Assimilated. Damian
RFC 194 (v1) Standardise Function Pre- and Post-Handling
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Standardise Function Pre- and Post-Handling
=head1 VERSION
Maintainer: Jarkko Hietaniemi
Date: 05 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 194
Status: Developing
=head1 ABSTRACT
A standardised way of registering/unregistering/inspecting pre- and
posthandlers (also known as hooks) for handlers, and possibly also for
code references any, is needed.
NOTE: this RFC does not (yet) propose any particular syntax or
interface. Its main purpose for now is to point out the potential for
standardising, and to outline the required functionality.
=head1 DESCRIPTION
Many modules [PV:HPPC, JP:HWS, MJD:M] introduce their own way of
either installing/uninstalling generic function handlers [PV:HPPC,
JP:HWS] or installing/uninstalling specific function handlers [MJD:M].
With the more generic approaches one can wrap a function to a
chain/stack of pre- and post-handlers: pre-handlers can do anything
they want to the argument list; post-handlers can do anything they
want to return value list. To the caller of the original function
there is (should be) no difference. The [MJD:M] is a special-purpose
prehandler: it caches the return values for idempotent ('pure',
side-effect-free) functions, using the arguments as the key to to
the cache, after the initial call fetching the return values from
the cache, resulting in a (hopefully) saved computation and faster
function calls.
All the above support registering and deregistering handler functions
for functions, but in more general case it should be possible to do
the same for code references. This would be much more orthogonal, and
also kind of mandatory if core functions become referenceable as
[JV:RFC168] proposes. This would open up a way towards very nifty
features like the ubiquitously-requested URL-aware open(). Just
install your URL-ware prehandler to \CORE::open and off you go. Want
versioned files? warn() that also transparently does syslog()?
close() that automatically renames the file to file.MMDD-hhmmss
after it has been closed?
Prehandlers should stack as BEGIN blocks do; posthandlers should
stack in the reverse order as END blocks do.
There should be a way inspect the pre- and post-stacks of handlers,
and the all handlers should have a symbolic name. For example,
a handler X may want to install before another handler Y but after
another handler Z. A meta-handler may want to remove a handler.
=head1 IMPLEMENTATION
The implementation is dependent on what happens to typeglobs in Perl
6, how does one inspect and modify the moral equivalent of the symbol
table? Also: what will become of prototypes? Will it become possible
to declare return types of functions?
As pointed out in [JP:HWS] certain intricacies are involved: what are
the semantic of caller()? Should it see the prehooks? If yes, how?
How does this relate to the proposed generalized want() [DC:RFC21]?
=head1 REFERENCES
RFC 21: Replace wantarray with a generic want function, by Damian Conway
RFC 168: Built-in functions should be functions, by Johan Vromans
Hook::WrapSub by John Porter,
http://search.cpan.org/search?dist=Hook-WrapSub
Memoize by Mark-Jason Dominus,
http://search.cpan.org/search?mode=modulequery=Memoize
Hook::PrePostCall by Philippe Verdret,
http://search.cpan.org/search?dist=HookPrePostCall
RFC 195 (v1) Retire chop().
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Retire chop(). =head1 VERSION Maintainer: Nathan Torkington [EMAIL PROTECTED] Date: 5 Sep 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 195 Status: Developing =head1 ABSTRACT Remove chop() from the core. Its purpose is better served by chomp(), so its remaining applications are few and limited. =head1 DESCRIPTION chop()'s original purpose was to remove trailing line terminators. However, chop() is dangerous: it always removes the last character, and it doesn't care whether the last character is a line terminator or not. So chomp() was introduced. This only removes the value of $/, and if there's no $/ at the end of the string then it doesn't remove anything. This makes it safer: if you don't know whether your string is chomp()ed or not, you can chomp() it anyway. With chop() you had to have a separate explicit test. chop() also doesn't know about $/ and the different values it might have. chop() is still occasionally used, but very rarely. Not enough, in my opinion, for chop() to stay in the core. Its functionality might be available in a library. =head1 IMPLEMENTATION The perl526 translator can simply use s/.\z//s; for a chop() action. If there were a chop() in a standard library then the conversion would simply be a matter of putting: use String::Chop; # or whatever at the top of any converted program that uses chop(). Implementation in perl6 is very straightforward: don't implement chop(). =head1 REFERENCES RFC 58: Cchomp() changes. perlfunc manpage for discussion of chomp() and chop()
