> 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 people saying the same thing. If
At 12:48 PM 8/13/00 +1000, Jeremy Howard wrote:
>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 o
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,
>
At 12:23 PM 8/12/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Yup. It's an issue for things that implement any non-standard semantics for
>: existing ops, especially if those ops are overridden at runtime so the
>: optimizer doesn't know. It's one thing to mess with tied variables, its
>:
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
On Fri, Aug 11, 2000 at 04:53:01PM -0500, Jarkko Hietaniemi wrote:
> On Fri, Aug 11, 2000 at 04:48:12PM -0500, David L. Nicol wrote:
> > It's a vast and contrived joke, right?
>
> If it is, someone has really gone into some trouble:
>
> http://www.cobolscript.com/samples.htm
Looks real to me, b
Philip Newton wrote:
>
> > $'bar = 'unchanging'; # klingon?
>
> Has there ever been an RFC discussing retention or deletion of this
> backwards-compatibility feature?
Yes. :) RFC71, which caused much grief to Damian: Now he will never be
able to port his new Klingon.pm to Perl 6.
$pkg'var! $d
> > Notice that the hours/mins are always padded but the rest isn't.
>
> I think you meant minutes/seconds.
Yep, oops. Thanks.
> if you're going to have an object interface, perhaps the constructor
> can take the strftime string for use as the default scalar output?
That's exactly what happen
On Fri, Aug 11, 2000 at 09:56:47AM -0700, Nathan Wiger wrote:
> > > Replace localtime() and gmtime() with date() and gmtdate()
> >
> > I think to be politically acceptable to all that should be utcdate()
>
> Me too. Actually, this was my first choice, believe it or not.
utcdate() is fine with m
On Thu, Aug 10, 2000 at 05:11:17PM +0100, Graham Barr wrote:
> I was more thinking of
>
> eval {
> # fragile code
> }
> else {# catch ALL exceptions
> switch ($@) {
> case __->isa('IO') { ... }
> c
Dan Sugalski writes:
: Yup. It's an issue for things that implement any non-standard semantics for
: existing ops, especially if those ops are overridden at runtime so the
: optimizer doesn't know. It's one thing to mess with tied variables, its
: another entirely to make + behave differently.
On Fri, 11 Aug 2000, Nathan Wiger wrote:
> To me, the real question is which date() should we use:
>
>$date = date $seconds_since_epoch; # uses time()
>$date = date $modified_julian_date; # non-Unix
>
> If we can make it work, the second one seems a lot more
> platform-independent. A
On Fri, 11 Aug 2000, Mike Pastore wrote:
> $'bar = 'unchanging'; # klingon?
Of course, this is impossible unless Perl6 (finally?) drops compatibility
with the old Perl4 package separator '. Now, $'bar eq $::bar, and package
D'oh is package D::oh.
Has there ever been an RFC discussing retention
> Since you didn't mention it in your references, you may want to
> check out RFC 92, Extensible Meta-Object Protocol -- Method Search
> at http://tmtowtdi.perl.org/rfc/92.pod
I saw it after I posted the RFC. Yes, this is exactly the kind
of support that we need in the core to allow us to do th
To nick some pits
On Fri, 11 Aug 2000, Nathan Wiger wrote:
> Here is the justification. As most people write dates, they write
> something like this:
>
>1/20/1976 2:34:02
>4/5/981 11:05:09
>
> Very few people I've met write dates like this habitually in the real
> world:
>
>01/
* Philip Newton ([EMAIL PROTECTED]) [13 Aug 2000 04:10]:
> On Fri, 11 Aug 2000, Nathan Wiger wrote:
> > Philip Newton wrote:
> > > So if we're now on 1-indexing, we'll see lots of @months = (undef, 'Jan',
> > > 'Feb') or qw(dummy Jan Feb)... oh well.
> >
> > Far better, use the new builtin object
On Fri, 11 Aug 2000, Nathan Wiger wrote:
> Philip Newton wrote:
> > So if we're now on 1-indexing, we'll see lots of @months = (undef, 'Jan',
> > 'Feb') or qw(dummy Jan Feb)... oh well.
>
> Far better, use the new builtin object methods:
>
>$d = date;
>print "today is ", $d->date('%A');
> Renaming is a good idea.
>
> But @ARGS has one disadvantage: it's a plural form.
You're right, but one problem is that @ARG is already a synonym for @_.
We'd either have to break this, or put the command-line args in a
top-level @_. While this would make stuff even more consistent, it would
br
> Still, your matrix/unmatrix idea is intruiging... I'd be interested to see
> this fleshed out further (particularly to n-dimensional tensors, which is
> where I find generic functions hard to specify)...
What the heck! I'll try to produce something on it this weekend. By
Monday for sure.
If an
I simply can't get over the feeling that the proposed
zip/unzip/partition functions are far too specialized/simple, and that
something more general-purpose in the order of pack/unpack (with the
transformation spec encoded in a template) for lists would be preferable.
When someone said that matrix/
I'm still saving the proposal for further digestion, but wanted
to get this out quickly:
> "Perl6" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
Perl6> The existing C keyword can be used to create new object instances
Perl6> of a given class.
There is no existing "new" keyword in Perl.
> "Perl6" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
Perl6> Perl should be modified so that if C<$ISA::Search> (or equivalent)
Do you mean "$YOUR_PACKAGE::ISA::Search"
which is in the package "YOUR_PACKAGE::ISA"?
This would be the first time (to my knowledge) that something would
be
Peter Scott wrote, in RFC 80 (v2):
>
> =item id
>
> Unique numeric identifier, assigned by perl developers.
I'm loath to bother everyone with this, but to me the id of an
object should be unique to each *instance* of the class. If we had
my $e = Exception->New(id => "ABC.1234");
my $f
Andy Wardley wrote:
>
> A key feature of this proposal is that object/class variable and
> methods are indistinguishable to the user. The dot operator does
> the right thing to call a method (if defined), or instead access a
> variable, or follow a delegation reference, etc. i.e.
>
> $foo.bar
Andy ~
Since you didn't mention it in your references, you may want to
check out RFC 92, Extensible Meta-Object Protocol -- Method Search
at http://tmtowtdi.perl.org/rfc/92.pod
RFC 92 considers an existing Perl 5 module we have that allows
us to write code like the following, and it considers ho
Sorry that read this later...
It is one step from matrix to create SQL syntax :")
if we have MATRIX operations what about adding a conditions to it.. i.e. :
@a = (1,2,3);
@b = (4,5,6);
@c = (7,8,9);
matrix x3, @a, @b, @c where x3 > 5;
( 1,2,3
4,5,6
7,8,9 );
x3 in where mean column 3 (?synta
what about (not zip() offcource :")):
@a = (1,2,3);
@b = (4,5,6);
@c = (7,8,9);
zip (how,@a,@b,@c);
i.e.
@list = zip (0,@a,@b,@c); #stright
result (1,2,3,4,5,6,7,8,9)
@list = zip (1,@a,@b,@c); #reverse
result (7,8,9,5,6,7,1,2,3)
@list = zip(2,@a,@b,@c); # all first elems, then all
Subject: RFC 90 (v1) Builtins: zip() and unzip()
I just don't like the name zip(), unzip() - shold be saved for something
that will really do commpression.
Variants : combine
I like merge too..
As of this it will be good if there some sort of compression internally
by the perl, say for the
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Exception objects and classes for builtins
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 9 Aug 2000
Last-Modified: 12 Aug 2000
Version: 2
Mailing List: [EMAI
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Deep Copying, aka, cloning around.
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last-Modified: 12 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
> Couldn't:
>my $u = User.new('abw', 'Andy Wardley', '[EMAIL PROTECTED]');
> just be
>my $u = User->new('abw', 'Andy Wardley', '[EMAIL PROTECTED]');
>
> And:
>$foo.bar.baz = 10;
> Just be:
>$foo::bar::baz = 10;
Yes, but the semantics change. A key feature of this proposal is tha
31 matches
Mail list logo
