Re: RFC 54 (v1) Operators: Polymorphic comparisons

[Bart Lateur]

On Tue, 08 Aug 2000 23:43:26 -0400, Ken Fox wrote:

>(assuming min() is polymorphic):
>
>  min($a, $b) eq $a
>
>Ugly, but minimal changes to the language.

We could adopt a syntax similar to sort():

$lowest  = min($x, $y, $z); # default: numerical (?)

$first = min { $a cmp $b } ($x, $y, $z);  # alphabetical

-- 
Bart.

Re: access to pod/doc text by code

[Bart Lateur]

On Tue, 08 Aug 2000 20:49:38 -0400, Matthew Persico wrote:

>pod2usage is the call I THINK you are refering to. Who cares if it is
>slow?

YA extension to perldoc?

-- 
Bart.

Re: RFC 65 (v1) Add change bar functionality to pod

[Hildo Biersma]

> =head1 DESCRIPTION
> 
> Making what's changed in documentation stand out's quite useful,
> something I'm coming to appreciate more and more as the RFCs are
> flying back and forth. The standard way to do this is to mark the
> changed sections with one or more vertical bars on the left margin.
> 
> Since changes can themselves be changed, multiple levels of change bar
> can occur. This mirrors the common practice in printed documentation.

I have a strong feeling this is a bad idea, because:
- Not everyone is interested in the changes
- Human authors are fallible, and it's easy to forget changebars
- We don't want the pods to grow indefinitely

Instead, it should be pretty trivial to write a tool that compares the
pods for the current and (any) previous version, generate the
changebars, then writes that out as a separate document - for those who
want it.  It may be desirable to include that with the default module
distribution, or we may want to make this a web-based CPAN resource, but
boy this should not clutter up every module out there.

Hildo

Re: RFC 23 (v2) Higher order functions

[Hildo Biersma]

> =head1 TITLE
> 
> Higher order functions

Sounds good.  We should add this to the language.  Oh boy, the tricks we
can play with this...

Hildo

Re: RFC 73 (v1) All Perl core functions should return ob

[Hildo Biersma]

> 
> =head1 TITLE
> 
> All Perl core functions should return objects
> 

Yuck.  Why not use the proposed want() and return hash-refs or slices,
when appropriate.

Hildo

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

[Piers Cawley]

Peter Scott <[EMAIL PROTECTED]> writes:

> At 09:28 AM 8/8/00 +0100, Piers Cawley wrote:
> >Peter Scott <[EMAIL PROTECTED]> writes:
> >
> > > At 12:07 AM 8/8/00 +0200, Bart Lateur wrote:
> > > >On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote:
> > > >
> > > > >I meant that BEGIN, END, and INIT aren't declared as subs at present but
> > > > >named blocks.  I was surprised to discover that they're put in the 
> > symbol
> > > > >table anyway though.
> > > >
> > > >Check the docs again. [snip]
> > > > Four special subroutines act as package constructors and
> > > > destructors. These are the `BEGIN', `CHECK', `INIT', and `END'
> > > > routines. The `sub' is optional for these routines.
> > >
> > > Drat.  I propose making it non-optional for 
> > P6.  ETOOMANYSPECIALCASES.  Any
> > > objections?
> >
> >But what happens if you want multiple BEGIN blocks?
> 
> Same as now:
> 
> $ perl -le 'sub BEGIN{print "one"} sub BEGIN{print "two"}'
> one
> two
> 
> It's a bit of a white lie to suggest that they're just plain ol' 
> subroutines, but at least we're getting closer to the truth.

Woohoo but that's butt ugly. I definitely vote for removing the 'sub
BEGIN {}' syntax rather than making 'BEGIN {}' become 'sub BEGIN {}'

-- 
Piers

Re: RFC 71 (v1) Legacy Perl $pkg'var should die

[Leon Brocard]

Damian Conway sent the following bits through the ether:

> If you take this, I won't be able to port the forthcoming Klingon.pm
> module to Perl 6!!!

D'oh! ;-)

Leon
-- 
Leon Brocard.http://www.astray.com/
yapc::Europe - September 22-24 London - http://yapc.org/Europe/

... Error 404: .signature generator ran out of tuits

Re: access to pod/doc text by code

[Piers Cawley]

Uri Guttman <[EMAIL PROTECTED]> writes:
> some people have mentioned help strings as special parts of a sub
> declaration like gnu lisp has. this could be more support for that type
> of thing. but i don't want it to be too strange.

Hmm...

   sub foo ($$;@) :lvalue
   "Documentation string here"
   {
   # meat
   }

You know, I'm not sure if that's ugly or beautiful. Of course, if it
did come into use there'd have to be some way for pod to get at the
docstrings, otherwise we'd end up with something like:

   =item foo ARG1, ARG2, [@ARRAY] 
   
   Documentation string here

   =cut

   sub foo ($$;@) :lvalue
   "Documentation string here too"
   {
# meat
   }

Which violates the 'never write stuff more than once' principle.

Err... I still haven't made up my mind about whether I like it though.

-- 
Piers

Re: RFC 23 (v2) Higher order functions

[Piers Cawley]

Peter Scott <[EMAIL PROTECTED]> writes:

> >=head1 TITLE
> >
> >Higher order functions
> 
> Well, this should keep the Obfuscated Perl Contest going for at least 
> another decade :-)

Whilst still being deeply useful in non obfuscatory contexts too.

-- 
Piers

Re: Error handling

[Peter Bevan]

>  >
> > Timeouts, shouldn't be reliant on UNIX. (Although I dont think they
should
> > be in the language eigther. A system is easily developed using threads.
> > something which I hope to develop when perl6 is ready...)
> >
>
> I don't understand this paragraph.

As it stands, if you want to have a timeout on a peice of
code/function/whatever.. you need to use eval, $SIG{ALRM}and alarm()

Unfortuantely alarm() doesnt work on windows (and probobally any other
non-posix os)...

I just think that if Perl6 means one thing, and it effects only one great
change. TRUE platform independance should be it
Java is the success it is because of it. And lets face it, we're all here
because we like Perl more, so to paraphrase Larry "Use the stuff that rocks,
and not the stuff that sucks"...

Re: println() ... printbr()

[raptor]

> I actually saw this in the newsgroups and thought it was a neat idea. What
> about
>println $textvar;
> instead of
>print "$textvar\n";
> Ever so much easier to read and write, prints the arg and appends \n.

]- I thought 'bout this too, but I think it is not general enought..Why ?
we shall then add this too :

printbr "text";

i.e.

print "text";

OR  printtd, printtr

print "text";

and many other like this !!!
current way for many prints operators is :
$old = $\;
$\ = "\n";
print ...
print ...

print ...
$ =$old;

OR
{
  local $\ = "\n";
  print ...
  print ...
  
  print ...
}


There shall be easier way in Perl6 for doing this ... I too get really tired
of these "\n" and 's at the end
ALSO ...

print @array;

must work like this :
foraeach (@array) { print "$_\n"};
foraeach (@array) { print "$_"};

not like at the moment :
foraeach (@array) { print $_};

=
iVAN
[EMAIL PROTECTED]
=

Fw: println() ... printbr()

[Peter Bevan]

- Original Message -
From: "Peter Bevan" <[EMAIL PROTECTED]>
To: "raptor" <[EMAIL PROTECTED]>
Sent: Wednesday, August 09, 2000 11:05 AM
Subject: Re: println() ... printbr()


>
> > > I actually saw this in the newsgroups and thought it was a neat idea.
> What
> > > about
> > >println $textvar;
> > > instead of
> > >print "$textvar\n";
> > > Ever so much easier to read and write, prints the arg and appends \n.
> >
> > ]- I thought 'bout this too, but I think it is not general enought..Why
?
> > we shall then add this too :
> >
> > printbr "text";
> >
> > i.e.
> >
> > print "text";
> >
> > OR  printtd, printtr
> >
> > print "text";
> >
> > and many other like this !!!
> > current way for many prints operators is :
> > $old = $\;
> > $\ = "\n";
> > print ...
> > print ...
> > 
> > print ...
> > $ =$old;
> >
> > OR
> > {
> >   local $\ = "\n";
> >   print ...
> >   print ...
> >   
> >   print ...
> > }
> >
> >
> > There shall be easier way in Perl6 for doing this ... I too get really
> tired
> > of these "\n" and 's at the end
> > ALSO ...
>
>
> Although I agree that a println is a top idea (not only for ease of use
but
> also for cross-platform line end characters)
> the other versions you mention (printbr etc) have (in my opinion) no place
> within the Perl language. Perl is not a cgi language perse, simply one in
> which its is easy to implement and as such it should not contain web
> specific functions. That is the function of modules (such as the excellent
> CGI module, which will do those things you mentioned anyway)...
>
> >
> > print @array;
> >
> > must work like this :
> > foraeach (@array) { print "$_\n"};
> > foraeach (@array) { print "$_"};
> >
> > not like at the moment :
> > foraeach (@array) { print $_};
> >
>
> This I totally disagree with. The use of an array in scalar context does
> (and I believe should always) return it's length. It is one of Perl's
single
> most usful features (in my expirience)...
>

Re: println() ... printbr()

[iain truskett]

* Peter Bevan ([EMAIL PROTECTED]) [09 Aug 2000 20:08]:
> To: "raptor" <[EMAIL PROTECTED]>
[...]
> > print @array;
> >
> > must work like this :
> > foraeach (@array) { print "$_\n"};
> > foraeach (@array) { print "$_"};
> >
> > not like at the moment :
> > foraeach (@array) { print $_};

> This I totally disagree with. The use of an array in scalar context
> does (and I believe should always) return it's length. It is one of
> Perl's single most usful features (in my expirience)...

Almost. print @array is a list context.


cheers,
-- 
iain truskett, aka Koschei.
 Q: How do I block warnings?
 A: The simplest way is to do: close STDERR; -- perliaq.

Re: RFC 65 (v1) Add change bar functionality to pod

[Bryan C . Warnock]

On Wed, 09 Aug 2000, Hildo Biersma wrote:
> > =head1 DESCRIPTION
> > 
> > Making what's changed in documentation stand out's quite useful,
> > something I'm coming to appreciate more and more as the RFCs are
> > flying back and forth. The standard way to do this is to mark the
> > changed sections with one or more vertical bars on the left margin.
> > 
> > Since changes can themselves be changed, multiple levels of change bar
> > can occur. This mirrors the common practice in printed documentation.
> 
> I have a strong feeling this is a bad idea, because:
> - Not everyone is interested in the changes

Some of us have to add them anyway. :-)
The real question is whether the distributed Perl docs will include
change bars.

> - Human authors are fallible, and it's easy to forget changebars

Yep.  (Although human authors are fallible, and it's easy to ^_foo,
or whatever the current currying syntax is now.)

