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.
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
=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
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
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
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
(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
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:
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
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
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
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,
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
[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,
"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
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
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.
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
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
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
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
--
"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
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
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
[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 ?
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,
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
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{$_}}
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,
"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
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
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
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
33 matches
Mail list logo
