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
the arc hyberbolics
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
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 solution but there doesn't seem
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]\n;
RFC 272
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.
PS. I
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.
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 how
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] = STDIN;
shouldn't read just two lines from that filehandle,
Michael G Schwern wrote:
Hmmm... an object which contains a method reference which contains a
referent to itself.
Yup. I don't know why some people think that circular references are complex
;-)
Something like this would be nice in a class that creates method
references--it would simply
Michael G Schwern wrote:
On Sun, Dec 17, 2000 at 12:11:01PM +1100, Jeremy Howard wrote:
Something to be careful of--it's easy to create a circular reference
when
using method pointers. As a result, neither the referrer nor referee
objects
are ever destroyed.
When using method
Michael G Schwern wrote:
package Class::MethRef;
use strict;
sub meth_ref {
my($proto, $method, @args) = @_;
return sub { $proto-$method(@args) };
}
So this...
my $meth_ref = $obj-meth_ref('foo', @some_stuff);
$meth_ref-();
is equivalent to this..
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 use
4. faster
Leon Brocard wrote:
Bradley M. Kuhn sent the following bits through the ether:
It should be noted that in Larry's speech on Friday, he said that he
wanted
to write the Lexer and Parser for Perl in some subset of Perl. :)
Is there a writeup somewhere for those who couldn't attend?
Hmmm,
Ilya Zakharevich wrote:
On Sun, Oct 01, 2000 at 08:51:04AM +1100, Jeremy Howard wrote:
Please no! Anything that makes it harder to write 'quick-and-dirty'
scripts
is never going to fly--this is part of what makes Perl special.
Why? I see no problem in making -Mstrict and -Wall
Karl Glazebrook wrote:
Ilya Zakharevich wrote:
On Thu, Sep 28, 2000 at 11:39:51AM -0400, Karl Glazebrook wrote:
so what is wrong with the statement '@y = 3*@x;' then ?
That other constructs *also* create an array context, in which the
behaviour of multiplication you propose is
In 2 and a bit days all RFCs must be frozen--those not frozen will be
auto-retracted by the librarian! So, could you please freeze your RFCs--the
following have some still outstanding:
Ilya Zakharevich [EMAIL PROTECTED] 8
David Nicol [EMAIL PROTECTED] 2
Buddha Buck [EMAIL PROTECTED] 1
Buddha Buck wrote:
The main problem I see are these:
@array = ([1,2],[3,4]); # 2-dimensional array, using LOL syntax
print $array[[1,1]]; # prints 4, OK
print $array[1]; # prints ?
print $array[[1,1,1]]; # prints ?
print $array[[1]]; # prints ?
According
=head1 TITLE
Add 'tristate' pragma to allow undef to take on NULL semantics
...
The Ctristate pragma allows for undef to take on the RDBMS concept of
CNULL, in particular:
1. Any math or string operation between a NULL and any other
value results in NULL
Any math or string or
Karl Glazebrook:
Well if a dimension has N elements then the numbering of the elements
runs 0...N-1
similarly if the shape has M dimensions, then the numbering of the
dimensions is 0..M-1
the arguments to reshape should be sizes not last elements (i.e. N's
not N-1's).
I think this is
[EMAIL PROTECTED] wrote:
Jeremy Howard wrote:
So where is mv(), you ask? If you use the 'reorder' syntax, but don't
specify all of the dimensions in the list ref, then the remaining
dimensions
are added in order:
That sounds good. I'd say why not also allow the mv syntax
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;
carp "\$a is null!" unless defined($a);
That way
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 a couple of
days
ago. Is someone interested
Karl Glazebrook wrote:
Jeremy Howard wrote:
BTW, I notice that you're using dimension numbering starting at 0 for
your
transpose() examples. Is everyone happy to start at 0 rather than 1?
OF COURSE!!
anything else would be WRONG
Well
Karl Glazebrook wrote:
Ilya Zakharevich wrote:
You are trading a frequently used shortcut @a == 1 + $#a for a
rarely-used-but-beautiful/intuitive semantic. I'm not sure it is a win.
It's now boiling down to a matter of opinion and we'll have to agree to
differ. Of course I use array
Ilya Zakharevich wrote:
Are you trying to convince me/us that is going to be used often?
Yes, I am. You made the unsupported statement that array operations are
rarely used. I'm suggesting otherwise (although to say that they're rarely
used in Perl 5 is a tautology, of course!).
Array
Ilya Zakharevich wrote:
Moveover,
$x = 3 * @_;
suddently being equivalent to
$x = @_;
does not look very promising...
Why are these equivalent? RFC 82 only applies in list context. Am I missing
something?
Karl Glazebrook wrote:
Ilya Zakharevich wrote:
f(3*@a)
would typically be a list context - and suddently instead of 3*(1+$#a)
you get Cmap 3*$_, @a.
This is true, what I would propose is we declare 3*(1+$#a) outmoded and
always have it mean Cmap 3*$_, @a in all contexts.
This
Karl Glazebrook wrote:
you should look at the PDL mv() and xchg() methods
and factor this into your thinking!
Actually, the RFC is based on PDL's xchg()! I forgot to document using
negative numbers to count from the last dimension--I'll add that into the
next version. Are there any other
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.
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 any other new
Michael G Schwern wrote:
On Mon, Sep 18, 2000 at 01:35:42AM -0400, Adam Turoff wrote:
Background: RFCs should be in development until frozen or retired.
Problem: Frozen RFCs are being updated.
Solution #4: Slip the RFC status back to 'developing'.
If someone updates a frozen RFC, its
Let's jump in. This RFC proposes a Creshape builtin with the following
syntax:
Err... this syntax isn't what I expected at all! I thought the first
argument would define the shape of the result, like NumPy or PDL...
When one array is passed in, it is split up. Here, the C$x and C$y
Ilya Zakharevich wrote:
On Sat, Sep 16, 2000 at 11:08:18AM +1100, Jeremy Howard wrote:
- How does it relate to RFC 204? Is it an alternative, or an addition?
204 cannot be implemented since it prohibits usage of overloaded
objects as array indices.
Why is it important for overloaded
Ilya Zakharevich wrote:
On Sat, Sep 16, 2000 at 07:15:34PM +1100, Jeremy Howard wrote:
Why is it important for overloaded objects to be used as array indices?
Overloaded objects should behave the same way as non-objects.
Why
does RFC 204 rule that out? RFC 204 simply specifies
=head1 TITLE
Data: Multi-dimensional arrays/hashes and slices
...
=item *
proposes a convenient syntax to slice multi-dimensional arrays;
=item *
proposes a convenient syntax create subobjects which behave as slices;
=item *
does it with as little overhead as possible.
=back
It
Adam Turoff wrote:
I didn't use Date::Parse, but I did look for all RFCs still stting
at v1 status. Since they're numbered chronologically, I cut off the
bottom (anything submitted after 9/7).
There are 100 RFCs in the list that follows. Code and data upon request.
Thanks Ziggy--very
Nathan Wiger wrote:
Jeremy Howard wrote:
RFC 203 defines a :bounds attribute that defines the maximum index of
each
dimension of an array. RFC 206 provides the syntax @#array which returns
these maximum indexes. For consistancy, the arguments to reshape()
should be
the maximum index
Perl6 RFC Librarian (aka Damian Conway) wrote:
This RFC (seriously) proposes Perl 6 provide Cany and Call operators,
and, thereby, conjunctive and disjunctive superpositional types.
Great to see this RFC'd--this will makes lots of data crunching code _way_
easier.
Now, I haven't quite
Nathan Wiger wrote:
Jeremy Howard wrote:
148: Change to Numeric Python semantics of reshape(), or write
counter-RFC
specifying these semantics (preferably renaming this RFC's 'reshape' to
something else)
There are a couple things that the NumPy one lacks that RFC 148
currently has
rather use a transpose() function for this that can transpose across a
given
axis.
You'll be RFC'ing that, I suppose? ;-) (But seriously, it sounds like a
good idea)
Yes, I will.
I don't think we need to define the ability to work on multiple lists as
special behaviour. Perl knows
Removed -language x-post
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
Christian Soeller wrote:
Jeremy Howard wrote:
Removed -language x-post
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
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:
@c
[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 ?
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
[EMAIL PROTECTED] wrote:
Reading through the examples left me wondering about some
technicalities:
@t[|i;|j] = @a[|j;|i]; # transpose 2-d @a
Written like this it would require that @a is exact 2-dim, i.e. it would
not just swap the first two dims of any n-dim array? I suppose if I'd
Christian Soeller wrote:
Jeremy Howard wrote:
However I like the Numeric Python reshape() semantics better:
http://starship.python.net/~da/numtut/array.html
Is that in any significant way different from PDL's reshape?
http://pdl.sourceforge.net/PDLdocs/Core.html#reshape
Buddha Buck wrote:
Reading through the examples left me wondering about some
technicalities:
@t[|i;|j] = @a[|j;|i]; # transpose 2-d @a
Written like this it would require that @a is exact 2-dim, i.e. it would
not just swap the first two dims of any n-dim array? I suppose if I'd
Buddha Buck wrote:
At 12:00 AM 9/12/00 +1100, Jeremy Howard wrote:
[EMAIL PROTECTED] wrote:
Reading through the examples left me wondering about some
technicalities:
@t[|i;|j] = @a[|j;|i]; # transpose 2-d @a
Written like this it would require that @a is exact 2-dim, i.e
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",
Removed RFC announce list x-posting
[EMAIL PROTECTED] wrote:
Perl6 RFC Librarian wrote:
The bounds of an array or list can be specified at run time, of course:
my int @t1 :bounds(@dimList) = getFromSomeplace();
Hm, I think some clarification would be good. I'd imagine three cases:
[EMAIL PROTECTED] wrote:
Perl6 RFC Librarian wrote:
This RFC proposes using @#array, analogous to $#array, to get the list
of
upper bounds for a multidimensional array @array. The length of @#array
would indicate the dimensionality of @array.
That's fine. This RFC does not seem to touch
Nathan Wiger wrote:
The only thing that *really* makes me nervous about the RFC is this
part:
@d = @b * @c; # Returns (2,8,18)
If the lists are not of equal length, an error is raised.
I really don't like the "error is raised" part, at least not by default.
Maybe "use strict
Matthew Wickline wrote:
(not on list, just tossing this in for discussion)
OK--we'll keep you cc'd in on this discussion.
RFC 90 (v3) wrote:
- Both Cmerge and demerge do not make
- a copy of the elements of their arguments;
- they simply create an alias to them:
-
1 @a = (1,3,5);
2
[EMAIL PROTECTED]
Nathan Wiger wrote:
This RFC proposes that operators in a list context should be applied
element-wise to the elements of their arguments:
@d = @b * @c; # Returns (2,8,18)
If the lists are not of equal length, an error is raised.
I've been watching
David L. Nicol wrote:
In order to work with lists of arbitary size, it is often necessary to
split a list into equal sized sub-lists. A Cpart function is proposed
that achieves this:
Are the sublists copies or aliases? I imagine they are aliases,
but this could be specified in the RFC
: Jeremy Howard [EMAIL PROTECTED]
Created: 3 September 2000
Status: Developing
Last modified: 3 September 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: ?
=head1 ABSTRACT
Adding multidimensional array syntax to Perl 6 requires a large number of
separate but highly connected language
Moved to perl6-language-data from PDL Porters
[EMAIL PROTECTED] wrote:
Jeremy Howard wrote:
quote
C; is particularly useful for creating slices of multidimensional
arrays:
my int @array = ([1,2,3],
[4,5,6],
[7,8,9]);
@col2 = @array[(0..2
Moved to perl6-language-data from PDL Porters
Robin Williams wrote:
"Jeremy Howard" writes:-
The first version of this
RFC had a
@start..$end:gen
but it just seems too dangerous, so I removed it. I'm still willing to
be
convinced though...
as well as @start..gen:
Nathan Wiger wrote:
Tom Christiansen wrote:
Ever consider then having
($a, $b, $c) = FH;
or
@a[4,1,5] = FH;
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 think this would
Karl Glazebrook wrote:
Can we not keep calling them matrices? They are just a special
case.
Normally I call them tensors, but this is only meaningful to a mathematics
audience.
I was using 'matrix' because both laypersons and mathematicians would know
what the RFCs are referring to. This
Karl Glazebrook wrote:
I would rather see one largeish RFC integrating all these. More RFCs
are not necessarily better.
The -language WG chair has requested that each RFC contain just one key
proposal, and that multiple related RFCs be drawn together with an overview
RFC.
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 manipulate
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
Baris wrote:
We're talking about how we'll write Perl 6 programs, not PDL programs. We
need to ensure that the syntax we create is Perlish.
Aggreed.
But there is nothing wrong with making the syntax user friendly, or am I
totally missing what perl is?
Perl is user-friendly to Perl users.
Baris wrote:
Looping through the matrix elements is probably most common thing people
do
in matrix computation. And because of some weird reason I am not aware of,
the only way to do this efficiently is to write your program in C. So
everybody I know sooner or later switches to C because of
Buddha Buck wrote:
If I'm stepping on toes here, please tell me...
See my other message today for the RFCs I'm thinking of writing. Buddha--you
and I should probably sought out offline which of us will write what RFC.
RFC 169v2: Matrix Indexing
Cover my $matrix[$x;$y;$z] syntax
Add
Christian Soeller wrote:
No, at least 18. One more piece of semantics that would be appreciated
is optional omission of trailing dimensions in slices, e.g. for a 3-dim
@a:
@a[0:1] == @a[0:1;] == @a[0:1;;]
I'd rather see the ';' be required, but the '(0..)' not be required, so you
could
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.
Even if they aren't
Christian Soeller wrote:
There might still be a need for something for those people who need FFTs
and work on really large blocks of data. The hope would be that a perl6
PDL would fill such a gap and be more perlish than it is now. But again
concrete syntax ideas are needed along with a clear
Baris wrote:
First of all I know that perl syntax has limitations and I understand why
the reasons of the new syntax proposals. And I think the syntax proposals
are pretty good if you accept the syntax limitations. I don't think any of
them do consider that if somebody will write a PDL
Buddha Buck wrote:
I think that once you have LOL's automagically padded to size, and that
size stored as an intrinsic part of the LOL, you no longer have a
traditional LOL. You have something that looks, walks, and quacks like
a matrix and doesn't walk or quack like an LOL. Why not call it
Buddha Buck wrote:
I'm willing to put this proposed compromise in RFC169v2 -- I like it,
too -- but I'm not willing to put $a[$i][$j][$k] as equivilant to
$a[[$i,$j,$k]] or $a[$i;$j;$k] into any RFC with me as the maintainer.
I welcome Jeremy writing an RFC that does that, though.
This
Christian Soeller wrote:
Jeremy Howard wrote:
14,17;...20,29). What if we created a new operator ';' that works within
a
list that creates a cartesian product?:
(10:20:2; 11:30:3); # Cartesian product of 10:20:2 and 11:30:3 as a
LOL
A possible approach. Two issues: (1) others
Christian Soeller wrote:
I think a combination of yours and Budda's proposal is actually very
nice:
@a[10:20:2; 11:30:3]; # ; implies cartesian product of indices
@a[10..20:2; 11..30:3]; # same with .. syntax
@a[[10,20,2],[@index], [0,0,0]] # comma-separated index refs means
we are after SIMPLE syntax. This means like C, Fortran, IDL and Matlab.
Perl is about working like most people expect.
Yes, we are after simple syntax. We also want to make to hard things
possible. Therefore we want a syntax that is also flexible.
To access a single element we want
Dan Sugalski wrote:
At 02:16 PM 8/30/00 -0400, Karl Glazebrook wrote:
subgroups should iron out there differences among themselves and come up
with a coherent set of proposals.
the final decision should not be in the hands of one person.
Someone ultimately has to make the in or out
Christian Soeller wrote:
Jeremy Howard wrote:
Basically, I want to be able to create a list ref of list refs, specify
a
data type (eg 'int') and attributes of ':compact' or ':sparse', and have
the
As Dan Sugalski suggested it seems not a good idea to bring in the list
of list ref
Christian Soeller wrote:
Jeremy Howard wrote:
Ditto. As I said yesterday, my current preferred option is that a list
ref
of list refs will also support a multidimensional indexing syntax.
Furthermore, if it has a single basic data type and is declared
':compact'
it should be stored
Karl Glazebrook wrote:
Dan Sugalski wrote:
On the other hand, just extending out arrays to be multidimensional may
well be good enough.
This is my view.
Ditto. As I said yesterday, my current preferred option is that a list ref
of list refs will also support a multidimensional indexing
Dan Sugalski wrote:
On Wed, 30 Aug 2000, Jeremy Howard wrote:
Furthermore, if it has a single basic data type and is declared
':compact'
it should be stored in a contiguous block of memory.
If you do a plain
my int @foo;
it'll end up with a contiguous block of memory anyway. :compact
Chaim Frenkel wrote:
Aren't RFC 90 (zip/unzip) and RFC 148 (reshape) really the same?
Yes. RFC 148 can also partition (RFC 91). I've updated RFC 91 to also allow
a 3rd argument that gives a step size--I haven't checked whether reshape()
can do this. The updated RFCs 90 and 91 don't seem to have
This post attempts to consolidate and summarise my proposals which I hope
provides a platform for n-dim matrices/tensors. I have repeated parts of
earlier posts to avoid confusion--sorry for the redundancy. I've also fixed
some areas from earlier posts--hopefully the examples here are correct and
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 destructive, the 1st
Removed perl6-announce x-post
Tom Christiansen wrote:
Hm I don't recall C++ ever thinking to overload the control-flow
operators ("", "||", "," (that is, comma), and "?:"). Why not?
Even if their "a b" should produce a more mundane 1 or 0, one
still might wish control.
'', '||', et
First of all, apologies for my lack of input over the last
week--unfortunately I went on holidays pretty much as this list went online,
so I've been pretty quiet. Anyhow, for those who don't know me, I'm the
chair of perl6-language-data. For the remainder of its existance I'll be
more active.
Buddha Buck wrote:
I think the better way is to take Buddha's idea (soon to be RFC'ed, by
the sounds of it), and make current arrays a little more flexible. It
sounds like we'll just have to add an extra dimension somehow, and then
"arrays of compact arrays" will simply be "arrays with
X-posted to [EMAIL PROTECTED]
David L. Nicol wrote:
If arrays as we know them implement by using a key space restricted to
integers, I think a reasonable way to get matrices would be to open
up their key space to lists of integers.
I've been thinking along exactly the same lines. There's a
Dan Sugalski wrote:
Plus I can see each being used more often if we extend it to be valid for
sparse arrays, or used more under the hood with iterators and lazy lists
and suchlike things. Each, when used on a sparse array, would presumably
return a list of offset/value pairs of valid entries
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].
sort { $_[0] = $_[1] } @list
is very ugly.
I
[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.
Ken Fox wrote:
Dave Storrs wrote:
On Thu, 17 Aug 2000, Jonathan Scott Duff wrote:
BTW, if we define Cwith 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, " ", ^lastname;
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 been amply
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
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" and
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 commitments,
internally, how to do it:
ASSIGNMENT, as in, Change-my-values-w/o-changing-my-type,
is in the vtable for the object.
When an object becomes constant, its ASSIGNMENT function gets
replaced with
$heres_what_it_gets_replaced_with=sub{
throw "ERROR-ASSIGNMENT-TO-CONSTANT"
};
or something
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
evaluates to
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?' # :-)
|
| my int @a: sparse;
| $a[1_000_000_000] = 'Y
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 history? (As
1 - 100 of 103 matches
Mail list logo
