On Tue, Aug 01, 2000 at 09:18:12PM +, Nick Ing-Simmons wrote:
>We need a quick glossary:
>
>perl core:
> perl.exe + perl.dll or .../bin/perl + libperl.so
>
>perl distribution
> anything from perl6.tar.gz
>
>Optional module
> things in CPAN
I've used the following terms:
Perl 6
Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
> perl.exe + perl.dll or .../bin/perl + libperl.so
RFC: Should the perl program be called differently (e.g., perl6) to
allow sites to run 5 and 6 in parallel until their migration is
completed (if ever)?
-- Johan
At 10:53 PM 8/1/00 -0400, Chaim Frenkel wrote:
>What do things that are moving out of the executable to auto loaded
>space be called?
>
> perl near core?
>
>"We've got insertion. Formats have entered near-core space..."
I've been thinking of 'em as "opcode wannabes", but I like yours bett
What do things that are moving out of the executable to auto loaded
space be called?
perl near core?
"We've got insertion. Formats have entered near-core space..."
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> I assume 'core perl engine' i.e. /usr/bin/perl or perl.e
> > I disagree with keeping the same name as a Unix function, but having a
> > radically different calling sequence or return value. If you want a
> > new interface, *name* a new interface.
>
> Amen!
Agreed, completely. I posted a follow-up under "Re: date interface" that
some might be interest
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
>
>LW> But yelling that formats are essential to the core reminds me of my
>LW> kids, who sometimes act as if they're being excoriated when we're
>LW> merely trying to get them out of their dirty clothe
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> But yelling that formats are essential to the core reminds me of my
LW> kids, who sometimes act as if they're being excoriated when we're
LW> merely trying to get them out of their dirty clothes and into some
LW> clean clothes. As humans w
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> Let me just add that I don't mind the brainstorming at all. To be a
LW> good language designer, you have to stuff your brain with what you
LW> *could* do before you can reasonably choose what you *will* do. At the
LW> moment, I'm not only
On Tue, Aug 01, 2000 at 01:17:25PM +1000, Damian Conway wrote:
> My (limited) understanding of the aims of Perl 6 were to start again with a
> clean slate and fix the things that are broken, or that could be designed
> better with hindsight. Backwards compatibily was to be fed to the lions.
>
>
Chaim Frenkel writes:
: > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
:
: DC> Only if you simultaneously remove Perl 5!
:
: DC> My (limited) understanding of the aims of Perl 6 were to start again with a
: DC> clean slate and fix the things that are broken, or that could be designed
:
Nathan Torkington writes:
: Damian Conway writes:
: > My (limited) understanding of the aims of Perl 6 were to start again with a
: > clean slate and fix the things that are broken, or that could be designed
: > better with hindsight. Backwards compatibily was to be fed to the lions.
:
: Larry's
> "RLS" == Randal L Schwartz <[EMAIL PROTECTED]> writes:
RLS> But yes, the manuals should be completely self-contained and not
RLS> require examining some C doc.
RLS> I disagree with keeping the same name as a Unix function, but having a
RLS> radically different calling sequence or return va
On Tue, Aug 01, 2000 at 06:31:45AM -0700, Randal L. Schwartz wrote:
>
> I disagree with keeping the same name as a Unix function, but having a
> radically different calling sequence or return value. If you want a
> new interface, *name* a new interface.
Amen!
Tim.
> "Tim" == Tim Jenness <[EMAIL PROTECTED]> writes:
Tim> Agreed. The localtime() docs suffer from a 'read the C manual' problem at
Tim> the moment
Well, as long as "deleting a file" is spelled u-n-l-i-n-k,
we might as well have the output of localtime() be consistent with
the C function o
On Mon, 31 Jul 2000, Bryan C. Warnock wrote:
> I don't think we're advocating its (their) complete demise, just the
> transition out of the core. (Which would, of course, still require a
> change to the scripts to 'use Format;'. Hmmm, perhaps all of
> formatting that is left in the core would b
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Only if you simultaneously remove Perl 5!
DC> My (limited) understanding of the aims of Perl 6 were to start again with a
DC> clean slate and fix the things that are broken, or that could be designed
DC> better with hindsight. Backward
On Mon, 31 Jul 2000, Matthew Persico wrote:
> Which leads me to the question:
>
> Where do we discuss where to install modules? The prime question being
> how do we keep modules installed for multiple versions of Perl? I
> haven't yet seen that discussion, but it is one I want to participate
> in
> "MP" == Matthew Persico <[EMAIL PROTECTED]> writes:
MP> The original format stuff HAS to be kept. Don't document it so as not to
MP> encourage its use. Play up Text::Autoformat::form if you wish, but there
MP> will be way too much breakage/too little updateage if hundreds of old
MP> web log
> TJ> The month and day indices should stay zero since they are array
> TJ> indices. The manual will reflect this.
>
> [rspier@localhost rspier]$ perl -wle 'print +(localtime)[3] '
> 31
>
> To what index do you refer?
>
> month days are currently 1 based.
>
> _consistency_ would be nice, C b
> Chuckle, chuckle. Gee I guess we need more voices like yours to remind
> us what the goal is. I guess it is all too easy for any one person to
> locate their one or two small pieces of Perl turf they don't want
> touched. Problem is, when you add up all those little pieces, you end u
Damian Conway wrote:
>
>> Of all the items up for change in Perl6, these two bother me the most.
>> Format less so than localtime, but I still worry about breakage.
>>
>> The original format stuff HAS to be kept. Don't document it so as not to
>> encourage its use. Play up Tex
TJ> The month and day indices should stay zero since they are array
TJ> indices. The manual will reflect this.
[rspier@localhost rspier]$ perl -wle 'print +(localtime)[3] '
31
To what index do you refer?
month days are currently 1 based.
_consistency_ would be nice, C be dammed.
I propose "c
Simon Cozens wrote:
>
> On Mon, Jul 31, 2000 at 11:14:34PM -0400, Matthew Persico wrote:
> > The original format stuff HAS to be kept. Don't document it so as not to
> > encourage its use.
>
> Deliberately leaving things undocumented? I'm sorry, you must have us
> confused with another language.
Damian Conway writes:
> My (limited) understanding of the aims of Perl 6 were to start again with a
> clean slate and fix the things that are broken, or that could be designed
> better with hindsight. Backwards compatibily was to be fed to the lions.
Larry's the one who will decide what goes int
> > Language
> > -> Unixcentrism
> > -> 1.PROBLEM: localtime's behaviour is non-intuitive for non-Unix people
> >
> > (I've always wondered is why it is 'non-intuitive'? If 0 == January is
> > a problem. What do they do to translate day-of-week? Is it Monday
> > based or Sunday based. Don
On Mon, Jul 31, 2000 at 11:14:34PM -0400, Matthew Persico wrote:
> The original format stuff HAS to be kept. Don't document it so as not to
> encourage its use.
Deliberately leaving things undocumented? I'm sorry, you must have us
confused with another language.
--
Doubt is a pain too lonely to
On Mon, 31 Jul 2000, Matthew Persico wrote:
> The original format stuff HAS to be kept. Don't document it so as not to
> encourage its use. Play up Text::Autoformat::form if you wish, but there
> will be way too much breakage/too little updateage if hundreds of old
> web log scripts have to be ri
I was asked to repost this here. I didn't realize perl6-language was up
yet. My bad, sorry. :-)
-Nate
Original Message
Subject: Re: perl 6 requirements
Date: Mon, 31 Jul 2000 19:57:42 -0700
From: Nathan Wiger <[EMAIL PROTECTED]>
To: Chaim Frenkel <[EMAIL PROTECTED]>
CC: [EMAIL
> Of all the items up for change in Perl6, these two bother me the most.
> Format less so than localtime, but I still worry about breakage.
>
> The original format stuff HAS to be kept. Don't document it so as not to
> encourage its use. Play up Text::Autoformat::form if you wish,
"Bryan C. Warnock" wrote:
>
> On Mon, 31 Jul 2000, [EMAIL PROTECTED] wrote:
>
> > How about a Format module that works pretty much exactly the same way
> > but isn't actually in the Perl core?
> >
>
> One of the original suggestions, I believe. In this case, because
> other stuff *does* exist,
On Mon, 31 Jul 2000, [EMAIL PROTECTED] wrote:
> How about a Format module that works pretty much exactly the same way
> but isn't actually in the Perl core?
>
One of the original suggestions, I believe. In this case, because
other stuff *does* exist, the Format.pm mod should just attempt (to t
> >Unless you replace it with something better. (Postscript or TeX or ...)
> >You'll have a hard time finding something that makes life so easy.
>
> How about a Format module that works pretty much exactly the same way
> but isn't actually in the Perl core?
I have a paper on that
At 12:27 PM 8/1/00 +1000, [EMAIL PROTECTED] wrote:
>[ moved to perl6-language ]
>
>On Mon, Jul 31, 2000 at 02:40:20PM -0400, Chaim Frenkel wrote:
> >Unless you replace it with something better. (Postscript or TeX or ...)
> >You'll have a hard time finding something that makes life so easy.
>
>How
[ moved to perl6-language ]
On Mon, Jul 31, 2000 at 02:40:20PM -0400, Chaim Frenkel wrote:
>Language
> -> Obsolete Features
> -> 1. Formats are not commonly used
>
>I'm sorry where did this come from. I use formats regularly and quite
>usefully.
>
>I suspect that those folks that have
34 matches
Mail list logo
