Re: RFC 75 (v2) structures and interface definitions
Chaim Frenkel wrote:
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
PRL%DataHash = unpack $mypic, $SomePackedCobolData;
Does it unpack it into the hash? Or does it keep a pointer into
the original structure?
I'd think it would depend on if %DataHash is defined already. For
unpack() to return a list of key/value pairs is not all that different
from just returning values the way it does now. For unpack to return
a tied object that refers to a copy of the initial data, that is a little
bit more different but it is within possibility.
What happens when a new key is added to the hash?
that may or may not be possible, I'd like to discuss it further
before declaring one way or the other.
What happens if the underlying structure is overlayed?
sysread(FOO, $SomePackedCobolData, $length);
%DataHash = unpack $mypic, $SomePackedCobolData;
sysread(FOO, $SomePackedCobolData, $length);
chaim
Perl data accessors generally create copies to avoid these "action at
a distance" situations such as the case where %DataHash is composed
of offsets into a scalar which gets redefined. Perl5's unpack function
creates copies.
These issues presuppose a "closed hash" data type, and its internal
representation. Why don't you write the RFC that answers these questions?
How would you like to see your coboldata represented and used as a
perl hash?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=' ~/nsmail/Inbox
Standardization of Perl IO functions
All-
This is an idea I've been chewing on for some time. RFC 14 proposes a
new syntax to open():
$FH = open dir "/usr/local/bin" or die "Badness: $!";
which is far different from the current open(). This is actually a more
flexible and consistent syntax, with a cool feature I just came across
the other day:
@file = open("/etc/motd")-readline or die;
open("/var/log/logfile")-print("Hello, world!");
Python, anyone? ;-)
Anyways, I was thumbing through ye ol' Camel, looking at lots of IO
functions, wondering if we shouldn't look at doing something similar to
them. For example, let's consider sys*. Currently they look like this:
sysopen(FH, $file, O_RDONLY|O_CREAT, 0644);
sysread(FH, $scalar, $length, $offset);
syswrite(FH, $scalar, $length, $offset);
sysseek(FH, $pos, $whence);
If we instead took changed these to look more like this this new open()
and other Perl functions (like print), taking advantage of indirect
objects:
$FH = sysopen $file, O_RDONLY|O_CREAT, 0644;
$scalar = sysread $FH $length, $offset;
syswrite $FH $scalar, $length, $offset;
sysseek $FH $pos, $whence;
Then these could potentially be chained as well:
sysopen($file, O_WRONLY)-syswrite($scalar, $length, $offset);
That looks like it could be useful. Of course, you wouldn't have to do
things this way:
$FH = sysopen($file, O_WRONLY) or die;
syswrite $FH $scalar, $length, $offset;
And at the very least you get a more internally consistent syntax.
Comments?
-Nate
Draft RFC: my Dog $spot is just an assertion
=head1 TITLE
Cmy Dog $spot is just an assertion
=head1 VERSION
Maintainer: Piers Cawley [EMAIL PROTECTED]
Date: 12th September 2000
Last Modified: 12th September 2000
Mailing List: [EMAIL PROTECTED]
Version: 0
Status: Draft
=head1 ABSTRACT
The behaviour of the my Dog $spot syntax should simply be an
assertion of the invariant:
(!defined($spot) || (ref($spot) $spot-isa('Dog)))
=head1 DESCRIPTION
The syntax
my Dog $spot = Dog-new();
currently carries little weight with Perl, often failing to do what
one expects:
$ perl -wle 'my Dog::$spot; print "ok"'
No such class Dog at -e line 1, near "my Dog"
Execution of -e aborted due to compilation errors.
$ perl -wle 'sub Dog::new; my Dog $spot; print "ok"'
ok
$ perl -wle 'sub Dog::new; my Dog $spot = 1'
ok
The first example is obvious, as is the second. The third one is
Iweird.
I therefore propose that Cmy Dog $spot comes to mean that C$spot
is restricted to being either undefined or a reference to a CDog
object (or any subclasses of Dog). Simply having this implicit
assertion can be useful to the programmer, but I would argue that its
main advantage is that the compiler knows the object's interface at
compile time and can potentially use this fact to speed up method
dispatch.
=head2 Examples
In class methods:
package Dog;
sub speak {
my Dog $self = shift; # Sadly 'my __PACKAGE__ $self' doesn't work
print $self-name, " barks!\n";
}
Admittedly, this makes little sense unless there is some optimization
available, but it can still be useful as a notational convenience.
Or, consider the case where you have an CAnimalShelter object and
you're looking to get a Dog from there.
my AnimalShelter $shelter = RSPCA-find_nearest_shelter;
my Dog $stray;
try {
PET: while (!defined($stray)) {
$stray = $shelter-next_animal;
}
}
catch Exception::WrongClass {
next PET;
}
$stray-bark;
Admittedly this makes some assumptions about the possibility of loops
within try blocks, but I think the point is still valid.
My main concern with this proposal is to make it possible to use the
Cmy Dog $spot syntax along with it's associated (posited)
optimizations and assertions wherever it's appropriate in user code.
=head1 IMPLEMENTATION
I've not really looked into using source filters, but if
Cmy Dog $spot can be mapped to
Ctie my $spot, Tie::Invariant, 'Dog' then Tie::Invariant can look
something like:
package Tie::Invariant;
use carp;
sub TIESCALAR {
my $self = bless {value = undef}, shift;
$self-{class} = shift;
return $self;
}
sub FETCH {
my $self = shift;
return $self-value;
}
sub STORE {
my($self,$newval) = @_;
if (!defined($newval) || (ref($newval)
UNIVERSAL::isa($newval, "UNIVERSAL")
$newval-isa($self-{class}))) {
croak "Value must be 'undef' or be a $self-{class}"
}
$self-{value} = $newval;
}
=head1 MIGRATION
Migration issues should be minor, the only problem arising when people
have assigned things that aren't objects of the appropriate type to
typed variables, but they deserve to lose anyway.
=head1 REFERENCES
RFC 171: my Dog $spot should call a constructor implicitly
This RFC is a counter RFC to RFC 171. See my forthcoming
'new pragma: use package' RFC for something that addresses one of the
concerns of RFC 171.
RFC 137: Overview: Perl OO should Inot be fundamentally changed
My guiding principle.
--
Piers
Re: Draft RFC: my Dog $spot is just an assertion
Piers wrote:
The behaviour of the my Dog $spot syntax should simply be an
assertion of the invariant:
(!defined($spot) || (ref($spot) $spot-isa('Dog)))
(!defined($spot) || (ref($spot) $spot-isa('Dog')))
Otherwise, AMEN!
Damian
Re: RFC 72 (v3) Variable-length lookbehind: the regexp engine should also go backward.
From: Hugo [EMAIL PROTECTED] Sent: Monday, September 11, 2000 11:59 PM mike mulligan replied to Peter Heslin: : ... it is greedy in the sense of the forward matching "*" or "+" constructs. : [snip] This is nothing to do with greediness and everything to do with left-to-rightness. The regexp engine does not look for x* except in those positions where the lookbehind has already matched. I was trying to understand at what point the lookbehind was attempted, and confused myself and posted a bad example. My apologies to everyone. Let's see if I can make sense of it on a second try. My question is: if I have the regex /(?=[aeiou]X[yz]+/ then does Perl: 1. scan first for 'X', test the lookbehind, and then test the '[yz]', or 2. scan for 'X[yz]' and then test the lookbehind? I am expecting these two alternatives to give the same result, but certain test strings might run slower or faster depending on the approach. Running perl -Dr shows that alternative 1 is used: qq(aXuhXvoXyz) =~ /(?=[aeiou])X[yz]/ Guessing start of match, REx `(?=[aeiou])X[yz]' against `aXuhXvoXyz'... Found anchored substr `X' at offset 1... Guessed: match at offset 1 Matching REx `(?=[aeiou])X[yz]' against `XuhXvoXyz' Setting an EVAL scope, savestack=3 1 a XuhXvoXyz | 1: IFMATCH[-1] 0 aXuhXvoXyz | 3:ANYOF[aeiou] 1 a XuhXvoXyz | 12:SUCCEED could match... 1 a XuhXvoXyz | 14: EXACT X 2 aX uhXvoXyz | 16: ANYOF[yz] failed... Setting an EVAL scope, savestack=3 4 aXuh XvoXyz | 1: IFMATCH[-1] 3 aXu hXvoXyz | 3:ANYOF[aeiou] failed... failed... Setting an EVAL scope, savestack=3 7 aXuhXvo Xyz | 1: IFMATCH[-1] 6 aXuhXv oXyz | 3:ANYOF[aeiou] 7 aXuhXvo Xyz | 12:SUCCEED could match... 7 aXuhXvo Xyz | 14: EXACT X 8 aXuhXvoX yz | 16: ANYOF[yz] 9 aXuhXvoXy z | 25: END Match successful!
Re: RFC 166 (v1) Additions to regexs
On Mon 11 Sep, Mark-Jason Dominus wrote:
(?@foo) is sort of equivalent to (??{join('|',@foo)}), ie it expands into
a list of alternatives. One could possible use just @foo, for this.
It just occurs to me that this is already possible. I've written a
module, 'atq', such that if you write
use atq;
then your regexes may contain the sequence
(?\@foo)
with the meaning that you asked for.
Yes, but is this a very good way to go forward, the use of overload is
"heavy", if somthing might be useful. (See other note about generalised
additions to regexes).
(The \ is necessary here because (?@foo) already has a meaning under
Perl 5, and I think your proposal must address this.)
(?@foo) has no meaning I checked the code
Anyway, since this is possible under Perl 5 with a fairly simple
module, I wonder if it really needs to be in the Perl 6 core. Perhaps
it would be better to propose that the module be added to the Perl 6
standard library?
The module is small, but this does not mean that adding functionality to the
core is necesarily a bad idea.
Richard
--
[EMAIL PROTECTED]
Generalised Additions to regexes
(proto RFC possibly, and some generalised ramblings)
Given that expansion of regexes could include (+...) and (*...) I have been
thinking about providing a general purpose way of adding functionality.
I propose that the entire (+...) syntax is kept free from formal
specification for this and is available for pluggable (module) expansion.
(+ = addition).
A module or anything that wants to support some enhanced syntax
registers something that handles "regex enhancements".
At regex compile time, if and when (+foo) is found perl calls
each of the registered regex enhancements in turn, these:
1) Are passed the foo string as a parameter exactly as is. (There is
an issue of actually finding the end of the foo.)
2) The regex enhancement can either recognise the content or not.
3) If not it returns undef and perl goes to the next regex enhancement
(Does it handle the enhancements as a stack (Last checked first) or a list
(First checked first?) how are they scoped? Job here for the OO fanatics)
4) If perl runs out of regex enhancements it reports an error.
5) if an enhancement recognises the content it could do either of:
a) return replacement expanded regex using existing capabilities perl will
then pass this back through the regex compiler.
b) return a coderef that is called at run time when the regex gets to this
point. The referenced code needs to have enough access to the regex
internals to be able to see the current sub-expression, request more
characters, access to relevant flags and visability of greediness. It may
also need a coderef that is simarly called when the regex is being unwound
when it backtracks.
Thinking from that - the last case should be generalised (it is sort of
like my (?*{...}) from RFC 198. If so both cases a and b are the same,
b is just a case of returning (?*{...}).
Following on, if (?{...}) etc code is evaluated in forward match, it would
be a good idea to likewise support some code block that is ignored on a
forward match but is executed when the code is unwound due to backtracking.
Thus (?{ foo })(?\{ bar }) could be defined to execute foo on the forward
case and bar if it unwinds.
For example - Think about foo putting something on a stack (eg the
bracket to match [RFC 145]) and bar taking it off.
I dont care at the moment what the syntax is - what about the concepts?
Richard
--
[EMAIL PROTECTED]
RFC 110 (v5) counting matches
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
counting matches
=head1 VERSION
Maintainer: Richard Proctor [EMAIL PROTECTED]
Date: 16 Aug 2000
Last Modified: 12 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 110
Version: 5
Status: Developing
=head1 ABSTRACT
Provide a simple way of giving a count of matches of a pattern.
=head1 DESCRIPTION
Have you ever wanted to count the number of matches of a patten? s///g
returns the number of matches it finds. m//g just returns 1 for matching.
Counts can be made using s//$/g but this is wastefull, or by putting some
counting loop round a m//g. But this all seams rather messy.
TomC (and a couple of others) have said that it can also be done as :
$count = () = $string =~ /pattern/g;
However many people do not like this construct, here are a couple of quotes:
jhi: Which I find cute as a demonstration of the Perl's context concept,
but ugly as hell from usability viewpoint.
Bart Lateur: '()=' is not perfect. It is also butt ugly. It is a "dirty hack".
This construct is also likely to be inefficient as perl will have to
build up a list of all the matches, store them somewhere, count them, then
throw them away.
Therefore I would like a way of counting matches.
=head2 Proposal
m//gt (or m//t see below) would be defined to do the match, and return the
count of matches, this leaves all existing uses consistent and unaffected.
/t is suggested for "counT", as /c is already taken.
Relationship of m//t and m//g - there are three possibilities, my original:
m//gt, where /t adds counting to a group match (/t without /g would just
return 0 or 1). However \G loses its meaning.
The Alternative By Uri :
m//t and m//g are mutually exclusive and m//gt should be regarded as an error.
Hugo:
I like this too. I'd suggest /t should mean a) return a scalar of
the number of matches and b) don't set any special variables. Then
/t without /g would return 0 or 1, but be faster since no extra
information need be captured (except internally for (.)\1 type
matching - compile time checks could determine if these are needed,
though (?{..}) and (??{..}) patterns would require disabling of
that optimisation). /tg would give a scalar count of the total
number of matches. \G would retain its meaning.
I think Hugo's wording about the relationship makes the best sense, and
this is the suggested way forward.
=head1 CHANGES
RFC110 V1 - Original posting to perl6-language
RFC110 V2 - Reposted to perl6-language-regex
RFC110 V3 - Added Uri's alternitive m//t
RFC110 V4 - Added notes about $count = () = $string =~ /pattern/g
RFC110 V5 - Added Hugo's wording about /g and /t relationship, suggested this
is the way forward.
Unless any significant discussion takes place this RFC will move to frozen
within a week.
=head1 IMPLENTATION
Hugo:
Implementation should be fairly straightforward,
though ensuring that optimisations occurred precisely when they
are safe would probably involve a few bug-chasing cycles.
=head1 REFERENCES
I brought this up on p5p a couple of years ago, but it was lost in the noise...
Re: RFC 72 (v3) Variable-length lookbehind: the regexp engine should also go backward.
In 085601c01cc8$2c94f390$[EMAIL PROTECTED], "mike mulligan" w rites: :From: Hugo [EMAIL PROTECTED] :Sent: Monday, September 11, 2000 11:59 PM : : : mike mulligan replied to Peter Heslin: : : ... it is greedy in the sense of the forward matching "*" or "+" :constructs. : : [snip] : : This is nothing to do with greediness and everything to do with : left-to-rightness. The regexp engine does not look for x* except : in those positions where the lookbehind has already matched. : :I was trying to understand at what point the lookbehind was attempted, and :confused myself and posted a bad example. My apologies to everyone. Let's :see if I can make sense of it on a second try. : :My question is: if I have the regex /(?=[aeiou]X[yz]+/ then does Perl: 1. :scan first for 'X', test the lookbehind, and then test the '[yz]', or 2. :scan for 'X[yz]' and then test the lookbehind? 3. The regexp is matched left to right: first the lookbehind, then 'X', then '[yz]'. :I am expecting these two alternatives to give the same result, but certain :test strings might run slower or faster depending on the approach. : :Running perl -Dr shows that alternative 1 is used: Running perl -Dr shows that alternative 3 is used. However the -Dr data is confused by the optimiser, which happens to have chosen the fixed string 'X' as something worth searching for first. So the optimiser permits the main matching engine to look only at those positions where there is an 'X' immediately following. I've annotated the -Dr output below to try and clarify. Note that if you replace 'X' with '(x|X)', no optimisations take place (other than a 'minimum length' check) and -Dr will give a much clearer picture of the flow; again, if you replace 'X[yz]' with '(x|X)y' the optimiser will now pick 'y' as the most significant thing worth searching for. Hope this helps, Hugo --- :qq(aXuhXvoXyz) =~ /(?=[aeiou])X[yz]/ : :Guessing start of match, REx `(?=[aeiou])X[yz]' against `aXuhXvoXyz'... The optimiser is entered. :Found anchored substr `X' at offset 1... This is what the optimiser is looking for. :Guessed: match at offset 1 This is what the optimiser found. :Matching REx `(?=[aeiou])X[yz]' against `XuhXvoXyz' The real matcher is entered. : Setting an EVAL scope, savestack=3 : 1 a XuhXvoXyz | 1: IFMATCH[-1] : 0 aXuhXvoXyz | 3:ANYOF[aeiou] Checking lookbehind ... : 1 a XuhXvoXyz | 12:SUCCEED Ok. : could match... : 1 a XuhXvoXyz | 14: EXACT X Checking 'X' ... : 2 aX uhXvoXyz | 16: ANYOF[yz] Checking '[yz]' ... :failed... Failed: try the next position permitted by the optimiser. : Setting an EVAL scope, savestack=3 : 4 aXuh XvoXyz | 1: IFMATCH[-1] : 3 aXu hXvoXyz | 3:ANYOF[aeiou] Checking lookbehind ... : failed... Failed. :failed... Try the next position permitted by the optimiser. : Setting an EVAL scope, savestack=3 : 7 aXuhXvo Xyz | 1: IFMATCH[-1] : 6 aXuhXv oXyz | 3:ANYOF[aeiou] Checking lookbehind ... : 7 aXuhXvo Xyz | 12:SUCCEED Ok. : could match... : 7 aXuhXvo Xyz | 14: EXACT X Checking 'X' ... : 8 aXuhXvoX yz | 16: ANYOF[yz] Checking '[yz]' ... : 9 aXuhXvoXy z | 25: END :Match successful! Match successful.
Re: $a in @b (RFC 199)
On Mon, Sep 11, 2000 at 04:41:29PM -0500, Jarkko Hietaniemi wrote: Allow me to repeat: instead of trying to shoehorn (or piledrive) new semantics onto existing keywords/syntax, let's create something new. The blocks of grep/map/... are special. They are not quite looping blocks, they are not quite sub blocks, they are different. Well, to be frank they are just very plain, ordinary, blocks that return their last value, but if we want to introduce both flow control (short-circuiting) and as a derived requirement, a return value (was the last test a success or a failure), they definitely begin to become not your ordinary blocks. I do not think the existing arsenal of keywords/syntax is enough to cover all the behaviour we are after. The 'pass' keyword someone suggested has potential (when combined with allowing last -- and next -- to work on these mongrel blocks). Also it should be possible for someone to write thier own looping construct like map/grep as a sub and take advantage of this. Graham.
Check this !! messaging langage or so ...!!!
hi, snip REBOL is the next generation of distributed communications. By "distributed" we mean that REBOL code and data can span more than 40 platforms without modification using ten built-in Internet protocols. The pieces of a program can be distributed over many systems. By "communications" we mean that REBOL can exchange not only traditional files and text, but graphical user interface content and domain specific dialects that communicate specific meaning between systems. We define communications to include not only information exchanged between computers, but information exchange between people and computers, and information exchanged between people. REBOL accomplishes all of these. /snip http://www.rebol.com/developer.html http://www.rebol.com/howto.html http://www.rebol.com/faq.html Q. I noticed REBOL has built-in compression. How do I use it? Q. Why doesn't REBOL have an ELSE statement? Q. What IS a series? = iVAN [EMAIL PROTECTED] =
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Tom Christiansen [EMAIL PROTECTED] writes: I don't want a set representation. I want set operations. And somehow for this having to add a use statment and who knows what overhead for what seems to be a simple operation is a pain. The overhead is not that it should be a module, but rather, the sillily/evilly inefficient thing that *you* are doing. Or trying to do. We have modules to do this. We have hashes to do this. We have the technology. It is ignored. Ignorance of technology is no excuse for adding strange basic types and operations on them into the very heart of a programming language. I wonder if an RFC proposing some way of allowing folks to implement named infix operators wouldn't be better than the current one proposing adding set theoretic functions? Then the set theretic stuff is just a SMOP on top of the more general 'making named infix operators' RFC. Of course, there's every chance that said RFC would get shot down in flames, but if it *were* accepted and proved possible to implement then we get a whole lot more functionality than just set munging ops. However, I'm damned if I'm writing such an RFC; I'm not even sure that the functionality would be a win. -- Piers
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Tom Christiansen wrote: I don't want a set representation. I want set operations. And somehow for this having to add a use statment and who knows what overhead for what seems to be a simple operation is a pain. The overhead is not that it should be a module, but rather, the sillily/evilly inefficient thing that *you* are doing. Or trying to do. We have modules to do this. We have hashes to do this. We have the technology. It is ignored. Ignorance of technology is no excuse for adding strange basic types and operations on them into the very heart of a programming language. --tom I'm not an expert in technology of programming languages, but I know that such basic operations exists in other languages, and I'm sure that it can be possible to add such functions/operators in the heart of Perl without doing it with sillily/evilly inefficiency. If others languages can do it, why not Perl ? Gael,
Re: Please take RFC 179 discussion to -data
[EMAIL PROTECTED] wrote: Could we please take discussion of 179 to -data? I think that's where it should be. K. Personnally, I don't see any objection to this. If everybody is ok, why not ? How should I process ? Submit again the proposal with a modified mailing-list email ? Gael,
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
Basically a hash with
only the keys, no other baggage.
TC If you don't want but the keys, don't use but the keys.
Does that mean, that none of the other bookeeping for the values will
be done?
Is this "@hash{@keys};" valid?
Would it be possible to make push(%hash, @keys) work? Doesn't look likely
is @keys the keys, the values, or both?
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: $a in @b
At 09:37 AM 9/12/00 -0400, Jerrad Pierce wrote:
Doh! perhaps then more like:
#grep for str's beginning and ending in a digit
grep ITEM: { /^[1-9]/; next ITEM unless /[1-9]$/ } @list;
Of course there are other ways of writing this...
Are there any cases people want this for that CANNOT be rewritten?
Or is it purely syntactic sugar? Not that that is a bad thing,
as I've mentioned I think a way to short-circuit/bypass/"return" from
an otherwise undistinguished block would be nice. There have been
many times I've wanted to do same.
I think it's fine to allow a loop label on the grep block, but it wasn't
really what I thought we were discussing; you still haven't indicated what
the value of the block should be on that iteration. undef is a reasonable
default but how to provide another? That's what my idea was, to provide a
second argument. Also, shouldn't be necessary to label a loop if you don't
have another one inside it, although if you did, it would avoid the
embarrassment of "last undef, 'foo'" that fell out of my suggestion.
--
Peter Scott
Pacific Systems Design Technologies
Re: $a in @b (RFC 199)
Jarkko Hietaniemi wrote:
Allow me to repeat: instead of trying to shoehorn (or piledrive) new
semantics onto existing keywords/syntax, let's create something new.
The blocks of grep/map/... are special. They are not quite looping
blocks, they are not quite sub blocks, they are different. Well, to
be frank they are just very plain, ordinary, blocks that return their
last value, but if we want to introduce both flow control
So, why not get rid of the specialness? Why can't all blocks return
their last value? The ones that currently do not return a value would
just be given void context. (Just because there's nowhere for the value
to go doesn't mean they can't return a value.) And if that's done, then
$val = 1;
$fact = while ($n) { $val *= $n--; } || $val;
might not be a horrible idea either.
Then we would have sub BLOCKs and loop BLOCKs. 'return' would escape the
nearest enclosing sub BLOCK and return a value. last/redo/next would
escape/repeat/continue the enclosing BLOCK of any sort, and would be
extended to specify the value returned. 'last $value' would be
equivalent to 'return $value' inside a subroutine unless it were
enclosed in a loop BLOCK.
Extension idea: just use last LABEL, $value:
last LABEL = $value
or
last = $value
(last, $value seems like it wouldn't be terribly useful otherwise,
right?)
Oh yeah. do BLOCK is still a third kind, which is transparent to all
control constructs.
What am I missing?
Re: $a in @b (RFC 199)
Steve Fink wrote:
So, why not get rid of the specialness? Why can't all blocks return
their last value?
Then we would have sub BLOCKs and loop BLOCKs. 'return' would escape the
nearest enclosing sub BLOCK and return a value. last/redo/next would
escape/repeat/continue the enclosing BLOCK of any sort...
Oh yeah. do BLOCK is still a third kind, which is transparent to all
control constructs.
I think any block which currently can "return" a value by letting it
fall out the end should be able to return a value by using Creturn
explicitly. I can count how many times I've wanted to -- and thought
I should be able to -- do something like the following:
@x = map {
/:/ and return( $`, $' );
/,/ and return( $`, $' );
()
} @y;
O.k., ignore the stupidness of the example. Point is, I can't
return a value "early" from the loop.
--
John Porter
We're building the house of the future together.
reversable foreach ()?
I really like
(do something) if (something is TRUE);
as opposed to
if (something is TRUE) {do something}
Just personal taste I guess, but to me the former is a nice Perlism.
So what about
(do something) foreach (some list);
i.e.
print foreach (@l);
as opposed to
foreach (@l) {print}
Just a thought..
-E
_
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: reversable foreach ()?
Ed Mills wrote: So what about (do something) foreach (some list); Just a thought.. No, it's not just a thought. % perl56 -e 'print "Item $_\n" for qw( foo bar quux )' Item foo Item bar Item quux But you're thinking along the right lines! -- John Porter
Re: reversable foreach ()?
On Tue, 12 Sep 2000 18:46:04 GMT, Ed Mills wrote: So what about (do something) foreach (some list); i.e. print foreach (@l); You really should try out one of the more recent Perls. http://www.perl.com/CPAN-local/doc/manual/html/pod/perldelta.html#C_EXPR_foreach_EXPR_is_supporte -- Bart.
Re: $a in @b
"Randal L. Schwartz" wrote:
how do you indicate with 'last' that you
want a false return, or a true return? This never comes up with a do
{} block, or a subroutine block, because while those are being
evaluated for a value, they don't respect last/next/redo.
if "last" means, return the most recently evaluated expression as
a return value and do not re-enter the block, the various semantics
can be created with a comma.
Your
request to have the grep block understand 'last' was the first block
in Perl history that would have simultaneously needed to exit early
*with* a value. And we hadn't come around that block yet. :)
We really need a clean way to distinguish those four cases:
"yes" and keep going
"no" and keep going
"yes" and abort after this one
($FirstSmall) = grep { $_ = 7 and last } @numbers; # already true
"no" and abort after this one
my $count;
# minor chicanery required to force short-circuit with false result
@Smalls_in_first_five =
grep { $count++ 5 ? ($_ = 7) : (0,last)} @numbers;
I see Clast in grep/map as implicitly setting a gatekeeping variable which
would prevent the remainder of the data from being evaluated. Since this is
known, evaluation of the remainder of the data can be safely optimised away.
Using the "gatekeeper" idea without Clast we get these:
"yes" and abort after this one
my $gatekeeper = 1;
($FirstSmall) = grep
{ $gatekeeper and $_ = 7 and ($gatekeeper = 0), 1 } @numbers;
"no" and abort after this one
my $count;
my $gk = 1;
@smalls_in_first_five = grep
{$gk and ($count++ 5 ? ($_ = 7) : $gk=0 )} @numbers;
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=' ~/nsmail/Inbox
Cmap in RFC 31
Damian Conway wrote:
:-)
I did consider that too, but the problem is that according to RFC 31 a
Cyield leaves the future entry point of a block at the next statement
after the Cyield, whereas the block needs to start from the beginning on
each iteration.
Damian
Have you considered adding a Cmap example to RFC 31? Yield would add
multiple output items per input item better IMO than the current practice
of accumulating a list of output items and returning it at the end.
%newhash = map {yield $_; transform $somehash{$_}} @keysubset;
isn't any better than
%newhash = map {($_,transform $somehash{$_})} @keysubset;
but you can certainly come up with a reasonable example. Listing inventories
by department, for instance. By yielding we would save the creation of the
per-iteration temporary and push directly onto the result.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=' ~/nsmail/Inbox
logical ops on arrays and hashes
I hate to bring this back up, but I'm designing bits of the internal api at the moment, so this is an issue. I'd like to have some sort of support for doing things like: @a = @b || @c; where @a is as big as the biggest of @b and @c, and for any individual entry, will be the value from @b if its true, and @c if its not. Unfortunately this has some short-circuiting issues and strong feelings abound, and I'd just as soon not stir that up again. I *still* want the feature though. Given that, would anyone object to the _binary_ operators being used instead? They don't have short-circuit semantics, and generally don't have any reasonable meanings for hashes and arrays. With that, instead of writing the above code, you'd write: @a = @b | @c; nothing short-circuits but then you don't expect it to, and that's more or less OK. The and operation would likely return the left-hand value if both are true, and xor would return whichever of the two were true, or undef of both (or neither) were true. For hashes, presumably we'd run through the keys of each hash, and missing keys would translate to false values. Objections, anyone? (I don't feel that strongly about it being a visible language feature, so if folks really dislike it I'll withdraw the suggestion and quietly slip the feature in anyway where nobody can see it... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Please take RFC 179 discussion to -data
[EMAIL PROTECTED] wrote: Could we please take discussion of 179 to -data? I think that's where it should be. K. Personnally, I don't see any objection to this. If everybody is ok, why not ? How should I process ? Submit again the proposal with a modified mailing-list email ? Gael, Yes. If you do this, I suggest you take the opportunity to fill out RFC 179 with more detail. In particular: - Why you think set operations should work on arrays rather than hashes - In what way the current Set:: modules are insufficient - Why set operations should be added to the core rather than a module That way the list will be able to understand the reasoning behind the RFC better.
RE: $a in @b (RFC 199)
From: Steve Fink [mailto:[EMAIL PROTECTED]]
Jarkko Hietaniemi wrote:
Allow me to repeat: instead of trying to shoehorn (or piledrive) new
semantics onto existing keywords/syntax, let's create something new.
The blocks of grep/map/... are special. They are not quite looping
blocks, they are not quite sub blocks, they are different. Well, to
be frank they are just very plain, ordinary, blocks that return
their last value, but if we want to introduce both flow control
So, why not get rid of the specialness? Why can't all blocks return
their last value?
Yes... why not?
The ones that currently do not return a value would
just be given void context. (Just because there's nowhere for
the value to go doesn't mean they can't return a value.) And if
that's done, then
$val = 1;
$fact = while ($n) { $val *= $n--; } || $val;
might not be a horrible idea either.
Then we would have sub BLOCKs and loop BLOCKs. 'return' would
escape the nearest enclosing sub BLOCK and return a value.
last/redo/next would escape/repeat/continue the enclosing BLOCK
of any sort, and would be extended to specify the value
returned. 'last $value' would be equivalent to 'return $value'
inside a subroutine unless it were enclosed in a loop BLOCK.
I agree... why can't a block be a block? Or put another way, instead of
trying to shoehorn in something new, why don't we take away something old
and treat all the blocks the same under Perl 6? I.e, make loop, bare, and
code blocks able to Creturn, Cyield, Cnext, Clast, and Credo? And
make all blocks that haven't been short-circuited to return their last
value...
That would unify bare and code blocks. They'd be like an iterative loop that
executes once and allows a return value.
But loop blocks are still different. When you use a loop control statement
(Cnext, Clast, or Credo) in a loop block, you don't short-circuit the
loop block, you short-circuit the loop statement.
Since blocks can have labels, how about giving built-in functions and
user-defined subroutines their own name as a magic or default label? I know
labels currently can't have package qualifiers. So perhaps this will
conflict with some interals issue. Or maybe it doesn't matter. In any case,
this will leave the programmer some freedom as to whether they are
short-circuiting the block, the loop, or the user-defined function.
Combine the unification of blocks with Tom Christiansen's suggestion which
maintains DWIMish syntax (and doesn't feel like a shoehorn to me at least):
return $true next;
return $false next;
return $true last;
return $false last;
return $true redo;
return $false redo;
Bonus: I no longer have to care about the difference between "code", "loop",
and "bare" blocks...
Here's an user-defined grep subroutine using the proposed changes:
sub mygrep (@) {
my ($block, @list, @results) = @_;
push @results, LOOP: $block and $_ foreach (@list);
@results
}
@list = (1,2,3,2,1);
@a = mygrep { $_ = 2 or last} @list;
@b = mygrep { $_ = 2 or last LOOP} @list;
@c = mygrep { $_ = 2 or last mygrep} @list;
@d = mygrep { $_ = 2 or return $_ last} @list;
@e = mygrep { $_ = 2 or return $_ last LOOP} @list;
@f = mygrep { $_ = 2 or return $_ last mygrep} @list;
Resulting I would hope in:
@a = (1 2 2 1)
@b = (1 2)
@c = [exception]
@d = (1 2 3 2 1)
@e = (1 2 3)
@f = (3)
Oh yeah. do BLOCK is still a third kind, which is transparent to all
control constructs.
The Cdo block is really more like special anonymous subroutine that takes
no arguments and is special in the sense that it is evaluated before the
loop condition of Cwhile and Cuntil. I have no idea why it is evaluated
before the loop condition... That seems un-DWIMish.
Garrett
Re: types that fail to suck
You talked about Good Typing at YAPC, but I missed it. There's a discussion of typing on perl6-language. Do you have notes or a redux of your talk available to inform this debate? http://www.plover.com/~mjd/perl/yak/typing/TABLE_OF_CONTENTS.html http://www.plover.com/~mjd/perl/yak/typing/typing.html Executive summary of the talk: 1. Type checking in C and Pascal sucks. 2. Just because static type checking is a failure in C and Pascal doesn't mean you have to give up on the idea. 3. Languages like ML have powerful compile-time type checking that is successful beyond the wildest imaginings of people who suffered from Pascal. 4. It is probably impossible to get static, ML-like type checking into Perl without altering it beyond recognition. 5. However, Perl does have some type checking mechanisms, and more are coming up. Maybe I should also mention that last week I had a dream in which I had a brilliant idea for adding strong compile-time type checking to Perl, but when I woke up I realized it wasn't going to work.
Re: Cmap in RFC 31
Have you considered adding a Cmap example to RFC 31? Yield would add
multiple output items per input item better IMO than the current practice
of accumulating a list of output items and returning it at the end.
%newhash = map {yield $_; transform $somehash{$_}} @keysubset;
I can see what you're attempting, and it's a cool idea. But your
semantics are a little screwy in the above example. What you want is:
%newhash = map {yield $_; transform($_)} %oldhash;
This flattens the %oldhash to a sequence of key/value pairs. Then the
first time the map block is called (i.e. on a key) it immediately
returns the key. The second time, it resumes after the Cyield and
transforms the value. That resets the block so that for the next
iteration (another key) it returns at once, then tranforms the second
value, etc., etc.
I'll definitely add *that* in to RFC 31.
Thanks
Damian
Re: types that fail to suck
Mark-Jason Dominus wrote:
Maybe I should also mention that last week I had a dream in which I
had a brilliant idea for adding strong compile-time type checking to
Perl, but when I woke up I realized it wasn't going to work.
What do you see as the major obstructions?
eval "" isn't too bad, because you can just forget about type inference
until after all use's and BEGIN{}'s have finished and you're about to
start the final run. Then you can allow any remaining eval""'s to trash
the inference.
Symbolic references are ok for user programs, because you can punt on
inference unless they use strict 'refs'. import() is much worse; you'd
need to alter Perl to either do those before the inferencer runs or make
a built-in Exporter that the typechecker is buddies with.
$class-$method may be survivable if you can infer the possible values
of $method most of the time.
Closures are tough, but they exist in many languages that people have
written inference engines for. You have to play some tricks to avoid
infinite loops in the inferencer.
Subroutine arguments cause trouble. They're a list, and most type
systems only allow a single type in lists. But if we use a list type
like (T1, T2, T3...) meaning the first element, if it exists, is of type
T1, the second of type T2, and the third and all remaining of type T3,
then we might be able to stem the precision hemorrhaging somewhat.
References scare me.
$b = 17; # $b(0) : integer
$b++; # $b(1) : number
$b .= "fish"; # $b(2) : string
$c{1000} = $b; # %c(0) : hash{integer - string}
$c{2000} = \%c;# %c(1) : hash{integer - string | integer -
ref(hash)} + %c is exposed
$c{$$}-{$b} = 42; # %c(2) : hash{nonref scalar - scalar?}
Tying is ok as long as it can be reduced to FETCH etc. calls.
When I get some time, I'm planning on prototyping a perl5 type
inferencer that handles the easy stuff and correctly punts on the harder
stuff. I should have it done by Christmas.
Christmas 2023 sounds about right.
Re: $a in @b (RFC 199)
"Garrett" == Garrett Goebel [EMAIL PROTECTED] writes:
Garrett I agree... why can't a block be a block? Or put another way, instead of
Garrett trying to shoehorn in something new, why don't we take away something old
Garrett and treat all the blocks the same under Perl 6?
You mean this would no longer work?
while () {
if ($some_condition) {
fred fred fred;
next;
}
barney barney barney;
}
Yup. Sure looks like a block to me. If "next" aborts only the "if"
block, but still executes barney barney, then it's now useless for
about 70% of my usage of "next".
Nope, I think we need a distinction between "looping" blocks and
"non-looping" blocks. And further, it still makes sense to
distinguish "blocks that return values" (like subroutines and map/grep
blocks) from either of those. But I'll need further time to process
your proposal to see the counterarguments now.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: logical ops on arrays and hashes
Dan Sugalski wrote: @a = @b | @c; nothing short-circuits but then you don't expect it to, and that's more or less OK. The and operation would likely return the left-hand value if both are true, and xor would return whichever of the two were true, or undef of both (or neither) were true. First, from a language pov, these can all be implemented on reduce. Second, I think 'and' should select the item vrom @c, not @b. -- John Porter We're building the house of the future together.
Re: logical ops on arrays and hashes
Dan Sugalski wrote: ...would anyone object to the _binary_ operators being used instead? They don't have short-circuit semantics, and generally don't have any reasonable meanings for hashes and arrays. With that, instead of writing the above code, you'd write: @a = @b | @c; nothing short-circuits but then you don't expect it to, and that's more or less OK. The and operation would likely return the left-hand value if both are true, and xor would return whichever of the two were true, or undef of both (or neither) were true. Of course they have reasonable meanings for arrays--element-wise operations (RFC 82): http://tmtowtdi.perl.org/rfc/82.html Any operation you can do on a scalar you should be able to do element-wise on a list, and certainly it's not hard to come up with situations where this is useful for non-short-circuiting bitwise operators. Bit vectors and associated masks may well be stored in lists, for instance. This discussion should probably be on -data, BTW.
Re: logical ops on arrays and hashes
Jeremy Howard wrote: Of course they have reasonable meanings for arrays--element-wise operations (RFC 82): http://tmtowtdi.perl.org/rfc/82.html Any operation you can do on a scalar you should be able to do element-wise on a list, and certainly it's not hard to come up with situations where this is useful for non-short-circuiting bitwise operators. Bit vectors and associated masks may well be stored in lists, for instance. This discussion should probably be on -data, BTW. Wouldn't it be very useful if all of the applicable polymorphic methods of RFC 159 would be overloadable for nD arrays (arrays becoming effectively instances of array objects)? I am not sure if this has been discussed before but I could think of a whole lot of applications. Often you might want to do just that with the suggested multidim arrays. Or is that already suggested in some other way? Christian