> - We don't want the pods to grow indefinitely

Yep.  (I think we keep the last five versions, so we simply filter out
/^\|{6,}/.

> 
> Instead, it should be pretty trivial to write a tool that compares the
> pods for the current and (any) previous version, generate the
> changebars, then writes that out as a separate document - for those who
> want it.  It may be desirable to include that with the default module
> distribution, or we may want to make this a web-based CPAN resource, but
> boy this should not clutter up every module out there.

We tried this, too.  It worked, but was a little too awkward for our
use.  (And failed the requirements in the end anyway.)

FFT.

-- 
Bryan C. Warnock
([EMAIL PROTECTED])

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

[John Tobey]

On Tue, Aug 08, 2000 at 10:47:10PM -0700, Russ Allbery wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> > On Wed, Aug 09, 2000 at 02:22:22AM +0200, Bart Lateur wrote:
> 
> >> date() would be more general, and replace both. You can pass it a time
> >> zone, ANY time zone, and it will tell you what time it is in that time
> >> zone.
> 
> You're proposing embedding the full power of the Olson TZ library into
> Perl core.  This is a nontrivial amount of data that changes four or five
> times a year.  I really don't think this is a good idea.  Furthermore, the
> only time zone database that can actually do this doesn't use the naming
> scheme that you're probably used to.
> 
> > The JTobey::Date module uses the TZ environment variable (which, I'm
> > told, is non-portable), the esoteric POSIX routines tzset and tzname,
> > and some functions from the CPAN modules Date::Parse and Date::Format.
> 
> It's far worse than non-portable; it's completely insufficient.  The POSIX
> TZ syntax cannot represent many real time zones.  You need the Olson-style
> naming scheme which refers to entries in a fairly large external database

You mean the "EST5EDT", "US/Pacific", "America/New_York", and suchlike
files in /usr/share/zoneinfo.  Actually, I do use those indirectly,
though probably non-portably, by localizing C<$ENV{TZ}>.  GNU Libc
takes care of finding the zoneinfo file, but lamentably reparses it
every time TZ changes and C is called.

My module does not parse old-style TZ formats, though some other
module (Date::Format or Time::Zone?) does.

-John

Re: println() ... printbr()

[Bart Lateur]

On Wed, 9 Aug 2000 12:42:18 +0100, raptor wrote:

>There shall be easier way in Perl6 for doing this ... I too get really tired
>of these "\n" and 's at the end
>ALSO ...
>
>print @array;

I assume that's "printbr"

>must work like this :
>foreach (@array) { print "$_"};

sub printbr {
local($\, $,) = ("\n", "\n");
   # let's add anewline as well
print @_;
}

I don't see the need for something in the core that

 - can take one of many, many forms;
 - can be written in a sub in two simple lines of code.

Besides, if this is for HTML, I wouldn't *ever* use it, because I want
my strings HTML-ified. ( '&' --> '&', '<' --> '<', etc.)

-- 
Bart.

chomp & unchomp

[Ed Mills]

Here is the argument-

Perl has (had?) chomp(). It removes \n at the end of a line. That's 
something we often need to do. We ALSO often need to ADD \n to the end of a 
line. This usually looks something like:

  print "$kitty\n";

Hence my println() suggestion. Maybe instead it should be:

  unchomp;
  print;

Where unchomp ADDS \n to the end of text if it isn't already there.

If there is chomp there should be unchomp- the reasons for including it are 
the same as for including chomp. If chomp is optimized so too can unchomp.

Having chomp without unchomp would be like having <= but not having >=
[see note]. Sure you can get by without it- just change the order of the 
args, but why would you want to? If you have one, the other needs to be 
there for, if nothng else, parity.

BTW I never suggested println() was in the language before. I just glommed 
onto another thread inadvertantly. Sorry!

Ed

note- in Programming Perl v2 and v3 this IS the case by the way- the >= (ge) 
logical operator is not in the book!

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: RFC 48 (v2) Objects should have builtin stringifying

[John Porter]

Michael Fowler wrote:
> 
> I think a stringified reference is worth seeing, moreso than a simple undef,
> for debugging purposes if nothing else.

I personally would like to have the stringification of refs be a
symmetric operation, i.e. such a string should dwim in a ref context:

$r = bless {}, 'Foo';
$s = "$r";
ref($s); # True.
$s->bar; # call method of Foo.

I guess that means the deref operator would have be implicitly overloaded
for strings...

-- 
John Porter

Re: RFC 58 (v1) C changes.

[John Porter]

Bart Lateur wrote:
> 
> chomp() is basically just a "postprocess data coming from a file"
> command.

That is way too simplistic.  I for one think the current behavior
of chomp() is ideal for its simplicity.

while(<>) {
/foo/ and next;  # why bother chomping?
if ( /bar/ ) {
print; # why bother chomping?
}
elsif ( /quux/ ) {
s/$/ (quux found)/;
print; # why bother chomping?
}
else {
chomp;
$x{ $_ . $y };
}
}

-- 
John Porter

Re: RFC 58 (v1) C changes.

[John Porter]

Dan Sugalski wrote:
> > unless you think we should require arrays to be passed by reference.
> 
> It's an op. Arrays can be passed in any way we want. 

But as I already pointed out, we don't want to pass just arrays,
we need to be able to pass any LIST.

-- 
John Porter

Re: RFC 58 (v1) C changes.

[Bart Lateur]

On Wed, 9 Aug 2000 09:23:02 -0400, John Porter wrote:

>That is way too simplistic.  I for one think the current behavior
>of chomp() is ideal for its simplicity.
>
>   while(<>) {
>   /foo/ and next;  # why bother chomping?
>   if ( /bar/ ) {
>   print; # why bother chomping?
>   }
...
>   }

It's not "simple". It's confusing. Very often I do stuff like you
describe, and then it turns out that there are cases where I needed the
chomp, and I forgot to add a newline. Argh. Edit the code, and run the
script again. ALWAYS or NEVER chomp is simpler.

If a built-in chomp() takes less than 1% of the time of reading the
line, and I'm 100% sure it can even be far less (cutting of a preknown
length of the a string is pretty damn fast), then why NOT do it?

I'm quite convinced that always implicit chomp can prove to be faster
than doing it for some cases, using an explicit perl keyword for a
fraction of the lines.

Say that we're talking about an overhead of under 0.3% of execution
time, with a turnover point at where less than 20% of the lines need the
chomp. Would you bother?

Note: if we become more liberal in what can mark a line end, say, regex
support instead of a plain fixed string, chomp() as currently used would
slow down quite a bit. An implicit chomp() need not to slow down at all
(i.e. a difference of under a microsecond), since we just found a string
that terminates the line, and thus we already know its length.

-- 
Bart.

Re: RFC 58 (v1) C changes.

[Graham Barr]

On Tue, Aug 08, 2000 at 08:53:30PM -0400, Dan Sugalski wrote:
> On Tue, 8 Aug 2000, Michael Mathews wrote:
> 
> > Dan Sugalski said:
> > > > > * Do we even want to allow after-the-fact chomps, or do it
> > automagically
> > > >at read time?
> > > "Yes" is rather ambiguous.
> > 
> > To clarify: "Yes", we (I) want to allow after-the-fact chomps. As you
> > alluded to yourself there are times when you may want to chomp strings that
> > were not read from files, therefore there would be no "read time".
> 
> Just because we can do it now doesn't necessarily mean it's the right
> thing to do. Arguably anything you use chomp on that didn't come from a
> filehandle really ought to be run through a regex.

Unless you set $\, calling chomp is bad news anyway (in a module) because
it may not do what you want. And if you are going to write

 { local $\ = "\n"; chomp($str); }


you may as well write

  $str =~ s/\n$/s;

Graham.

Re: RFC 71 (v1) Legacy Perl $pkg'var should die

[Bart Lateur]

On Wed, 9 Aug 2000 08:59:41 +0100, Leon Brocard wrote:

>D'oh! ;-)

Ah, yes. Chris Nandor's module D'oh couldn't possibly be called with
this appropriate name any more.




OTOH, try this:

$hash{a'b} = 1;
print keys %hash;
-->
a::b

That shows that the current situation is not ideal, anyway.

Besides, p52p6.pl can handle the conversion.

-- 
Bart.

Re: RFC 65 (v1) Add change bar functionality to pod

[Dan Sugalski]

At 08:56 AM 8/9/00 +0100, Hildo Biersma wrote:
> > =head1 DESCRIPTION
> >
> > Making what's changed in documentation stand out's quite useful,
> > something I'm coming to appreciate more and more as the RFCs are
> > flying back and forth. The standard way to do this is to mark the
> > changed sections with one or more vertical bars on the left margin.
> >
> > Since changes can themselves be changed, multiple levels of change bar
> > can occur. This mirrors the common practice in printed documentation.
>
>I have a strong feeling this is a bad idea, because:
>- Not everyone is interested in the changes
>- Human authors are fallible, and it's easy to forget changebars
>- We don't want the pods to grow indefinitely

Ah, you misunderstand. I'm not asking that these be required for anyone's 
pods (though I would like 'em for the RFCs), merely that the pod syntax 
supports it. It's fine with me if the bars are automagically generated, and 
I don't much care if the first thing that someone does is run through and 
strip out the bars that are 2 (or more) deep already.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 73 (v1) All Perl core functions should return ob

[Dan Sugalski]

At 11:05 PM 8/8/00 -0700, Nathan Wiger wrote:
>I agree with what Ken said completely:
>
> > Hey! That sounds like an implementation topic... ;) (The internals
> > should be able to handle this if the language wants it, right?)
>
>Let's get the ideas going. The internals might have some honest concerns
>that cause us to radically rethink this or dump it later. However, let's
>figure out what we want the language to do first, and figure out how to
>do it second.

Keeping the internals in mind is important when designing features, though. 
I generally stay out of things I know won't be terribly onerous, but part 
of my job as internals guy is to step in and say "Have you gone stark, 
raving mad?!?" when something with serious repercussions is proposed. This 
is one of those things. It means a lot more code to write (and debug) for 
the things that return these objects, and that means parts of perl will be 
slower, take longer to write, and take up more space.

I'm making no judgements on the utility of the RFC, mind. I'm just weighing 
in on the technical side of RFC winnowing.

>Internals aside, I think if we could get the language to do this it
>would be a tremendous step forward. But that's just my opinion.

I don't think it's that big a deal, but people do have a tendency to do 
lost of Neat Things with features that are unexpected.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Things to remove

[Steve Simmons]

On Tue, Aug 08, 2000 at 06:34:19PM -0500, Mike Pastore wrote:
> Perl++

perm -- good old hairy perl, finally under control.

Running and ducking,
 
 --Steve

Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

[John Porter]

Ken Fox wrote:
> 
> Both of those expressions are the infinite list (-infinity..-1). I have
> no idea how to write that properly 'cause I'm not a math guy. These
> things aren't streams (infinite queues) -- they're infinite stacks. I'm
> not sure they have a name in computer science.

O.k., here's the basic question.  (If someone has already answered this,
I didn't find it satisfactorily comprehensible.  Assume I'm an idiot.)

