Re: RFC: println()

[Hildo Biersma]

Ed Mills wrote:
> 
> 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.

This is probably what I disliked most about Pascal - it presumes it
knows best what units of output you want to write at any one time - a
piece of a line or an entire line.  I feel this dates back to the
mainframe world (as does the rest of Pascal I/O), and I'd prefer not to
see this duplicated in perl...

Hildo

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

[Piers Cawley]

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:

> This and other RFCs are available on the web at
>   http://dev.perl.org/rfc/
> 
> =head1 TITLE
> 
> Proposal to utilize C<*> as the prefix to magic subroutines

I freely accept that this is not anything approaching a reasoned
critique but:

Yecch!

-- 
Piers

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

[Piers Cawley]

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?

-- 
Piers

wildcard includes

[Peter Bevan]

Just a thought, but I think it woul be a good idea to include the
'java-esqe' practice of including packages via foo.barr.*
or in Perl's case Foo::Bar::* (assume that the module include syntax remains
the same)...

I can see that in the case of some module directories, where the modules are
fairly insular it may not be a great idea. However there are some occations
where I think that inclusion of multiple modules would be ideal (such as
maybe LWP or Net)...

What do you think

Re: RFC 50 (v1) BiDirectional Support in PERL

[Roman M . Parparov]

On Mon, Aug 07, 2000 at 11:51:06PM +0200, Bart Lateur wrote:
> On 07 Aug 2000 17:27:55 -0400, Chaim Frenkel wrote:
> 
> >He mentioned two different encodings. Logical and Visual. I'm not clear
> >which is which. One orders the characters so that the first char is
> >first. The other reorders the characters to correctly display on a
> >device that can not understand rtl text.
> 
Logical is the one to display first as first.
The idea is to support directly visual outputs, thus only requiring
from a device to support the output font.

> It's just that, in his application area, CGI, that the browser just
> might display it as RtL regardless of what he expected.
> 
It's not only the browser in the end.
It'd expand the capabilities to any output device presumed LTR.

> It sounds like a hack. Should Perl support such hacks in the core?
> 
> Is this sofisticated enough, or do we need something more low-level?
> 
>   $ltr = join '', reverse split /($sequence|.)/, $rtl;
> 
It won't work with a mixed text, and there the pain in the ass begins.
Numbers, Latin char strings, here we go.

This is what Hebrew ViM did, and it is not easy to work with EVERYTHING
going from right to left.

The problem was big enough for that ECMA document to appear.

> -- 
>   Bart.

-- 
Roman M. Parparov - NASA EOSDIS project node at TAU technical manager.
Email: [EMAIL PROTECTED]   http://www.komkon.org/~romm
Phone/Fax: +972-(0)3-6405205 (work), +972-(0)54-629-884 (home)
--
The economy depends about as much on economists as the weather does on
weather forecasters.
-- Jean-Paul Kauffmann

Re: wildcard includes

[Piers Cawley]

"Peter Bevan" <[EMAIL PROTECTED]> writes:

> Just a thought, but I think it woul be a good idea to include the
> 'java-esqe' practice of including packages via foo.barr.*
> or in Perl's case Foo::Bar::* (assume that the module include syntax remains
> the same)...
> 
> I can see that in the case of some module directories, where the modules are
> fairly insular it may not be a great idea. However there are some occations
> where I think that inclusion of multiple modules would be ideal (such as
> maybe LWP or Net)...
> 
> What do you think

I think that multiple question marks are the sign of an unsound mind.[1]

However, I do like the idea of syntactic sugar to load a bunch of
modules. I'm not sure you need the '*' though. Something like:

require Foo::Bar:: ;

Has no real meaning currently and could be taken to mean 'load all of
the modules under Foo::Bar'. 

Question: Should this include Foo::Bar itself?

1: Look it's a *joke*! Pinched from Terry Pratchett.

-- 
Piers

Re: RFC 25 (v1) Multiway comparisons

[Martyn J. Pearce]

On Fri, Aug 04, 2000 at 04:48:24PM -0400, John Porter wrote:
> I think this should mean what it means in Icon, namely, that
> $x < $y  evaluates to false if $x >= $y, and evaluates to
> "$y (but true)" if $x < $y.  This allows the operators to be
> nested, i.e.   $x < $y < $z would be ( $x < $y ) < $z, which
> performs the $y < $z comparison iff $x < $y.

So, given -2 < $y < 2, when the value of $y is 0, the -2 < 0 evaluates
to 0 but true?  I'll assume for now that $y isn't changed by this, but
then, 0E0 < 2 succeeds, so the user gets 0E0 were (s)he previously had
0.  That sounds to me like a classic scenario for people getting very,
very confused indeed.

Mx.

-- 
See, the stars are shining bright
Everything's all right tonight
-- (Martin L. Gore, Never Let Me Down Again)

Re: Things to remove

[Martyn J. Pearce]

>   ?pattern?   # one-time match

Oi!  Scott!  No!

I use this in one-liners, and it's _dead_ handy.  Of course, if it's
modularized as Dan suggests, which has no effect at language level, I
wouldn't be unhappy.

Mx.

-- 
See, the stars are shining bright
Everything's all right tonight
-- (Martin L. Gore, Never Let Me Down Again)

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

[Bart Lateur]

On Tue, 8 Aug 2000 13:30:22 +1000 (EST), Damian Conway wrote:

>   > As for the regexp issue, just to clarify there's only one ambiguous case
>   > we need to work out that I can see:
>   > 
>   >/.*^foo/;   # ok
>
>But:   /.*^foo/m;  #ambiguous

Hold it. What does this mean? Is the whole regex gonna be turned into an
anonymous sub, or what?

I find this whole  "higher order function" thing nothing but butt ugly.
Perl already has anonymous subs, which look far less confusing. If you
want shorter syntax for "sub { ... }" and for $_[1] etc, I can
understand that. But please please please do not make this thing look
like an ordinary expression, when it is anything but!

Obfuscation at its worst.

-- 
Bart.

Re: Things to remove

[Leon Brocard]

Martyn J. Pearce sent the following bits through the ether:

> I use this in one-liners, and it's _dead_ handy

May I suggest that Perl6 will be a different language? I've seen the
"I use it, don't change it" argument a couple of times now and it's
not a strong enough argument. The whole point is to clean up the
language.

Cheers! 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: Things to remove

[Piers Cawley]

Leon Brocard <[EMAIL PROTECTED]> writes:

> Martyn J. Pearce sent the following bits through the ether:
> 
> > I use this in one-liners, and it's _dead_ handy
> 
> May I suggest that Perl6 will be a different language? I've seen the
> "I use it, don't change it" argument a couple of times now and it's
> not a strong enough argument. The whole point is to clean up the
> language.

However, it is a good argument for making sure that such functionality
isn't removed from the language, even if the syntax changes.

-- 
Piers

Re: RFC 55 (v1) Compilation: Remove requirement for fina

[Andy Wardley]

On Aug 7, 10:12am, Nathan Torkington wrote:
> Is there any reason you couldn't use "die" instead?

This isn't an objection to the proposal, but one example of where I'm
relying on the value returned by require() for a reason other than
error reporting.

I'm building Perl sub-routines (from templates) and writing them to
a file as:

   sub {
# blah blah blah
   }

And then I can

  eval { $mysub = require $filename };

Of course, I should point out that I've already been burnt by this.
If the file has already been required then require() returns 1 instead
of the subref.  So I have to delete $INC{ $file } before I require it.
There are other ways I could easily do the same thing (the Data::Dumper
approach for one).


A

-- 
Andy Wardley <[EMAIL PROTECTED]>   Signature regenerating.  Please remain seated.
 <[EMAIL PROTECTED]>   For a good time: http://www.kfs.org/~abw/

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

[Jeremy Howard]

> >   > As for the regexp issue, just to clarify there's only one ambiguous
case
> >   > we need to work out that I can see:
> >   >
> >   >/.*^foo/;   # ok
> >
> >But: /.*^foo/m;  #ambiguous
>
> Hold it. What does this mean? Is the whole regex gonna be turned into an
> anonymous sub, or what?
>
> I find this whole  "higher order function" thing nothing but butt ugly.
> Perl already has anonymous subs, which look far less confusing. If you
> want shorter syntax for "sub { ... }" and for $_[1] etc, I can
> understand that. But please please please do not make this thing look
> like an ordinary expression, when it is anything but!
>
First of all, it won't look like an ordinary expression. Damian and I have
just finished off v2 of this RFC, which should be in your inbox RSN.
Hopefully you'll agree that the suggestions made there never create a higher
order function when there's ambiguity (you have to use braces to
disambiguate).

Secondly, it's not just shorter syntax for sub{} and $_[1] etc:

 $check = ^_ < 2 + ^_ * atan($pi/^_) or die ^_;

is actually equivalent to:

 $check = sub (;) {
   @_==0 ?  ^_ < 2 + ^_ * atan($pi/^_) or die ^_
 : @_==1 ?  $_[0] < 2 + ^_ * atan($pi/^_) or die ^_
 : @_==2 ?  $_[0] < 2 + $_[1] * atan($pi/^_) or die ^_
 : @_==3 ?  $_[0] < 2 + $_[1] * atan($pi/$_[2]) or die ^_
 :  $_[0] < 2 + $_[1] * atan($pi/$_[2]) or die $_[3]
 ;
 };

to allow for re-currying of deferred expressions.

Re: wildcard includes

[Peter Bevan]

- Original Message -
From: "Piers Cawley" <[EMAIL PROTECTED]>
To: "Peter Bevan" <[EMAIL PROTECTED]>
Sent: Tuesday, August 08, 2000 10:32 AM
Subject: Re: wildcard includes


> "Peter Bevan" <[EMAIL PROTECTED]> writes:
> > > "Peter Bevan" <[EMAIL PROTECTED]> writes:
> > > However, I do like the idea of syntactic sugar to load a bunch of
> > > modules. I'm not sure you need the '*' though. Something like:
> > >
> > > require Foo::Bar:: ;
> > >
> > > Has no real meaning currently and could be taken to mean 'load all of
> > > the modules under Foo::Bar'.
> >
> > The syntax is obvoiusly debatable, I'd be happy where it
> > "Foo^^%%$%^Bar%^%^%$$£" as long as it worked
> >
> > But seriously, I think that the systax you described is certainly better
> > than "*" which doesn't much fit the current Perl "style" I thin that
some
> > kind of identifier/wildcard is nessesary - if only that when you leave
> > things open, mistakes are made
> >
> > It also may be an idea to have some kind of package global to indicate
> > "community-mindedness" for want of a better phrase, thus leaving the
module
> > writer free to opt-out of the widlcard if he/she/it wished...
>
> Hmm... I think you run into the halting problem there. ie: Without
> loading the module how do you know if it's 'community minded'? And if
> you do load it, and it isn't community minded, how do you undo the
> load given that irreversible side effects are possible (hmm... a case
> for continuations perhaps...)
>

