Damian Conway <[EMAIL PROTECTED]> writes:
>> > It was Damian's, no?
>>
>> I bet he has a paper on it.
>
> http://www.csse.monash.edu.au/~damian/Perl/want.proposal
Ooh, I like that. I'm already frustrated with the current lvalue
setup, this would be a big improvement. Actually, I'd
On Thu, Aug 03, 2000 at 07:27:18PM -0700, Nathan Wiger wrote:
>> if (want 'hash') { return %hash } # rather than eq
>
>I like this alot.
Works for me.
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins
> if (want 'hash') { return %hash } # rather than eq
I like this alot.
-Nate
Versions, dear boy. Versions. Don't forget versions.
We will need them.
(This really belongs on -internals. Reply-to: adjusted)
And while were here, does anyone understand kpathsea? Would it be a
win. I think it would.
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> lexer saw a n
On Fri, Aug 04, 2000 at 05:24:43AM +1000, Damian Conway wrote:
> Tad pointed out:
>> I will RFCify this within the next few days (unless someone
>> can shoot it down right now).
>
> http://www.csse.monash.edu.au/~damian/Perl/want.proposal
I withdraw my threat of RFCification, and bow
Tad pointed out:
> Due to the recent "rename local()" and "can't return an array"
> discussions here, we should also consider "rename wantarray()"
> as well.
>
> It should be named wantlist(), because it does not tell you
> if it wants an array, it tells you whether you were ca
> > my $date = localtime;
>
> >And use $date->day (or month or year) later when you need to.
>
> But people *like* to be able to put things in simple variables.
> It's more convenient to type $day than $date->day for repeated usage.
Precisely. Hence my previous suggestion:
> > It was Damian's, no?
>
> I bet he has a paper on it.
http://www.csse.monash.edu.au/~damian/Perl/want.proposal
:-)
Damian
> >This reminds me -- once there was a proposal to extend the wantarray
> >functionality on p5p. Anyone remember? Anyone want to turn it into an
> >RFC?
>
> It was Damian's, no?
I certainly claim it and intend to RFC it.
I already have improvements to the previous proposal in min
On Thu, Aug 03, 2000 at 11:15:17AM -0400, Clayton Scott wrote:
> Why not context()?
Sure, that works too. Although for want(), I can see this instead:
if (want 'hash') { return %hash } # rather than eq
and that reads better than
if (context hash) { return %hash }
Hmm.
want = 'hash';
Jonathan Scott Duff wrote:
>
> On Thu, Aug 03, 2000 at 10:02:44AM -0400, Tad McClellan wrote:
> >
> > On Thu, Aug 03, 2000 at 10:53:02AM +0100, Hildo Biersma wrote:
> >
> > > If functions could distinguish between
> > > 'wantarray' and 'wanthahs' this would be easy to do.
> >
> >
> > Due to the r
On Thu, Aug 03, 2000 at 10:02:44AM -0400, Tad McClellan wrote:
> It should be named wantlist()
I actually think there is a need for a more generic replacement, say
want() or context()
Graham.
On Thu, Aug 03, 2000 at 09:02:12AM -0600, Tom Christiansen wrote:
> >> localtime->{'day', 'month', 'year'}
> >That's really scary and I like it a lot.
> That already has a meaning, thank you very much. :-(
Fair enough. "If it looks like it should be valid Perl, it probably is."
(or similar)
-
>On Thu, Aug 03, 2000 at 10:53:02AM +0100, Hildo Biersma wrote:
>> Ah, but we could make the language support this:
>>
>> localtime->{'day', 'month', 'year'}
>>
>> in hash-slice fashion.
>That's really scary and I like it a lot.
That already has a meaning, thank you very much. :-(
--tom
On Thu, Aug 03, 2000 at 10:02:44AM -0400, Tad McClellan wrote:
>
> On Thu, Aug 03, 2000 at 10:53:02AM +0100, Hildo Biersma wrote:
>
> > If functions could distinguish between
> > 'wantarray' and 'wanthahs' this would be easy to do.
>
>
> Due to the recent "rename local()" and "can't return an
On Thu, Aug 03, 2000 at 10:53:02AM +0100, Hildo Biersma wrote:
> If functions could distinguish between
> 'wantarray' and 'wanthahs' this would be easy to do.
Due to the recent "rename local()" and "can't return an array"
discussions here, we should also consider "rename wantarray()"
as well.
On Thu, Aug 03, 2000 at 10:53:02AM +0100, Hildo Biersma wrote:
> Ah, but we could make the language support this:
>
> localtime->{'day', 'month', 'year'}
>
> in hash-slice fashion.
That's really scary and I like it a lot.
--
"If you want to travel around the world and be invited to speak
On Thu, Aug 03, 2000 at 07:04:05AM -0600, Tom Christiansen wrote:
> >This reminds me -- once there was a proposal to extend the wantarray
> >functionality on p5p. Anyone remember? Anyone want to turn it into an
> >RFC?
>
> It was Damian's, no?
I bet he has a paper on it.
-- Johan
>This reminds me -- once there was a proposal to extend the wantarray
>functionality on p5p. Anyone remember? Anyone want to turn it into an
>RFC?
It was Damian's, no?
--tom
On Thu, Aug 03, 2000 at 10:53:02AM +0100, Hildo Biersma wrote:
> If functions could distinguish between
> 'wantarray' and 'wanthash' this would be easy to do.
This reminds me -- once there was a proposal to extend the wantarray
functionality on p5p. Anyone remember? Anyone want to turn it into a
On Thu, 3 Aug 2000, Tom Christiansen wrote:
> >I'd either leave that as (localtime)[3,4,5] (please read the man page for
> >Time::Object), or understand that there's absolutely no need to separate
> >off the variables like that in an object oriented interface:
>
> > my ($day, $month, $year) =
>I'd either leave that as (localtime)[3,4,5] (please read the man page for
>Time::Object), or understand that there's absolutely no need to separate
>off the variables like that in an object oriented interface:
> my ($day, $month, $year) = (localtime)[3,4,5];
>becomes:
> my $date = localtim
On Thu, 3 Aug 2000, Hildo Biersma wrote:
> >
> > I'd either leave that as (localtime)[3,4,5] (please read the man page for
> > Time::Object), or understand that there's absolutely no need to separate
> > off the variables like that in an object oriented interface:
>
> Ah, but we could make the
Matt Sergeant wrote:
>
> [I might join perl6-language some day, but until then, please CC me on all
> Time::Object related messages]
>
>
> On Wed, 2 Aug 2000 08:14:22 +0100 (BST), Matt Sergeant wrote:
>
> >I used to be a C programmer myself (well OK, I was a C++ programmer...),
> >but I'd rat
[I might join perl6-language some day, but until then, please CC me on all
Time::Object related messages]
On Wed, 2 Aug 2000 08:14:22 +0100 (BST), Matt Sergeant wrote:
>I used to be a C programmer myself (well OK, I was a C++ programmer...),
>but I'd rather any day type "localtime->year" than
At 11:30 AM 8/2/00 -0400, Chaim Frenkel wrote:
>Since perl6 will/should have a new Configure methodology[1] there
>could be a registry (hate that word) of all available function
>calls[2], developed during the build processes. Then the core would be
>able to infer a 'use' command.
Yes. What I'd l
Simon Cozens <[EMAIL PROTECTED]> writes:
>On Tue, Aug 01, 2000 at 09:39:28PM -0400, Dan Sugalski wrote:
>> I like perl's smart built-in IO just fine, thanks. :) Don't mind making it
>> better, but I do mind making it optional.
>
>If we're going to do line disciplines, we need a built-in stdio rep
On Wed, 2 Aug 2000 08:14:22 +0100 (BST), Matt Sergeant wrote:
>I used to be a C programmer myself (well OK, I was a C++ programmer...),
>but I'd rather any day type "localtime->year" than "(localtime)[5]".
And what would you type instead of
(localtime)[3, 4, 5]
? localtime->(day, mont
On Wed, Aug 02, 2000 at 09:41:06AM -0600, Tom Christiansen wrote:
> >> Well we should still have POSIX::localtime().
>
> >True, and hopefully in a more optimal form.
>
> Were you planning on updating the Standard? :-)
Sure, everything is up for grabs right :)
Actually I meant the way the POSI
>> Well we should still have POSIX::localtime().
>True, and hopefully in a more optimal form.
Were you planning on updating the Standard? :-)
--tom
On Wed, Aug 02, 2000 at 11:37:06AM -0400, Andy Dougherty wrote:
> On Wed, 2 Aug 2000, Chaim Frenkel wrote:
>
> > If it is decided (and I hope not) that localtime and its kin are verboten,
> > it should not exists _at all_ in Perl6 and any existance at all would be
> > only as a support module for
On Wed, 2 Aug 2000, Chaim Frenkel wrote:
> If it is decided (and I hope not) that localtime and its kin are verboten,
> it should not exists _at all_ in Perl6 and any existance at all would be
> only as a support module for Perl5 backward compatiblity.
Well we should still have POSIX::localtime
Since perl6 will/should have a new Configure methodology[1] there
could be a registry (hate that word) of all available function
calls[2], developed during the build processes. Then the core would be
able to infer a 'use' command.
[1] Where is the perl6-configure list? Did anyone request one?
[
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW> An existing Perl 5 script:
NW>my $date = localtime();
NW> Could generate something like
NW>"Function localtime() deprecated - use date() instead"
No, deprecations just as we are coming out of the gate. What goes in
is in for the
On Tue, 1 Aug 2000, Tom Christiansen wrote:
> >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> >sense) so Mac, VMS and Windows users feel less confused.
>
> Did it get decided that we were *supposed* to make Unix and C programmers
> feel more confused and less at home
Nat observed:
> Moving things to modules (a) does little for the size of Perl, and (b)
> promotes Pythonization of the language (i.e., all programs begin with
> 20 lines of `load this module, load that module, load the other
> module'). Your criteria for moving to a module can't simp
J. David Blackstone writes:
> Re: #1, above, I'd go so far as to suggest that nearly every system
> call in Perl (along with just about every punctuation variable) should
> find itself in a module and only in a module.
(nat as nat)
I'd like to suggest that Pascal is a language to *avoid* emula
On Tue, Aug 01, 2000 at 09:13:44PM -0500, J. David Blackstone wrote:
> Creating an all new function is a very good idea, I think. The
> whole function "localtime" should just plain go away.
Also remember that localtime() is intimately tied to gmtime(), and
timelocal(), timegm() of Time::Local.
At 12:24 PM 8/2/00 +0900, Simon Cozens wrote:
>On Tue, Aug 01, 2000 at 11:01:14PM -0400, Dan Sugalski wrote:
> > Right, I know the underside will be yanked and redone. (Hopefully with
> > async support on platforms that have it to do some I/O and processing
> > overlap) It's not getting removed fr
On Tue, Aug 01, 2000 at 11:01:14PM -0400, Dan Sugalski wrote:
> Right, I know the underside will be yanked and redone. (Hopefully with
> async support on platforms that have it to do some I/O and processing
> overlap) It's not getting removed from the core language from a perl
> programmer stan
At 11:04 AM 8/2/00 +0900, Simon Cozens wrote:
>On Tue, Aug 01, 2000 at 09:39:28PM -0400, Dan Sugalski wrote:
> > I like perl's smart built-in IO just fine, thanks. :) Don't mind making it
> > better, but I do mind making it optional.
>
>If we're going to do line disciplines, we need a built-in std
At 09:39 PM 8/1/00 -0400, Bryan C. Warnock wrote:
>On Tue, 01 Aug 2000, Tom Christiansen wrote:
> > >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> > >sense) so Mac, VMS and Windows users feel less confused.
> >
> > Did it get decided that we were *supposed* to make Un
On Tue, 01 Aug 2000, J. David Blackstone wrote:
> How about this: perhaps we should compile a list of system calls
> that _should_ remain in the core language. I think it will probably
> be very small.
I would suspect no more than the ones that perl needs internally for
itself, excluding, of
Nathan Wiger wrote:
>
> > C is, at times, less than logical. Witness the localtime fun: some of it's
> > zero-based, some of it's one-based, and some of it's -1900-based. All from the
> > same function. The localtime concept is needed, the localtime brain damage is
> > really not.
>
> I agree co
Dan Sugalski wrote:
> >Languages like C and
> >Pascal even go so far as to make I/O an "option" that you have to
> >#include (or whatever, depending on the language; Pascal makes you
> >specify it explicitly in some way I don't quite remember), and they
> >seem to do fine.
>
> For some pretty pat
On Tue, Aug 01, 2000 at 09:39:28PM -0400, Dan Sugalski wrote:
> I like perl's smart built-in IO just fine, thanks. :) Don't mind making it
> better, but I do mind making it optional.
If we're going to do line disciplines, we need a built-in stdio replacement.
Full ground-up rewrite, like sfio bu
> C is, at times, less than logical. Witness the localtime fun: some of it's
> zero-based, some of it's one-based, and some of it's -1900-based. All from the
> same function. The localtime concept is needed, the localtime brain damage is
> really not.
I agree completely. I take issue with changin
On Tue, 01 Aug 2000, Tom Christiansen wrote:
> >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> >sense) so Mac, VMS and Windows users feel less confused.
>
> Did it get decided that we were *supposed* to make Unix and C programmers
> feel more confused and less at home
At 05:51 PM 8/1/00 -0600, Tom Christiansen wrote:
> >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> >sense) so Mac, VMS and Windows users feel less confused.
>
>Did it get decided that we were *supposed* to make Unix and C programmers
>feel more confused and less at ho
At 06:59 PM 8/1/00 -0500, J. David Blackstone wrote:
> I'm presuming we can count on really fast methods to be one of the
>goals of the internals group. Perl is where I learned O-O
>(discovering wasn't just a useless buzzword), and I'd like to see
>Perl6 make O-O much more natural, without forc
Tom Christiansen wrote:
>
> >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> >sense) so Mac, VMS and Windows users feel less confused.
>
> Did it get decided that we were *supposed* to make Unix and C programmers
> feel more confused and less at home with Perl?
>
> -
Re: the Time::Object module, Tim Jenness wrote:
> Sounds good since:
>
> 1. It removes unnecesary core functionality to a loadable module
>
> 2. Can be retrofitted to perl5 code fairly easily (essentially as easy as
> exporting a backwards compatible localtime() function).
>
> 3. It no longer h
On Tue, 1 Aug 2000, Tom Christiansen wrote:
> >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> >sense) so Mac, VMS and Windows users feel less confused.
>
> Did it get decided that we were *supposed* to make Unix and C programmers
> feel more confused and less at home
On Tue, Aug 01, 2000 at 05:51:29PM -0600, Tom Christiansen wrote:
> >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> >sense) so Mac, VMS and Windows users feel less confused.
>
> Did it get decided that we were *supposed* to make Unix and C programmers
> feel more conf
>3. It no longer has a unix specific flavour (PS I am not anti-unix in any
>sense) so Mac, VMS and Windows users feel less confused.
Did it get decided that we were *supposed* to make Unix and C programmers
feel more confused and less at home with Perl?
--tom
On Tue, 1 Aug 2000, J. David Blackstone wrote:
> Moving from bootstrap to perl6-language ...
>
> In response to [EMAIL PROTECTED]'s requirements document, Hildo
> Biersma wrote:
> > In issue 3.2.1 (localtime), note that the month starting at 0 is very
> > useful for arrays - which is of the cour
Moving from bootstrap to perl6-language ...
In response to [EMAIL PROTECTED]'s requirements document, Hildo
Biersma wrote:
> In issue 3.2.1 (localtime), note that the month starting at 0 is very
> useful for arrays - which is of the course the reason it is done this
> way. I am not convinced goi
57 matches
Mail list logo