What would be the output of the following program:

$\ = "\n";
$i = 0;
for ( .. -1 ) {
$i++;
last if $i > 2;
print 
}

If the answer is (as I suspect), "This never prints anything; it goes
into an infinite loop just trying to generate the first number", then
the proposal is absurd and should be scrapped.

-- 
John Porter

Re: RFC 58 (v1) C changes.

[Dan Sugalski]

At 09:24 AM 8/9/00 -0400, John Porter wrote:
>Dan Sugalski wrote:
> > > unless you think we should require arrays to be passed by reference.
> >
> > It's an op. Arrays can be passed in any way we want.
>
>But as I already pointed out, we don't want to pass just arrays,
>we need to be able to pass any LIST.

So? It's an op. Lists can be passed any way we want. :)

If iterators and lazy doohickeys get added to perl (and I think they're 
pretty keen, personally), then lists will need to become semi-first-class 
things under the hood anyway.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 48 (v2) Objects should have builtin stringifying

[Dan Sugalski]

At 09:13 AM 8/9/00 -0400, John Porter wrote:
>Michael Fowler wrote:
> >
> > I think a stringified reference is worth seeing, moreso than a simple 
> undef,
> > for debugging purposes if nothing else.
>
>I personally would like to have the stringification of refs be a
>symmetric operation,

That leads us possibly into C's wild pointer swamp, and I'm not sure I 
personally want to go there. It also makes strings the equivalent of weak 
refs, which can cause someone (either you or the garbage collector, and 
almost undoubtedly the guy who writes the core code) some headaches.


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

[Ted Ashton]

Thus it was written in the epistle of John Porter,
> Ken Fox wrote:
> > 
> > Both of those expressions are the infinite list (-infinity..-1). I have
> > no idea how to write that properly 'cause I'm not a math guy. These
> > things aren't streams (infinite queues) -- they're infinite stacks. I'm
> > not sure they have a name in computer science.
> 
> O.k., here's the basic question.  (If someone has already answered this,
> I didn't find it satisfactorily comprehensible.  Assume I'm an idiot.)
> 
> What would be the output of the following program:
> 
>   $\ = "\n";
>   $i = 0;
>   for ( .. -1 ) {
>   $i++;
>   last if $i > 2;
>   print 
>   }
> 
> If the answer is (as I suspect), "This never prints anything; it goes
> into an infinite loop just trying to generate the first number", then
> the proposal is absurd and should be scrapped.

By my understanding (which is definitely not very thorough), the output would
be a run-time error.  And I think that 

$\ = "\n";
$i = 0;
for ( .. -1 ) {
next unless $_ > -10;
$i++;
last if $i > 2;
print 
}

is supposed to print

-9
-8

How it would know to do that is beyond my ken, but I believe that is what it
is expected to do.

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
Leibniz never married; he had considered it at the age of fifty; but the
person he had in mind asked for time to reflect. This gave Leibniz time to
reflect, too, and so he never married.
  -- Fontenelle, Bernard Le Bovier (1657-1757)
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 58 (v1) C changes.

[John Porter]

Bart Lateur wrote:
> 
> It's not "simple". It's confusing. 

Not at all!  At least, not to me.  If you find it unsimple and confusing,
then I guess I'll have to chalk it up to the heterogeneity of the Perl
community.


> Very often I do stuff like you
> describe, and then it turns out that there are cases where I needed the
> chomp, and I forgot to add a newline. 

Strawman.  There are times I forgot to increment the count of frobnitzes,
and had to go edit the code.

-- 
John Porter

Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

[John Porter]

Ted Ashton wrote:
> John Porter:
> > 
> > What would be the output of the following program:
> > 
> > $\ = "\n";
> > $i = 0;
> > for ( .. -1 ) {
> > $i++;
> > last if $i > 2;
> > print 
> > }
> > 
> > If the answer is (as I suspect), "This never prints anything; it goes
> > into an infinite loop just trying to generate the first number", then
> > the proposal is absurd and should be scrapped.
> 
> By my understanding (which is definitely not very thorough), the output would
> be a run-time error.  

What error message?  "Program never halts!" ???

-- 
John Porter

Re: RFC 48 (v2) Objects should have builtin stringifying

[Hildo Biersma]

John Porter wrote:
> 
> Michael Fowler wrote:
> >
> > I think a stringified reference is worth seeing, moreso than a simple undef,
> > for debugging purposes if nothing else.
> 
> I personally would like to have the stringification of refs be a
> symmetric operation, i.e. such a string should dwim in a ref context:
> 
> $r = bless {}, 'Foo';
> $s = "$r";
> ref($s); # True.
> $s->bar; # call method of Foo.
> 
> I guess that means the deref operator would have be implicitly overloaded
> for strings...

Bit dangerous there - the string-to-ref operator is left out for a
purpose.  
- Would you really want the ref-counting system / the GC system to
  scan strings?
- Would like like the effects of pointer arithmetic that 
  the ref-tostring, edit-string, string-to-ref sequence allows?

Hildo

Re: Things to remove

[Nathan Torkington]

The discussion of a new name for perl6 is amusing but irrelevant.
It's not like this list doesn't get enough traffic already.  Thanks for
ceasing and desisting.

Nat

Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

[Ted Ashton]

John Porter replied to what
> Ted Ashton wrote:
> > John Porter:
> > > 
> > > What would be the output of the following program:
> > > 
> > >   $\ = "\n";
> > >   $i = 0;
> > >   for ( .. -1 ) {
> > >   $i++;
> > >   last if $i > 2;
> > >   print 
> > >   }
> > > 
> > > If the answer is (as I suspect), "This never prints anything; it goes
> > > into an infinite loop just trying to generate the first number", then
> > > the proposal is absurd and should be scrapped.
> > 
> > By my understanding (which is definitely not very thorough), the output would
> > be a run-time error.  
> 
> What error message?  "Program never halts!" ???

:-).  I don't know, really.  This proposal, while interesting to me, isn't
mine and is pretty much a new thought.  My guess would be that the actual list
implementation would be to not unroll anything until it was needed and so the
print or the for would notice that the output is still based on "coming from
infinity" and would die.  

I understand very well the concern.  I, for one, don't agree that having
(1..) in the language implies that having (..-1) is possible (though it does
make sense to me that having (1..) and (..-1) would imply having (..)).  After
all, if I were to write

  for (1..) {
print;
  }

I would get an infinite loop, but one which was doing something, whereas

  for (..-1) {
print;
  }

would either have to error out, count backwards from -1  or go into an infinite
loop trying to find the beginning.  Perhaps one of the proponents can enlighten 
us.  After all, even mathematical induction cannot generate all the elements
of (..-1) unless it starts at -1 and goes backward.

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
Whereas at the outset geometry is reported to have concerned herself with
the measurement of muddy land, she now handles celestial as well as
terrestrial problems: she has extended her domain to the furthest bounds of
space.
-- Frankland, W.B.
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 73 (v1) All Perl core functions should return ob

[Nathan Wiger]

> > All Perl core functions should return objects
> >
> 
> Yuck.  Why not use the proposed want() and return hash-refs or slices,
> when appropriate.

No reason you couldn't do that too. This just affects scalar contexts.

-Nate

Re: RFC 73 (v1) All Perl core functions should return ob

[Nathan Wiger]

> It means a lot more code to write (and debug) for the things that
> return these objects, and that means parts of perl will be
> slower, take longer to write, and take up more space.

Point taken. I don't think internals should be ignored altogether, just
that they shouldn't be the driving force in the language design.
Otherwise we'd wind up with something like C. :-)

One alternative is to add a pragma to implement this, maybe called
'object'. So a person could 'use object' to get the objects flowing
everywhere. But again, this is an implementation thing I'd rather save
until at least v2, after people have given input on the idea itself.

-Nate

Re: RFC 48 (v2) Objects should have builtin stringifying

[John Porter]

Hildo Biersma wrote:
> 
> Bit dangerous there - the string-to-ref operator is left out for a
> purpose.  
> - Would you really want the ref-counting system / the GC system to
>   scan strings?
> - Would like like the effects of pointer arithmetic that 
>   the ref-tostring, edit-string, string-to-ref sequence allows?

Um, no...   )-:

-- 
John Porter

Re: RFC 58 (v1) C changes.

[Bart Lateur]

On Wed, 9 Aug 2000 10:24:28 -0400, John Porter wrote:

>Bart Lateur wrote:
>> 
>> It's not "simple". It's confusing. 
>
>Not at all!  At least, not to me.  If you find it unsimple and confusing,
>then I guess I'll have to chalk it up to the heterogeneity of the Perl
>community.

>> Very often I do stuff like you
>> describe, and then it turns out that there are cases where I needed the
>> chomp, and I forgot to add a newline. 
>
>Strawman.  There are times I forgot to increment the count of frobnitzes,
>and had to go edit the code.

There's no need for that macho "I can lick this" attitude. Being
consistent, everywhere, is clearly simpler.

I've done some benchmarks, copying a 650k file 200 times (over the same
output file every time). I've modified the same script a little, and
then ran it, so that mutual influence of the scripts was minimal. This
is the basic script:

use Benchmark;
my $file = 'win32api.txt';
# $\ = "\n";   # in some versions: explicit setting of $/ to "\n"
sub go {
@ARGV = $file;
open OUT, ">$ENV{TMP}/copy.txt"
  or die "Can't write to file: $!";
while(<>) {
# chomp;  # explicit chomp() in some versions
print OUT;
}
close OUT;
}
go(); # possibly load file in file cache

timethis(200, \&go);

Results:

Plain code: no chomp, $\ clear:

   timethis 200: 20 wallclock secs (20.16 usr +  0.00 sys = 20.16 CPU) @
9.92/s (n=200) 

Command line option = '-l': implicit chomp, $\ set by system:

   timethis 200: 22 wallclock secs (21.42 usr +  0.00 sys = 21.42 CPU) @
9.34/s (n=200)

No chomp, $\ set to "\n" (double the newlines in output)

   timethis 200: 22 wallclock secs (21.64 usr +  0.00 sys = 21.64 CPU) @
9.24/s (n=200)

Explicit chomp, $/ set to "\n":

   timethis 200: 24 wallclock secs (23.73 usr +  0.00 sys = 23.73 CPU) @
8.43/s (n=200)


As it turns out, no chomp() and $/ not set is fastest, explicit chomp()
and $/ set to newline is slowest, difference about 20%. However, it's
the other results that are interesting.

