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
At 03:37 PM 8/2/00 -0400, Chaim Frenkel wrote:
> > "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>
> >> Please explain what the utility of having unshared variables? I might
> >> as well just fork().
>
>TC> The only sane situation is to have safety by default. Things should not
>TC> be
> > 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
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> At 10:42 PM 8/1/00 -0400, Chaim Frenkel wrote:
>>> We may need that all variables are by default lexical.
>>>
>>> Without the explicit declaration of cross-thread visible variables, doing
>>>
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
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> Please explain what the utility of having unshared variables? I might
>> as well just fork().
TC> The only sane situation is to have safety by default. Things should not
TC> be shared unless you say they are.
Err, I understood his c
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
>Please explain what the utility of having unshared variables? I might
>as well just fork().
The only sane situation is to have safety by default. Things should not
be shared unless you say they are.
--tom
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 10:42 PM 8/1/00 -0400, Chaim Frenkel wrote:
>> We may need that all variables are by default lexical.
>>
>> Without the explicit declaration of cross-thread visible variables, doing
>> threading may well be difficult (on one's fingers
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
At 02:18 PM 8/2/00 +0100, Piers Cawley wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> > From a language perspective, I have a scheme to allow us to yank all the
> > cruft (sockets, shm, messages, localtime...) out into separate libraries,
> > yet pull them in on demand without needing a use.
>> 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
Dan Sugalski <[EMAIL PROTECTED]> writes:
> From a language perspective, I have a scheme to allow us to yank all the
> cruft (sockets, shm, messages, localtime...) out into separate libraries,
> yet pull them in on demand without needing a use.
a la dbmopen in perl5?
--
Piers
On Wed, Aug 02, 2000 at 11:25:52AM +0100, Tim Bunce wrote:
> On Wed, Aug 02, 2000 at 12:16:33AM -0400, Dan Sugalski wrote:
> >
> > I'd actually like to see some work on the shared memory and IPC stuff on
> > the language list--it'd be nice to have them in as mostly-primitives,
> > though in a m
On Wed, Aug 02, 2000 at 12:16:33AM -0400, Dan Sugalski wrote:
>
> I'd actually like to see some work on the shared memory and IPC stuff on
> the language list--it'd be nice to have them in as mostly-primitives,
> though in a more platform-neutral way.
"mostly-primitives" sounds like a fudge. L
On Tue, Aug 01, 2000 at 09:09:09PM -0500, J. David Blackstone wrote:
>
> I suppose the suggestion I made about stripping out every system
> call is more along the lines of the microperl idea.
>
> How about this: perhaps we should compile a list of system calls
> that _should_ remain in the c
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 01:02 PM 8/2/00 +0900, Simon Cozens wrote:
>On Tue, Aug 01, 2000 at 11:37:49PM -0400, Dan Sugalski wrote:
> > Right. That was my point. (The original poster wanted to pull IO out of
> the
> > core entirely)
>
>Ah. Barbarians-at-gates approach, then.
Damn straight. Dump the boiling oil! :)
>O
On Tue, Aug 01, 2000 at 11:37:49PM -0400, Dan Sugalski wrote:
> Right. That was my point. (The original poster wanted to pull IO out of the
> core entirely)
Ah. Barbarians-at-gates approach, then. On the other hand, there is
a lot of rubbish that *can* go out of core; I'd like to see core being
At 10:42 PM 8/1/00 -0400, Chaim Frenkel wrote:
>We may need that all variables are by default lexical.
>
>Without the explicit declaration of cross-thread visible variables, doing
>threading may well be difficult (on one's fingers)
The two things are orthogonal. Threading doesn't place any sort o
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
We may need that all variables are by default lexical.
Without the explicit declaration of cross-thread visible variables, doing
threading may well be difficult (on one's fingers)
> "PC" == Piers Cawley <[EMAIL PROTECTED]> writes:
>> * no need to declare variables: I think variables shoul
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
Edwin Steiner <[EMAIL PROTECTED]> writes:
> In my opinion Perl lacks (at least partially) some features which
> I consider important for scripting languages:
>
> * elimination of pointers (If I want to spend my time considering how
> many dereference operators to use I'll go for ***C++).
> I'm aw
>> > > Perl isn't a programming language - Perl's grammar is much more like
>> > > a natural language than a computer one.
>> >
>> > Well, $I wonder if anyone except @computers can find it natural to put a
>> > f... $dollar_sign in front of every $noun you use.
>>
>> Grammar != vocabulary.
>You'
Tom Christiansen schrieb:
[snip]
> "Seems" may be the operative term here. Feckless worship of the
> false idol of universal popularity will, in attempting to please
> everyone, be doomed to please no one. A less proselytist message
> would be much useful, perhaps one more along the lines of: "T
Simon Cozens schrieb:
>
> On Tue, Aug 01, 2000 at 01:13:17PM +0200, Edwin Steiner wrote:
> > > Perl isn't a programming language - Perl's grammar is much more like
> > > a natural language than a computer one.
> >
> > Well, $I wonder if anyone except @computers can find it natural to put a
> > f.
On Tue, Aug 01, 2000 at 01:13:17PM +0200, Edwin Steiner wrote:
> > Perl isn't a programming language - Perl's grammar is much more like
> > a natural language than a computer one.
>
> Well, $I wonder if anyone except @computers can find it natural to put a
> f... $dollar_sign in front of every $n
> Language
> Miscellaneous language issues
> item 1.
> Perl is not like other programming languages. Ilya used to say that
> Perl isn't a programming language - Perl's grammar is much more like
> a natural language than a computer one.
Well, $I wonder if anyone except @computers can find
77 matches
Mail list logo
