Ask the usenet group comp.lang.perl.misc. This list is only for discussion
of the design of the upcoming Perl 6.
- Original Message -
From: "Phil Daws" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 17, 2001 1:54 AM
Subject: Berkeley Help
Hi:
I have a HASH file th
[EMAIL PROTECTED] wrote:
> > > @arr3 = @arr1[^i] + @arr2[^i] # also @arr[^i] = @arr1[^i] +
@arr2[^i]
> >
> > Hyper-operators do this just fine.
> >
> Oh yes they do. The point is that the ^i-loop way is better (more powerful
and simpler at the same time).
>
> Maybe the examples where not good en
Damian Conway wrote:
> @a ^+= reduce {$^a+$^b} @b;
What's this? Are positional args to HOFs now alphabetic rather than numeric?
cf. http://dev.perl.org/rfc/23.html#Positional_placeholders
Brent Dax wrote:
> Edwin Steiner:
> # Could there also be *hypo*-operators, i.e. operators which try to
> # *lower* (reduce) the dimensionality of their operands to the lowest
> # common dim. So
> #
> # $foo = 5 +^ (1,2);
> #
> # would set $foo to (5 + 1) + 2 <...>
> #
>
> I don't really see the u
Piers Cawley wrote:
> Damian Conway <[EMAIL PROTECTED]> writes:
>
> >> > my @images = qw( pic1 pic2 pic3) ^_ ('.jpg');
> >>
> >> Doesn't that clash with the default currying argument?
> >
> > No. The DCA is: $^_
>
> Duh. I brought this up at the London.pm meeting when Simon previewed
>
Erik Lechak wrote:
> 2) RFC 082: Arrays: Apply operators element-wise in a list context
> (hyper operators)
> and
> 3) Special variable representing index of array in foreach structure
> "$#" maybe (not in apocolypse3, I think)
>
Hi Eric. Thanks for your comments. Unfortunately it's a little ear
Michael G Schwern wrote:
> Binary and unary dot:
>
> This makes me *very* happy. This is probably the best thing I've
> heard all day.
>
Seconded.
> I've been playing with Ruby, which has a similar feature. @foo is an
> object instance variable. Inside a class definition, foo() is a
> object m
> Imagine:
>
> @strings ^=~ s/pattern/replacement/;
>
> @refs = ^\ @list;
>
> @objects^.method();
>
> @values^++;
>
Both text-processing and number-crunching examples are here:
http://dev.perl.org/rfc/82.html#EXAMPLES
Adding the '^' before each operator is left as an exercise for the reade
Damian Conway wrote:
>> But... earlier messages from
>> Larry suggested that the hyper-operator symbol would actually be an
adverb
>> (back then ':' was being proposed, IIRC), which sounded even more
>> exciting... Is this still the plan, with more to come in later
apocolypses
>
I haven't seen it mentioned here yet, so for those who haven't noticed A3 is
now out:
http://www.perl.com/pub/a/2001/10/02/apocalypse3.html
There's a lot to like here. I'll just cover 2 points for now though...
Larry's discussion of RFC 082, while not quite complete, does a great job of
learni
Uri Guttman wrote:
> > "BS" == Benjamin Stuhl <[EMAIL PROTECTED]> writes:
>
> >> Can anyone think of things I've forgotten? It's been a while since
> >> I've done numeric work.
>
> BS> ln, asinh, acosh, atanh2?
>
> dan mentioned log (base anything) but i don't recall ln. and definitely
>
Sam Tregar wrote:
> On Wed, 29 Aug 2001, Jeremy Howard wrote:
>
> > The answer used in .NET is to have a dispose() method (which is not a
> > special name--just an informal standard) that the class user calls
manually
> > to clean up resources. It's not an ideal solut
Hong Zhang wrote:
> Most of finalization is used to deal with external resource, such as open
> file, socket, window. You don't really want to depend on finalization,
> since it is very likely run out of default file descriptor limit before
> the finalization kicks in. The rule of thumb is to let
David L. Nicol <[EMAIL PROTECTED]> wrote:
> Yes, exactly. I would like to have a transpose operator, which
> will work on a list of hash refs, so this:
>
> $solids = [1..7];
> $stripes = [9..15];
> foreach (transpose($solids,$stripes));
> print "the $_->[0] ball is the same color as the $_->[1]\
"Sterin, Ilya" <[EMAIL PROTECTED]> wrote:
> Hmmm. Didn't think about that. That would be a nice way, that way you can
> manipulate it's behaviour depending with how many aliases you provide.
>
> for my $el1, $el2 ( (@foo, @bar) ) {
> print "$el\n"
> }
>
> $el1 and $el2 would of course be ali
"John Porter" wrote:
> Sterin, Ilya wrote:
> > Don't really know which would be more helpful, since I first need to
find a
> > scenerio where I would use this facility, then what result would I
expect
> > once the shortest list runs out.
>
> Let us ask the PDL folks.
>
> In fact, I'm quite sure th
"raptor" <[EMAIL PROTECTED]> wrote:
> but now I'm looking at these too...
> http://dev.perl.org/rfc/90.pod
> http://dev.perl.org/rfc/91.pod
> http://dev.perl.org/rfc/148.pod
>
> so may be what must be the order of passing the arguments and other stuff
> should be done via these proposed functions.
"raptor" <[EMAIL PROTECTED]> wrote:
<...>
> the idea of aliasing is to preserve the fast access and on the other side
to
> shorden the "accessor"(i.e the way to access the structure) and make code
> clearer.(mostly u can choose a name that has better meaning in your
context)
>
This reminds me... a
Michael Schwern wrote:
> mjd tricked me into reading his "Strong Typing Doesn't Have To Suck"
> talk, and now I'm looking at the typing proposals for Perl 6 and
> thinking... boy, its going to be almost as bad as C. That sucks.
>
> Is there hope? I dunno, but read the talk.
> http://perl.plover.
> What I was suggesting was to consider broadening what the
> $foo : bar style postfix sub syntax allows/assists bar to do,
> so that bars can be used to set properties OR do other stuff.
>
What's the practical utility of this? This discussion has been pretty
abstract so far... It's easy to see ho
Dan Sugalski wrote:
> At 09:40 PM 4/6/2001 +0100, Richard Proctor wrote:
> >On Fri 06 Apr, Dan Sugalski wrote:
> > > This is, I presume, in addition to any sort of inherent DWIMmery? I
don't
> > > see any reason that:
> > >
> > > @foo[1,2] = ;
> > >
> > > shouldn't read just two lines from tha
Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> DS> So unless we come up with something concrete, the goals are:
>
> DS> 1) A nebulous ~10% faster
> DS> 2) Faster in the things that annoy Dan the most
> DS> 3) Faster in the OO bits the folks upstairs from me u
Simon Cozens wrote:
> On Sun, Oct 08, 2000 at 01:12:13PM +0100, raptor wrote:
> > [ for in ]
> > Can this be done easly at the moment OR via some of the new proposals
?!!!?
>
> map { expression } sequence
>
See also RFC 81.
Dan Sugalski wrote:
> At 11:33 AM 10/1/00 -0700, Peter Scott wrote:
> >But, setting aside my visceral reaction to changing array bases, you have
> >precisely the same problem here that has scuppered my intent to file an
> >RFC for hashes with fixed keys; how do you apply the attribute to
> >anonym
> =head1 TITLE
>
> Open-ended slices
>
<...>
>
> @thingy = function()
> for (@thingy[3..$#thingy]) { ... }
>
> Horrible, isn't it? People want something better.
>
> I thought about it last year or so, and produced a couple of patches. It
> seemed then that the right syntax was not, for ins
Nathan Wiger wrote:
> Jeremy Howard wrote:
> >
> > Can we have an isnull() function then, please. Otherwise there's no
> > operation to test for nullness.
> >
> > PS: Nullness? Nullility?
>
<...>
>use tristate;
>$a = undef;
>
> =head1 TITLE
>
> Add 'tristate' pragma to allow undef to take on NULL semantics
>
<...>
>
> The C pragma allows for undef to take on the RDBMS concept of
> C, in particular:
>
>1. Any math or string operation between a NULL and any other
> value results in NULL
>
Any math or string or
Nathan Wiger wrote:
> Jeremy Howard wrote:
> >
> > Good question. I haven't tackled this in RFC 83, because it is a more
> > general question about attribute syntax. We don't really have a good
> > attribute syntax RFC yet, although Nate threw up some ideas
Greg Boug wrote:
> Apologies if these comments have already been noted...
>
> > my $PI : constant = 3.1415926;
> > my @FIB : constant = (1,1,2,3,5,8,13,21);
> > my %ENG_ERRORS : constant = (E_UNDEF=>'undefined',
E_FAILED=>'failed');
> >
> > Constants can be lexically or globally scoped (or a
Ed Mills wrote:
> These would be perlish, nice, terse, succint, and economical:
>
<...>
>
> ($i, $i, $k) += 2;
>
>@nums = 10 * @nums;
>
These are both covered by RFC 82.
> [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-
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
Gregory S Hayes wrote:
> Types just seem so very un-perl. There is much to be said for the
> universal scalar vairable. I'm not sure I fully understand just why we
> NEED types in the language. We have functions such as:
>
> my $integervalue = int($value);
>
> and...
>
> my $float = sprintf("%2.2f
Jonas Liljegren wrote:
> Does any other RFC give the equivalent to an 'in' operator?
>
>
> I have a couple of times noticed that beginners in programming want to
> write if( $a eq ($b or $c or $d)){...} and expects it to mean
> if( $a eq $b or $a eq $c or $a eq $d ){...}.
>
> I think it's a natura
Nathan Wiger wrote:
> Tom Christiansen wrote:
> >
> > Ever consider then having
> >
> > ($a, $b, $c) = ;
> > or
> > @a[4,1,5] = ;
> >
> > only read three lines? I mean, how many if any builtins would it
> > make sense to make aware of this, and do something "different"?
>
> Personally, I
Tom Hughes wrote:
> > For example, in Perl you have for a long time been able to do this:
> >
> >($one, $two) = grep /$pat/, @data;
> >
> > However, what currently happens is grep goes to completion, then
> > discards possibly huge amounts of data just to return the first two
> > matches. For
Michael G Schwern wrote:
> If pop @array, -1 == shift @array, 1 and shift @array, -1 == pop
> @array, 1, and if both Ways To Do It are almost exactly the same, then
> there's no value to allowing negative numbers. In most cases I'd
> expect passing a negative number to be a mistake on the program
Gael Pegliasco wrote:
> > First is the choice of arrays verses hashes as the choice for set
storage.
> > Arrays are obviously easier to construct, but hashes are both faster
> > implementations, and easier to determine membership.
>
> Well in fact I'm interested by such functions in order to manip
Buddha Buck wrote:
> At 05:35 PM 8/31/00 +, David L. Nicol wrote:
> >Buddha Buck wrote:
> > > > The array
> > > > syntax would also be useful in multi-dimensional arrays.
> > >
> > > That is if multi-dimensional arrays are implemented as lists-of-lists,
> > > which they might not be.
> >
> >Ev
Eric Roode wrote:
> >
> >Also the ability to traverse multiple lists at once
> >
> > for ($a,$b,$c) (zip(@a,@b,@c)) { ... }
>
> I don't get it. This is a great advantage over:
>@looparray = zip(@a,@b,@c);
>while ( ($a,$b,$c) = splice (@looparray, 0, 3))
> ?
>
Because splice() is destructi
[EMAIL PROTECTED] wrote:
> I think all discussion fo RFC 76 (reduce) should be on the new -data
> sublist. Jeremy, am I on track here?
>
You sure are. Any stuff related to data crunching features belongs over
there, please.
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].
&
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, "
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
>
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
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
> 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
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
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?
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,
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
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'
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 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
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
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
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
> >
> 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
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?' # :-)
>
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
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
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
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
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
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.
>
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.
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
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
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
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
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
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
> =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
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
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:
> > 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,
>
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
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
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:
> 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
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
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
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
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
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
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
>
>
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
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.
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)!
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).
>>
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
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
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
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..) {
>
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
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
> >
> > > 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?
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
>> 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
1 - 100 of 142 matches
Mail list logo