It turns out that $/ set to "\n" (by system) and implicit chomp is AS
FAST as $/ set to "\n" and no chomp at all. (The results are halfway
between both extremes. The output files are slightly different, so take
times with a grain of salt.) An explicit chomp does slow down my program
by a large amount of about 10%. Seen the small task it does, compared to
reading and writing the files, that is a lot.

If there is any optimization to be done, it is in the appending of the
"\n" at the end when printing (again, 10% of total time). This is quite
slow, it must be possible to do this a lot faster. But I think that in
principle, this shows that an implicit chomp does NOT slow down the
program. By contrast, an explicit chomp() does, and quite a bit.

Oh, and doing

print "$_\n"; 

or

print $_, "\n";

turns out to be quite a bit slower still than using the feature of $\.
(time above 27 seconds)

-- 
Bart.

RFC 79 (v1) Code which is both executable and POD.

[Perl6 RFC Librarian]

This and other RFCs are available on the web at
  http://dev.perl.org/rfc/

=head1 TITLE

Code which is both executable and POD.

=head1 VERSION

  Maintainer: John Porter <[EMAIL PROTECTED]>
  Date: 9 Aug 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: 79

=head1 ABSTRACT

Allow some executable code to be recognized also as POD.

=head1 DESCRIPTION

As of Perl 5, any chunk of source text is either POD, or executable code.
This RFC proposes that a class of source text be allowed which is both
recognized as POD by any POD processor, and as non-POD by the perl parser.
This allows actual running code to be inserted directly into the documentation
for that code.

=head1 IMPLEMENTATION

How this is implemented depends on whether supporting changes can be made
to the perl parser, to POD processors, or both.  Changes to the POD specification
can reasonably be assumed to necessitate changes to both the perl parser and
to POD processors.

=head2 1: Leave perl's POD recognition unchanged; modify POD processors

This could be done by adding a variant of the C<=cut> directive, which
is recognized as a normal C<=cut> by perl, but is passed over by POD
processors.  This exploits the fact that perl stops ignoring text at
the C<=cut> directive.  The POD processors must be modified to NOT stop
accumulating POD when they see the C<=cut include> directive.

The downside of this approach is that overlaps between pod and code can
only occur in this order ( pod, both, code ).  Alternatively, the POD
processors could also I accumulating code on a C<=cut include> directive,
but this would look kludgy.

Example:

=pod

This documents the code.

=cut include

sub foo($\%@)

=cut

{
#code for foo
}


=head2 2: The POD spec is changed to include special directives

This is cleaner, but has farther reaching effects in both
the perl parser and POD processors.

This could be done by adding a special variant of the C<=pod> directive,
such as C<=pod code>.

Example:

=pod

Normal documentation.

=pod code

sub foo($\%@)

=cut

{
#code for foo
}

=pod code

$^W = 1; # enable warnings :-)

=pod

Rest of documentation.

=cut


=head1 REFERENCES

  RFC 5: "Multiline Comments for Perl"
  RFC 11: "Examples encoded with =also for|begin|end POD commands"
  RFC 44: "Bring Documentation Closer To Whatever It Documents"
  perlpod manpage for discussion of POD.

=cut

Re: RFC 58 (v1) C changes.

[John Porter]

Bart Lateur wrote:
> 
> There's no need for that macho "I can lick this" attitude. Being
> consistent, everywhere, is clearly simpler.

Being explicit about when you want your lines chomped is more
consistent, IMHO, than always getting it whether you want it or not.

[irrelevant timings of perl5 code snipped]

-- 
John Porter

Re: RFC 58 (v1) C changes.

[Nathan Torkington]

John Porter writes:
> Being explicit about when you want your lines chomped is more
> consistent, IMHO, than always getting it whether you want it or not.

I'm getting the feeling that this discussion should either end or
become an RFC.  Soon.

Nat

RE: RFC 58 (v1) C changes.

[Brust, Corwin]

The Perl 6 Librarian writes
>=head1 DESCRIPTION 
>
>This RFC contains two proposed changes.  First, as it is common to want to 
>removed newlines upon reading a file, 
>
>  while (chomp()) {
>. . .
>  }
>
>should become the equivalent of
>
>  while () {
>chomp;
>. . .
>  }
>

>where the various equivalent constructions would, of course, work as
expected.  
>
>Second, as it seems common for someone learning perl to expect
>
>  $without_newline = chomp($previous_form);
>
>to put a copy of the text in C<$previous_form>, sans newline, into
>C<$without_newline> while not modifying C<$previous_form>, Perl should
>do just that.
>
>C called in void context would remove the newline
>from the variable (or members of the list) upon which it was called.
>C called in a scalar context would leave its argument variable
>untouched and instead return a Ced version of that variable's
>contents.  Likewise and furthermore for other contexts.


chomp good.  nice word.  me like.  me want chomp strings and file handles
too.

I think the people we actualy need to hear from are those who are actualy
using the return value from chomp, as they are the only ones who could be
negitivly affected by this proposal.  

As to what we look to match ($/, $FH->IRS,$SOME_WACKEY_NEW_VAR) as Larry
pints out that's far from knowable right now, so like, we'll firgure that
out when the time comes.

Also, I don't want to quote anyone - but: I don't like the "We can focus on
ripping things up" attitude that some of us have been justifying by assuming
that Larry will sort though the myriad of conflicting RFC and comments, tell
us which are Perl and set us about implementing them.  

My understanding is that perl6 is the Perl community's rewrite of the
program (and -to some degree- the language).

So, kids, whatcha doing with that return value? (the number of characters
removed by the operation)?

And, oh yeah, ++Ted.

-Corwin

Re: RFC 48 (v2) Objects should have builtin stringifying

[Nathan Wiger]

> I think a stringified reference is worth seeing, moreso than a simple undef,
> for debugging purposes if nothing else.

Debugging is great, but I don't think this is the way to do it. The
reason is some objects might have a STRING method while others don't, so
you'll only get partial access to some of the objects' underlying
structures.

I think a separate call that dumped the info (basically what print
$object does now) is better. That way you're guaranteed to get it.

And a novice programmer isn't confused by seeing "HASH(0xe3902)" when
they expected to see some type of "real" data.

-Nate

Re: RFC 73 (v1) All Perl core functions should return ob

[Dan Sugalski]

At 07:55 AM 8/9/00 -0700, Nathan Wiger wrote:
> > It means a lot more code to write (and debug) for the things that
> > return these objects, and that means parts of perl will be
> > slower, take longer to write, and take up more space.
>
>Point taken. I don't think internals should be ignored altogether, just
>that they shouldn't be the driving force in the language design.
>Otherwise we'd wind up with something like C. :-)

I do agree that the internals shouldn't drive the language (otherwise a 
crack team of Ninja would've already taken care of that Conway guy... :), 
but neither can they be completely ignored. I'm just weighing in with a 
rough estimate of the cost. It's someone else's job to balance that cost 
with the benefits, but that can't be done without at least some idea of the 
cost. (I expect Larry's got a good handle on that already, or will when he 
takes a hard look at the final proposal, but...)

>One alternative is to add a pragma to implement this, maybe called
>'object'. So a person could 'use object' to get the objects flowing
>everywhere. But again, this is an implementation thing I'd rather save
>until at least v2, after people have given input on the idea itself.

Honestly, I'd rather you put together a general scheme for handling the 
object/scalar morphing thingie and RFC it, and then we migrate the various 
functions that people think should do the object thing as time and effort 
allow. They all might not be in perl 6.0.0 (And what are we going to call 
the first dev release--perl 6.-1.0?) but could get added in as modules and 
make it into perl 6.2.0 or something)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 79 (v1) Code which is both executable and POD.

[Michael Mathews]

From: "Perl6 RFC Librarian"
> This allows actual running code to be inserted directly into the
documentation
> for that code.

This (if I understand your aim here) points out The Difference between
comments and POD, and underlines why POD is not a good way to comment code.

Comments can always be assumed to be visible with the code they are about.
POD is sometimes visible with the code it is about, but only when viewed in
the source. However POD is intended to be viewed without its surrounding
code, using a pod-viewing application. You can't have it both ways. Either
POD is a comment or its not (and my position is that its not, its
documentation.).

This RFC would seem to address the issue quite neatly.

--Michael

Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

[James Mastros]

Tangentialy, can I suggest that a nicer synthax might be -Inf..-1 / 1..Inf,
etc.

Assuming that we end up supporting full IEEE floats, this becomes the
"obvious"
synthax, and I find C<(-Inf..Inf)> to be far more clear then C<(..)>.  We've
got
plenty of puncuation already, thank you very much.

Also, can someone please suggest a reasonable implementation of (-Inf...-1)?
If not, can I suggest that we require that if one of the arguments to (list)
.. s +/-infinity, it be the second one, and additionaly say that a..b is the
list , a+1, a+2, ... b if b>a, and a, a-1, a-2, ... b if a>b.  This would
allow the full expressiveness of both (-inf..0) and (0..inf) without ever
having an infinite starting point to a list.

(If a..b where a==b, then we get the list containing only a.)

In any case, (-inf...-1) would "obviously" either:
begin with the smallest negitive integer representable,
or begin with the IEEE -inf.
If it begins with the IEEE -inf, then it has to continue with an infinite
number of -infs, since
-inf+1=-inf (a rule of IEEE arithmitic).

Ergo, it is useless to begin at -inf unless perl6 becomes _very_ good at
finding out what you "really" meant.
OTOH, having it begin with the smallest non-(negitive)infinite value means
that it becomes non-infinite,
IE scalar((-inf..0)) != inf.  This is obviously a Bad Thing.  Also, if
bignums are intergrated (as has been proposed),
then there is no smallest representable integer.

(This assumes that the float synthax will be extended to include "NaN" and
"Inf" as valid
floating-point numbers.  (This does take away from non-reserved namespace.)
Has this
been proposed yet?)

-=- James Mastros,
In slightly over his head.

Re: vector and matrix calculations in core? (was: Re: Ramblings on "base class" for SV etc.)

[Ed Mills]

Bart et al:

In keeping with Larry's design philosophy that the language should "not just 
sit there -do something!" I agree that there should be a number of 
vector/matrix manipulations available, performed in a psuedo-scalar context 
(not in a loop). Just to name a few:

arithmetic ops +-*/
ceiling, floor
rank
reshape / matrix transposition
vector generators (generate an array of integers 1..100)
inner/outer product
polynomial expansion
and / or reduction
sigma function
mathmatical functions for multiple vectors such as (@x) + (@y) (in a 
non-scalar sense)

etc. etc. This kind of functionality would attract a whole new category of 
users from mathematics and other areas, as well as giving us optimized 
solutions to operations that many of us do regularly in loop contexts.

On the other hand one can argue all of these belong in CPAN under a matrix:: 
library or something like that, but to me if would make Perl a powertool to 
build these kinds of functions into the language syntax. In many cases these 
can be treated as overloading scalar ops for a non-scalar context.

Ed




Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: RFC 58 (v1) C changes.

[Chaim Frenkel]

> "UG" == Uri Guttman <[EMAIL PROTECTED]> writes:

UG> and the globals can be used by the magic <> which was asked by jonathan
UG> scott. when you use <> you rarely IMO use many other handles. typically
UG> <> is used in filter programs.

Personal counter example. Many times, I take multiple inputs and tee
them off to multiple files.

Consider taking a web logfile and isolating the entries based upon
the owners of the pages.


-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 71 (v1) Legacy Perl $pkg'var should die

[Larry Wall]

Bart Lateur writes:
: On Wed, 9 Aug 2000 08:59:41 +0100, Leon Brocard wrote:
: 
: >D'oh! ;-)
: 
: Ah, yes. Chris Nandor's module D'oh couldn't possibly be called with
: this appropriate name any more.
: 
:   
: 
: 
: OTOH, try this:
: 
:   $hash{a'b} = 1;
:   print keys %hash;
: -->
:   a::b
: 
: That shows that the current situation is not ideal, anyway.
: 
: Besides, p52p6.pl can handle the conversion.

Alternately:

use ident qr/[A-Za-z_][A-Za-z_0-9']*/;

or some such.

Larry

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

[Russ Allbery]

John Tobey <[EMAIL PROTECTED]> writes:
> On Tue, Aug 08, 2000 at 10:47:10PM -0700, Russ Allbery wrote:

>> It's far worse than non-portable; it's completely insufficient.  The
>> POSIX TZ syntax cannot represent many real time zones.  You need the
>> Olson-style naming scheme which refers to entries in a fairly large
>> external database

> You mean the "EST5EDT", "US/Pacific", "America/New_York", and suchlike
> files in /usr/share/zoneinfo.

Specifically America/New_York, yes.  The other two names you list are from
inferior naming schemes that ideally should go away; they're basically
just aliases for the more accurate names and have been for a while.

Okay, I guess the question is whether the goal is to provide access to the
real time zones or to the system time zone library.  If the latter,
that's simpler, but a lot of systems don't have adequate time zone support
to do what you really want.  Particularly non-Unix systems; pretty much
all Unix systems at this point use *some* version of the Olson library,
although their data may be woefully out of date.

> Actually, I do use those indirectly, though probably non-portably, by
> localizing C<$ENV{TZ}>.  GNU Libc takes care of finding the zoneinfo
> file, but lamentably reparses it every time TZ changes and
> C is called.

That's fine; zoneinfo files are designed for that.  They're extremely fast
to parse.  That's what you want.

I'm not as worried about Unix, since most Unixes have a decent time zone
library.  I'm worried more about all the *other* platforms that Perl
supports; if we want time zone support to be portable, I'm pretty sure
we'd end up embedding the tz library, since otherwise the results are
going to vary wildly in quality from system to system.  (Even worse than
the situation with sprintf.)

I think this is a bit heavy-weight for core.

> My module does not parse old-style TZ formats,

Nothing should really ever use them anyway, so I wouldn't be too worried
about that.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

RE: RFC 67 (v1) Deep Copying, aka, cloning around.

[Garrett Goebel]

From: Peter Scott [mailto:[EMAIL PROTECTED]]
>
> >I would like deep copying to include copying CODE. It would 
> >be useful for implementing object methods...
> 
> Why would it be necessary to deep copy a CODE reference?

It might not be necessary. I'm still learning how to write kosher Perl...
elegance is a long way off for me.  

It'd be nice to for a class to be able to initialize a new object containing
a copy of an anonymous subroutine instead of a reference to a common one.
There might be some real justification when used with closures. Then class
methods could pass through to object methods that could be switched at
runtime.

Besides, it wouldn't be deep copying if it shallow copied the subroutines ;)

If deep copying and cloning are though of in terms of persistent objects...
aka Data::Dumper and Storable, then deparsing subroutines into something
that can be stored becomes more important too.  Class::Tom does this pretty
well.

Garrett

Re: vector and matrix calculations in core? (was: Re: Ramblings on "base class" for SV etc.)

[Dan Sugalski]

At 04:06 PM 8/9/00 +, Ed Mills wrote:
>In keeping with Larry's design philosophy that the language should "not 
>just sit there -do something!" I agree that there should be a number of 
>vector/matrix manipulations available, performed in a psuedo-scalar 
>context (not in a loop).

That would be list context. (Or perhaps array or hash context, and yes I 
know we don't have those right now)

>  Just to name a few:

[Snip]

>etc. etc. This kind of functionality would attract a whole new category of 
>users from mathematics and other areas, as well as giving us optimized 
>solutions to operations that many of us do regularly in loop contexts.

I expect it would make other things interesting as well, not just math 
things. (Running a substitution on an array would be keen, for example)

>On the other hand one can argue all of these belong in CPAN under a 
>matrix:: library or something like that, but to me if would make Perl a 
>powertool to build these kinds of functions into the language syntax. In 
>many cases these can be treated as overloading scalar ops for a non-scalar 
>context.

While I'm firmly of the opinion the code to actually Do Something should be 
elsewhere (at least to start), support definitely needs to be in the core 
to notice what that something is--you won't get very far with:

   @a * @b

if perl does a scalar on both arrays before doing the multiplication...



Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 73 (v1) All Perl core functions should return ob

[Nathan Wiger]

> I do agree that the internals shouldn't drive the language (otherwise a
> crack team of Ninja would've already taken care of that Conway guy... :),
> but neither can they be completely ignored. 

Agreed. Which reminds me, we should call off those Ninja... :-)

> Honestly, I'd rather you put together a general scheme for handling the
> object/scalar morphing thingie and RFC it, and then we migrate the various
> functions that people think should do the object thing as time and effort
> allow.

Agreed again. No reason to bloat the language with 10,000 pragmas.

I think RFCs 49 (object STRING func) and 73 (this one), taken together,
do a pretty good job of a first stab at this. However, as I get more
input from people, integrating this all together into another RFC is
probably a good idea, as you suggest. 

But I do like keeping 49 separate because it could be integrated into
the language without having to include 73.

-Nate

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

[Nathan Wiger]

> I think this is a bit heavy-weight for core.

Agreed. General-purpose timezone support is scheduled for a swift and
painless death in the next version of RFC 48. Only the local timezone
and GMT will be included in the RFC, same as now.

I wish it could happen, but too many people have brought up concerns
that I feel are extremely legitimate "show-stoppers".

-Nate

Re: Things to remove

[Larry Wall]

[EMAIL PROTECTED] writes:
:> Most of the requests for deletion seem to begin with, "This isn't
:> used..." 
:> 
:> To which, "*I* use it." is a very valid argument.
: 
: Agreed. The real problem with ?...? is that it complicates the hell out
: of the parser. So long as the special magic is retained for m?...?, I
: would suggest that raw ?...? could beneficially disappear.

Or turned into m//f, or some such.  Must think about relationship to
an extension-based reset operator as well.  To maintain current semantics
we'd need introspection into the regular expressions used in a particular
package.

Larry

Fw: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

[James Mastros]

Tangentialy, can I suggest that a nicer synthax might be -Inf..-1 / 1..Inf,
etc.

This assumes that the float synthax will be extended to include "NaN" and
"Inf" as valid floating-point literals.  (This does take away from
non-reserved namespace.)   Has this been proposed yet?

Assuming that we end up supporting full IEEE floats, this becomes the
"obvious" synthax, and I find C<(-Inf..Inf)> to be far more clear then
C<(..)>.  We've got plenty of puncuation already, thank you very much.

Also, can someone please suggest a reasonable implementation of (-Inf...-1)?
If not, can I suggest that we require that if one of the arguments to (list)
.. s +/-infinity, it be the second one, and additionaly say that a..b is the
list , a+1, a+2, ... b if b>a, and a, a-1, a-2, ... b if a>b.  This would
allow the full expressiveness of both (-inf..0) and (0..inf) without ever
having an infinite starting point to a list.

(If a..b where a==b, then we get the list containing only a.)

In any case, (-inf...-1) would "obviously" either: begin with the smallest
negitive integer representable, or begin with the IEEE -inf.
If it begins with the IEEE -inf, then it has to continue with an infinite
number of -infs, since -inf+1=-inf (a rule of IEEE arithmitic).

Ergo, it is useless to begin at -inf unless perl6 becomes _very_ good at
finding out what you "really" meant.

OTOH, having it begin with the smallest non-(negitive)infinite value means
that it becomes non-infinite, IE scalar((-inf..0)) != inf.  This is
obviously a Bad Thing.  Also, if bignums are intergrated (as has been
proposed), then there is no smallest representable integer.


-=- James Mastros,
In slightly over his head.

Re: RFC 58 (v1) C changes.

[Johan Vromans]

Dan Sugalski <[EMAIL PROTECTED]> writes:

> So? It's an op. Lists can be passed any way we want. :)

In what respect would that be different from a function?
(cf. RFC 26).

-- Johan

Re: access to pod/doc text by code

[Johan Vromans]

Uri Guttman <[EMAIL PROTECTED]> writes:

>   MP> pod2usage is the call I THINK you are refering to. Who cares if it is
>   MP> slow? I'll bet that if you are writting to the screen or a file, THAT's
>   MP> the slow part, not traipsing through the file parsing for POD. It might
>   MP> make an interesting Benchmark test.
> 
> i think reading the file may have issues like finding it. or doc strings
> for each sub vs. parsing that out of the whole pod. i just bothers me to
> have to read that file for stuff that was in the source. so some better
> syntax to make that accessible to the code seems like a win.

A neglectible one.
Remember, 99.99% of the times this is used to fetch a final (fatal?)
usage or help message. It is not something that is done 400 times
during the lifetime of a common program.

-- Johan

Re: RFC 73 (v1) All Perl core functions should return ob

[Chaim Frenkel]

I don't think it will be a half million objects.

Let's take stat (and all the other long list returns). The underlying
implementation object could be a packed structure psuedohash. (Think
DSECT.)  Then the only op would be the packed structure pseudohash
lookup. Which would be done at compile time. (Fallbacks to the hash
lookup if really generic.)

For the other types, it would be quite invisible. The parser would
translate the $foo->SCALAR into whatever you would want scalar($foo)
to have returned.

Similarly for other possible constructs. Just think of it as moving
the internal access routines closer to the language.



> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:

DS> On 9 Aug 2000, Perl6 RFC Librarian wrote:
>> =head1 TITLE
>> 
>> All Perl core functions should return objects

DS> While an interesting idea, it'll mean we have a half-bazillion different
DS> types of objects floating around just from the core. The number of
DS> different vtables needed to deal with this (along with the functions in
DS> those tables) is rather formidable, and it will tend to impact
DS> performance. (The more different pieces of code you have the less cache
DS> coherency, which means things go slower)

DS> These really aren't objects anyway, they'd be magic scalars. (And yes, I
DS> know--the difference would be what, exactly? :) Regardless, I think this'd
DS> be rather slow, and I don't think it ought to be core.

DS> However...

DS> If you feel the need, it should be possible to let you do this, or at
DS> least a part of it for one or three ops, with a module. I think it might
DS> be better to wait until the plain way's in and then embellish it later.


-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: access to pod/doc text by code

[Uri Guttman]

> "JV" == Johan Vromans <[EMAIL PROTECTED]> writes:

  JV> Uri Guttman <[EMAIL PROTECTED]> writes:

  >> i think reading the file may have issues like finding it. or doc strings
  >> for each sub vs. parsing that out of the whole pod. i just bothers me to
  >> have to read that file for stuff that was in the source. so some better
  >> syntax to make that accessible to the code seems like a win.

  JV> A neglectible one.
  JV> Remember, 99.99% of the times this is used to fetch a final (fatal?)
  JV> usage or help message. It is not something that is done 400 times
  JV> during the lifetime of a common program.

i have a new use for this, which is getting help text from long lived
objects (which could be remote). that will not be a fatal/final
message. i would like the speed to be decent and going to a file (and
parsing the pod and filtering) is not a good solution IMO.

as i said, there are workarounds and we now have an rfc on this
subject. that is all i wanted, to bring this matter up.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

Re: RFC 58 (v1) C changes.

[Dan Sugalski]

At 07:19 PM 8/9/00 +0200, Johan Vromans wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > So? It's an op. Lists can be passed any way we want. :)
>
>In what respect would that be different from a function?
>(cf. RFC 26).

Ops are lower level. (I'm not talking about, say, the localtime op, but 
rather things like the dereference or newstate op) Though honestly I don't 
much care if this is all visible to perl code. Some oddball smacking about 
of @_, I expect.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Larry Wall]

[EMAIL PROTECTED] writes:
: Note that it may not be possible to satisfy conflicting requests.  If
: module C and module C demand two different versions of the same
: module C, the compiler should halt and state the module conflicts.

Pardon me for sniping at a great RFC, but I already promised the CPAN
workers that I'd make that last statement false.  There's no reason in
principle why two modules shouldn't be allowed to have their own view
of reality.  Just because you write Foo::bar in your module doesn't mean
that Perl can't know which version of Foo:: you mean.

The issue is actually more general than just versioning.  The larger
view of it is how to support package aliasing.  A package name is
essentially the name of a public interface.  Suppose you have one
interface, but two or more different implementations of that interface
by different people.  Each might have their own version sequence.

There are open questions on that, of course.  If we have two different
packages of the same name differentiated only by version or by author
(or both), we obviously count that internally as part of the name of
the package.  To what extent do we need to reveal the full internal
name of a package?  (For instance, does the author/version show up as
part of the name when you say "ref $object".)

Another question is whether the two different versions of the "same"
module are going to stomp on each other?  (Not in package space, since
the packages are distinguished internally, but how about in the
filesystem?)

There are also policy issues with package naming.  When and how do we
declare that a package name like XML::DOM is a standard abstract
interface that belongs to no one implementation, and restrict version
numbers to interface revisions, not implementation revisions?

Basically, there are some more things we have to think about if we
really want to do Best Fit rather than First Fit.  And I think we do.

Larry

Re: RFC 76 (v1) Builtin: reduce

[Chaim Frenkel]

Please consider the possiblity of tristate logic (RFC TBD.) ala, SQL.

Assuming a "use tristate", undef + number = undef

This might require that the reduce function be able to ignore undefs.
Either always under the tristate pragma. Or on a case by case basis.

Also you haven't specified if the arguments to reduce are evaluated
lazily.



> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:

PRL> The first call to the reduction subroutine will be passed the first N
PRL> elements of the list, and subsequent calls will be passed the result of
PRL> the previous call and the next N-1 elements in the list, until no more
PRL> elements remain in the list. If fewer than N-1 elements remain on the
PRL> final call, all the remaining elemetns are passed.

PRL> If the original list has no elements, C immediately returns C.
PRL> If the original list has a single element, that element is immediately returned
PRL> (without every calling the reduction subroutine).
PRL> Otherwise, the result of the final reduction call is the result returned
PRL> by C.

PRL> If the reduction subroutine is ever terminated by a call to C,
PRL> the enclosing C immediately returns the last reduction value
PRL> (i.e. C on the first reduction call, $_[0] otherwise)

-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 73 (v1) All Perl core functions should return ob

[Peter Scott]

At 01:33 PM 8/9/00 -0400, Chaim Frenkel wrote:
>I don't think it will be a half million objects.

The problem I have with this RFC is that it is too broad a brush.  Since 
different core functions would need to return different objects (there 
would be some common ones, but otherwise it would be pretty near 1:1, I 
would think), what we're really saying here is that we're overloading the 
interface for each core function differently.

Has the author really looked at every core function and determined an 
object for each?  How about exists()?  defined()?  sin()?  chr()?  There 
are surely some functions for which it doesn't make sense to come up with 
an object interface just for the sake of it, so that word 'all' bugs me.

I'm not against it in principle for many functions.  In fact, it could be 
used to improve RFC 52 by overloading, e.g., chown:

 $result = chown $uid, @dirs;
 print "Failed for these dirs: ", $result->failures;
 print "Failure reasons: ", map $_->failure_reason, $result->failures;

But IMHO that word 'all' puts a stake in its heart.  Each system function 
should be evaluated on its own merits.

--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Dan Sugalski]