But surely a new loading mechanism can be included in the new perl build
which would determine the modules "community-mindedness" and them load or
unload it accordingly

Failing that, would a naming convension be appropriate??? (ie the call would
be to Foo::Bar or Foo::* [1] but the file name would be appened ie
/foo/bar.pmc [2])
[1] Using the '*' just for the sake of argument
[2] A "community-minded" module being .pmc and a "non-community-minded"
being .pm"

Or maybe the option to opt-out is just implauseable, I dont know. The
question really lies on whether this is deemed as important enough to
require loading concessions from the new internals...

For my money the loading convension should be this:

/foo.pm=> use Foo;
/Foo/Bar.pm=> use Foo::Bar;
/Foo/* => use Foo::*;  (or whatever wildcard is agreed upon);

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

[Matt Sergeant]

> On Mon, Aug 07, 2000 at 01:44:28AM -0500, Jonathan Scott Duff wrote:
>   > On Sun, Aug 06, 2000 at 11:07:02AM -0700, Russ Allbery wrote:
>   > > Basically, you don't want to go anywhere near this mess; it eats people.
>   > 
>   > I agree.
>   > 
>   > > I see two reasonable options to go with instead.  One is to just use a
>   > > binary flag that says use UTC or not; this is the simplest and most
>   > > reliable to explain.  The other is to allow a timezone offset; this
>   > > doesn't deal with daylight savings time and historic time zone changes,
>   > > but it provides enough power for most of what people want to do and if you
>   > > want to deal with the rest you have to deal with time zone naming.
> 
>   I agree completely with Russ, and I would further state that I don't
>   want this C feature in the core.  Dates, times, timezones, leap
>   seconds, month and day names, localized formats, etc., are too
>   complex.  No one here has thought out the complexity enough to say
>   "this is what Perl will support from now on".
> 
>   Currently, there isn't even an adequate (in my opinion) module on CPAN
>   that gives dates a proper abstract interface.  Time::Object may be
>   okay as a lightweight localtime/strftime interface, but it does not
>   support date, as opposed to time/date, arithmetic, or rather, it
>   mis-supports it.

Well its called Time::Object, not Date::Object for a reason... :)

>   Since we really don't understand dates here, I don't want us commiting
>   to a certain interface without a `use' directive in the program.
>   Distribute Time::Object as a standard module, but keep it a module,
>   and don't force its quirks on people.  Certainly, don't force the
>   complex, quirky, and untested interface being developed here now on
>   anyone without a long, patient discussion period.
> 
>   > This makes an incredible amount of sense.  We could even let the user
>   > specify a coderef to a sub that implements their own particular
>   > timezone oddities. (i.e. a sub to tell date() what the TZ offset is)
> 
>   Gross.  Put it in a module.

While I think Time::Object is a really great module, and following these
discussions I'm thinking of adding a date() function to it, I'm actually in
total agreement with John here. Times and dates are something that should be
supported _simply_ by the core of Perl, and more extensively in an external
module. I'd be very happy to see the Time::Object in core perl as a module,
but I'd hate to see it as the _only_ interface to dates. And the extensions
being proposed here just seem like bloat to me. And John is totally correct:
Time::Object attempts to do some datetime arithmetic, but doing this sort of
thing properly for dates alone is really a tough nut to crack, and not
something that we need put in the core. There are modules out there to do
this sort of thing, lets keep it that way (or improve them enough to put in
core).

The only part of this proposal that I like is Damian's WANTHASH extension
which would allow localtime{'day', 'month', 'year'}.

I'm also really aware that trying to change localtime in an array context to
return the real year is going to be a very painful change. There are lots of
simple scripts that use localtime that I wouldn't have thought people will
want to run through the p5top6 conversion script just to get running on a
newer perl. (and then theres the issue of how you detect the addition of
1900 to the year even using the B::* stuff).

BTW: Since I'm not subscribed to p6-lang (I think you guys would kill my 64k
link!), I'd just like to say that just because strftime() is a unix-ism or
POSIX-ism, does not mean that its bad. Programmers know strftime, they've
heard of strftime, lets not try and confuse things by doing a "Java" and
inventing our own new date formatting functions with new format specifiers.
Perl is not about NIH.

-- 


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org

Re: RFC 55 (v1) Compilation: Remove requirement for fina

[Bart Lateur]

On Tue, 8 Aug 2000 07:20:41 +1000, iain truskett wrote:

>A call to people:
>
>Who here has actually used something other than a constant '1' in a
>package?
>
>If so, why? (Possibly cite the code.)

I have. Just for fun.

42; # the ultimate answer...
# see "Hitchhiker's Guide To The Galaxy"

or a string. The joke is if you think of the subjective interpretation
of how such a string evaluates to true.

"Well, at least it compiles alright."; 
# if it doesn't then this won't be true...

"Because I say so.";# Those d*mn kids...


But nothing of all that is serious in any way.

If there's a warning if a require'd or use'd file is empty, that's more
than good enough for me.

-- 
Bart.

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

[Bart Lateur]

On Mon, 07 Aug 2000 15:19:00 -0700, Peter Scott wrote:

>>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?

If you mean that you MUST use "sub", I object. If you mean that the
"sub" may not be used, I agree.

The whole thing with reminds me of FORTH's [ ... ] syntax, which
temporarily stops compilation, and the code between the square brackets
is executed instead of compiled. It maps directly to Perl's 
BEGIN { ... }. To me, it is not a sub that gets compiled and immedialy
executed.

OTOH, for END { ... }, you could say it is.

The possibility of multiple BEGIN and END blocks do distinguish it from
ordinary callback subs, though.

-- 
Bart.

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

[Bart Lateur]

On Tue, 08 Aug 2000 13:03:16 +0200, Bart Lateur wrote:

>If you mean that you MUST use "sub", I object. If you mean that the
>"sub" may not be used, I agree.

Addendum. I would propose that

BEGIN {
...
}

would be what it is now, and that

sub BEGIN {
...
}

would be just a plain user defined sub.

That's what it looks like to ordinary users unfamiliar with Perl's
current behaviour, IMO.

-- 
Bart.

Re: Things to remove

[Bryan C . Warnock]

On Tue, 08 Aug 2000, Leon Brocard wrote:
> Martyn J. Pearce sent the following bits through the ether:
> 
> > I use this in one-liners, and it's _dead_ handy
> 
> May I suggest that Perl6 will be a different language? I've seen the
> "I use it, don't change it" argument a couple of times now and it's
> not a strong enough argument. The whole point is to clean up the
> language.

Most of the requests for deletion seem to begin with, "This isn't
used..." 

To which, "*I* use it." is a very valid argument.

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

Re: RFC 20 (v1) Overloadable && and ||

[Martyn Pearce]

On Tue, Aug 08, 2000 at 01:42:40AM +, Nate Mueller wrote:
> Along the same line it would be useful to be able to overload the "truth
> operator" (bad word, I'm sorry).  It's great to be able to do:
>   
>   if ($var1 && $var2)...
> 
> But if you also want to do:
> 
>   if ($var1)...
> 
> It should be the same as:
> 
>   if (user_defined_truth($var1))...

I'm sure I'm missing something, but how does this differ from 
use overload 'bool' ?

Mx.

-- 
See, the stars are shining bright
Everything's all right tonight
-- (Martin L. Gore, Never Let Me Down Again)

Re: wildcard includes

[Graham Barr]

On Tue, Aug 08, 2000 at 10:02:35AM +0100, Piers Cawley wrote:
> "Peter Bevan" <[EMAIL PROTECTED]> writes:
> 
> > Just a thought, but I think it woul be a good idea to include the
> > 'java-esqe' practice of including packages via foo.barr.*

Hey, I'm famous :)

> However, I do like the idea of syntactic sugar to load a bunch of
> modules. I'm not sure you need the '*' though. Something like:
> 
> require Foo::Bar:: ;
> 
> Has no real meaning currently and could be taken to mean 'load all of
> the modules under Foo::Bar'. 

It does, but probbaly not what it should be

  perl -e 'require Foo::'
Can't locate Foo/.pm in @INC

  perl -e 'Foo::->new'
Can't locate object method "new" via package "Foo" at -e line 1.

So the require probably should load Foo.pm as Foo:: is treated as Foo elsewhere
in perl.

Graham.

Re: RFC 50 (v1) BiDirectional Support in PERL

[Bryan C . Warnock]

On Tue, 08 Aug 2000, Roman M . Parparov wrote:
> It's not only the browser in the end.
> It'd expand the capabilities to any output device presumed LTR.
> 
> > It sounds like a hack. Should Perl support such hacks in the core?
> > 
> > Is this sofisticated enough, or do we need something more low-level?
> > 
> > $ltr = join '', reverse split /($sequence|.)/, $rtl;
> > 
> It won't work with a mixed text, and there the pain in the ass begins.
> Numbers, Latin char strings, here we go.
> 

To explain for those who haven't handled a RTL language, numbers look
the same as in LTR for most RTL languages, and I believe numerical
prefixes also appear the same.

The number is 1,358.

alrqm ?w 1,358.

Or, to compensate for a LTR display,

.1,358 w? mqrla

Also, 

.-1,358% w? roala mqrla

I've never done anything but the simplest math in Arabic, so I don't
know if evaluation order is reversed.

x = 4 / 8;

1/2?  Or 2?

This has the potential for opening up a huge batch of problems (but
making a lot of people happy.)

The more I think about, the more I'd like to see at least hooks for
handling this.  After all, in some cases it's more than just a scalar
reverse.  Formatting, Text::Wrap, etc, for instance, has to wrap the
other way.

Perhaps a sub-list to hash out how we can do this without bloating Perl
too much?

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

Re: RFC 50 (v1) BiDirectional Support in PERL

[Roman M . Parparov]

On Tue, Aug 08, 2000 at 07:11:33AM -0400, Bryan C. Warnock wrote:
> On Tue, 08 Aug 2000, Roman M . Parparov wrote:
> 
> To explain for those who haven't handled a RTL language, numbers look
> the same as in LTR for most RTL languages, and I believe numerical
> prefixes also appear the same.
> 
Yes, the numbers representation including the minus, the comma, the
dot and the per cent are written in the regular order.

> The number is 1,358.
> 
> alrqm ?w 1,358.
> 
> Or, to compensate for a LTR display,
> 
> .1,358 w? mqrla
> 
> Also, 
> 
> .-1,358% w? roala mqrla
> 
> I've never done anything but the simplest math in Arabic, so I don't
> know if evaluation order is reversed.
> 
> x = 4 / 8;
> 
> 1/2?  Or 2?

This is a tough one. But it is known that the numerical game scores and
likewise are being written RTL. As for math, I've seen it being written
both ways. I am not a native hebrew speaker and I consulted some natives
at work and no consensus was reached. It means some expanded and very 
precise spec should be written on how a pure RTL and RTL with portions of 
LTR have to look like.

Besides, speaking of Arabic, they do have even their own digits, but then,
I think they behave just like letters.

> Perhaps a sub-list to hash out how we can do this without bloating Perl
> too much?
> 
I think not at this stage. We need to decide how important this is for
PERL and after we're done with ths more or less general stage, 
we'll roll out the Specs and then it'd be possible to start coding.

Currently, an item for the discussion IMHO is - whether to empower 
existing print to handle visual RTL output, whether to write a core 
output function rtlprint, or to reduce ourselves to a Text:: module?
I.e. - WHAT are we going to do, but not yet - HOW.

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

-- 
Roman M. Parparov - NASA EOSDIS project node at TAU technical manager.
Email: [EMAIL PROTECTED]   http://www.komkon.org/~romm
Phone/Fax: +972-(0)3-6405205 (work), +972-(0)54-629-884 (home)
--
The economy depends about as much on economists as the weather does on
weather forecasters.
-- Jean-Paul Kauffmann

RFC: Perl Switch for @INC searching

[Ed Mills]

Short of writing a perlscript to do it, searching @INC for modules can be a 
pain. How's about a switch that searches @INC for modules matching a regex 
instead of executing anything (behaves like perl -v), so for example:

  perl -M 'spook'

might return

  /usr/local/lib/perl5:
  -rw-r--r--   1 root other  13889 Mar 21  1996 spook.pl

or
  perl -M 'st\D+'

  /usr/local/lib/perl5:
  -r--r--r--   1 root other  658 Jan 11  1996 stat.pl
  -r--r--r--   1 root other   2175 Jun  4  1997 strict.pm


Just a thought.

-E

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

Re: Things to remove

[Ted Ashton]

Thus it was written in the epistle of Leon Brocard,
> Martyn J. Pearce sent the following bits through the ether:
> 
> > I use this in one-liners, and it's _dead_ handy
> 
> May I suggest that Perl6 will be a different language? 

Actually, I think the point is that Perl6 won't be a different language.  
"Improved", yes, "New", no.  There will be some syntax changes and some things
will work differently, but if something is "_dead_ handy" it needs to be at
least that handy when we get done :-).

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
The human mind has first to construct forms, independently, before we can
find them in things.
-- Einstein, Albert (1879-1955)
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 55 (v1) Compilation: Remove requirement for fina

[John Porter]

Damian Conway wrote:
> So require and do issue a warning if they require or do an empty file.
> Better that than meaningless 1;'s at the end of every module.

If we're going to be changing these things, can't we at least ensure that 
use Foo 'bar';
returns the result of the
Foo->import('bar');
which implicitly occurs?

-- 
John Porter

Re: RFC 58 (v1) C changes.

[Segher Boessenkool]

> I guess that's not yet clear to me.  After all, as I had pointed out to me,
> 
> while() 
> 
> means
> 
> while (defined($_ = ))
> 
> not 
> 
> while ($_ = )
> 
> even if the chomp() is handed an empty line, it will return a defined value.
> Only at the point at which  returns undef will the while cease.

The magic defined($_ = ) only happens if  is the only thing
inside while().

In this case, it's not (there's a chomp() inside as well), so the magic
doesn't apply.


Segher Boessenkool
East Site

Re: RFC 58 (v1) C changes.

[Ted Ashton]

Thus it was written in the epistle of Segher Boessenkool,
> 
> The magic defined($_ = ) only happens if  is the only thing
> inside while().
> 
> In this case, it's not (there's a chomp() inside as well), so the magic
> doesn't apply.

Ok.  One more time . . .

  I'm proposing that we change that.

:-),
Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
Do not worry about your difficulties in mathematics, I assure you that mine
are greater.
-- Einstein, Albert (1879-1955)
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 55 (v1) Compilation: Remove requirement for fina

[William Setzer]

iain truskett <[EMAIL PROTECTED]> writes:
: 
: Who here has actually used something other than a constant '1' in a
: package?

I have.

: If so, why? (Possibly cite the code.)

Because it's more aesthetic (and useful) for me to see:

  open '/afs/bp.ncsu.edu/path/to/no_such_file': No such file or directory
  NCSU/SomeModule.pm did not return a true value at ./make_lockers line 25.
  BEGIN failed--compilation aborted at ./make_lockers line 25.

rather than:

  open '/afs/bp.ncsu.edu/path/to/no_such_file': No such file or directory
  BEGIN failed--compilation aborted at ./make_lockers line 25.

especially if this is showing up in a cron message somewhere.  (I know
I could add the module name to the error, but I like letting perl do
it for me.  Less work for me.)


William

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

[Jonathan Scott Duff]

On Tue, Aug 08, 2000 at 09:28:17AM +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?

The same thing that happens now.  As I understand it, perl compiles
and executes the BEGIN block then detroys it so that you may have as
many BEGIN blocks as you want and each time perl thinks it's the first
one.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

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

[Jonathan Scott Duff]

On Tue, Aug 08, 2000 at 09:27:24AM +0100, Piers Cawley wrote:
> > Proposal to utilize C<*> as the prefix to magic subroutines
> 
> I freely accept that this is not anything approaching a reasoned
> critique but:
> 
> Yecch!

That comment is as good as any  :-)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

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

[John Porter]

Jonathan Scott Duff wrote:
> > But what happens if you want multiple BEGIN blocks?
> 
> The same thing that happens now.  As I understand it, perl compiles
> and executes the BEGIN block then detroys it so that you may have as
> many BEGIN blocks as you want and each time perl thinks it's the first
> one.

That's sort of a special case.  What happens with multiple END blocks?
perl must compile them and stash them in the END symbol, chained somehow.

-- 
John Porter

Error handling

[Peter Bevan]

I started writing this mail by asking:

>Does anyone else agree that perl should have support for (but not
forcefully) error handling...
>maybe a little like Java's??

>I know that sort of thing can be acheived with eval(), but surely

Which is as far as I got, because something new has occured to me...

We all know (and most of us love) the timeless Perl ideoms, such as using
eval to trap die's etc
However, with the birth of the new Perl, I think it is time to bury those
ideoms in the language and
start inventing new ones..

Error handling should be supported by it's own keyword i.e.:

trap {
  #CODE
}
release (error) {
  # ERROR
}

(just because I didn't want to steal throw and catch)

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...)

The list could go on forever... and although I accept that most of them
should stay as they are, there is a little core that should become part of
the language

What do you all think

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

[Michael Mathews]

> In a scalar context, it could produce a date object always:
>
>$date = date;
>
> However, when you went to do anything with it in a string context, it
> would call the appropriate method:
>
>print "$date"; # calls $date->STRING, which in this case would
>   # print out a ctime formatted date string


Well, I like this. It reminds me of Java's .toString method (see
http://java.sun.com/products/jdk/1.1/docs/api/java.lang.String.html ). I am
intrigued by the idea of a "scalar" context, and a "string" context though.

--Michael

RE: Error handling

[Brust, Corwin]

From: Peter Bevan [mailto:[EMAIL PROTECTED]]


>Error handling should be supported by it's own keyword i.e.:
>
>trap {
>  #CODE
>}
>release (error) {
>  # ERROR
>}


I think this is touched on by RFC# 3 wherein I ask for user definable error
messages.   With those one could presumably set an error or warning's
handler (I suggested a callback interface) to undef to ignore that error or
warning.

What I was suggesting was somthing like:

$PERL_CORE{DIE} => undef; 

die 'you can't kill me!'; # is ignored

{
$PERL_CORE{DIE} = { fatal => 0 }
die 'just a warning!';  # just produces a warning
}

die 'I\'m not dead yet!';   # back to ignoring die

$PERL_CORE{DIE} = { fatal => 'tiz true' };
die 'OK, OK, already, I'm dead';   # terminates program using CORE::die
   # and prints "OK, OK, already, I'm dead"

$PERL_CORE{DIE} = { fatal => 1, sub { CORE::die q(Bring out yer dead!) } }

die 'OK, OK, already, I'm dead';   # terminates program using 
   # $PERL_CORE{DIE}->{handler}->()
   # so it prints "Bring out yer dead!"

Not knowing much about perl internals, my propostal is quite vague, but am I
correct in assuming that what your asking for is the same, namely executing
a custom code block when a known error (and perhaps warning) is encoutered
at runtime?

As for implementation (ie: 
$PERL_CORE{SOME_ERROR} 
vs 
trap { ... } release () { ... } 
) I'm not opposed to either, but I think a few others should weigh in, then
maybe an RFC.  Also I kind of like 

catch / release 

for amusement value.

-Corwin

Re: Things to remove

[Ed Mills]

As long as were culling, might want to consider removing chomp() and 
possibly chop(). The language provides other ways to accomplish those thru a 
simple regex, and if the "println" suggestion I made was "too specific" then 
certainly chomp() is as well.

Just a thought to chomp on..


E

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

Re: Things to remove

[Simply Hao]

> might want to consider removing chomp() and possibly chop().

They're faster than regexes, right?

-Hao

Re: Things to remove

[Jonathan Scott Duff]

On Tue, Aug 08, 2000 at 03:46:45PM +, Ed Mills wrote:
> As long as were culling, might want to consider removing chomp() and 
> possibly chop().  The language provides other ways to accomplish those thru a 
> simple regex, and if the "println" suggestion I made was "too specific" then 
> certainly chomp() is as well.

TMTOWTDI.  chop() and chomp() should stay (IMHO).

Your "println" suggestion has merit though.  There's already a way to
accomplish it via a command line switch (-l), but I guess what you're
after is a language level method to turn automatic addition of
newlines on and off.  How about a new lexical pragma--newlines?


use newlines;
print "Hi"; # Automatically adds the newline
no newlines;
print "Hi"; # Does NOT automatically add the newline


-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

RE: Things to remove

[Brust, Corwin]

From: Simply Hao [mailto:[EMAIL PROTECTED]]

>> might want to consider removing chomp() and possibly chop().
>
>They're faster than regexes, right?


Dunno about faster but  so sweet.

I like 

while (<>) { print chomp } 

better then

while (<>{ 
  s/$/$//;
  print
}
and it *seems* like it would be faster

-Corwin

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

[Peter Scott]

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.

--
Peter Scott
Pacific Systems Design Technologies

sub optional for BEGIN: bad idea

[Nathan Torkington]

These aren't normal subroutines because of the way they stack.  If I
had my druthers, I'd make "sub" *forbidden* on such things.

If you wanted to make that parsable, pretend that BEGIN and END are
the names of functions with prototype (&) which register callbacks.

Nat

Re: Things to remove

[Jonathan Scott Duff]

On Tue, Aug 08, 2000 at 11:12:40AM -0500, Brust, Corwin wrote:
> From: Simply Hao [mailto:[EMAIL PROTECTED]]
> 
> >> might want to consider removing chomp() and possibly chop().
> >
> >They're faster than regexes, right?
> 
> 
> Dunno about faster but  so sweet.
> 
> I like 
> 
>   while (<>) { print chomp } 
> 
> better then
> 
>   while (<>{ 
> s/$/$//;
> print
>   }
> and it *seems* like it would be faster

Someone proposed (I think I deleted that email) to make 

while () { ...  }

work like 

while () { chomp; ... }

If this were to happen, then I'd fully support removing chomp() from
the language as long as there was a way to turn that behavior on and
off, of course. (use/no chomping anyone?)  We're going to have to
revisit chomp() anyway if we make $/ per-filehandle because chomp()
acts on strings, not filehandles.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

RE: Error handling

[Peter Scott]

At 10:33 AM 8/8/00 -0500, Brust, Corwin wrote:

>From: Peter Bevan [mailto:[EMAIL PROTECTED]]
>
>
> >Error handling should be supported by it's own keyword i.e.:
> >
> >trap {
> >  #CODE
> >}
> >release (error) {
> >  # ERROR
> >}
>

This is being hashed out on per6-language-flow right now...


--
Peter Scott
Pacific Systems Design Technologies

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

[Nathan Wiger]

> I am intrigued by the idea of a "scalar" context, and
> a "string" context though.

A string context is a special type of scalar. This distinction already
exists in Perl:

   $one = $two; # scalar (not string)
   print "$one";# string (and scalar)

-Nate

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

[Nathan Wiger]

> While I think Time::Object is a really great module, and following these
> discussions I'm thinking of adding a date() function to it

Aaah! Please don't. :-) Name it something else, por favor (or at least
wait until this is finalized and make the interface the same).

> date arithmetic...not something that we need put in the core.

I'm torn on this one. If it's efficiently done on objects, I think it's
really cool. However, it could be implemented really poorly and suck.
But I'd rather leave it in and let Larry decide to axe it (he suggested
it, after all...)

> The only part of this proposal that I like is Damian's WANTHASH extension
> which would allow localtime{'day', 'month', 'year'}.

That and returning an object in a scalar context. This is a key shift
I'd like to see in Perl 6 - embedding objects at a low-level and
translating them to strings only on demand.

> I'm also really aware that trying to change localtime in an array context to
> return the real year is going to be a very painful change.

The RFC doesn't mention localtime() for just this reason. The idea would
be localtime would be GONE in Perl 6, instead moved to Time::Local.
date() would replace it.

The syntax of localtime would remain identical. All the translation
script would have to do is add a 'use Time::Local' if localtime was
called, maybe outputting a warning message like 

  $ ./p52p6 mydatescript
  localtime() no longer in core - use date() instead [importing
Time::Local]

> I'd just like to say that just because strftime() is a unix-ism or
> POSIX-ism, does not mean that its bad. 

Yeah, this is a tough call. I agree with you, personally. When I see
strftime() I instantly know what it does. However, I think I've come up
with an alternative that's just as good. I encourage you to check out
v2, probably out by tomorrow. I think you'll like it better.

Cheers,
Nate

Re: RFC: println()

[Bart Lateur]

On Tue, 08 Aug 2000 01:29:47 GMT, Ed Mills wrote:

>I actually saw this in the newsgroups and thought it was a neat idea. What 
>about
>
>   println $textvar;
>
>instead of
>
>   print "$textvar\n";

I can currently do that with $\, and $, for strings between items. For
example:

($\, $,) = ("\n", "\t");
@ary = qw(one two three);
print @ary;

The output will be the same as if you had done:

print "one\ttwo\tthree\n";


Now, *I* expect that $, and $\ will closely be linked to each
filehandle, so that output STDERR will not have this feature enabled if
you specified it for printing to your file.

Besides, Perl has quite a few better alternatives than a bunch of
println statements, which is probably what you'd use it for. For
example: here-docs.

-- 
Bart.

Re: RFC 34 (v1) Angle brackets should not be used for fi

[Graham Barr]

On Sat, Aug 05, 2000 at 12:30:02AM -0600, Nathan Torkington wrote:
> Someone wrote:
> > > How about "Deprecate use of file globbing with angle brackets.  Emit a
> > > warning when this behaviour is used."
> 
> I want to RFC this, but I feel like starting a new language with
> deprecated behaviours is a Bad Move.  The whole damn point is so we
> can get away from all the deprecated crud in perl5.

Right, and <*.c> can be translated into glob('*.c') by the
translator, so I don't see the issue.

Graham.

Re: RFC 64 (v1) New pragma 'scope' to change Perl's defa

[Nathan Wiger]

> How usable is this ?
> 
> I may be missing something, but if every variable mentioned in an anonymous
> block is assumed to be declared with my, then how do you access or modify
> the value of any variable outside the block ?
>
> Graham.

I knew someone was going to ask this; after I sent it I realized I
should have included an example.

There's two ways I see it:

1) do {} block

   $val = do {
$x = 10;
# ... stuff happens ...
$y;
   };

In which case $val = $y.

2) explicit our() scoping

   $x = 10;
   our $y = 10;
   {
  $x = 5;   # auto-my'ed
  $y += $x; # $y already our'ed above
   }
   print "$y";  # 15

Remember, you can still override the scopes I propose with an explicit
my or our. Admittedly, 'blocks' is not nearly as big a benefit as 'subs'
is, but has some applications, particularly if you're a "likes anonymous
blocks" kind of person (which some people are).

-Nate

Re: Things to remove

[Riad Wahby]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:
>As long as were culling, might want to consider removing chomp() and 
>possibly chop(). The language provides other ways to accomplish those thru a 
>simple regex, and if the "println" suggestion I made was "too specific" then 
>certainly chomp() is as well.

Not really.  I've provided a definition of println that is simple and
fast as a subroutine.  I challenge you to do the same (remember,
fast--no regexps, sorry) for chomp and chop given neither.

And we're not culling--we're just preventing bloat.  println was never
there, so there's nothing to cull.

Riad Wahby
[EMAIL PROTECTED]
[EMAIL PROTECTED]

5105
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5kC5GiHor6RkxxqYRAkp1AJ9f774bPQD9rfMFpLO1CUn8v0CmsQCfZD2n
VjvNpVN9aD60QtLLIVZoY98=
=V5H4
-END PGP SIGNATURE-

Re: RFC 64 (v1) New pragma 'scope' to change Perl's defa

[Michael Mathews]

Graham Barr said:
> > Would result in "25" being printed out. Here's why:
> >
> >1. The C<$x = 10> is automatically scoped with its own C.
> >
> >2. The C<$x = 5> inside the B block is automatically
> >   scoped with its own C.
> >
> >3. The C<$x = 25> code, however, inside the C statement
> >   is not scoped, since it is not an B block. Since
> >   there is already an C<$x> in the current block, there is
> >   no need to rescope it.
>

> I may be missing something, but if every variable mentioned in an
anonymous
> block is assumed to be declared with my, then how do you access or modify
> the value of any variable outside the block ?

Yes, seems like we need a way to import globally scoped variables into the
block, if this were to be accepted.

In PHP, for example (see
http://php.net/manual/html/language.variables.scope.html) all variables are
considered local to their block, unless imported into a block with the
"global" keyword. I absolutely hate this though.

--Michael

Re: RFC: println()

[Riad Wahby]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:
>This is probably what I disliked most about Pascal - it presumes it
>knows best what units of output you want to write at any one time - a
>piece of a line or an entire line.  I feel this dates back to the
>mainframe world (as does the rest of Pascal I/O), and I'd prefer not to
>see this duplicated in perl...

Agreed.  Anyway, if you really want it,

sub println { print join("\n", @_), "\n"; }

or

sub println { print join(' ', @_), "\n"; }

depending on how you like multiple arguments to be handled.

Riad Wahby
[EMAIL PROTECTED]
[EMAIL PROTECTED]

5105
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5kBdPiHor6RkxxqYRAsACAJ41c94hfyKTwNr5E5VylHA5iBFFzQCcC+/b
Brf1TEdVBRyKtnpsJ43jVc4=
=g5ns
-END PGP SIGNATURE-

Re: RFC 58 (v1) C changes.

[Larry Wall]

Ted Ashton writes:
: Thus it was written in the epistle of Segher Boessenkool,
: > 
: > The magic defined($_ = ) only happens if  is the only thing
: > inside while().
: > 
: > In this case, it's not (there's a chomp() inside as well), so the magic
: > doesn't apply.
: 
: Ok.  One more time . . .
: 
:   I'm proposing that we change that.

Before we get too carried away discussing the syntax of chomp, let's
look a bit at the semantics.  What's chomp supposed to work on if we
make $/ go away?  I think any discussion of chomp without considering
how the input discipline finds line terminators is destined to be a
partial solution.  If chomp exists in Perl 6 at all, I think it would
have to be some kind of method call on the string that figures out what
the discipline determined to be the terminator *for the current line*.
(Note that under Unicode, we might well have one line terminated with a
line separator, and the next line terminated with a page separator, and
the line after that terminated with a CFLF.)

On the other end, we're constrained to be able to translate current
uses of chop and chomp to something that will work in Perl 6, so we
can't just throw them out and say the input disciplines will do it all.
Even if chop and chomp are not longer the preferred way of doing it,
we'll still have to emulate the functionality somehow.

Larry

Re: sub optional for BEGIN: bad idea

[Peter Scott]

At 10:17 AM 8/8/00 -0600, Nathan Torkington wrote:
>These aren't normal subroutines because of the way they stack.  If I
>had my druthers, I'd make "sub" *forbidden* on such things.
>
>If you wanted to make that parsable, pretend that BEGIN and END are
>the names of functions with prototype (&) which register callbacks.

I am not going to write any more RFCs at midnight.  This looks much more 
sensible in the light of morning.  I will reverse the sense of the RFC.

As to why there is still something in the symbol table after a BEGIN block 
has executed, I'll leave that for another day...

$ perl -le 'BEGIN{print"Fie!"}print $::{BEGIN}'
Fie!
*main::BEGIN

--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 58 (v1) C changes.

[Larry Wall]

Larry Wall writes:
: (Note that under Unicode, we might well have one line terminated with a
: line separator, and the next line terminated with a page separator, and

Make that paragraph separator.

Larry

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

[Dan Sugalski]

At 03:52 PM 8/7/00 -0400, Andy Dougherty wrote:
>Yes, obviously it has been used by many.  That means that the equivalent
>functionality needs to be provided somehow in the complete standard perl6
>distribution.  It doesn't mean localtime() has to be a keyword with its
>very own opcode that is part of the core language.  It could be part of a
>module.  In fact it already is in perl5:  POSIX::localtime.

Whether localtime remains a keyword is up to Larry, with advice from the list.

It's amazingly unlikely to have its own opcode anymore, though. (Not that 
it matters, as long as enough Weird Magic is provided. :)

Dan

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

Re: RFC 58 (v1) C changes.

[Nathan Wiger]

> Second, as it seems common for someone learning perl to expect
> 
>   $without_newline = chomp($previous_form);

This proposal seeks to make things more consistent, which is good, but
at the expense of being less usable, which is bad. For example, these:

   chomp;
   chomp(@file);
   chomp($val = <$STDIN>);

Now become:

   $_ = chomp;
   @file = chomp(@file);
   $val = chomp(<$STDIN>);

I don't particularly mind the last two - in fact they add some benefits
(like not modifying the original), which are nice to have. However, that
first one, frankly, drives me nuts.

I suggest a modification to this RFC: if chomp() is called without args,
it modifies $_ directly, consistent with its current implementation.
That way you can write:

   while(chomp(<$STDIN>)) {
  # do stuff with $_
   }

or:

   while(<$STDIN>) {
  chomp;
  # do stuff with $_
   }

without being forced to write:

   while($_ = chomp()) {
  # do stuff with $_ 
   }

Wow, true TMTOWTDI! I like it.

-Nate

Re: RFC 23 Higher order functions

[Andy Dougherty]

Quoting RFC 23:
> That is, the expression:
> 
> $check = __ < 2 + __ * atan($pi/__) or die __;
> 
> is equivalent to:
> 
> $check = sub (;) {
>   $_[0] < 2 + $_[1] * atan($pi/$_[3]) or die $_[4]
>   };

It strikes me that this is very fragile and limited (unless I
misunderstand, which is quite possible).  For one thing, it appears to
only be useful if your subroutine uses each argument exactly once.  If
you need to use any of the arguments more than once, you can't use this
notation.  For example, you might want to check $_[3] to be sure
$pi/$_[3] didn't end up dividing by zero.  I don't see how to to that
with the __ version.

Further, if you find you need to revise the check function in a way
that changes the order in which the arguments are used, but you don't
want to replace all the calls to $check elsewhere in your code, I
don't see how you can do that with the __ version.

Thus it seems to me that this notation doesn't really buy us very much.  
It's only useful for a very specialized set of subroutines. Of course you
have to realize I had never heard of either "higher order functions" or
"Re-currying deferred expressions" prior to reading this RFC, so it's
quite possible I'm missing something.

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

Proto-RFC: isa() function

[jmastros]

Hello all.  I'm not certian if there's a sublist that this is more approprate for, if 
so, could someone tell me what it is?  I can't see that this clearly applies to any of 
them.  Please cc me; I'm not yet subscribed to these lists (just tried again; if this 
doesn't work, the listmasters will be getting an email).

With no further ado,

=head1 TITLE

Suggested isa() operator.

=head1 VERSION
  
  Maintainer: James Mastros <[EMAIL PROTECTED]>
  Date: 08 Aug 2000
  Version: 1
  Mailing List: perl6-language
  Number: Unassigned

=head1 ABSTRACT

Currently, there is no way to determine if a scalar holds somthing that
could validly form a number/boolean/etc.  This RFC seeks to remedy that.

=head1 DESCRIPTION

The suggested semantics of the isa operator are as follows:

=over 4
=item $result = isa($obj, $type);
 TRUE VALUES:
  $result = "blessed" if $obj is blessed into the package $type.
  $result = "inherits(n)" if $obj is blessed into a package that ISA $type 
in the Nth degree.
  $result = "is a" if $obj currently has a $type value associated with it.
  $result = "can be a" if $obj could be promoted to a $type value.
  $result = "tied to a" if $obj is tied to (somthing which inherits from)
$type.
 FALSE VALUES:
  $result = 0 if $obj is not a $type, but $type is a known package or basic
 type.
  $result = undef if $type is not a known package or basic type.

 in all cases, if $type is a blessed ref, it should be taken as if ref($type)
 had been specified.  An unholy ref is invalid for $type.
=back

This is incompatable with UNIVERSAL::isa() in one case: if $obj is a
string containing the name of a package, the current C 
will do what the proposed C would do.

This, unfornatly, would not be automaticly convertable.  Therefor, it might
be better to have the existing semantics apply to C when
$obj holds the name of an existing package.  Unfornatly, this means that
you cannot apply isa() to arbitrary strings in absolute saftey.  FIXME.

=over 4
=item @result = isa($obj, $type);

@result is the lineage of $obj that leads to $type.  More exactly, it
is a list such that C.  
(Hmm, perhaps things like that are a good argument for why isa should treat $obj=a 
package name specialy.)  Also, the list will always
either be empty (if C is false), or will end in
(the cannonical form, if there is some noncannonical form of package names
or basic types).

=item $result = isa($obj);

$result is the basic type of $obj -- "INTEGER", "NUMBER", "STRING", "REF", 
"FILEHANDLE", etc.  This is it's most specific IS_xOK() (or similar) type (INTEGER 
winning over NUMBER, which wins over STRING, FILEHANDLE winning over REF, if they end 
up being different basic types).  Note that this doesn't dereference $obj or give the 
type it is blessed into; ref() is for that.  (If you want to know the basic type of 
the object that it points to, even if it is blessed, see the next form.)

=item @result = isa($obj);

This will follow the chain of refs, giving a list of the packages, etc, of each, as 
well as going into lists and hashes.  For example:

 my $foo = [14, "21"];
 my $bar = bless (\$foo, "Example::Package1");
 my $baz = bless (\$bar, "Example::Package2");

 print Data::Dumper \(isa($baz));

Will print (assuming I got the parens right on that last line):
 
 ("Example::Package2", "Example::Pacakge1", "LIST", ["INTEGER", "STRING"])

Note that the last element is a ref to the list that doing a list of 
scalar(isa($thingies)) on the thingy that has it's type mentioned in the -2th element. 
This has the possibility of producing very deep (even infinitly deep/self-referencing) 
lists, and should possibly be limited to the return of the scalar form, or ommited 
entirely.  However, completely eliminating it would mean that you couldn't find the 
types of a list of items by doing isa(\@list).  FIXME.

Also, I'm not shure what to do about tied thingies, since things can be
tied, blessed, and have subvalues all at the same time.  FIXME.

This would have to stop somewhere with recrusive and infinite (including 
non-terminating ties, infinite, and semi-finite lists/hashes) structures.  FIXME.

Note also that this has the list at the end returning the current basic type instead 
of the most specific possible basic type.  FIXME.

=back

=head1 IMPLEMENTATION

Hmm, it's nativly (and naivetély) recrusive.

=head1 UNRESOLVED ISSUES

C.

=head1 REFERENCES

L for UNIVERSAL::isa compatability
L

Re: RFC 23 Higher order functions -- macros instead?

[Andy Dougherty]

In RFC 23, Damian Conway <[EMAIL PROTECTED]> proposes a syntax for
"higher-order functions".  One example given is related to a proposed
switch statement (RFC 22).  A trimmed version is:

>   sub beverage {
>   switch (shift) {
>   case sub{ $_[0] < 10 }  { return 'milk' }
>   case sub{ $_[0] < 20 }  { return 'coke' }
>   else{ return 'milk' }
>   }
>   }

which it is proposed could be re-written as:

>   sub beverage {
>   switch (shift) {
>   case  __ < 10  { return 'milk' }
>   case  __ < 20  { return 'coke' }
>   else   { return 'milk' }
>   }
>   }

While I appreciate and applaud the attempt to solve a specific problem
with a generalized mechanism, it occurs to me that another general way to
attack this same problem might be through some sort of macro language.

As a trivial example, using CPP (*not* what I'd propose for perl6),
the switch example could be written 

#define arg_lt(X)   sub{ $_[0] < (X) }

sub beverage {
switch (shift) {
case  arg_lt(10)  { return 'milk' }
case  arg_lt(20)  { return 'coke' }
else   { return 'milk' }
}
}

I submit this is at least as clear as the __ version.

So I'd like to encourage folks to consider whether adding some sort of
(optional) macro language (perlpp ?) to perl6 would be worthwhile.
Folks with experience with a variety of macro languages would be more
qualified than I to develop an RFC on the subject, but I think it's
worth pursuing.

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

Re: Error handling

[Uri Guttman]

please move this thread to flow as we have the error RFC posted there.

thanx,

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 23 Higher order functions

[Jonathan Scott Duff]

On Tue, Aug 08, 2000 at 01:27:48PM -0400, Andy Dougherty wrote:
> It strikes me that this is very fragile and limited (unless I
> misunderstand, which is quite possible).  For one thing, it appears to
> only be useful if your subroutine uses each argument exactly once.  If
> you need to use any of the arguments more than once, you can't use this
> notation.  For example, you might want to check $_[3] to be sure
> $pi/$_[3] didn't end up dividing by zero.  I don't see how to to that
> with the __ version.
> 
> Further, if you find you need to revise the check function in a way
> that changes the order in which the arguments are used, but you don't
> want to replace all the calls to $check elsewhere in your code, I
> don't see how you can do that with the __ version.

Yep, both very valid points.  Thus somewhere buried within the thread
of discussion following this RFC was proposed positional and/or named
currying with _1, _2, _3 and/or _foo, _bar, _baz.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

default $/ (was Re: RFC: println())

[Uri Guttman]

> "BL" == Bart Lateur <[EMAIL PROTECTED]> writes:

  BL> On Tue, 08 Aug 2000 01:29:47 GMT, Ed Mills wrote:
  >> I actually saw this in the newsgroups and thought it was a neat idea. What 
  >> about
  >> 
  >> println $textvar;

i am against println. it is not so useful that i would be using it a
lot. 

  BL> Now, *I* expect that $, and $\ will closely be linked to each
  BL> filehandle, so that output STDERR will not have this feature
  BL> enabled if you specified it for printing to your file.

interesting point: we are all in agreement for filehandle specific $/
and $\. but what about global default values for those handles which hve
not had theirs set? you can still set the global $/ and affect all
handles which don't have private $/.

i like the ability to set global defaults here.

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: default $/ (was Re: RFC: println())

[Peter Scott]

At 01:46 PM 8/8/00 -0400, Uri Guttman wrote:

>interesting point: we are all in agreement for filehandle specific $/
>and $\. but what about global default values for those handles which hve
>not had theirs set? you can still set the global $/ and affect all
>handles which don't have private $/.
>
>i like the ability to set global defaults here.

If filehandles are objects, then they live in classes which could inherit 
from UNIVERSAL, no?

--
Peter Scott
Pacific Systems Design Technologies

Re: default $/ (was Re: RFC: println())

[Ted Ashton]

Thus it was written in the epistle of Uri Guttman,
> 
> interesting point: we are all in agreement for filehandle specific $/
> and $\. but what about global default values for those handles which hve
> not had theirs set? you can still set the global $/ and affect all
> handles which don't have private $/.
> 
> i like the ability to set global defaults here.

Hear, hear!  Chomp (which I still consider a useful critter :-), needs a 
$/ sort of thing to know what to chomp and the lines it chomps may or may 
not have come from a given file.

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
We come now to the question: what is a priori certain or necessary,
respectively in geometry (doctrine of space) or its foundations? Formerly we
thought everything; nowadays we think nothing. Already the distance-concept
is logically arbitrary; there need be no things that correspond to it, even
approximately.
-- Einstein, Albert (1879-1955)
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 58 (v1) C changes.

[Dan Sugalski]

At 10:12 AM 8/8/00 -0700, Larry Wall wrote:
>Ted Ashton writes:
>: Thus it was written in the epistle of Segher Boessenkool,
>: >
>: > The magic defined($_ = ) only happens if  is the only thing
>: > inside while().
>: >
>: > In this case, it's not (there's a chomp() inside as well), so the magic
>: > doesn't apply.
>:
>: Ok.  One more time . . .
>:
>:   I'm proposing that we change that.
>
>Before we get too carried away discussing the syntax of chomp, let's
>look a bit at the semantics.  What's chomp supposed to work on if we
>make $/ go away?  I think any discussion of chomp without considering
>how the input discipline finds line terminators is destined to be a
>partial solution.  If chomp exists in Perl 6 at all, I think it would
>have to be some kind of method call on the string that figures out what
>the discipline determined to be the terminator *for the current line*.

Which brings up the questions:

* What about scalars that didn't come from filehandles?
* Should the chomp function use the filehandle's current separator, or the 
one in effect when it was read?
* Do we even want to allow after-the-fact chomps, or do it automagically at 
read time?
* Is it worth the extra space per scalar to store the record separator (or 
a pointer to the filehandle holding the record separator)?

Dan

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

Re: Things to remove

[Ted Ashton]

Thus it was written in the epistle of Jonathan Scott Duff,
> 
> Someone proposed (I think I deleted that email) to make 
> 
>   while () { ...  }
> 
> work like 
> 
>   while () { chomp; ... }

I'm not sure if I'm the someone you meant, but if so, the proposal was to make

while (chomp()) { ... }

work like

while () { chomp; ... }

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
Most of the fundamental ideas of science are essentially simple, and may, as
a rule, be expressed in a language comprehensible to everyone.
-- Einstein, Albert (1879-1955)
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 58 (v1) C changes.

[Uri Guttman]

> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:

  LW> Before we get too carried away discussing the syntax of chomp,
  LW> let's look a bit at the semantics.  What's chomp supposed to work
  LW> on if we make $/ go away?  I think any discussion of chomp without
  LW> considering how the input discipline finds line terminators is
  LW> destined to be a partial solution.  If chomp exists in Perl 6 at
  LW> all, I think it would have to be some kind of method call on the
  LW> string that figures out what the discipline determined to be the
  LW> terminator *for the current line*.  (Note that under Unicode, we
  LW> might well have one line terminated with a line separator, and the
  LW> next line terminated with a page separator, and the line after
  LW> that terminated with a CFLF.)

a couple of ideas. one, i proposed we keep a global $/ and $\ for
default use by handles which haven't set their own. two, instead of
tying the chomp the string and the stream it cam from (boy would that be
easy to break), how about tying it to the handle itself?

$fh = open( );

$fh->IRS( "\r\n" ) ;

$fh->chomp( $foo ) ;

now whether chomp works on the var or returns the chomped string is
still an issue. since this chomp is an method, how about if we pass it a
reference to the var, it works on the var. else it works on the string
and returns it.

  LW> On the other end, we're constrained to be able to translate current
  LW> uses of chop and chomp to something that will work in Perl 6, so we
  LW> can't just throw them out and say the input disciplines will do it all.
  LW> Even if chop and chomp are not longer the preferred way of doing it,
  LW> we'll still have to emulate the functionality somehow.

the handle object approach can support the old way easily. a naked chomp
would assume the $/ from STDIN or the global default $/. the ref
vs. value fixes the do i return a chomped string or the count of chomped
letters.

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: Things to remove

[Bennett Todd]

2000-08-08-04:42:00 Leon Brocard:
> Martyn J. Pearce sent the following bits through the ether:
> > I use this in one-liners, and it's _dead_ handy
> 
> May I suggest that Perl6 will be a different language?

If perl6 substantially fails to fill the important roles that perl5
fills, we should stop screwing everybody up by calling it "perl",
and call it something else.

The project name "perl6" carries a presumption in most folks' mind
that this language is intended to _replace_ perl5; that after it
goes live with a stable production release, there probably won't be
much further active development of perl5, and after a few more years
at most will die off. If we intend to abandon that goal, then let's
also abandon the name perl6. I'm sure there are plenty of other
semiprecious gemstones left that haven't been claimed by languages.
Or we could use a snake, or a comedy troupe.

> I've seen the "I use it, don't change it" argument a couple of
> times now and it's not a strong enough argument.

Alone, it's not. That's why it should be accompanied by a
description of _how_ the arguer uses the feature, with the intent of
indicating how valuable it is. That lets the readers make their own
judgement about whether the feature merits removal.

The poster you are replying to said "I use this in one-liners, and
it's _dead_ handy."; that conjures up the idioms like

perl -nle 'print if 1.. ?^$?' [filename]

which barfs out only the header; replace "if" with "unless" and it
chops the head off.

And don't forget that the poster, who you were responding to,
finished up by saying:

> > Of course, if it's modularized as Dan suggests, which has no
> > effect at language level, I wouldn't be unhappy.

I.e. while it's useful, the use doesn't carry performance demands
sufficient to make a demand that it remain in the core; the poster
would be content if it were factored out into a loadable extension
module.

> The whole point is to clean up the language.

There are many intents and points to this project. As _I_ see them,
they include, in no particular order:

- cleaning up the language definition, where practical without
  losing the distinctive appeal of perl to happy perl programmers;

- cleaning up the implementation, to better support further growth,
  and possibly allow perl to better penetrate other areas (e.g.
  embedded applications);

- cleaning up the development process, to allow people who wish to
  focus on specific aspects of perl development to more easily
  concentrate their attentions; and

- adding fundamental new features to allow perl to better support
  new and different ways of programming, and new application
  domains.

-Bennett

 PGP signature

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

[Dan Sugalski]

At 02:18 PM 8/8/00 +, Perl6 RFC Librarian wrote:
>This and other RFCs are available on the web at
>   http://dev.perl.org/rfc/
>
>=head1 TITLE
>
>Objects should have builtin stringifying STRING method
>
>=head1 VERSION
>
>Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
>Date: 06 Aug 2000
>Version: 2
>Status: Developing
>Mailing List: [EMAIL PROTECTED]
>Number: 48

Is this an update to the original RFC 48 with a new title? Or is it a new 
RFC mis-numbered?

Dan

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

Re: RFC 58 (v1) C changes.

[Ted Ashton]

Thus it was written in the epistle of Nathan Wiger,
> > Second, as it seems common for someone learning perl to expect
> > 
> >   $without_newline = chomp($previous_form);
> 
> This proposal seeks to make things more consistent, which is good, but
> at the expense of being less usable, which is bad. For example, these:
> 
>chomp;
>chomp(@file);
>chomp($val = <$STDIN>);
> 
> Now become:
> 
>$_ = chomp;
>@file = chomp(@file);
>$val = chomp(<$STDIN>);
> 
> I don't particularly mind the last two - in fact they add some benefits
> (like not modifying the original), which are nice to have. However, that
> first one, frankly, drives me nuts.

Please reread the proposal.  chomp() called in void context continues to 
work exactly as it does now.  None of the above need to change.  The below
are acceptable, I suppose (with the last, perhaps, being somewhat easier
to understand than its alternative) but they aren't necessary.

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
It is here [in mathematics] that the artist has the fullest scope of his
imagination.
-- Ellis, Havelock
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

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

[Nathan Torkington]

Dan Sugalski writes:
> Is this an update to the original RFC 48 with a new title? Or is it a new 
> RFC mis-numbered?

Actually, it's an update to 49 with a slightly different title, so the
answer to both of your questions is "yes".  The 48/49 confusion has
been cleared up in the archive.

Nat

Re: Things to remove

[Hildo Biersma]

Bennett Todd wrote:
> 
> There are many intents and points to this project. As _I_ see them,
> they include, in no particular order:
> 
> - cleaning up the language definition, where practical without
>   losing the distinctive appeal of perl to happy perl programmers;
> 
> - cleaning up the implementation, to better support further growth,
>   and possibly allow perl to better penetrate other areas (e.g.
>   embedded applications);
> 
> - cleaning up the development process, to allow people who wish to
>   focus on specific aspects of perl development to more easily
>   concentrate their attentions; and
> 
> - adding fundamental new features to allow perl to better support
>   new and different ways of programming, and new application
>   domains.

As long as there is a reliable perl5-to-perl6 translator, I would
definitely include:

- Remove relatively little-used features, as long as they can still 
  be done (in some cases, maybe by including a 'perl5compat' module)
  and as long as automatic translation is Good Enough in most cases.

It would be silly to say that every one-liner must remain working or
that no one-liner should become longer.

Does anyone have a better name than 'perl5compat' for an 'old cruft'
module?

Hildo

Re: Things to remove

[Jonathan Scott Duff]

On Tue, Aug 08, 2000 at 01:53:21PM -0400, Ted Ashton wrote:
> I'm not sure if I'm the someone you meant, but if so, the proposal was to make
> 
> while (chomp()) { ... }
> 
> work like
> 
> while () { chomp; ... }

Oh.  I think I'd prefer to see chomp() go away and be replaced by
something like this:

$fh = open "foo" or die;
$fh->auto_chomp = 1;# Insert some appropriate syntax
$fh->newline = "\n";# Insert some appropriate syntax
while (<$fh>) {
...
}
close $fh;

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 58 (v1) C changes.

[Ted Ashton]

Thus it was written in the epistle of Larry Wall,
> Before we get too carried away discussing the syntax of chomp, let's
> look a bit at the semantics.  What's chomp supposed to work on if we
> make $/ go away?

Right.  But that's not yet decided :-).

>   I think any discussion of chomp without considering
> how the input discipline finds line terminators is destined to be a
> partial solution.

As is the destruction of $/ withought considering chomp ;-).

I, for one, would like to know where the assumption came from that there would
be no default filehandle.  Is it necessary that instead of typing 

  print 'Hello World.';

we need now type

  $STDOUT->print('Hello World.');

Is that not going the wrong direction?  If, on the other hand, there *is* a
default filehandle, then would it not be reasonable for chomp to use the $/
thingy associated with it?  Or, as Uri (I believe) suggests, why not have a 
global $/ which is the default for all filehandles and which chomp uses 
except on those cases where it is called as chomp(<$filehandle>) or 
chomp($_ = <$filehandle>)?

> On the other end, we're constrained to be able to translate current
> uses of chop and chomp to something that will work in Perl 6, so we
> can't just throw them out and say the input disciplines will do it all.
> Even if chop and chomp are not longer the preferred way of doing it,
> we'll still have to emulate the functionality somehow.

chop() does not, I believe, either suffer from the $/ problem or stand as an
obvious candidate to join in this proposal.  After all, there *are* uses for
the return value of chop() as it stands.

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
God is a child; and when he began to play, he cultivated mathematics. It is
the most godly of man's games.
-- Erath, V.
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 58 (v1) C changes.

[Jonathan Scott Duff]

On Tue, Aug 08, 2000 at 01:56:12PM -0400, Uri Guttman wrote:
> a couple of ideas. one, i proposed we keep a global $/ and $\ for
> default use by handles which haven't set their own.

Rather than having global $/ and $\, each filehandle has their's
defaulted to something reasonable.

> two, instead of
> tying the chomp the string and the stream it cam from (boy would that be
> easy to break), how about tying it to the handle itself?
> 
>   $fh = open( );
> 
>   $fh->IRS( "\r\n" ) ;
> 
>   $fh->chomp( $foo ) ;
> 
> now whether chomp works on the var or returns the chomped string is
> still an issue. since this chomp is an method, how about if we pass it a
> reference to the var, it works on the var. else it works on the string
> and returns it.

How about $fh->chomp($string); modifies the string and returns the
what it removed?  This could be useful if "end of line" varies while
reading from a single stream.

As an aside:

How do we get at the magic <> filehandle or its settings.  Would we
usurp $ARGV to be the object and $ARGV->filename to do what $ARGV
currently does?

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 58 (v1) C changes.

[Ted Ashton]

Thus it was written in the epistle of Jonathan Scott Duff,
> On Tue, Aug 08, 2000 at 01:56:12PM -0400, Uri Guttman wrote:
> > a couple of ideas. one, i proposed we keep a global $/ and $\ for
> > default use by handles which haven't set their own.
> 
> Rather than having global $/ and $\, each filehandle has their's
> defaulted to something reasonable.

I think that the point of the global $/ and $\ was to define "reasonable."

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
A Mathematician is a machine for turning coffee into theorems.
-- Erdos, Paul
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 62 (v1) Wildcards for multiple module imports

[Chaim Frenkel]

I don't like it.

There is currently nothing preventing author B from adding something
to the Foo::Bar hierarchy and infecting the other modules.

This would require two authors that currently do not have to
coordinate with each other to be careful.

Another problem is that an external change would have an unexpected
effect on the application.



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

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

PRL> =head1 TITLE

PRL> Wildcards for multiple module imports

PRL> The option to load modules thus:

PRL> use Foo::*  [The '*' character isn't very pleasant, any sugestions??]
PRL> or
PRL> use Foo::Bar::* [An alternate Foo::, has been sugested]
PRL> etc

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

Re: RFC 58 (v1) C changes.

[Michael Mathews]

Dan Sugalski said:
> Which brings up the questions:
>
> * What about scalars that didn't come from filehandles?
> * Should the chomp function use the filehandle's current separator, or the
> one in effect when it was read?
> * Do we even want to allow after-the-fact chomps, or do it automagically
at
> read time?

YES, of course!

> * Is it worth the extra space per scalar to store the record separator (or
> a pointer to the filehandle holding the record separator)?
>

What about a
chomp($foo, '\r\n');
# or
chomp(, '\r\n');
syntax. The default for the second argument could be defined in a global
special variable so that "chomp $foo" would be equiv to "chomp $foo, $/" or
something.

I like the Java trim() function ( see
http://java.sun.com/products/jdk/1.1/docs/api/java.lang.String.html#trim() )
which removes whitespace from either end of the string.

Re: RFC 58 (v1) C changes.

[Jonathan Scott Duff]

On Tue, Aug 08, 2000 at 02:16:57PM -0400, Ted Ashton wrote:
> I, for one, would like to know where the assumption came from that there would
> be no default filehandle.  

I believe Larry said he was probably going to axe it.

> Is it necessary that instead of typing 
> 
>   print 'Hello World.';
> 
> we need now type
> 
>   $STDOUT->print('Hello World.');
> 
> Is that not going the wrong direction?  

Indeed it is.  However, print() could be prototyped to take an
optional first argument that has a default value of $STDOUT (or
whatever we call it)  Getting rid of default filehandles will make
this not work:

select($STDERR);# Perl 6 Error
print "Oops!";  # Always goes to STDOUT

but that can always be replaced with

print $STDERR "Oops!";

or even 

local $STDOUT = $STDERR;
print "Oops!";

programmatically.

Of course we could define chomp() to have an optional first argument
that is the filehandle to do the chomping on too.  These sorts of
decisions will have to be made on a per-subroutine basis rather than
having some global $/ that affects many different subroutines.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Things to remove

[Russ Allbery]

Bennett Todd <[EMAIL PROTECTED]> writes:

> The poster you are replying to said "I use this in one-liners, and it's
> _dead_ handy."; that conjures up the idioms like

>   perl -nle 'print if 1.. ?^$?' [filename]

> which barfs out only the header; replace "if" with "unless" and it
> chops the head off.

Why do you need one-time matching here?  /^$/ should work fine.

I've very rarely found cases where ?? was useful and // didn't work, and
never in regular code.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 58 (v1) C changes.

[Uri Guttman]

> "TA" == Ted Ashton <[EMAIL PROTECTED]> writes:

  TA> Thus it was written in the epistle of Jonathan Scott Duff,
  >> On Tue, Aug 08, 2000 at 01:56:12PM -0400, Uri Guttman wrote: > a
  >> couple of ideas. one, i proposed we keep a global $/ and $\ for >
  >> default use by handles which haven't set their own.
  >> 
  >> Rather than having global $/ and $\, each filehandle has their's
  >> defaulted to something reasonable.

  TA> I think that the point of the global $/ and $\ was to define
  TA> "reasonable."

yup.

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

this makes perl5 bahavior the default which is nice and gives perl6 more
control with the handle specific vars.

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.

[Brust, Corwin]

From: Ted Ashton [mailto:[EMAIL PROTECTED]]
>> I don't particularly mind the last two - in fact they add some benefits
>> (like not modifying the original), which are nice to have. However, that
>> first one, frankly, drives me nuts.
>
>Please reread the proposal.  chomp() called in void context continues to 
>work exactly as it does now.  None of the above need to change.  


give our code is:

for (chomp(<>)) { print }
I'm finding this use of void context confusing.  

Normaly I would take that to mean that the caller has provided a context for
the call, however this is obvously not the case here. I beleive that for()
calls chomp in array context.  

Even if I had used while() as my example, chomp would have had a calling
context.

Would someone be kind enought to explain 'void context' as used above?

-Corwin

Re: default $/ (was Re: RFC: println())

[Jonathan Scott Duff]

On Tue, Aug 08, 2000 at 01:46:41PM -0400, Uri Guttman wrote:
> interesting point: we are all in agreement for filehandle specific $/
> and $\. but what about global default values for those handles which hve
> not had theirs set? you can still set the global $/ and affect all
> handles which don't have private $/.

That word "global" bothers me.  We can have default settings for
$STDIN, $STDOUT, $STDERR that vary as well as default settings on
filehandles opened by the user.  But changing $/ shouldn't affect all
of them.  $/ should go away.

MHO,

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 58 (v1) C changes.

[Dan Sugalski]

At 02:29 PM 8/8/00 -0400, Michael Mathews wrote:
>Dan Sugalski said:
> > Which brings up the questions:
> >
> > * What about scalars that didn't come from filehandles?
> > * Should the chomp function use the filehandle's current separator, or the
> > one in effect when it was read?
> > * Do we even want to allow after-the-fact chomps, or do it automagically
>at
> > read time?
>
>YES, of course!

That last was an "A or B" sort of question. Yes is rather ambiguous. :)

> > * Is it worth the extra space per scalar to store the record separator (or
> > a pointer to the filehandle holding the record separator)?
> >
>
>What about a
> chomp($foo, '\r\n');
> # or
> chomp(, '\r\n');
>syntax.

Looks an awful lot like:

   s/\r\n//;

to me...


Dan

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

Re: default $/ (was Re: RFC: println())

[Jonathan Scott Duff]

On Tue, Aug 08, 2000 at 01:50:35PM -0400, Ted Ashton wrote:
> Hear, hear!  Chomp (which I still consider a useful critter :-), needs a 
> $/ sort of thing to know what to chomp and the lines it chomps may or may 
> not have come from a given file.

Chomping *is* useful, but it's a per-filehandle thingy.

If the line it chomps isn't coming from a file, where does it come
from?  (s/file/any form of IO/ because that's what we're really
talking about)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: default $/ (was Re: RFC: println())

[Uri Guttman]

> "JSD" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes:

  JSD> On Tue, Aug 08, 2000 at 01:46:41PM -0400, Uri Guttman wrote:
  >> interesting point: we are all in agreement for filehandle specific
  >> $/ and $\. but what about global default values for those handles
  >> which hve not had theirs set? you can still set the global $/ and
  >> affect all handles which don't have private $/.

  JSD> That word "global" bothers me.  We can have default settings for
  JSD> $STDIN, $STDOUT, $STDERR that vary as well as default settings on
  JSD> filehandles opened by the user.  But changing $/ shouldn't affect
  JSD> all of them.  $/ should go away.

the key word besides global is default. this would be the value used by
any new filehandle created. you can override that at anytime in that
filehandle. otherwise the default value for $/ for new handles will be
hardcoded in %CONFIG or something like that. the global aspect was meant
to show it was the default for ALL new handles. i don't care if it is in
$/ or some new place.

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: default $/ (was Re: RFC: println())

[Jonathan Scott Duff]

On Tue, Aug 08, 2000 at 02:44:59PM -0400, Uri Guttman wrote:
> the key word besides global is default. this would be the value used by
> any new filehandle created. you can override that at anytime in that
> filehandle. otherwise the default value for $/ for new handles will be
> hardcoded in %CONFIG or something like that. the global aspect was meant
> to show it was the default for ALL new handles. i don't care if it is in
> $/ or some new place.

Yes, yes, you are right ... I was suffering from perl 5 myopia.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

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

[Damien Neil]

On Tue, Aug 08, 2000 at 09:46:04AM -0700, Nathan Wiger wrote:
> The RFC doesn't mention localtime() for just this reason. The idea would
> be localtime would be GONE in Perl 6, instead moved to Time::Local.
> date() would replace it.

Why is this a good idea?  Perl programs have been using localtime() for
over a decade.  Why do we suddenly want to make them all obsolete?  Is
the goal of Perl 6 really to require that every Perl program in creation
be rewritten?

I'm all for adding a new and improved time mechanism with a bit less
of the oddness localtime() carries, but does it really hurt us to leave
the old style in the core?

>   $ ./p52p6 mydatescript
>   localtime() no longer in core - use date() instead [importing
> Time::Local]

It would be a horrible idea to have every existing Perl program spit
out reams of warnings whenever running under Perl 6.

Let's keep Perl Perl.  Clean up the internals, yes.  Remove deprecated
features, yes.  Add nifty new functionality, yes.  Change everything
that looks the slightist bit ugly?  Please, no.

I would humbly offer that Perl 6 should run at least 90% of all old
Perl 5 scripts, without translation or compatability modules.  If it
doesn't, how can it be called Perl?

- Damien

Re: RFC 58 (v1) C changes.

[Ted Ashton]

Thus it was written in the epistle of Brust, Corwin,
> 
> From: Ted Ashton [mailto:[EMAIL PROTECTED]]
> >> I don't particularly mind the last two - in fact they add some benefits
> >> (like not modifying the original), which are nice to have. However, that
> >> first one, frankly, drives me nuts.
> >
> >Please reread the proposal.  chomp() called in void context continues to 
> >work exactly as it does now.  None of the above need to change.  
> 
> give our code is:
> 
> for (chomp(<>)) { print }
> I'm finding this use of void context confusing.  
> 
> Normaly I would take that to mean that the caller has provided a context for
> the call, however this is obvously not the case here. I beleive that for()
> calls chomp in array context.  
> 
> Even if I had used while() as my example, chomp would have had a calling
> context.
> 
> Would someone be kind enought to explain 'void context' as used above?

But you snipped the examples of void context.  Things like:

  chomp;

and

  chomp($var);

while (chomp(<>)) { } gets magically changed (as previously described),

for(chomp(<>)) pulls in all the lines of <>, chomps each one and iterates over
the resulting list (actually, I hadn't thought about it before, but that' what
makes sense to me :-).

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
If a nonnegative quantity was so small that it is smaller than any given
one, then it certainly could not be anything but zero. To those who ask what
the infinitely small quantity in mathematics is, we answer that it is
actually zero. Hence there are not so many mysteries hidden in this concept
as they are usually believed to be. These supposed mysteries have rendered
the calculus of the infinitely small quite suspect to many people. Those
doubts that remain we shall thoroughly remove in the following pages, where
we shall explain this calculus.
-- Euler, Leonhard (1707 - 1783)
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 58 (v1) C changes.

[Michael Mathews]

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".

> >What about a
> > chomp($foo, '\r\n');
> > # or
> > chomp(, '\r\n');
> >syntax.
>
> Looks an awful lot like:
> s/\r\n//;
> to me...

Yep. It should-- that's all chomp does afterall. The difference is that the
proposed chomp should be smarter than a regex, since it will assume certain
defaults, that is: "chomp;" should act like "chomp($_, $/)"; If, however you
wanted to explicitly say something different you could.

--Michael

Re: wildcard includes

[Steve Simmons]

I'm working on an RFC on module versioning.  It'd be done by now, except
my boss and family keep expecting me to work and be fatherly.  :-)  Let
me get that banged out, and then lets look at adding wildcards to it.

Re: sub optional for BEGIN: bad idea

[John Porter]

Nathan Torkington wrote:
> These aren't normal subroutines because of the way they stack.  If I
> had my druthers, I'd make "sub" *forbidden* on such things.

I like that idea.  But then, they also shouldn't go into the symbol table.
At least, not as CODE.


> If you wanted to make that parsable, pretend that BEGIN and END are
> the names of functions with prototype (&) which register callbacks.

I agree ... except that, in perl5 at least, you'd need a terminating
semicolon if that analogy were 100% accurate.


-- 
John Porter

Re: RFC 58 (v1) C changes.

[Uri Guttman]

> "MM" == Michael Mathews <[EMAIL PROTECTED]> writes:

  >> >What about a > chomp($foo, '\r\n'); > # or > chomp(, '\r\n');
  >> >syntax.
  >> 
  >> Looks an awful lot like: s/\r\n//; to me...

  MM> Yep. It should-- that's all chomp does afterall. The difference is
  MM> that the proposed chomp should be smarter than a regex, since it
  MM> will assume certain defaults, that is: "chomp;" should act like
  MM> "chomp($_, $/)"; If, however you wanted to explicitly say
  MM> something different you could.

but chomp is faster as it is not a compiled regex, it is anchored to the
end of the string. so all it has to do is a simple rindex and if it
matches the line (or paragraph) terminator there, chomp at that
point. since chomp traditionally modifies its argument (as i think it just
changes the internal length of the string) it is faster there compared
to s///.

so here is my full take:

bare chomp:

uses the global default $/. (or maybe the $/ of STDIN or the magic <>)

if a scalar string arg, it chomps and returns the new (possibly shorter)
string.

if a ref to a scalar, it chomps in place. return the ref? the chomped
char count?

2nd arg chomp:

that extra arg specifies the string to be chomped.

OO chomp:

this is a method of a filehandle object. the string to chomp is take
from the filehandle or the global default $/. if a second arg is passed
or the main arg is a ref, then the above behaviors work as well.

i think that sums it up well.

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: sub optional for BEGIN: bad idea

[Nathan Torkington]

John Porter writes:
> > If you wanted to make that parsable, pretend that BEGIN and END are
> > the names of functions with prototype (&) which register callbacks.
> 
> I agree ... except that, in perl5 at least, you'd need a terminating
> semicolon if that analogy were 100% accurate.

I realized that after I sent it :)

I'm chewing over an RFC on giving you more control over the
compile-time and run-time nature of functions.  One possibility is to
define an attribute for subroutines that means they're BEGIN-like:

  sub CLEANUP :immediate :blockish (&) {
push(@cleanup_handlers, @_);
  }
  END {
print "Starting cleanup\n";
foreach (@cleanup_handlers) {
  &$;
}
  }

  CLEANUP { unlink $tempfile }
  CLEANUP { close SOCKET }

C would:
 - be called at compile-time (:immediate)
 - not need a semicolon (:blockish)

I'm just not sure whether this is an itch that needs to be scratched.

Nat

Re: RFC 64 (v1) New pragma 'scope' to change Perl's defa

[Ariel Scolnicov]

Nathan Wiger <[EMAIL PROTECTED]> writes:

> > How usable is this ?
> > 
> > I may be missing something, but if every variable mentioned in an anonymous
> > block is assumed to be declared with my, then how do you access or modify
> > the value of any variable outside the block ?
> >
> > Graham.
> 
> I knew someone was going to ask this; after I sent it I realized I
> should have included an example.
> 
> There's two ways I see it:
> 
> 1) do {} block
> 
>$val = do {
> $x = 10;
> # ... stuff happens ...
> $y;
>};
> 
> In which case $val = $y.
> 
> 2) explicit our() scoping
> 
>$x = 10;
>our $y = 10;
>{
>   $x = 5;   # auto-my'ed
>   $y += $x; # $y already our'ed above
>}
>print "$y";  # 15

This example scares me.  It means that every time I add a `my' or an
`our' line to my program, to add another local variable (sorry,
fluid-let should *really* be called `now'), I have to run along the
entire program and see if I happened to use that variable name
somewhere else, expecting it to be local to that block.  Will this
also apply to `use scope 'subs''?

I, for one, will *never* use such a construct.  It provides the user
with the dangers of `no strict' combined with the illusion of safety
of `use strict'.  

> Remember, you can still override the scopes I propose with an explicit
> my or our. Admittedly, 'blocks' is not nearly as big a benefit as 'subs'
> is, but has some applications, particularly if you're a "likes anonymous
> blocks" kind of person (which some people are).

Only you must make *very* sure that the variable name you're using in
your block is used *nowhere* else.  So it's every bit as bad as using
a global variable -- the name must be unique.

-- 
Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED]
Compugen Ltd.  |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`-
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels

Re: RFC 58 (v1) C changes.

[Ted Ashton]

Thus it was written in the epistle of Uri Guttman,
> 
> if a ref to a scalar, it chomps in place. return the ref? the chomped
> char count?

. . . the point of the RFC was to propose making chomp()'s behaviour change
depending on context.

Here's the summary so far as I can tell:

One-argument chomp():
  void context:
no argument: 
  chomp()s $_ using one of (global $/, $/ of current filehandle, depending
upon other implementation choices 
(called $/? below))
scalar: 
  chomp()s value in scalar using $/?
array:
  chomp()s each element of array using $/?
hash:
  chomp()s each value (not key) of hash using $/?
reference to one of the above:
  does the appropriate thing to the referenced variable (I believe that's
what was suggested)
otherwise does nothing except perhaps producing a warning
  while(chomp(<>)) and friends:
does the appropriate sort of while(<>) { chomp; } thing
  scalar or list context:
returns the chomp()ed value of the argument (see above).
  As an OO filehandle method:
does as above, but using the $/ associated with the filehandle.
two-argument chomp(): 
does as above, but using the second argument (which is a scalar, not a
   regex)

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
An expert problem solver must be endowed with two incompatible qualities, a
restless imagination and a patient pertinacity.
-- Eves, Howard W.
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 55 (v1) Compilation: Remove requirement for fina

[Damian Conway]

   > If there's a warning if a require'd or use'd file is empty, that's more
   > than good enough for me.

Already added to V2 of the RFC.

Damian

Re: Things to remove

[Damian Conway]

   > 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.

Damian

Re: RFC 58 (v1) C changes.

[Uri Guttman]

> "TA" == Ted Ashton <[EMAIL PROTECTED]> writes:

  TA> One-argument chomp():

  TA> array:
  TA>   chomp()s each element of array using $/?

  TA> two-argument chomp(): 
  TA> does as above, but using the second argument (which is a scalar, not a
  TA>regex)

how do you tell the above two apart? by array do you mean only an array
variable? then you can't chomp a list of scalar values or multiple
arrays, etc.

this needs to be clarified.

but the overall flavor seems good to me. a very smart chomp. boy, just
think if simple chomp gets this smart, what the hell will happen to some
of the more complex ops? they will be damianed! :-)

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.

[Ted Ashton]

Thus it was written in the epistle of Uri Guttman,
> 
> how do you tell the above two apart? by array do you mean only an array
> variable? then you can't chomp a list of scalar values or multiple
> arrays, etc.
> 
> this needs to be clarified.

Quite true.  The two-argument one is new to me and I hadn't thought much 
about it.  Do you have a suggestion?

> but the overall flavor seems good to me. a very smart chomp. boy, just
> think if simple chomp gets this smart, what the hell will happen to some
> of the more complex ops? they will be damianed! :-)

:-).

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
One is hard pressed to think of universal customs that man has successfully
established on earth. There is one, however, of which he can boast the
universal adoption of the Hindu-Arabic numerals to record numbers. In this
we perhaps have man's unique worldwide victory of an idea.
-- Eves, Howard W.
Note: In Asia the Hindu-Arabic numerals have not yet been adopted as standard
notation.
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted