it would make numeric programming fun again.
--
Jeremy Howard
[EMAIL PROTECTED]
> At 09:38 AM 8/2/00 +1000, Jeremy Howard wrote:
> >Dan Sugalski wrote:
> > > I've been thinking that it'd be nice to support extended array/list
stuff
> > > to allow the rudiments of matrix operations into perl:
> > >
> > > @foo = @bar x
people feel about compatibility through pragmas? When
we talk about the 80% hurdle for compatibility, could this be only if a 'use
perl5' or similar pragma were used (which would enable things like dynamic
scoping)?
--
Jeremy Howard
[EMAIL PROTECTED]
wei ye wrote:
> I'm interested in how OO Perl 6 will be.
> It's very hard to develop big project in a language without OO support,
> so I think OO should be a very important part of Perl6.
Perl 5 supports OO quite well. Read the docs by typing 'perldoc '
where is one of:
perlboot
Graham Barr said:
> ...
> So there probably should be an RFC to add iterators to the language and
> be avaliable from perl, not just C. But I have no idea how they
> should look etc.
>
More generally, I wonder whether there should be an RFC on the changes
required to make perl a more friendly envi
Martyn J. Pearce wrote:
> <...> what I would like to discuss adding to the language is
>
> 1) a means to signal an early exit to the iterator,
> 2) a means to tell we're at the end of a list without having to
> evaluate the list length as we start
> 3) a much more lightweight, and language built-i
Nathan Wiger said:
> > What lexical scope should $x be _implicitly_ declared in? Maybe, just
> > maybe, we need a my $x at the top to tell us it is outside the scope of
the
> > first reference. Otherwise we get three different lexical variables,
and an
> > undefined value warning at run time.
>
Bryan C.Warnock wrote:
> On Thu, 03 Aug 2000, Simon Cozens wrote:
> > On Thu, Aug 03, 2000 at 08:36:01PM -0700, Nathan Wiger wrote:
> > > > Keep default Perl free of constraints such as warnings and strict.
> > >
> > > I second this.
> >
> > I third this. Perl is not, nor do I believe it ever shou
> > BTW, I'd like to see a more lightweight currying mechanism too. The
> > challenge is to find a 'perlish' but not heavyweight approach...
>
> Ah, good. I assume that having established the challenge, you'll be
> rising to it? :-)
>
Yes of course. But I want to first of all see the following RF
Tom Christiansen said:
> >This doesn't fix the problem of:
> >{
> > $somevar = 0;
> > $someVar++; # oops, wrong case!
> >}
> >Forcing 'my' by default allows these errors to be caught.
>
> How so?
>
If the default is to force 'my' to create a lexical, rather than providing a
default lexical scope
Karl Glazebrook wrote:
> OK I will raise to the bait
>
> I think it's a bit unfair to say that PDL people have failed to 'bite',
> there was quite a bit of discussion on our list after your post. Also
> some concern about how much of perl6 is vapourware.
>
I do apologise, Karl. It turns out that I
> $check = sub (;) {
> @_==0 ? __ < 2 + __ * atan($pi/__) or die __
> : @_==1 ? $_[0] < 2 + __ * atan($pi/__) or die __
> : @_==2 ? $_[0] < 2 + $_[1] * atan($pi/__) or die __
> : @_==3 ? $_[0] < 2 + $_[1] * atan($pi/$_[1]) or die __
> : $_
> This RFC proposes that the right operand of a C<..> operator
> may be omitted in a list context, producing a lazily evaluated
> semi-finite list. It is further proposed that operations on
> such lists also be carried out lazily.
>
Why only the right operand? What's wrong with @a[..1]?
Of cours
Ken Fox wrote:
> And neither did you... ;) The last line should be:
> > : $_[0] < 2 + $_[1] * atan($pi/$_[2]) or die $_[3]
>
> That's why curried functions should automatically re-curry themselves
> instead of depending upon lazy programmers. ;)
>
But of course I only included thi
Damian Conway said:
> switch ( $x < __ ) {
>
> case 0 { print "negative" }
> case 1 { print "unity" }
> case any(2..9) { print "small" }
> case @list { print "in range" }
> }
>
Now _that's_ the coolest thing I've seen since, well, umm, this morning,
when I read the original RFC.
Damian, a lot of
> I haven't gotten my head around anything curried, except Indian food
> but it appears to be powerful, and a kind of like generic programming on
> the fly. I'd like to learn more: if someone would give a tutorial
> reference that would be helpful.
>
A quick description is here:
http://www.cs
Simon Cozens wrote:
> Right. You don't seem to be getting it, so I'm going to have to be harsh
here.
>
Are you sure? Is it possible that it's just that this isn't a side of
programming you've had need for or are familiar with yourself? TMTOWTDI, you
know, even if you're way is the best way.
> You
> I'd thought I try to summarize what has come up so far and see if we can
> find somebody who can write some RFCs.
>
Terrific--thanks!
Make sure you read the interesting RFCs from Damian Conway on related
issues:
> * Built-ins: min() and max() functions and acceptors
>
> * Built-ins: reduce() f
> This RFC proposes that the right operand of a C<..> operator
> may be omitted in a list context, producing a lazily evaluated
> semi-finite list. It is further proposed that operations on
> such lists also be carried out lazily.
>
OK, I've already requested that we allow omitting the left operan
> @u = [..];# @a contains the univeral set
> works just fine, so I can then say:
> @i = grep {$_=abs($_)} @u;# @i contains the integers
> # See higher-order function and multi-way comparison RFCs
> $s = sum (grep 0<__<=100 @i);
> print "The sum of the 1st 100 integers is: $s";
>
> It is proposed that Perl reserve the bareword C<__>
(underscore-underscore)
> as a "placeholder" for generating higher order functions more cleanly.
>
But what if I want to say:
@n = (0.2, 1, 3.5, 4);
@integersInN = grep __=abs(__) @n; # @intsInN is empty!
Instead I would need:
@integersI
> > Oops, a correction. [..] should mean 'the set of all integers'. _Not_
the
> > univeral set. So my code snippet should be:
> > @i = [..];# @i contains the integers
> > $s = sum (grep 0<__<=100 @i);
> > print "The sum of the 1st 100 integers is: $s";
> >
> > I still think it would be c
> Oops, a correction. [..] should mean 'the set of all integers'. _Not_ the
> univeral set. So my code snippet should be:
> @i = [..];# @i contains the integers
> $s = sum (grep 0<__<=100 @i);
> print "The sum of the 1st 100 integers is: $s";
>
Oh dear, another correction! I meant, of co
> > > * Built-ins: min() and max() functions and acceptors
> > >
> > > * Built-ins: reduce() function
> > >
> > > * Subroutines: lazy evaluation of argument lists
> > >
> > > * Superpositions: vector operations via superpositions
>
> Couldn't see those either. Could you refer to the actual RFC #s,
> Ariel Scolnicov wrote:
> Consider C. Clearly, this
> "should" generate the "list" C<(..0)>. But it doesn't! Here's what
> really happens: Perl says to itself "1 is not nonpositive, 2 is not
> nonpositive, 3 is not nonpositive, ..."; it B reaches the point
> where it starts saying "0 is nonpos
> For any result of grepping (1..) (with a predicate which always
> terminates, say), you can do this. If C is
> nonempty, then it has a first element; we can find this first element
> by running essentially this:
>
> for(my $n=1; ; $n++) {
> last if g($n)
> }
>
> Note that this eve
Ken Fox wrote:
> Jeremy Howard wrote:
> > (..-1) == map -__ (1..);
>
> That really confuses me. If the sequence (-4..-1) is (-4, -3,
> -2, -1) then I don't see how your semantics are consistent. I'll
> admit (reverse map -__ (1..)) is the same as (..-1) but rev
> Objects should have builtin string SCALAR method
>
Sorry if I'm just being dumb, but... don't we already have this by
overloading the stringifying operator q{''}? How is the proposed SCALAR
method different?
> (Note that I'm keeping the ':' notation, because then it's clear that
we're
> talking about a generation rule, not an upper bound). Now I write it like
> this, wouldn't it be nice if we could also say:
> (1..:f(__)) == apply(f(__), (1..); # But I digress!
>
Correction (sorry). This should be:
Damian Conway wrote:
> I think I opened a bigger can of worms than I intended :-)
Yes, sorry about the overload of email you must of got from me on this, this
morning ;-)
>
> As MJD as pointed out to me in private email, if we are serious
> about this feature, we probably want to go the whole hog
> I find the __ *really* hard to follow. I've been trying to keep up with
> this discussion, but it's really chewing me up.
>
> Since this is really something different (not a scalar, hash, etc), has
> any consideration been given to other variable names:
>
>^_
>&_ # kinda like this
> > Just as simply,
> >
> > - $foo is the variable 'foo'
> > - ^foo is the placeholder 'foo'
> > - $_ is the default variable
> > - ^_ is the default placeholder
>
> Yeah, I personally can read this much clearer. Peter also mentions that
> __ is hard to distinguish from _, unless they're right nex
> > New programmers should easily understand
>
> New? You're talking about "new" "easy" and "higher order functions"
> in the same sentence? ;)
>
This was intentional. (Err, yes, it was bait, basically...)
Higher order functions are harder for old [procedural] programmers than new
ones (IMHO). Ha
> Well, what's the different between the placeholder &foo and the sub
> &foo? That's the main reason why. Also, '&' already has a perfectly good
> meaning: binary AND with the function foo(). :) Not trying to be a
> smartass, but I think you understand what I'm trying to say.
Yes. '&' is misleadi
Ken Fox wrote:
> Actually I was wrong about ^ not working. The binary operator ^ is XOR.
> The unary "operator" ^ could be for curries.
>
Right. I though you were just worried about it looking confusing. I don't
think the parser will be bothered (at least, I can't think of anything
ambiguous so fa
Tim Bunce said:
> On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote:
> > <...>
> > That's a good summary of what we've been thinking. Here's another
> > article that talks about a lot of the things we *should* be thinking.
> > In fact, it's possible this article should be required readin
Ken Fox wrote:
> Jeremy Howard wrote:
> > Anyhoo, there's no reason why you can't have ^1, ^2, and so forth, _and_
> > allow named placeholders too. Although I don't see what this buys you.
>
> Argument ordering. We might be constrained by the caller as to what
> > Another win is in evaluation of lists constructed by generator
functions:
> > # ($start: f(__): $end) == ($start, f($start), f(f($start)), ...)
> > @powersOf2 = (1:__*2:); # (1, 2, 4, 8, ...)
> > @first10PowersOf2 = @powersOf2[0..9]; # Calculates 1st 10 powers of 2
> > # ...interesting
Ken Fox wrote:
> > $a = sum(@b*@c+@d)
>
> I'm not strong in math, but I do remember a bit about row and column
> vectors. Isn't @b*@c ambiguous? Shouldn't it normally be interpreted
> as a dot product, i.e. treat all vectors the same?
>
It depends on what perl6-language comes up with. Probably
Joshua N Pritikin wrote:
> <...>
> Also, you can specify a non-default step size:
>
> @pdl(1:9:2, 1:9:2); # (1,1) (3,1) (5,1) (7,1) (9,1) (1,3) (3,3) ...
>
> Although I'm not sure how frequently custom step sizes are used in PDL
> code...
>
More generally, we need to be able to specify:
- Sli
John Porter wrote:
> Has anyone suggested '*'? Since its use for typeglobs is (repsumably)
> going away, it's available (right?).
>
> It the "wildcard" mnemonic value is consistent with "placeholder".
>
Yes, it's been suggested, but we might be too late on that one--another RFC
suggests reserving
>> We could undo the ambiguity like so:
>>
>>/^{foo}/; # like ${foo} and @{foo} and %{foo}
>>
>> In fact, this seems built-in if we follow the same var conventions.
We
>> can make ^ bind to {} as tightly as we need.
>
> That would be the right solution. And of course
Damian Conway wrote:
>> And there's no argument about having anonymous, positional, and named
>> placeholders in the redraft...?
>
> There's *always* arguments! ;-)
>
Although arguments from the RFC author are generally more compelling ;-)
> Personally, if we have positional placeholders
> > > As for the regexp issue, just to clarify there's only one ambiguous
case
> > > we need to work out that I can see:
> > >
> > >/.*^foo/; # ok
> >
> >But: /.*^foo/m; #ambiguous
>
> Hold it. What does this mean? Is the whole regex gonna be turned into an
> anonymous sub, or what?
Ken Fox wrote:
> John Porter wrote:
> > Jeremy Howard wrote:
> > > Yes, they're not identical. What I mean of course is:
> > > (..-1) == reverse(map -__ (1..));
> >
> > WHAT? So the semantics of .. are magically different in the context
> >
Ted Ashton wrote:
> Thus it was written in the epistle of John Porter,
> > Ken Fox wrote:
> > >
> > > Both of those expressions are the infinite list (-infinity..-1). I
have
> > > no idea how to write that properly 'cause I'm not a math guy. These
> > > things aren't streams (infinite queues) -- t
Ted Ashton wrote:
> I understand very well the concern. I, for one, don't agree that having
> (1..) in the language implies that having (..-1) is possible (though it
does
> make sense to me that having (1..) and (..-1) would imply having (..)).
After
> all, if I were to write
>
> for (1..) {
>
Bart Lateur wrote:
> If you're talking about matrix manipulations, I should immediately hold
> you back. Perl arrays are pretty bad as is for representing matrices.
> Don't let anybody tell you otherwise: Perl data structures are
> one-dimensionaly by nature.
>
A lazily evaluated slicing operator
Bryan C.Warnock wrote:
> On Wed, 09 Aug 2000, Jeremy Howard wrote:
> > Of course, if the user wants to overload this behaviour, we should let
them.
> > In the multiplication example, however, I would have thought that 'x' is
a
> > more suitable inner product opera
In trying to write some algorithms using the proposed higher-order function
notation, I keep finding myself wanting to explicitly bracket parts of the
curried expression:
$sum_xy = sub {reduce ^last+^x*^y, zip($_[0], $_[1])};
Sure, in this case reduce() would probably be written such that its
Damian Conway wrote:
>> AS> Also, the RFC should specify that the function is always
evaluated in
>> AS> a scalar context (for things to make sense).
>>
>> Why? reduce should be able to reduce a set of matrices to a matrix.
Or
>> actually any aggregate (plural whatzit).
>>
John Porter wrote:
> Jeremy Howard wrote:
> > The reason that having (1..) implies having (..-1) is that if you allow
> > (1..), then this is a valid construct:
> >
> > @dot_dot_neg_one = reverse (map {-$_} (1..));
> >
> > which is identical to (..-1)!
Chaim Frenkel wrote:
> Okay, then for
>
> reduce &avg $identity, @list
>
> What should $identity be?
>
What's wrong with:
$average = reduce (^last+^this, @^list) / scalar @^list;
print $average->([1,3,5]); # Prints '3'
You don't need to explicitly add a '0' to the front of the summed list.
Peter Scott wrote:
> So I'm thinking:
>
> eval { ...
> } catch Exception::Foo {
>...
> } catch Exception::Bar, Exception::Baz {
>...
> } catch {
>... # everything else, but if this block is absent, uncaught exceptions
># head up the call stack
> } continue {
>... # Executed
Glenn Linderman wrote:
> Thanks for the clarification in your intentions, but isn't _any_ bareword
is
> converted to a string, unless it is in some particular context where a
bareword is
> meaningful (such as filehandle)? So that seems to be nothing unique to
=>. You
> could just as well say
>
>
Dan Sugalski wrote:
> The syntax is actually:
>
>my type $varname;
>
> This is in perl 5.6.0. Modifiers go as attributes after the colon:
>
> my Dog $spot : constant = new Dog;
>
Yes. But what about types and attributes within complex types?
- Constant refs vs refs to constants?
- Types o
Piers Cawley wrote:
> Graham Barr <[EMAIL PROTECTED]> writes:
> > On Fri, Aug 11, 2000 at 01:47:12PM +0100, Piers Cawley wrote:
> > > > /^_/
> > > >
> > > > What is that matching ?
> > >
> > > We've done this. It's matching a string that begins with '_'. Which is
> > > why, if you want to disamb
Chaim Frenkel wrote:
> A nice way of making a value read-only is lovely. And let it be a
> runtime error to modify it.
>
> The caller can easily do a &foo eval{$const_item} to remove the
> read-only attribute.
>
> Hmm, perhaps we should rename the attribute
> :read-only
>
Can't we make a value 'tr
Steve Simmons wrote:
> I really like the idea of constants in perl, but think the RFC should
> go a lot further. C/C++ has solved this problem; we should follow in
> their footsteps.
> <...>
I desparately _don't_ want to follow the horrible mess that is const in C++.
The enormous hassle in trying
Philip Newton wrote:
> Would it not be more natural to pass the *number* of lists to unzip,
> rather than the desired length? This way, unzip() would know to pick off
> elements two-at-a-time, three-at-a-time, etc., rather than having to go
> through the zipped list, count the elements, divide by
Buddha Buck wrote:
> Or... Let's say you had a 3x3 array implemented as follows:
>
> @array = ( a1, a2, a3,
> b1, b2, b3,
> c1, c2, c3 );
>
> unzip(3,@array) would return the columns.
> partition(3,@array) would return the rows.
>
Nice example! I think this better go
Nathan Wiger wrote:
> Let me make an observation, having done tons of matrix stuff: We're
> going to wind up with 200 functions, all of which essentially are doing
> special types of matrix operations.
>
> How about a matrix-like set of functions that interleaves and
> un-interleaves stuff however
Buddha Buck wrote:
> There has been some discussion recently about lazy-evaluated semi-infinite
> lists. The biggest point of disagreement is over lists of the form (..n)
> and (..), i.e., semi-infinite lists bounded from above and semi-infinite
> lists which are unbounded.
>
> I believe there ar
Jarkko Hietaniemi wrote:
> I simply can't get over the feeling that the proposed
> zip/unzip/partition functions are far too specialized/simple,
That's certainly a possibility. They are such common operations though, it
might be a win to build them in. With zip/unzip/partition and good array
slic
Nathan Wiger wrote:
> > With zip/unzip/partition
>
> I really gotta say, those functions *need* to be renamed, for a variety
> of reasons. First, they have well-established computer meanings
> (compression, disks). Second, "partition" is too long anyways.
>
> I've seen numerous emails from other p
Dan Sugalski writes:
> I don't mind if someone overrides the vtable functions for a variable of a
> built-in type--a standard declaration of:
>
> my $foo;
>
> is really shorthand for:
>
>my generic_scalar $foo;
>
> more or less. If a variable gets its vtable functions messed with, well,
>
Ariel Scolnicov wrote:
> Damian Conway <[EMAIL PROTECTED]> writes:
>
> > Just to point out that the standard CS term is "merge".
>
> `merge' produces a list of items from 2 (or more) lists of items;
> `zip' produces a list of pairs (or tuples) of items from 2 (or more)
> lists of items. So in a l
Nathan Wiger wrote:
> "David L. Nicol" wrote:
> >
> > These things sound like perfectly reasonable CPAN modules.
> > What's the block prevenenting their implementation w/in the
> > perl5 framework?
>
> Jeremy and I are working on a general purpose matrix/unmatrix function
> that may well be core-w
> =head1 TITLE
>
> Controllable Data Typing
>
> =head1 VERSION
>
> Maintainer: Syloke Soong <[EMAIL PROTECTED]>
> Mailing List: [EMAIL PROTECTED]
>
<...>
>
> Retain current flexibility of Perl liberal variables.
> Provide a new form of declaring variables:
>
> scope cast-type $varname:constrai
Jarkko Hietaniemi wrote:
> On Tue, Aug 15, 2000 at 11:31:50AM -0500, Adam Krolnik wrote:
> >
> >
> > Following the lead of the sort operator, it would be a little
> > simpler to see reduce expressions use $a and $b instead of
> > $_[0], $_[1].
>
> The $a and $b of the sort comparator were A Bad
Jonathan Scott Duff wrote:
> On Mon, Aug 14, 2000 at 06:28:23PM -0700, Nathan Wiger wrote:
> > Well, just to counter argue, I feel exactly the opposite way. I'd like
> > the keyword to be "constant" instead of "const". I've always thought
> > "const" was a needless save of 3 characters. Constants
John Porter wrote:
> iVAN Georgiev <[EMAIL PROTECTED]>:
> >
> > They behave similarly like &&, ||, and, or operator with one main
> > distinction they "backtrack" for example:
> >
> > { block1 } B { block2 };
>
> This would be a good use of the to-be-liberated => operator:
>
> { block1 } => { bl
Stephen P. Potter wrote:
> | If the list to be unzipped is not an exact multiple of the partition
size,
> | the final list references are not padded--their length is one less than
> | the list size. For example:
> |
> | @list = (1..7);
> | @unzipped_list2 = unzip(3, \@list); # ([1,4,7], [2,5
Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]>
whispered
> :
> | Here's a counter-proposal: throw out hashes as a separate internal
> | data type, and in its place define a set of operators which treat
> | (properly constructed) arrays as associat
Jarkko Hietaniemi wrote:
> On Wed, Aug 16, 2000 at 08:37:21AM +1000, Jeremy Howard wrote:
> > Stephen P. Potter wrote:
> > > Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]>
> > whispered
> > > :
> > > | Here's a coun
Nathan Torkington wrote:
> Jeremy Howard writes:
> > @result = @a || @b;
> >
> > Which applies '||' component-wise to elements of @a and @b, placing the
> > result in @result.
>
> *Ptui* That's not how *I* want || to behave on lists/arrays.
Mark Cogan wrote:
> At 05:47 PM 8/15/00 -0600, Nathan Torkington wrote:
> >Jeremy Howard writes:
> > > @result = @a || @b;
> > >
> > > Which applies '||' component-wise to elements of @a and @b, placing
the
> > > result in @result.
>
Dan Sugalski wrote:
> At 05:55 PM 8/15/00 -0500, Jarkko Hietaniemi wrote:
> > > > > No, neither proposal makes sense. Arrays can be stored compactly
and
> > > >
> > > > $a[1_000_000_000] = 'oh, really?' # :-)
> > > >
> > > my int @a: sparse;
> >
> >I see: you have a time machine and I don't. So
Nathan Torkington wrote:
> Your [Jeremy's] RFC says:
> > Currently, operators applied to lists in a list context behave
> > counter-intuitively:
>
> Counter-intuitively is different from consistently. Your title is
> misleading. Perl's ops *are* applied consistently: they consistently
> give the
Mark Cogan wrote:
> At 12:39 PM 8/16/00 +1000, Jeremy Howard wrote:
> >It seems obvious that @a should be the whole array @a, not the size of
the
> >array. If I want to check the size of @a, I should have to do so
explicitly,
> >with scalar or $#.
> >
> >This
Mark Cogan wrote:
> At 11:11 PM 8/15/00 -0400, Chaim Frenkel wrote:
> >You are missing the beauty of vector/matrix operations.
>
> No, I'm not; I'm opining that the vast majority of Perl users don't need
to
> do vector/matrix ops, and that they don't belong in the core.
>
The vast majority of Perl
raptor wrote:
> ]- I tried minimalistic approach as small as possible additions to the
Perl
> language, we get only the "backtrack" mechanism i.e. something that is
> harder or slower to be done outside of the perl core.
> The rest should be done outside . (I too want all in the core)
I don't
Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and "Jeremy Howard" <[EMAIL PROTECTED]>
whispered:
> | > > No, neither proposal makes sense. Arrays can be stored compactly and
> | >
> | > $a[1_000_000_000] = 'oh, really?' # :-)
>
Johan Vromans wrote:
> Damian Conway <[EMAIL PROTECTED]> writes:
>
> >> As I understand things:
> >>
> >> BLOCK1 andthen BLOCK2
> >>
> >> evaluates BLOCK1 and then if BLOCK1 evaluates to "true" evaluates
> >> BLOCK2. If BLOCK2 evaluates to "true" we're done. If BLOCK2
> >
Nathan Torkington wrote:
> Piers Cawley writes:
> > > > The $a and $b of the sort comparator were A Bad Idea to begin with.
> > >
> > > Ditto. Can we ditch these in Perl 6? Don't see why $_[0] and $_[1]
can't
> > > be used, or even a more standard $1 and $2. Either one makes it more
> > > obvious
Nathan Torkington wrote:
> Perl6 RFC Librarian writes:
> > It is proposed that in a list context, operators are applied
> > component-wise to their arguments. Furthermore, it is proposed that
> > this behaviour be extended to functions that do not provide a specific
> > list context.
>
> I don't m
Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and Perl6 RFC Librarian
<[EMAIL PROTECTED]>
> whispered:
> | =head1 TITLE
> |
> | Builtin: partition
> |
> | =head1 ABSTRACT
> |
> | It is proposed that a new function, C, be added to Perl.
> | C would return @list broken into
> | refe
Chaim Frenkel wrote:
> > "KH" == Kai Henningsen <[EMAIL PROTECTED]> writes:
>
> KH> Hashes and arrays, OTOH, really aren't different for people. The
concept
> KH> of an index needing to be a nonnegative number is a computer concept.
>
> I don't know about that. Good old PL/I had arbitrary rang
Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and "Jeremy Howard" <[EMAIL PROTECTED]>
whispered:
> | No. They are lazily evaluated and require special optimisations to allow
>
> I don't completely understand this whole lazy evaluation, so I'
David L. Nicol wrote:
> Yes, absolutely, about the semantics.
>
> About the syntax, how about just in a block behind %HASHNAME?
>
> (as long as it doesn't use $a and $b, of course )
> (or if the insta-sort thing needs "sort" written in and this doesn't)
>
> %record{
>
> $something_new = 3; # just
Damian Conway wrote:
> Suppose C were a built-in function with parameter list:
>
> sub with (\%; ^&) {...}
>
> That is, C takes an explicit hash and -- optionally -- a block, sub
ref,
> or higher order function.
> <...>
> If C is called with *both* a hash and a block/sub ref/h.o.f. as
> arguments,
James Mastros wrote:
> On Fri, Aug 18, 2000 at 08:46:17PM +0100, Richard Proctor wrote:
> > There is one significant area of perl that has very little attention
here
> > (other than one of my RFCs) that is regexs.
> >
> > Perl has very powerfull regexs - but what other features might be
desirable?
Nathan Wiger wrote:
> Damian Conway wrote:
> >
> > You're error is in assuming I have time *now*.
> >
> > With 30+ RFCs still to write, I've been seriously contemplating
> > just abandoning the Perl 6 effort, because added to the demands
> > of my full-time job, my O'Reilly and other tutorial comm
> Steve Fink writes:
> > And both those examples apply to the underpinnings. Ok, maybe I have an
> > unusually broad definition of the word "underpinnings". Think "anything
> > that can't be done with a pure perl module".
>
Say "anything that can't be done *fast*enough* with a pure perl module" an
Larry Wall wrote:
> Jarkko Hietaniemi writes:
> : > > (Yes, there is a small aesthetic edge in using $a vs $_[0], but I
still
> : > > consider the $ and $b to be warts.)
> : > >
> : > And anyhow, this will work just fine (see RFC 23):
> : >
> : > $sum = reduce ^a + ^b, @numbers;
> :
> : I have b
>
To: "Jarkko Hietaniemi" <[EMAIL PROTECTED]>; "Larry Wall" <[EMAIL PROTECTED]>; "Jeremy
Howard" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, August 19, 2000 3:22 PM
Subject: Re: RFC 76 (v1) Builtin: reduc
Damian Conway wrote:
>> Well, RFC 23 doesn't mention ^0, and has several examples starting
>> at ^1. And it draws the analogy between ^1, ^2, etc and $1, $2,
>> etc. I didn't make it up.
>
> My apologies. The examples you refer to are incorrect. They were added by
> a helper, but the
> On Tue, Aug 15, 2000 at 09:25:34AM -0700, Larry Wall wrote:
> > [EMAIL PROTECTED] writes:
> > : Yep. Or more generally "Standardize Perl on all platforms to one
> > : common time epoch" and reccommend the Unix epoch since it's so
> > : widespread. :-)
> >
> > Oh, gee, where's your sense of his
Ken Fox wrote:
> Dave Storrs wrote:
> > On Thu, 17 Aug 2000, Jonathan Scott Duff wrote:
> > > BTW, if we define C to map keys of a hash to named place holders
> > > in a curried expression, this might be a good thing:
> > >
> > > with %person {
> > > print "Howdy, ", ^firstname, "
Bart Lateur wrote:
> On Thu, 17 Aug 2000 07:44:03 +1000, Jeremy Howard wrote:
>
> >> $a and $b were done for speed: quicker to set up those global
> >> variables than to pass values through the stack.
>
> >The solution is to pass args in as $_[0] and $_[1].
&
1 - 100 of 142 matches
Mail list logo