At 10:44 AM 8/9/00 -0700, Larry Wall wrote:
>[EMAIL PROTECTED] writes:
>: Note that it may not be possible to satisfy conflicting requests.  If
>: module C and module C demand two different versions of the same
>: module C, the compiler should halt and state the module conflicts.
>
>Pardon me for sniping at a great RFC, but I already promised the CPAN
>workers that I'd make that last statement false.  There's no reason in
>principle why two modules shouldn't be allowed to have their own view
>of reality.  Just because you write Foo::bar in your module doesn't mean
>that Perl can't know which version of Foo:: you mean.

Does that mean, then, that when module A does a "$C::bar = 1" it affects a 
different package namespace than module B doing a "$C::bar = 2"? And does 
it also extend to things like this:

package A;
use C 1.2;
package B;
use C 1.4;

where two packages in the same file use different versions of module C and 
get them?

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 73 (v1) All Perl core functions should return ob

[Dan Sugalski]

At 01:33 PM 8/9/00 -0400, Chaim Frenkel wrote:
>I don't think it will be a half million objects.
>
>Let's take stat (and all the other long list returns). The underlying
>implementation object could be a packed structure psuedohash. (Think
>DSECT.)  Then the only op would be the packed structure pseudohash
>lookup. Which would be done at compile time. (Fallbacks to the hash
>lookup if really generic.)

stat makes some sense. (local|gm)time makes some sense. The socket 
functions make some sense. The message and shared memory functions make 
some sense. Basically most of the 'advanced' functions make some sense. 
That's the problem--they all make some sense, which is a lot of code to get 
right for the .0 release.


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 79 (v1) Code which is both executable and POD.

[John Porter]

Michael Mathews wrote:
> 
> This ... underlines why POD is not a good way to comment code.
> ...
> This RFC would seem to address the issue quite neatly.

So, are you saying that if this RFC is implemented, POD would be
an good way to comment code?

-- 
John Porter

Re: RFC 73 (v1) All Perl core functions should return ob

[Nathan Torkington]

Dan Sugalski writes:
> stat makes some sense. (local|gm)time makes some sense. The socket 
> functions make some sense. The message and shared memory functions make 
> some sense. Basically most of the 'advanced' functions make some sense. 
> That's the problem--they all make some sense, which is a lot of code to get 
> right for the .0 release.

stat, sockets, messaging, and the rest of the advanced stuff should
probably go to modules.  (local|gm)time belongs in the core, but
probably not as an object.

I want the core to stay useful but not complex.  If localtime returned
a hashref in scalar context, that'd be enough for me:

  $now = localtime;
  print $now->{MONTH};
  print $now->{YEAR};   # already has 1900 added onto it :-)
  print $now->{INTEGER};# epoch seconds value

To get what is now scalar localtime, you'd say

  print localtime->{STRING};

In list context it would return a simple list of values as it does now.

RFC 48 is way too complex for my liking.  In particular it expects
Perl to be able to distinguish between assignment to array and to a
hash.

I smell a counter-RFC, or at least a mailing list on which to thrash
this out.

Nat

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Larry Wall]

Dan Sugalski writes:
: Does that mean, then, that when module A does a "$C::bar = 1" it affects a 
: different package namespace than module B doing a "$C::bar = 2"?

Presumably.

: And does it also extend to things like this:
: 
: package A;
: use C 1.2;
: package B;
: use C 1.4;
: 
: where two packages in the same file use different versions of module C and 
: get them?

I expect that could also be made to work, provided the semantics of
importation remain package-scoped and don't become lexically scoped.

To me, it really just means that the *real* name of the package includes
the implementation (author?) and version, but that when you say

use C;

you're just choosing to wildcard both the implementation and version.
This view says that we probably ought to figure out how to encode the
implementation and version syntactically as part of the package name,
rather than as a 3rd argument to use.

Think about the long names of fonts for an example of how far this
can be taken.

Larry

Re: RFC 73 (v1) All Perl core functions should return ob

[Jarkko Hietaniemi]

On Wed, Aug 09, 2000 at 12:09:42PM -0600, Nathan Torkington wrote:
> Dan Sugalski writes:
> > stat makes some sense. (local|gm)time makes some sense. The socket 
> > functions make some sense. The message and shared memory functions make 
> > some sense. Basically most of the 'advanced' functions make some sense. 
> > That's the problem--they all make some sense, which is a lot of code to get 
> > right for the .0 release.
> 
> stat, sockets, messaging, and the rest of the advanced stuff should
> probably go to modules.  (local|gm)time belongs in the core, but
> probably not as an object.
> 
> I want the core to stay useful but not complex.  If localtime returned
> a hashref in scalar context, that'd be enough for me:
> 
>   $now = localtime;
>   print $now->{MONTH};
>   print $now->{YEAR}; # already has 1900 added onto it :-)
>   print $now->{INTEGER};  # epoch seconds value

$now->{EPOCH_SECONDS}

$now->{ISO8601} # -MM-DDThh:mm:ss
# -MM-DDThh:mm:ss[-+]hh:mm if offset known
# -MM-DDThh:mm:ssZ from gmtime()

