> From: Chris Nandor [SMTP:[EMAIL PROTECTED]]
>
> At 11:22 -0400 2000.09.12, Adams, Johnnie W wrote:
>
>> Speaking strictly for myself, I think anyone who tries to
write a
> >>legally binding document without the help of a lawyer is a
> self-destructive
> >>fool, and I have the scar
Nathan Wiger <[EMAIL PROTECTED]> wrote:
> I'm writing a prototype for RFC 99, Standardize ALL Perl platforms on
> UNIX epoch, which does some simplistic manipulation of CORE::time to
> return the UNIX epoch on all platforms.
>
> My question is: Are there any system-specific epochs that Perl uses
>
At 9:32 -0400 2000.09.12, Ben Tilly wrote:
>His lawyers were fine with the fact that it gave them the
>freedom that they were looking for. They were not answering
>the question of whether it gave Larry anything related to
>what he apparently wants out of it.
You said lawyers do not find it accep
Chris Nandor wrote:
>
>At 7:39 -0400 2000.09.12, Ben Tilly wrote:
> >I proposed, and Tom Christiansen for one agreed, that the
> >point of allowing modifications that are made freely
> >available is that they are then available for Larry to
> >consider adding to the standard version. I don't thin
Chris Nandor wrote:
>
>At 9:27 -0400 2000.09.12, Ben Tilly wrote:
> >You are clearly not reading closely. My statement several times
> >now is that I don't care what you do if you don't call it perl,
> >and I have even given examples (oraperl and perlex) of people
> >who did exactly that.
>
>
At 10:59 -0400 2000.09.12, Ben Tilly wrote:
>Chris Nandor wrote:
>>
>>At 9:27 -0400 2000.09.12, Ben Tilly wrote:
>> >You are clearly not reading closely. My statement several times
>> >now is that I don't care what you do if you don't call it perl,
>> >and I have even given examples (oraperl and
At 8:32 -0400 2000.09.12, Ben Tilly wrote:
>>That's just silly. None of those issues were around when the BSD and MIT
>>licenses were penned. They are very simple licenses that most any
>>reasonable person could have written. None of them could cite chapter and
>>verse what the issues are that
Chris Nandor wrote:
>
>At 8:22 -0400 2000.09.12, Ben Tilly wrote:
> >>I was going to disagree, but then I just decided I don't know what this
> >>means. What I don't understand is this thing about incorporating
>changes
> >>into the Standard Version. Why does it matter?
> >
> >Because if you ar
Chris Nandor wrote:
>
>At 8:24 -0400 2000.09.12, Ben Tilly wrote:
> >>And we also have statements of fact that some lawyers do find it
> >>acceptable. If you had said "some," I would have agreed. But I took
>your
> >>lack of quantifying modifier to be a statement that all, or even most,
> >>law
At 9:27 -0400 2000.09.12, Ben Tilly wrote:
>You are clearly not reading closely. My statement several times
>now is that I don't care what you do if you don't call it perl,
>and I have even given examples (oraperl and perlex) of people
>who did exactly that.
print "I don't get it ...\n" if "p
Bradley M. Kuhn wrote:
>
>Ben Tilly wrote:
>
> > My statement several times now is that I don't care what you do if you
> > don't call it perl, and I have even given examples (oraperl and perlex)
>of
> > people who did exactly that.
>
> > The only concern is if you call it perl (embrace), it is
At 12:50 -0400 2000.09.12, Bradley M. Kuhn wrote:
>I think that Chris is saying that we should not ask a lawyer to develop
>a new license *for* us. If that is indeed what Chris means, I am in
>agreement with him. (If I have misunderstood you, Chris, please let me
>know.)
Nope, that's it.
>Wha
J. David Blackstone writes:
> I think the success criteria on http://dev.perl.org/pm/pos.html
> should be more measurable.
You're right. I was happy to have simply avoided "better" and "good",
the classic unmeasurable words :-) I kept "faster" and "easier", two
similarly unpinnable words, th
Um, with all due respect, Chris, I'm having a lot of trouble following
your reasoning. I currently work for a company that is in serious trouble
and may well go under; one of the contributing factors to that situation
may well have been that our senior management writes their own contracts
witho
At 12:44 -0700 2000.09.12, Dave Storrs wrote:
>Um, with all due respect, Chris, I'm having a lot of trouble following
>your reasoning. I currently work for a company that is in serious trouble
>and may well go under; one of the contributing factors to that situation
>may well have been that our s
J. David Blackstone writes:
> Wait. Does a good idea have to go away simply because the person
> who originally proposed it no longer has interest? What if several
> people are interested, but the original author has totally skipped out
> on Perl6 development, and the other interested people d
> 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 m
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 define
> Consider the problem of multiplying together two 2-dimensional tensors. In
> standard notation, this would be symbolized by
>
>Cijkl = Aij * Bkl
>
> where the letters i, j, k and l are written as subscripts and represent
> the indices of their respective tensors. To accomplish that same
Jeremy Howard wrote:
> To be honest, I don't really get the point of stuff like NumPy's "NewAxis",
> so I might be misunderstanding your proposal. But at least for your
It's just another way to specify how implicit loops of a scalar
operation are iterated over array elements (TIMTWTDI). Very mu
Jeremy Howard wrote:
>
>
>
> > 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 whol
Christian Soeller wrote:
> Jeremy Howard wrote:
> >
> >
> >
> > > 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
> > > discu
Maybe that's already implicit in the broadcasting proposal but it
wouldn't hurt to spell it out:
A dimension size of 1 should be broadcasted to match that of the
other operand. So, for example, the following shapes (returned by
@#array) are compatible:
@c = @a *
Christian Soeller wrote:
> Maybe that's already implicit in the broadcasting proposal but it
> wouldn't hurt to spell it out:
>
> A dimension size of 1 should be broadcasted to match that of the
> other operand. So, for example, the following shapes (returned by
> @#array) are compatible:
>
> > (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
I don't know what you mean, but you're mistaken, because it means to
interpolate @foo as in a double-quoted string.
Larry's going to release a draft of his langauge decisions on the 1st
of October.
My plan to prevent a flood of 100 new RFCs on September 30:
- deadline for new RFCs of Sep 25. After that, only discussion of
old ones.
- send mail to existing authors of "developing" RFCs telling them
t
On Tue, Sep 12, 2000 at 10:28:28PM -0600, Nathan Torkington wrote:
> Larry's going to release a draft of his langauge decisions on the 1st
> of October.
>
> My plan to prevent a flood of 100 new RFCs on September 30:
>
> - deadline for new RFCs of Sep 25. After that, only discussion of
>o
Michael G Schwern writes:
> There's a good chunk of people who are working on things for
> YAPC::Europe at the moment and Sept 25th happens to coincide with
> about when everyone will be staggering back. To avoid having to
> choose between spending the next week working on YAPC or working on
> Pe
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
The Artistic License Must Be Changed
=head1 VERSION
Maintainer: Bradley M. Kuhn <[EMAIL PROTECTED]>
Date: 12 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 211
Version: 1
Status: Developing
=
=head1 TITLE
new pragma: C
=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
Cnew>
is a pain in the bum to type. We should re
=head1 TITLE
C 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 syntax should simply be an
as
At 7:39 -0400 2000.09.12, Ben Tilly wrote:
>I proposed, and Tom Christiansen for one agreed, that the
>point of allowing modifications that are made freely
>available is that they are then available for Larry to
>consider adding to the standard version. I don't think that
>the current language ha
Chris Nandor wrote:
>
>At 10:41 -0600 2000.09.11, Tom Christiansen wrote:
> >I suggest that one explore the answer to this question:
> >
> >What does one wish to prohibit people from doing?
>
>That is an excellent question. Bradley Kuhn asked we hold off on more
>discussion until he can relea
Chris Nandor wrote:
>
>At 12:45 -0400 2000.09.11, Ben Tilly wrote:
> >Chris Nandor wrote:
> >>
> >>At 11:40 -0400 2000.09.11, Ben Tilly wrote:
> >> >1. Larry is in charge of Perl.
> >> >
> >> >2. Perl should be available under terms agreeable with the
> >> > above statement.
> >> >
> >> >Two add
Chris Nandor wrote:
>
>At 6:21 -0400 2000.09.12, Ben Tilly wrote:
> >I know some non-lawyers who could write a software license I
> >would trust. But I would not want to rely on a license
> >written by anyone who didn't not only know the above, but
> >who could not cite chapter and verse what tho
At 8:24 -0400 2000.09.12, Ben Tilly wrote:
>>And we also have statements of fact that some lawyers do find it
>>acceptable. If you had said "some," I would have agreed. But I took your
>>lack of quantifying modifier to be a statement that all, or even most,
>>lawyers find it unacceptable. I am
At 8:22 -0400 2000.09.12, Ben Tilly wrote:
>>I was going to disagree, but then I just decided I don't know what this
>>means. What I don't understand is this thing about incorporating changes
>>into the Standard Version. Why does it matter?
>
>Because if you are going to embrace and extend, I wa
Chris Nandor wrote:
>
>At 20:04 -0700 2000.09.11, Russ Allbery wrote:
> >Chris Nandor <[EMAIL PROTECTED]> writes:
> >
> >> But my point is that I don't want a laywer actually writing the
>license.
> >> I would rather he give his input and opinions, and then others do the
> >> writing. I am far m
At 6:21 -0400 2000.09.12, Ben Tilly wrote:
>I know some non-lawyers who could write a software license I
>would trust. But I would not want to rely on a license
>written by anyone who didn't not only know the above, but
>who could not cite chapter and verse what those issues are.
That's just sil
Chris Nandor wrote:
>
>At 12:22 -0400 2000.09.11, Ben Tilly wrote:
> >> >2. Freely Available is too vague. Is it freely available if
> >> > I release my changes in a form with a copyright notice
> >> > saying (like Sun does) that you need to submit all of your
> >> > changes to my changes b
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. T
For everyone's sanity, I think if Chris and Ben would answer the
following questions, I think we can have more streamlined discussion:
1. What is the objective of the AL?
2. Should we (perl-developer-community) involve lawyers in the
discussion about whether the present wording of AL meets the o
Ajit Deshpande wrote:
>For everyone's sanity, I think if Chris and Ben would answer the
>following questions, I think we can have more streamlined discussion:
>
>1. What is the objective of the AL?
To explicitly allow any use of the code-base for Perl that
is not apparently intended to detract fr
Adams, Johnnie W wrote:
> Well, yesterday, after Bradley M. Kuhn wrote:
>
> "I have been talking with Eben Moglen, a prominent law professor at
> Columbia University, and he is willing to help us in developing some
> proposed new versions of the Artistic License."
>
> yo
I would no more let a lawyer work on a software licensing question
than I would let a programmer work on the design of a software system for
lawyers--especially at the
beginning, when they might make an impact.
Get a grip--lawyers are just another tool. Like all tools, it
At 11:22 -0400 2000.09.12, Adams, Johnnie W wrote:
> Get a grip--lawyers are just another tool.
That is your opinion. And I disagree with it. I see lawyers as sometimes
nececssary evils who should be avoided whenever possible. I respect your
opinion, please respect mine.
> Speaki
At 10:48 -0400 2000.09.12, Ben Tilly wrote:
>>Please don't misrepresent Tom.
>>
>I am representing my understanding of what Tom said.
All Tom said is "I agree," basically. And what you said in that post
differs from what you said in the one I was responding to, because in the
former you were add
Ben Tilly wrote:
> My statement several times now is that I don't care what you do if you
> don't call it perl, and I have even given examples (oraperl and perlex) of
> people who did exactly that.
> The only concern is if you call it perl (embrace), it is not perl
> (extend), and your goal is
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data/Binary Dumping and Freezing
=head1 VERSION
Maintainer: John van Vlaanderen
Date: 12 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 210
Version: 1
Status: Developing
=head1 ABSTRACT
A
Perl6 RFC Librarian sent the following bits through the ether:
> Allow Perl to create serialize both data and code from the core.
Hmmm, would it be enough to emit and take in bytecode? Might there be
versions of Perl 6 which omit this functionality?
As well as binary code, a human-readable vers
=head1 TITLE
Data/Binary Dumping and Freezing
=head1 VERSION
Maintainer: John van Vlaanderen
Date: 12 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 210
Version: 1
Status: Developing
=head1 ABSTRACT
Allow Perl to create serialize both data and code from the core.
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 acros
Nathan Wiger wrote:
> 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 co
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
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
(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
On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
> That's fine for the VM and the support libraries, but I'd *really* like
> to see the parser/front-end in Perl. There are dozens of RFCs that require
> some non-trivial extensions to the parser. It would be nice to code these
> in Perl
Are
On Tue, 12 Sep 2000, Simon Cozens wrote:
> On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
> > That's fine for the VM and the support libraries, but I'd *really* like
> > to see the parser/front-end in Perl. There are dozens of RFCs that require
> > some non-trivial extensions to the par
On Tue, Sep 12, 2000 at 04:55:02PM -0400, Dan Sugalski wrote:
> > Are there any better reasons than "It would be nice?"
> It'd make things easier? (I'd rather write a parser in perl than C...)
You're going to have to do it some time, for bootstrapping. And now you need
an interpreter on hand at t
Dan Sugalski wrote:
> For something like:
>
>@foo = @bar || @baz;
>
> I have no problem with the call sequence looking like (pseudo-codish here):
>
> set_context(ARRAY, ASSIGN);
> foo->store(bar->log_or(bar, baz));
But log_or must short circuit -- I think we have to preserve that b
At 03:57 PM 9/12/00 +0100, Leon Brocard wrote:
>Perl6 RFC Librarian sent the following bits through the ether:
>
> > Allow Perl to create serialize both data and code from the core.
>
>Hmmm, would it be enough to emit and take in bytecode? Might there be
>versions of Perl 6 which omit this functio
Dan Sugalski wrote:
> As for the language we implement perl in (and thus ultimately need to
> translate to the compiler-target language), I'm thinking of something like
> Chip's PIL.
That's fine for the VM and the support libraries, but I'd *really* like
to see the parser/front-end in Perl. There
"ye, wei" wrote:
> Tom Christiansen wrote:
> > It [miniperl] isn't substantially smaller, so that does you no good.
The socket library seems to be the poster child for what to leave
out, but that's a weak argument. If Perl 6 gets all the functionality
requested by Damian or the PDL folks, it woul
> 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
> Have you considered adding a C 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{$_}} @keysubse
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 ba
2000-09-11-16:23:20 Dan Sugalski:
> At 03:16 PM 9/11/00 -0500, Jarkko Hietaniemi wrote:
> >On Mon, Sep 11, 2000 at 01:12:44PM -0700, Russ Allbery wrote:
> > > INN has been embedding Perl for years, quite successfully.
> >
> >There's embedding and there's embedding. Embedding in an UNIX server
> >
Bennett Todd <[EMAIL PROTECTED]> writes:
> I think the complaint about mod_perl's weight bears looking at, despite
> the success of the INN embedding. One invocation of INN is likely to do
> a sufficiently heroic amount of work that the weight and bulk of a perl
> in there may well not hurt a bit
Piers wrote:
> The behaviour of the 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
Chris Nandor <[EMAIL PROTECTED]> writes:
> That's just silly. None of those issues were around when the BSD and
> MIT licenses were penned. They are very simple licenses that most any
> reasonable person could have written.
I think it's pretty obvious from the wording of both of those licenses
Chris Nandor <[EMAIL PROTECTED]> writes:
> There is no need for a lawyer to compose the actual language. We are
> probably better off if a writer does. Lawyers are not well-versed, in
> general, in writing clearly.
Comments like the above worry me a lot. It's a perception of lawyers, of
the l
Chris Nandor <[EMAIL PROTECTED]> writes:
> At 1:16 -0700 2000.09.11, Russ Allbery wrote:
>> Public Domain is clear, but what does Freely Available really mean?
> That is defined already in the license.
> "Freely Available" means that no fee is charged for the item
> itself, though t
Chris Nandor <[EMAIL PROTECTED]> writes:
> The Package must ALWAYS be distributed under the same licensing terms as
> the original. Unless it is public domain or you are the copyright
> holder, you cannot change the licensing terms.
Not true, as far as I know. I believe that in general, you ca
Chris Nandor <[EMAIL PROTECTED]> writes:
> If you are going to contact the Copyright Holder under the provisions of
> sections 3d and 4d, it would only be in reference to the Package as a
> whole, for which the stated Copyright Holder has complete authority to
> rule. If you don't like it, you s
Nathan Torkington wrote:
> Larry's going to release a draft of his langauge decisions on the 1st
> of October.
>
> My plan to prevent a flood of 100 new RFCs on September 30:
>
> - deadline for new RFCs of Sep 25. After that, only discussion of
>old ones.
>
> - send mail to existing autho
hi,
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 t
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
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
> "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
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)
Jon Ericson wrote:
>
> Is a problem with writing these the other way around as well:
>
> @file = readline open(" print open(">>/var/log/logfile") "Hello, world!";
Currently - and by currently I mean that only RFC 14 was adopted and
everything else stayed the same - these would have to be wr
> "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?
Wou
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)
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 f
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 differen
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 enclosin
I wrote:
>
> I can count how many times I've wanted to -- and thought
s/can/can't/. :-o
--
John Porter
Damian Conway wrote:
> :-)
>
> I did consider that too, but the problem is that according to RFC 31 a
> C leaves the future entry point of a block at the next statement
> after the C, whereas the block needs to start from the beginning on
> each iteration.
>
> Damian
Have you considered addin
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 i
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
> [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-
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
>
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
[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,
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 sill
>> grep ITEM: { /^[1-9]/ || next ITEM } @list;
>Not much that I can see, but your next does not include any return value,
>so what should it be? Of course, if it's false, you didn't need a next in
>the first place and if it's true you didn't need a grep in the first place :-)
Doh! perha
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;
>
> noth
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 si
100 matches
Mail list logo