$now->{JULIAN}  # to make date arith easier

> To get what is now scalar localtime, you'd say
> 
>   print localtime->{STRING};
> 
> In list context it would return a simple list of values as it does now.
> 
> RFC 48 is way too complex for my liking.  In particular it expects
> Perl to be able to distinguish between assignment to array and to a
> hash.
> 
> I smell a counter-RFC, or at least a mailing list on which to thrash
> this out.
> 
> Nat

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: RFC 73 (v1) All Perl core functions should return ob

[Peter Scott]

At 12:09 PM 8/9/00 -0600, Nathan Torkington wrote:
>stat, sockets, messaging, and the rest of the advanced stuff should
>probably go to modules.

Yes, plus the get* functions.  Do we need an RFC on this?

--
Peter Scott
Pacific Systems Design Technologies

Re: RFC: Higher resolution time values

[Nick Ing-Simmons]

Dan Sugalski <[EMAIL PROTECTED]> writes:
>>
>>As an engineer I would really like to know when you are going to
>>run out of precision in double - that is forty something bits of mantissa.
>>That is more precision than you have in the real world.
>
>It's not precision, it's resolution. What do you do if your timers return 
>values in 1/10ths of a second?

What is the problem with that?

-- 
Nick Ing-Simmons

Overloading && ||

[Nick Ing-Simmons]

Damian Conway <[EMAIL PROTECTED]> writes:
>Operator overloading is scheduled to be revamped.

While I remember - it would be good if overload mechansim
could be extended to cover && and || as well as & and | 
with the class deciding if short-circuit happens.

-- 
Nick Ing-Simmons

Re: RFC 79 (v1) Code which is both executable and POD.

[Larry Wall]

John Porter writes:
: Michael Mathews wrote:
: > 
: > This ... underlines why POD is not a good way to comment code.
: > ...
: > This RFC would seem to address the issue quite neatly.
: 
: So, are you saying that if this RFC is implemented, POD would be
: an good way to comment code?

It already is, as far as I'm concerned.
 
The view that the POD contained within a file specifies a single
document is oversimplified.  The moment we added =for and =begin/=end,
POD became a way to specify multiple, independent documents in the same
file.  Each keyword following =for or =begin/=end specifies a different
abstract document.  If one of those abstract documents happens to be
commentary on the code, great.  Not all of those abstract documents have
to be intended for external POD viewers, assertions to the contrary
notwithstanding.
 
Seems like all we're discussing now is how much those independent
documents should be independent (where the code itself is considered
one of the documents).
 
Larry

Re: RFC 79 (v1) Code which is both executable and POD.

[Michael Mathews]

John Porter asked:
> Michael Mathews wrote:
> > This ... underlines why POD is not a good way to comment code. ...
> > This RFC would seem to address the issue quite neatly.
> So, are you saying that if this RFC is implemented, POD would be
> a good way to comment code?

I do consider this a potential alternative to the MLC RFC but to my mind it
addresses the opposite problem: how to get executable code into a commenmt,
rather than how to get executable code out of the program (which is the
specific usage many proposed solutions seem to snag on).

Examples:
a) Jane wants to keep some chunk of code in the file (for now) but doesn't
want it to execute and doesn't want it to show up in the documentation --
this won't help her.
b) Jack wants to nest a block of comments, actually to quickly disable a
large swath of code without regard for any potential block comments
within -- this won't help him (since "=cut" ends all POD, not just the most
recent item).

To be fair, neither of these are examples of using a comment function for
"comments" though, but rather using a comment function to disable sections
of code and I suppose that makes as much sense as using POD to disable code.
I think, however if we wanted to support this type of misuse two more
features would be needed:

aa) Allow a POD that is "private", and won't ever show up in the
documentation:
=private
took this next part out because the client insisted, though I predict
they will flip-flop
...lots of disabled code...
=cut
bb) Allow for nesting
=private
...lots of disabled code...
=POD
...lots of POD...
=cut
...more disabled code...
=cut

Re: Overloading && ||

[Damian Conway]

   > Damian Conway <[EMAIL PROTECTED]> writes:
   > >Operator overloading is scheduled to be revamped.
   > 
   > While I remember - it would be good if overload mechansim
   > could be extended to cover && and || as well as & and | 
   > with the class deciding if short-circuit happens.

Oh, definitely. I need lazily evaluated args for that, but (of course)
there's an RFC in the pipeline to cover that too :-)

Damian

Re: Overloading && ||

[Peter Scott]

At 06:23 PM 8/9/00 +, Nick Ing-Simmons wrote:
>Damian Conway <[EMAIL PROTECTED]> writes:
> >Operator overloading is scheduled to be revamped.
>
>While I remember - it would be good if overload mechansim
>could be extended to cover && and ||

Yes.

>as well as & and |
>with the class deciding if short-circuit happens.

No.  I don't want to see && or || and not know whether it short-circuits 
without looking in the class interface.  My brain is conditioned through 
years of C and Perl to expect that they always short-circuit.  This is too 
venerable a semantic to change.  Please.


--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 79 (v1) Code which is both executable and POD.

[Andy Dougherty]

On Wed, 9 Aug 2000, Michael Mathews wrote:

> To be fair, neither of these are examples of using a comment function for
> "comments" though, but rather using a comment function to disable sections
> of code and I suppose that makes as much sense as using POD to disable code.

This is another instance where a macro preprocessor might be useful.
(My previous example was an alternative to some of the higher-level
function proposals.)
In cpp (though I'd not recommend that particular "language" for Perl):

#if 0
  ..disabled code...
#if 0
   ..older disabled code...  now in nested disables
#endif
  ..more disabled code
#endif

Just hoping that looking at it from another skewed viewpoint may inspire
someone,

Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042

Re: Ramblings on "base class" for SV etc.

[Nick Ing-Simmons]

Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>Well, compactness for one. With a scalar on one side it's less odd (it was 
>a bad example). When funkier, though:
>
>   @foo = @bar * @baz;
>
>the expansion becomes less obvious 

It is "obviously" a cross-product ;-)
With perl's $s and @s we can actually make sensible choice between
mathamaticians · (dot) and X (cross) produducts from context.
Whether that is a good idea is another matter.

>and quite a bit larger, especially if 
>the arrays are multidimensional.




>
>   Dan
>
>--"it's like this"---
>Dan Sugalski  even samurai
>[EMAIL PROTECTED] have teddy bears and even
>  teddy bears get drunk
-- 
Nick Ing-Simmons

Re: RFC 76 (v1) Builtin: reduce

[Damian Conway]

   > Please consider the possiblity of tristate logic (RFC TBD.) ala, SQL.
   > 
   > Assuming a "use tristate", undef + number = undef
   > 
   > This might require that the reduce function be able to ignore undefs.
   > Either always under the tristate pragma. Or on a case by case basis.

I'm not sure how this would affect the proposal. If an item in the list being
reduced is undef, it appears in the reduction subroutines arg list as undef.
The reduction subroutine can then handle it (or not) as it chooses. 

For example, to short-circuit if the reduction ever becomes undef:

$sum = { defined $_[0] or last; $_[0]+$_[1] } 0, @numbers;


   > Also you haven't specified if the arguments to reduce are evaluated
   > lazily.

Good point. They should definitely be Virtuous. :-)

Damian

Re: RFC 79 (v1) Code which is both executable and POD.

[John Porter]

Michael Mathews wrote:
> 
> I do consider this a potential alternative to the MLC RFC ...

I don't.  This RFC deals strictly with POD.  If a good in-line comment
solution is also implemented, so much the better; but orthogonal to
this.

> but to my mind it
> addresses the opposite problem: how to get executable code into a commenmt,
> rather than how to get executable code out of the program 

That's a very astute observation; and it's why the solutions may
reasonably be independent.

-- 
John Porter

Re: RFC 79 (v1) Code which is both executable and POD.

[John Porter]

Andy Dougherty wrote:
> 
> This is another instance where a macro preprocessor might be useful.
> ...
> Just hoping that looking at it from another skewed viewpoint may inspire
> someone,

Fine; but I hope people only see RFC 79 as an extension to POD, because
that's all it really is.  It does not attempt to address the in-line
comments issue -- and would fail if it did try, because that is a
issue with the whole of POD, even in the absence of RFC 79.

-- 
John Porter

Re: Overloading && ||

[Damian Conway]

   > No.  I don't want to see && or || and not know whether it short-circuits
   > without looking in the class interface.  My brain is conditioned through
   > years of C and Perl to expect that they always short-circuit.  This is too
  > venerable a semantic to change.  Please.

What if I want to overload && and || so that they help built an expression
tree, rather than immediately evaluating?

Damian

Re: RFC: Higher resolution time values

[Dan Sugalski]

At 06:16 PM 8/9/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >>
> >>As an engineer I would really like to know when you are going to
> >>run out of precision in double - that is forty something bits of mantissa.
> >>That is more precision than you have in the real world.
> >
> >It's not precision, it's resolution. What do you do if your timers return
> >values in 1/10ths of a second?
>
>What is the problem with that?

You can't accurately represent a tenth of a second with floating point 
numbers. If we're going to handle them, we might as well be exact.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Dan Sugalski]

At 11:11 AM 8/9/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Does that mean, then, that when module A does a "$C::bar = 1" it affects a
>: different package namespace than module B doing a "$C::bar = 2"?
>
>Presumably.

H. That brings up some issues of ambiguity, then. If you use C in 
package A, and also in package B, which do you see when you're in main and 
access $C::bar?

>: And does it also extend to things like this:
>:
>: package A;
>: use C 1.2;
>: package B;
>: use C 1.4;
>:
>: where two packages in the same file use different versions of module C and
>: get them?
>
>I expect that could also be made to work, provided the semantics of
>importation remain package-scoped and don't become lexically scoped.

Sure. They'd have to be, otherwise packages split across different files 
would get a rather bizarre view of the world. This sort of means we'll need 
some sort of two-level stash, one per-package and one global. (Unless 
you're outlawing symbolic references... :)

>To me, it really just means that the *real* name of the package includes
>the implementation (author?) and version, but that when you say
>
> use C;
>
>you're just choosing to wildcard both the implementation and version.
>This view says that we probably ought to figure out how to encode the
>implementation and version syntactically as part of the package name,
>rather than as a 3rd argument to use.

Yup. I can see the build procedures needing to know this too, since we'll 
probably need to give modules with shared libraries unique names. Some 
platforms (OS/2 and VMS, at least) will need that, as they get cranky if 
you try and load shareables with the same base filename.

>Think about the long names of fonts for an example of how far this
>can be taken.

Would this be "Taken to its logical and sensible conclusion" or "Taken as 
far as it can possibly go, though it you turn around and look *really* hard 
with binoculars you can see where you crossed the line, way back there by 
the horizon"?

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Overloading && ||

[Peter Scott]

At 04:58 AM 8/10/00 +1000, Damian Conway wrote:
>> No.  I don't want to see && or || and not know whether it short-circuits
>> without looking in the class interface.  My brain is conditioned through
>> years of C and Perl to expect that they always short-circuit.  This 
> is too
>   > venerable a semantic to change.  Please.
>
>What if I want to overload && and || so that they help built an expression
>tree, rather than immediately evaluating?

Is it worth the damage it will cause to fragile brains like mine?

I have often wondered whether a language could allow user-defined 
operators.  The fact that none have done it should be a clue :-)  I guess 
it's getting too incestuous with the lexer.

--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 73 (v1) All Perl core functions should return ob

[Dan Sugalski]

At 12:09 PM 8/9/00 -0600, Nathan Torkington wrote:
>I want the core to stay useful but not complex.  If localtime returned
>a hashref in scalar context, that'd be enough for me:
>
>   $now = localtime;
>   print $now->{MONTH};
>   print $now->{YEAR};   # already has 1900 added onto it :-)
>   print $now->{INTEGER};# epoch seconds value
>
>To get what is now scalar localtime, you'd say
>
>   print localtime->{STRING};

I'd just as soon that was scalar(localtime)--if we're going to do this, 
then we should do it so the short-hand format's convenient and useful.

Which sort of argues for localtime in a numeric scalar context to return 
epoch seconds, in a string scalar context to return a time string, and in a 
plain scalar context a hashref. (or mini-object, or tied thingamabob, or 
whatever) Of course, we're trying to kill $! which does that, which is a 
counter-argument...

>In list context it would return a simple list of values as it does now.
>
>RFC 48 is way too complex for my liking.  In particular it expects
>Perl to be able to distinguish between assignment to array and to a
>hash.
>
>I smell a counter-RFC, or at least a mailing list on which to thrash
>this out.
>
>Nat


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 79 (v1) Code which is both executable and POD.

[John Porter]

Larry Wall wrote:
> : So, are you saying that if this RFC is implemented, POD would be
> : an good way to comment code?
> 
> It already is, as far as I'm concerned.

I do too.  RFC 79 presumes that POD continues in its state of grace.


> Seems like all we're discussing now is how much those independent
> documents should be independent (where the code itself is considered
> one of the documents).

Indeed.  Sounds like we need some things:

a) a "perl" processor type for =for/=begin; and

b) ability to combine pod processors on =for/=begin, so that the stuff
goes to all the named pod processors.

c) a "pod" processor type, for which the stuff is not "diverted";

E.g.:

=for pod perl
# this line goes to both the default pod processor AND the perl parser.


Alternatively, the processor type named on the =for/=begin line could
actually be a pattern, and the stuff is passed to all matching pod
processors:

=for (pod|perl)
# this line goes to both the default pod processor AND the perl parser.

=for .*
# this line goes to all processors, including the perl parser.


While I'm on it -- perhaps the RFC should be phrased in terms of LP,
as in: "Perl On-line Documentation (:-) should more fully support LP".


-- 
John Porter

Re: Overloading && ||

[Dan Sugalski]

At 12:04 PM 8/9/00 -0700, Peter Scott wrote:
>At 04:58 AM 8/10/00 +1000, Damian Conway wrote:
>>> No.  I don't want to see && or || and not know whether it 
>> short-circuits
>>> without looking in the class interface.  My brain is conditioned 
>> through
>>> years of C and Perl to expect that they always short-circuit.  This 
>> is too
>>   > venerable a semantic to change.  Please.
>>
>>What if I want to overload && and || so that they help built an expression
>>tree, rather than immediately evaluating?
>
>Is it worth the damage it will cause to fragile brains like mine?

"And now it's time for the head on top of your shoulders to explode"

>I have often wondered whether a language could allow user-defined 
>operators.  The fact that none have done it should be a clue :-)

What, like C++? ("I don't believe in it?" "What, C++? Just a conspiracy of 
computer programmers?")

>I guess it's getting too incestuous with the lexer.

Nah, though it does restrict the optimizer some depending on how it overloads.

Of course, by the time Damian's done, perl won't actually *do* 
anything--you'll need to fire off another window and do a "kill 
-HEYYOUGETMOVING 23442" to actually make something happen...

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 79 (v1) Code which is both executable and POD.

[Uri Guttman]

> "JP" == John Porter <[EMAIL PROTECTED]> writes:

  JP>   =for pod perl
  JP>   # this line goes to both the default pod processor AND the perl parser.

but how will perl access that text? what perl var get the text in that
=for block? the proposal for a special here doc notation is possible but
that can be hard for pod to parse unless we restrict the format.

  JP> While I'm on it -- perhaps the RFC should be phrased in terms of LP,
  JP> as in: "Perl On-line Documentation (:-) should more fully support LP".

well, i see the problem not as keeping the docs near the code but the
letting the code access parts of the docs. that has nothing to do with
LP AFAIK. but all perl hackers are illiterate anyway. that's what all
our detractors seem to mean when they say our code is write only! :-)

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

Re: Overloading && ||

[Damian Conway]

   > >What if I want to overload && and || so that they help built an expression
   > >tree, rather than immediately evaluating?
   > 
   > Is it worth the damage it will cause to fragile brains like mine?

"Pain is the weakness leaving your body!"

;-)

   > I have often wondered whether a language could allow user-defined 
   > operators.  The fact that none have done it should be a clue :-)  I guess 
   > it's getting too incestuous with the lexer.

User-defined operators are a can of rattle-snakes that I *seriously*
recommend we don't open.

Damian

Re: Overloading && ||

[Damian Conway]

   > Of course, by the time Damian's done, perl won't actually *do* 
   > anything--you'll need to fire off another window and do a "kill 
   > -HEYYOUGETMOVING 23442" to actually make something happen...

Actually, the plan is exactly the opposite. By the time I'm finished
everything will be done...in constant time!

Damian

Re: RFC 54 (v1) Operators: Polymorphic comparisons

[Dan Sugalski]

At 05:12 PM 8/7/00 -0400, Chaim Frenkel wrote:
> > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>
> >> I currently fail to switch to 'eq' many times when I should, but the
> >> failure mode is obvious. Her the failure mode will be really strange.
>
>DC> I would claim that the failure mode is not obvious: "dog"=="cat" is 
>true
>
>Sure it is. I pass a large amount of data and _everything_ matches! Voila,
>I messed up the test. Test looks okay. (If I was a newbie, '==' is broken.
>Given my experience, I used the wrong test.)

Both ways have issues. "dog"=="cat", but "10.0"ne"10". Both are arguably 
wrong--dogs aren't cats, but 10.0 really is 10...


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Overloading && ||

[Dan Sugalski]

At 05:23 AM 8/10/00 +1000, Damian Conway wrote:
>> Of course, by the time Damian's done, perl won't actually *do*
>> anything--you'll need to fire off another window and do a "kill
>> -HEYYOUGETMOVING 23442" to actually make something happen...
>
>Actually, the plan is exactly the opposite. By the time I'm finished
>everything will be done...in constant time!

Sure, but being Quantum, we won't know how long that time is, or if we do 
we won't know what the answer is... (With all the lazy operations 
proposals, I can see the release slogan now: "Perl 6, the language for 
couch potatoes")

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: DRAFT RFC: Enhanced Pack/Unpack

[Dan Sugalski]

At 10:53 PM 8/7/00 +0200, Bart Lateur wrote:
>Right. Why you people don't call it "Intel" vs. "Motorola", like the
>rest of the civilised world, I don't know.  ;-)  See the TIFF spec, for
>example.
>
>Er, in case you were in any doubt: Motorola (from the 68k processors) is
>BigEndian, Intel (x86) is LittleEndian. TIFF marks the files with either
>"MM" or "II".

Yep, except for the PowerPC and 88k chips, which can do either, or the 
i860, which was BigEndian IIRC...

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: DRAFT RFC: Enhanced Pack/Unpack

[Dan Sugalski]

At 07:26 PM 8/7/00 +0100, Tom Hughes wrote:
> From /usr/include/endian.h on my linux box:
>
>#define __LITTLE_ENDIAN 1234
>#define __BIG_ENDIAN4321
>#define __PDP_ENDIAN3412
>
>Basically PDP or middle endian is low byte first within each word
>but high word first in the overall longword.

This, FWIW, is because the PDP-11 (as opposed to all the other PDP 
families) was a 16-bit machine, so this is actually two words each in 
little-endian storage...

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: chomp & unchomp

[Bryan C . Warnock]

On Wed, 09 Aug 2000, Ed Mills wrote:
> Here is the argument-
> 
> Perl has (had?) chomp(). It removes \n at the end of a line. That's 
> something we often need to do. We ALSO often need to ADD \n to the end of a 
> line. This usually looks something like:
> 
>   print "$kitty\n";

Chomp removes one or more line separators from the end.

> 
> Hence my println() suggestion. Maybe instead it should be:
> 
>   unchomp;
>   print;
> 
> Where unchomp ADDS \n to the end of text if it isn't already there.

How many?  Ideally, since you're looking for an inverse, you'd want to
replace however many were chomped off, right?

> 
> If there is chomp there should be unchomp- the reasons for including it are 
> the same as for including chomp. If chomp is optimized so too can unchomp.
> 
> Having chomp without unchomp would be like having <= but not having >=
> [see note]. Sure you can get by without it- just change the order of the 
> args, but why would you want to? If you have one, the other needs to be 
> there for, if nothng else, parity.
> 

chomp() uses $/, I believe.  $\ is the inverse of $/, and is used
automatically.

And it's fewer characters.

$\="\n";
print;


-- 
Bryan C. Warnock
([EMAIL PROTECTED])

Re: RFC 79 (v1) Code which is both executable and POD.

[John Porter]

Uri Guttman wrote:
> 
> but how will perl access that text? what perl var get the text in that
> =for block? 

Well, the proposal was more about getting perl code into doco than
getting doco into perl.


> the proposal for a special here doc notation is possible but
> that can be hard for pod to parse unless we restrict the format.

Yes, that's an idea.  

Maybe what's needed is two distinct perl pod processor types, one
which passes on the text literally to the compiler, and one which
wraps it up like a string literal.

The former type:

=for pod
The subroutine is defined as

=for perl-code pod
sub foo($\@%)

{
#...
}

The latter type:

print

=for perl-string pod
Help is on the way.

;

-- 
John Porter

Aus tiefem Traum bin ich erwacht.

Re: chomp & unchomp

[John Porter]

Bryan C. Warnock wrote:
> 
> Chomp removes one or more line separators from the end.

It does?  You're using a different version of Perl than I am.

-- 
John Porter