Re: Permanent sublists (was Re: Language WG report, August 16th 2000)

[skud]

On Wed, Aug 16, 2000 at 11:15:40PM -0700, Peter Scott wrote:
>
>Sorry I didn't chime in earlier, but I would like to say that I prefer 
>published deadlines.  Reason: people will talk for as long as you give 
>'em.  However long a meeting is scheduled for, that's how long it will 
>take.  We're already reaching the point of diminishing returns in several 
>discussions IMHO; if we let 'em drag on forever they may turn ugly.
>
>Besides, the -internals folk are waiting to see what they need to get going 
>on.  And I would think we'd want a time when we knew Larry could get going 
>on the RFCs without wondering whether something else was going to romp out 
>of the starting gate.

Well, there is a "hard" deadline set in the Project Plan / Roadmap, of
September 30th.

K.

-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Re: Permanent sublists (was Re: Language WG report, August 16th 2000)

[Peter Scott]

At 04:12 PM 8/17/00 +1000, [EMAIL PROTECTED] wrote:
>On Wed, Aug 16, 2000 at 10:35:09AM -0700, Nathan Wiger wrote:
> >I agree. I think the trend should be to establish some permanent
> >sublists, which we're informally leaning towards already. Something
> >like:
> >
> >   -io   = ALL I/O issues, like open/socket/filehandles
> >   -subs = ALL sub/method/func issues, like lvalue subs
> >   -strict   = ALL lexical/global variable scoping issues
> >   -objects  = ALL OO and module issues
> >   -flow = ALL flow/threading issues
> >   -errors   = ALL error handling issues
> >   -datetime = ALL date/time/etc issue
>
>Yup, this works for me.
>
>Ask, can you change the deadlines on these lists to be "as long as it
>takes" or similar?

Sorry I didn't chime in earlier, but I would like to say that I prefer 
published deadlines.  Reason: people will talk for as long as you give 
'em.  However long a meeting is scheduled for, that's how long it will 
take.  We're already reaching the point of diminishing returns in several 
discussions IMHO; if we let 'em drag on forever they may turn ugly.

Besides, the -internals folk are waiting to see what they need to get going 
on.  And I would think we'd want a time when we knew Larry could get going 
on the RFCs without wondering whether something else was going to romp out 
of the starting gate.
--
Peter Scott
Pacific Systems Design Technologies

Re: Permanent sublists (was Re: Language WG report, August 16th 2000)

[skud]

On Wed, Aug 16, 2000 at 10:35:09AM -0700, Nathan Wiger wrote:
>I agree. I think the trend should be to establish some permanent
>sublists, which we're informally leaning towards already. Something
>like:
>
>   -io   = ALL I/O issues, like open/socket/filehandles
>   -subs = ALL sub/method/func issues, like lvalue subs
>   -strict   = ALL lexical/global variable scoping issues
>   -objects  = ALL OO and module issues
>   -flow = ALL flow/threading issues
>   -errors   = ALL error handling issues
>   -datetime = ALL date/time/etc issue

Yup, this works for me.

Ask, can you change the deadlines on these lists to be "as long as it
takes" or similar?

K.

-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument

[skud]

On Tue, Aug 15, 2000 at 08:05:25PM -, Perl6 RFC Librarian wrote:
>=head1 TITLE
>
>lvalue subs should receive the rvalue as an argument
>
>=head1 VERSION
>
>Maintainer: Andy Wardley <[EMAIL PROTECTED]>
>Date: 15 Aug 2000
>Version: 1
>Mailing List: [EMAIL PROTECTED]
>Number: 107

I think discussion of this RFC should be on the -subs sublist, yesno?

K.

-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Re: error handling and syntax extension

[skud]

On Wed, Aug 16, 2000 at 12:15:30PM -0500, David L. Nicol wrote:
>
>If "catch" can be defined DURING PARSING
>
>and SYNTAX ERRORS are catchable
>
>error handling can be used to define otherwise
>undefined syntax, becoming a macro language.

Please take this to the -errors sublist.  Thanks...

K.

-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

RE: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Henrik Tougaard]

Jarkko Hietaniemi [mailto:[EMAIL PROTECTED]] wrote:
> 
> On Wed, Aug 16, 2000 at 09:49:36AM -0400, Stephen P. Potter wrote:
> > Lightning flashed, thunder crashed and Jonathan Scott Duff 
> <[EMAIL PROTECTED]> whispered:
> > | Um, it's not guaranteed to blow up in 2038.  That's an 
> implementation
> > | detail.  IF we implement our time values as 64-bit integers (for
> > | instance), we'll long out-live the 2038 deadline.
> > 
> > I don't know about anyone else, but I don't intend to care 
> by the time the
> > 2038 deadline comes around.  ;-)  I hope to still be alive 
> and enjoying my
> > grandchildren by then, but I really hope to not be still 
> programming!
> 
> That must sound awfully similar to what the COBOL programmers in the
> 60's said when they figured that two digits is enough :-)
> 
And the 2038 deadline won't hit us in 2038, it will do it evil work long
before that.
I have been hit by it some years ago, trying to calculate the 67'th
birthday of a person that was 18 years old.
Solution: switch to the Date::Calc module for all date calculations
and just use time() for short term timings, where the range is just
a few days.
This way the epoch just doesn't matter! Is would be nice for time() to
return a value that has a good precision (1 second is normally not enough),
and a reasonable range (eg a dozen centuries each way from now).


Henrik Tougaard - FOA, Denmark.

RFC 113 (v2) Better constants and constant folding

[Perl6 RFC Librarian]

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

=head1 TITLE 

Better constants and constant folding

=head1 VERSION

Maintainer: John Siracusa <[EMAIL PROTECTED]>
Date: Aug 15 2000
Last-Modified: Aug 16 2000
Version: 2 
Mailing List: [EMAIL PROTECTED]
Number: 113
Status: Retired

=head1 STATUS

This has been integrated with RFC 83.

This RFC was retracted by the author on 16 Aug 2000.

=head1 ABSTRACT

There are many ways to use named "constants" in Perl, but they all have
drawbacks: runtime initialization costs, the extra overhead of loading
another module, the inability to use the constants in certain situations,
and so on.

Constants should be first-class citizens in Perl, and should be constant
folded with a vengeance by a clever compiler.

=head1 DESCRIPTION

An ideal Perl constant can be used anywhere that a Perl variable of the
same type can be used: a constant scalar can be used in place of any
scalar, a constant array can be used in place of any array, and so on.
These constants should not incur runtime inefficiencies or undue
compile-time overhead.  Performance should be should be exactly as if the
data was hard-coded in place.

=head1 IMPLEMENTATION

The simplest solution is something like:

constant $PI = 3.14159265;

This looks shockingly similar to the current, much maligned (by me, anyway)
constant module:

use constant PI => 3.14159265;

but the former has many syntactic advantages.  First, there's no "use"
directive to reveal the constant's second-class citizenship.  Second, it
uses the assignment operator instead of the "fancy comma."  Third, context
is determined by the left-hand-side of the assignment operator instead of
always being forced into list context.

Using these constants is simple.  They behave just like variables of the
same type.

print "Would you like some apple $PI?"; # A constant string

That whole string is converted to a single constant at compile time.
Collections behave in a similar manner:

constant @FISH = (1, 2, 'red', 'blue');

print @FISH;   # prints "12redblue"
print "@FISH"; # prints "1 2 red blue"

print "$FISH[2] head"; # prints "red head"

Again, each argument to C is converted to a constant string at
compile time.

Modification of a constant is a compile-time error:

$PI = 5;   # Bzzt!
$PI =~ s/\.\d+$//; # Sorry
$#FISH = 15;   # Nice try

The C keyword should work when combined with C and C:

package Foo;

our constant $GOO = 5;

if(...)
{
  my constant $GOO = 10;
  
  print $GOO; # Prints 10
}

As an added implementation bonus, "constant methods" should be supported
in the same way that "constant subroutines are now.

package MyConstants;
constant $PI = 3.14159265;

package MyClass;
...
sub method { $MyConstants::PI }

package MyLib;
...
sub func { $MyConstants::PI } # Shouldn't have to be sub func() ...

Both C and C should know that they return constants,
and the compiler should optimize them away whenever possible, even without
explicit hints like an empty "()" prototype after C.  Yes, there
are issues with turning a method call into a constant at compile time, but
it's possible if Perl can determine with certainty that C
is the actual code that will be executed by an object or class method call.
Example:

my $obj = MyClass->new;

print $obj->method();# Converted to the constant 3.14159265
print MyClass->method(); # Ditto

Again, this magic is accomplished by a clever compiler that does not need
this type of help:

my MyClass $obj = MyClass->new; # Not necessary, ideally

As should be clear by now, I'm not too familiar with the perl internals
that are required to support this stuff.  It just "seems possible" to me.
And hey, there are no "perl internals" to speak of yet in a "clean-sheet"
implementation, right?

=head1 REFERENCES

Perl's C pragma documentation.

Hashes vs arrays (was Re: RFC 84 (v1) Replace => (stringifying comma) with =>)

[Jeremy Howard]

Chaim Frenkel wrote:
> > "KH" == Kai Henningsen <[EMAIL PROTECTED]> writes:
>
> KH> Hashes and arrays, OTOH, really aren't different for people. The
concept
> KH> of an index needing to be a nonnegative number is a computer concept.
>
> I don't know about that. Good old PL/I had arbitrary ranges for array
> indices.
>
> Hmm, I feel an RFC coming on
>
> my @arr :low(-32000) :high(+32000);
> my @population :low(1900) :high(2039);
>
> $population[1923] = 323000;
>
> How about
>
> my @population[1900:2039];
>
> Looks funny though.
>
I'm quite fond of the idea of negative array indices. But don't you touch my
precious C<:> operator, or I'll send in the hounds! I want its sanctity
recognised for the purpose of the notation in RFC 81:

  http://tmtowtdi.perl.org/rfc/81.pod

PS: Do you ever get the impression that some people will take every chance
possible to segue all threads into a discussion of their own RFCs? ;-)

Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)

[Chaim Frenkel]

> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:

NW> The concept isn't that hard ":lvalue makes it so you can assign to
NW> subs". But the hard part is deciding *where* it should be used. I think
NW> it puts an unfair burden on a CPAN author to try and forsee all the
NW> possible uses of a sub.

I'm sorry but this doesn't make sense?

$foo->twiddle = 42;

What if twiddle is my scramble eggs routine? Why are you assigning a value.

The author decides how his routines are to be used. You the client likes
it great. You think there is a better _approach_ then tell the author.

You are limited by what the author wrote.


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

Re: RFC 83 (v2) Make constants look like variables

[Chaim Frenkel]

> "JS" == John Siracusa <[EMAIL PROTECTED]> writes:

JS> On 8/16/00 12:37 PM, Perl6 RFC Librarian wrote:

>> It is proposed that a new syntax for declaring constants be introduced:
>> 
>> my $PI : constant = 3.1415926;
>> my @FIB : constant = (1,1,2,3,5,8,13,21);
>> my %ENG_ERRORS : constant = (E_UNDEF=>'undefined', E_FAILED=>'failed');
>> 
>> Constants can be lexically or globally scoped (or any other new scoping
>> level yet to be defined).

JS> I'm not crazy about the "attribute" syntax's use for constants.  I prefer
JS> this:

JS> constant $PI = 3.1415926;

Propose it but I believe that Larry has already semi-blessed the attribute
version.

The problem with the prefix version is that that is already reserved for
my/our/local. 

And constant-ness in my mind is an attribute or modifer of the value
or perhaps of the container. It has no bearing on the scoping or type
of the value.


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

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Chaim Frenkel]

> "KH" == Kai Henningsen <[EMAIL PROTECTED]> writes:

KH> Hashes and arrays, OTOH, really aren't different for people. The concept  
KH> of an index needing to be a nonnegative number is a computer concept.

I don't know about that. Good old PL/I had arbitrary ranges for array
indices.

Hmm, I feel an RFC coming on

my @arr :low(-32000) :high(+32000);
my @population :low(1900) :high(2039);

$population[1923] = 323000;

How about

my @population[1900:2039];

Looks funny though.


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

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Chaim Frenkel]

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

JSD> On Wed, Aug 16, 2000 at 12:48:12PM -0400, Dan Sugalski wrote:
>> At 11:09 AM 8/16/00 -0400, John Porter wrote:
>> >The difference between numbers and strings is analogous to --
>> >or, on further reflection, IDENTICAL to -- the difference between
>> >arrays and associative arrays.  (The former are numerically indexed,
>> >the latter indexed by strings.)
>> 
>> The analogy doesn't hold. And people treat arrays and hashes *very* 
>> differently, far more so than the trivial differences in the notation might 
>> lead you to believe.

JSD> Could you come up with concrete examples that illustrate this point?
JSD> What would stop people from treating arrays and hashes differently if
JSD> the trivial notational differences are removed?

In a hash exists() is a valid concept. In an array (even a sparse one)
exists() has no meaning. The data is always there. The sparsity is
an implementational detail.

A hash has symbols, names, things. An array has just numbers[*].



[*] Anyone remember "Secret Agent Man", "they given you a number and 
takin' way your name.

What was the name of the show? "Secret Agent"? And what came first
the song or the show?

What was the real theme song? The title song was never played during
the show, there was a different song played.

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

Re: RFC 111 (v1) Whitespace and Here Docs

[Bryan C . Warnock]

On Wed, 16 Aug 2000, Perl6 RFC Librarian wrote:

> This will ignore all leading white space on each line until the end terminator
> is found.  It effectively does s/^\s*// before processing each following line.

I don't agree with this, but

> It also ignores whitespace (but not the line termination) after
> the terminator.

...I agree with this.

> 
> Personally I find such blocks very usefull for cgi programming, when delivering
> large blocks of fixed html.

Personally, I find such blocks very useful for lots of things.  The
majority of my uses require/desire maintaining relative indentations,
and not the arbitrary removal of all leading whitespace.

Wasn't there a recipe for this?  (Although I wouldn't mind seeing it
implicit to the language.)

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

Re: Default filehandles(was Re: command line option: $|++)

[Nathan Wiger]

Chaim Frenkel wrote:
> 
> NW> P.S. If you're not on -io, this implicitly means you DON'T CARE and are
> NW> willing to accept whatever we come up with. So, everyone that's
> NW> interested please get on -io. Thanks again.
> 
> That's a bit strong. All we are doing is filtering the garbage for Larry.
> Larry may well be reading for flavour.

Obviously, this certainly wasn't meant to apply to Larry.
 
> And you forgot Rule #2. Larry can always change his mind.

Sure. My only point was that we've retraced the exact same discussion
about default filehandles twice now, once on -io and once on -language,
with the exact same conclusion. This is just plain a waste of time and
emails.

It's not anybody's fault, and I'm not mad. Just everyone, PLEASE try to
get on lists that you care about. It saves time and cuts down on the
extremely high bandwidth that is -language.

Thanks,
Nate

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Nathan Wiger]

> Either one or both of:
> Perl <-> Perl cross system will break.
> Perl <-> other program same system will break.
> 
> Pick your poison. I'd rather have cross system break. But if the
> epoch were available then an adjustment could be made intellegently.

I'd take choice (b). I want to be able to write the exact same Perl code
and have it deployed on multiple platforms.

There's no reason we couldn't introduce a systime() function that
returned the true system time. Then time() would always return UNIX
epoch time. This seems way more consistent than having time return
different values, making you rewrite your code or put ugly OS checks in
your code. 

So,

   1. Make all the time/date functions consistent cross-platform

   2. Add a systime() for those situations where you really need
  that specific system's epoch time

-Nate

Re: RFC 111 (v1) Whitespace and Here Docs

[Michael Fowler]

On Wed, Aug 16, 2000 at 08:22:16PM -0400, Chaim Frenkel wrote:
> > "MF" == Michael Fowler <[EMAIL PROTECTED]> writes:
> 
> MF> So what's insufficient about:
> 
> MF> print <<"EOF";
> MF> Stuff
> MF> More stuff
> MF> Even more stuff
> MF> EOF
> 
> 
> Counting spaces, why make the programer work. Are those tabs or spaces?

I would hardly consider counting spaces work, it's fairly typical for the
kind of tabbing I use.  If I used actual tabs, this would be a total
non-issue.

 
> And it doesn't strip the leading whitespace.

The RFC doesn't mention that the string will be stripped of leading
whitespace, at least not explicitly.  It mentions "it effectively does
s/^\s*// before processing each following line", but the phrase shortly
before that, it "will ignore all leading white space on each line until the
end terminator is found" implies that it simply ignores leading whitespace
until if finds the EOF.

If it strips whitespace I would be more for it.  If we can do some magic to
dictate what the leading characters to be stripped are I'd say we have a
winner here.

(Pardon the HTML, but it makes things more relevant.)

print <
Foo

Bar


EOF

This would still produce nicely-formatted HTML, whereas stripping all
whitespace wouldn't.


Michael
--
Administrator  www.shoebox.net
Programmer, System Administrator   www.gallanttech.com
--

Re: RFC 111 (v1) Whitespace and Here Docs

[Chaim Frenkel]

> "MF" == Michael Fowler <[EMAIL PROTECTED]> writes:

MF> So what's insufficient about:

MF> print <<"EOF";
MF> Stuff
MF> More stuff
MF> Even more stuff
MF> EOF


Counting spaces, why make the programer work. Are those tabs or spaces?

And it doesn't strip the leading whitespace.


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

Re: RFC 82 (listops in list context)

[Chaim Frenkel]

> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:

NT> Chaim Frenkel writes:
>> [use wacky Unicode characters for new operators]
>> I can see that this would give problems for current editors and displays,
>> but by the time perl6 comes out, perhaps the situation would be better.

NT> No.  Never ever gamble on the future being better than the present.
NT> Don't mandate Unicode-aware editors.  Nothing will sink Perl faster.

I'm not mandating it. Since perl6 _will_ be unicode aware, including
the script itself. The author takes it upon himself to use a unicode
aware editor. Other's need not apply.

The other magic variables would simply end up as some funny 8-bit
characters floating around. With one's handy (several thousand page)
translation table one can then interpret the meaning.

At worst, we could run the script through (the horror) a 
unicode -> trigraph/quadgraph/multi-graph translator to be able to
read it. And then put it back that way.

Basically, we make them available for the fellows that need the
symbols.

Just a thought,

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

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Chaim Frenkel]

> "BB" == Buddha Buck <[EMAIL PROTECTED]> writes:

BB> stat() returns time stamps (made in the past).  utime() sets time
BB> stamps.  They should be compatible with time().  e.g., "utime
BB> time,time,@files" should still set the modify and access times of
BB> @files to "now".

With or without a translation?

BB> sleep(), select() both take intervals.  The time scale is irrelevant.

It does matter, depending upon what an external system may supply.

BB> Will events need time stamps, intervals, or other (please specify)?

Why ever not?

I don't think the epoch matters. What matters is that all parties to a
programatic communication agree or we can illustrate that it doesn't
matter.

But if it really doesn't matter, then why have something different
than the system epoch.

Either one or both of: 
Perl <-> Perl cross system will break.
Perl <-> other program same system will break.

Pick your poison. I'd rather have cross system break. But if the
epoch were available then an adjustment could be made intellegently.


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

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Damien Neil]

On Wed, Aug 16, 2000 at 05:36:25PM -0400, Karl Glazebrook wrote:
> My take: I like perl, I don't mind it the way it is. But I'd be happier if
> it was a lot more like python! (indentation aside)

Why, then, don't you just use Python?

I'm not being sarcastic.  Python is a very good language.  It has a
lot to recommend it.  I really don't know of any practical reasons
these days to choose Perl over Python (or vice-versa), other than
preferences for the syntax of one over the other.

Python's significant-whitespace might be an obstacle, but it really
isn't that bad once you get used to it.  (It is also, I believe,
going to become optional in the upcoming Python rewrite, which
shouldn't take any more time to wait for than the Perl 6 rewrite.)

Perl is Perl.  I happen to like Perl.  I don't think that Perl 6 should
be Python 4, and I'd be most surprised if the average Perl programmer
didn't agree with me -- after all, anyone who prefers Python is
probably using it.

> I guess the question arises - how radical is perl6 allowed to be?

Given that it will have the word "Perl" in its name, I would expect
it to bear a striking resemblance to the current language which
bears that name.

   - Damien

Re: Default filehandles(was Re: command line option: $|++)

[Chaim Frenkel]

> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:

NW> P.S. If you're not on -io, this implicitly means you DON'T CARE and are
NW> willing to accept whatever we come up with. So, everyone that's
NW> interested please get on -io. Thanks again.

That's a bit strong. All we are doing is filtering the garbage for Larry.
Larry may well be reading for flavour.

And you forgot Rule #2. Larry can always change his mind.


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

Re: Language WG report, August 16th 2000

[Chaim Frenkel]

> "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:

TB> On Wed, Aug 16, 2000 at 05:23:04PM +1000, [EMAIL PROTECTED] wrote:
>> OK, weekly report.  Ugh.

TB> Shouldn't these to go -announce as well?

I thought we agreed that they percolate upward. 

The containing WG would report the results upward.


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

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Damien Neil]

On Wed, Aug 16, 2000 at 09:04:00PM +0200, Kai Henningsen wrote:
> And context dependency is bad for people.

Actually, people deal very well with context dependency.

  "Have you paid Bill?"
  "Have you paid that bill?"
  "It looks like a duck's bill."
  "The President vetoed the bill."

> A rose is a rose is a rose. Human minds really don't like context  
> dependancy.

  "Rose rose to the rosy glow of dawn.  On the pillow beside her
   was a rose."

The context dependency in Perl is intentional.  It isn't an accident,
and it isn't a mistake.  You may not like it; that's perfectly OK.
But if you don't like it, you may well be best served by finding
another language.  Arguing that it should be removed will simply waste
your time and that of other people.

 - Damien

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Damien Neil]

On Wed, Aug 16, 2000 at 05:34:51PM -0400, Karl Glazebrook wrote:
> > You appear to arguing that expressions in function argument lists should
> > not be evaluated in a list context.  Is this really what you mean?
> 
> I guess I do. I guess I just hate contexts!

Context is a fundemental part of Perl.  If you take out context, you
don't have Perl any more.  I'm not certain what you have, but it will
be a quite different language.

Perl 6 will be PERL 6.  A Perl 5 expert should not feel as if she is
learning a whole new language when she starts using it.  If you want
to create a whole new language that is almost, but not entirely,
unlike Perl, I think that this is not the correct place for it.

> If a function does stuff to lists it should take a list prototype.

This is certainly not the case in Perl 5.  I suppose this could
change.

Of course this would mean that every single Perl program in the world
would need to be rewritten in order to work with Perl 6.  This isn't
the sort of thing you can do automatically, either.

I really don't understand why you seem to want to make Perl 6 into
something that bears no resemblance to Perl 5.  This feels like
saying that the C9X standard should have made C into something like
Haskell, or that the Java 1.4 standard should turn that language
into a LISP clone.  If you didn't like the language in the first
place, why do you care what the next version is like?

   - Damien

Re: RFC 114 (v1) Perl resource configuration

[Casey R. Tweten]

Today around 7:17pm, Casey R. Tweten hammered out this masterpiece:

: Today around 2:34pm, Nathan Wiger hammered out this masterpiece:
: 
: : > Think on this:
: : > 
: : > use perlrc qw/Resource1 Resource5/; # Import only named 'Resources'
: : > 
: : > use perlrc qw/:all/;# Import all 'Resources'
: : 
: : > This sounds much more managable than a .perlrc that get's applied globaly
: : > without asking for it.
: : 
: : Bingo. This feature should be off by default if it exists. It should
: : only be turned on if the user specifies it explicitly.
: 
: Amen!
: 
: : Otherwise you can write a module that accidentally uses your ~/.perlrc
: : settings, publish it to CPAN (or commercially!), and wind up with a
: : horribly broken module in the real world. Or, you can download a script,
: : and it doesn't work because of your ~/.perlrc. Either one is bad.
: 
: Thinking in those terms, perhaps your .perlrc is perfect with your module
: and/or application.  Ok, so send it with your module/app.  Just send it in
: a different name.  Think on this syntax:
: 
: use perlrc './.my_apps.perlrc' => qw/:all/;
: 
: # or, use the default .perlrc
: 
: use perlrc qw/:all/; # uses some version of `.perlrc'
: 
: 
: Or, in more wild fasion... Perl modules may also contain `rc files` in
: their distribution.  Perhaps they live under a special directory, for
: instance:
: 
: $PERLLIB= '/usr/local/lib/perl5';
: 
: $PERLRCLIB  = "$PERLLIB/rclib/6.0.0"; # Version is just for example
: 
: $PERLSITERCLIB = "$PERLLIB/site_perl";

Err...

$PERLSITERCLIB = "$PERLLIB/rclib/site_perl";

Sorry.

: I think most of you get the idea.  This way, you could still say in your
: module:
: 
: use perlrc qw/:all/;
: 
: because there would be a naming convention involved similar to:
: 
: ModuleRC File
: -----
: CGI.pmCGI.rc
: Shell.pm  Shell.rc
: File/Find.pm  File/Find.rc
: 
: And so on.
: 
: Just some thoughts.
: 
: 

-- 
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce 

Re: RFC 114 (v1) Perl resource configuration

[Casey R. Tweten]

Today around 2:34pm, Nathan Wiger hammered out this masterpiece:

: > Think on this:
: > 
: > use perlrc qw/Resource1 Resource5/; # Import only named 'Resources'
: > 
: > use perlrc qw/:all/;# Import all 'Resources'
: 
: > This sounds much more managable than a .perlrc that get's applied globaly
: > without asking for it.
: 
: Bingo. This feature should be off by default if it exists. It should
: only be turned on if the user specifies it explicitly.

Amen!

: Otherwise you can write a module that accidentally uses your ~/.perlrc
: settings, publish it to CPAN (or commercially!), and wind up with a
: horribly broken module in the real world. Or, you can download a script,
: and it doesn't work because of your ~/.perlrc. Either one is bad.

Thinking in those terms, perhaps your .perlrc is perfect with your module
and/or application.  Ok, so send it with your module/app.  Just send it in
a different name.  Think on this syntax:

use perlrc './.my_apps.perlrc' => qw/:all/;

# or, use the default .perlrc

use perlrc qw/:all/; # uses some version of `.perlrc'


Or, in more wild fasion... Perl modules may also contain `rc files` in
their distribution.  Perhaps they live under a special directory, for
instance:

$PERLLIB= '/usr/local/lib/perl5';

$PERLRCLIB  = "$PERLLIB/rclib/6.0.0"; # Version is just for example

$PERLSITERCLIB = "$PERLLIB/site_perl";

I think most of you get the idea.  This way, you could still say in your
module:

use perlrc qw/:all/;

because there would be a naming convention involved similar to:

Module  RC File
--  ---
CGI.pm  CGI.rc
Shell.pmShell.rc
File/Find.pmFile/Find.rc

And so on.

Just some thoughts.

-- 
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce 

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Mike Pastore]

Real quick:

On Wed, 16 Aug 2000, John Porter wrote:

> grep() always treats its "second" arg as a list, even if it's a scalar,
> or some other list-of-one (or none); and grep() always returns a list,
> even if it's a list of one (or none).

True on the first part, false on the second. In scalar context, grep
returns the number of times the block or expression evaluated 'true'.

> Highlander variables acknowledge the fact that all variable types (scalar,
> array, hash) are simply objects.  Objects of different classes, sure; but
> still just objects.  You get no visual help in cases like

When I said 'highlander' I meant one variable per variable name. Please
read RFC9.

> Analogously, for variables of (perl) class "array", you need to know
> that "push" is a method, and that
> 
>   push var, things;
> 
> does what you know it does.  It doesn't help anyone to write "@var".

This is true. But you'll notice that in each of my examples I asked
questions where the context was ambiguous, and not implicit like C.

In your example, it WOULD help to write C<@things>, because from a
"birds-eye view" a programmer would see the C<@> and move to the next
line, not pausing to read all the way through to see that C is
obviously plural. Again, I refer you to Dan Sugalski's message about this.

> You are asking wrong/unnecessary questions, and getting wrong answers.

That was disturbingly Zen. ;-)

--
Mike Pastore
[EMAIL PROTECTED]

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Jon Ericson]

John Porter wrote:
> Mike Pastore wrote:
> Highlander variables acknowledge the fact that all variable types (scalar,
> array, hash) are simply objects.  Objects of different classes, sure; but
> still just objects.  

Not in Perl.

> You get no visual help in cases like
> 
> $dog->bark();
> $cat->scratch();
> 
> as to what $dog and $cat are, nor what bark or scratch do.  You, as
> programmer, need to know elsehow what bark does, and whether it's what
> you want.  

$dog and $cat are objects.  $dog can bark and $cat can scratch.  The
author of the module (Zoo::Animal?) should have documented these
methods.

> Analogously, for variables of (perl) class "array", you
> need to know that "push" is a method, and that
> 
> push var, things;
> 
> does what you know it does.  It doesn't help anyone to write "@var".

push is _not_ a method.  @var is not an object.  Perl is not Python with
funny variable prefixes.

Jon
-- 
Knowledge is that which remains when what is
learned is forgotten. - Mr. King

Re: RFC 113 (v1) Better constants and constant folding

[John Siracusa]

On 8/16/00 4:00 PM, Perl6 RFC Librarian wrote:
> =head1 TITLE 
> 
> Better constants and constant folding
> 
> =head1 VERSION 
> 
> Maintainer: John Siracusa <[EMAIL PROTECTED]>
> Date: Aug 15 2000
> Version: 1 
> Mailing List: [EMAIL PROTECTED]
> Number:  113

This RFC has been integrated with RFC 83.  The official retraction notice
ought to hit the list shortly.

-John

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[John Porter]

Mike Pastore wrote:
> 
> Scenario 2:
> 
> ret = grep(/hand/, var);
> 
> *puzzled expression* "Grepping a scalar for a string? Grepping a list for
> a string? Returning a list or a scalar?"

You have failed to enter the mind of an expert perl programmer.  ;-)

grep() always treats its "second" arg as a list, even if it's a scalar,
or some other list-of-one (or none); and grep() always returns a list,
even if it's a list of one (or none).

So, in fact, you don't need to puzzle over those questions, because the
answers are the same, regardless of whether "var" was a scalar or an array.


Highlander variables acknowledge the fact that all variable types (scalar,
array, hash) are simply objects.  Objects of different classes, sure; but
still just objects.  You get no visual help in cases like

$dog->bark();
$cat->scratch();

as to what $dog and $cat are, nor what bark or scratch do.  You, as
programmer, need to know elsehow what bark does, and whether it's what
you want.   Analogously, for variables of (perl) class "array", you
need to know that "push" is a method, and that

push var, things;

does what you know it does.  It doesn't help anyone to write "@var".


Similarly, in

> bar = unshift(hats, foo);
> 
> "Okay, C is obviously a list, but is it shifting in a scalar or a
> list of things? And is it assigning to another list or a scalar to get
> the new list lenghth?"

You are asking wrong/unnecessary questions, and getting wrong answers.


-- 
John Porter

Aus tiefem Traum bin ich erwacht.

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[John Porter]

> What makes Perl feel like Perl is, of course, subjective, but to me
> the punctuation is a lot of it.  We're trying to improve Perl, not
> replace it.  

This is an extremely loaded statement, and we've been hearing it a lot.
RFC 0, remember?  Invoking RFC0 immediately after stating your own
personal taste is not a valid rhetorical device in this forum.  Or at
least it shouldn't be allowed to be.

Clearly we all stand by RFC0.  That should go without saying, just like
RFC0 itself.



-- 
John Porter

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Mike Pastore]

On Wed, 16 Aug 2000, David Corbin wrote:

> Mike Pastore wrote:
>
> > $hashish{'dog'}# one whutzit
> > @hashish{'dog', 'cat'} # more than one whutzits
> > each %hashish  # one whutzit, indexed
> > %hashish   # all whutzits, indexed
> > keys %hashish  # all indices
> > values %hashish# all whutzits
>
> > I know I'm being terribly redundant, but the point I'm trying to make is
> > that the contextual clues (@$%) don't tell you what IT is, but what you're
> > getting from IT. That's what's so important.
> 
> Fine.  But the problem (confusion) comes from the fact that you've got
> multiple "IT"s named 'hishhash' that have no real correlation.  If the
> %@$ indicates what you're getting, you've got soemthing else ([0]/{x}/)
> which indicates what IT really is.  However, that's not how you declared
> IT.  You declared (first used) @$%.

I re-CC'd perl6-language because these are some of my arguments in
general.

The correlation between the different Ces is the name. The
confusion you're describing above can be much more easily rectified by a
highlander-type solution, or simply by using Good Programming. 

Remember, it isn't the goal of Perl to be easy to learn. A Perl newbie can
spend an hour learning the difference between a scalar, an array, an array
element, an array slice, a hash, a hash slice, and the different hash
calls. This will have been an hour well spent. Then they can enter the
world of the Perl programmer, where the variable context needs to be
easily identified. Please read Dan Sugalski's recent post about how the
human brain works, I won't get into it again.

> If I did this:
> 
>   my var{};
>   my var[];
>   my var;
> 
> And then used:
>   $var, $var[0], $var{x}, @var, etc. 
> 
> It would be far more consistent.

The only difference between the above and this:

my %var;
my @var;
my $var;

print $var;
$foo = $var[0];
$bar = $var{x};
@zot = @var;

Is about fifteen minutes of cognitive thinking for a new Perl
programmer, either way. He (or she) is still going to have to learn the
difference between an array (@/[]) and a hash (%/{}). 

Now, enter the mind of the veteran Perl 5 programmer (please note that I
am not claiming that I am one, but I am going attempt to think like one
for a minute :)

Scenario 1:

my var[];

"Umm, slice? Anonymous reference? Matrix? Have I stumbled into a C
library?"

my @var;

"A list. Next line."

Scenario 2:

ret = grep(/hand/, var);

*puzzled expression* "Grepping a scalar for a string? Grepping a list for
a string? Returning a list or a scalar?"

@ret = grep(/hand/, @var);

"Retrieving a list of matching array elements. Next line."

Scenario 3:

bar = unshift(hats, foo);

"Okay, C is obviously a list, but is it shifting in a scalar or a
list of things? And is it assigning to another list or a scalar to get
the new list lenghth?"

$bar = unshift(@hats, $foo);

"Prepending C<$foo> to C<@hats> and returning the length of the new
list. Next line."

Scenario 4:

ret = sort { foo{a} cmp foo{b} } map zot, reverse bar;

"It looks so clean! But what does it do?"

@ret = sort { $foo{$a} cmp $foo{$b} } map &zot, reverse @bar;

"What a mess! But I know exactly what's happening. Sorting the reversed,
Cted contents of the array C<@bar> by the index C<%foo> and
returning a new list."

You can't argue that you can make it clear by dressing up the statement:

ret[] = sort { foo{a} cmp foo{b} } (map zot(), reverse bar[]);

Because that would defeat the purpose of the RFC in the first
place: Decrease line noise. IMHO that's HARDER to read because my brain is
already trained to look for data containers as (@$%) and not
trailing ({}/[]/()).

__END__

I get angry when anti-Perlites critiscize the language because it's
"messy." It may be, but I can tell what it does in a flash because of
context clues. Give me braces, parens, and identifiers, or give me death.

Drop off the mnemonics and sure, the simple stuff gets simpler-looking. But 
you have to read more to get the same birds-eye view. And the complicated
stuff looks streamlined, but you have to analyze two pages of code for
three minutes to determine what's a scalar, what's an array, and what's a
hash. 

If you folks want a language that's flexible, powerful, fun to code, and
easy to understand with a little brain juice, then you have Perl. If you
want a "clean" language then you're in the wrong place.



--
Mike Pastore
[EMAIL PROTECTED]

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Jon Ericson]

Karl Glazebrook wrote:
> Jon Ericson wrote:
> > I've spent almost a day trying to come up with a polite response to this
> > suggestion.  I have started this mail 3 or 4 times but deleted what I
> > wrote because it was too sarcastic, angry or dismissive.  This RFC
> 
> Thanks!
> 
> > strikes to the very heart of Perl as far as I'm concerned.
> 
> What's wrong with that? There are no rules as to what we are allowed
> to discuss.
 
> Well FORTRAN and C are not array languages, and IDL costs N*$1000. Now
> there IS Numerical Python if you can put up with indents!

> Offensive is a strong word for what is essentially a discussion about
> computer lingo syntaces!

But this isn't about 'computer lingo syntaces' [sic].  It's about Perl. 
I think you should consider using Python and a good text editor that
takes care of indents for you.  There's no more point in discussing
this.

Jon
-- 
Knowledge is that which remains when what is
learned is forgotten. - Mr. King

Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)

[James Mastros]

- Original Message -
From: "Jonathan Scott Duff" <[EMAIL PROTECTED]>
Sent: Wednesday, August 16, 2000 10:00 AM
Subject: Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs
should receive the rvalue as an argument)


> On Wed, Aug 16, 2000 at 12:14:09AM -0700, Nathan Wiger wrote:
> > No problem. In fact, this fits under your rules. HOWEVER, it also
> > assumes that Lincoln thought that param() was :lvalue-worthy. What if he
> > forgot? Or didn't think of this case?
>
> Then you email him with a patch, and your reasons why your lvalue
> patch should be applied.
Or, if you prefer, patch your local copy without emailing Lincon.  Or do an
attributes(&CGI::param) |= :lvalue; (assuming synthax that hasn't been
RFCed, but...)

However, I think that this can all be solved fairly simply, by intergrating
it with the other problem: that functions wouldn't be able to tell the
diference between their lvalue and rvalue values.

Now, I rather like Buddha Buck's solution, of making the lvalue attribute
take the variable name the rvalue should be passed in.  However, for those
still of the mind that all subs should be lvalueable, might I propose that a
sub foo, called as foo(@a) = @b gets its @_ as @a,@b, as proposed in the
RFC, with the twist that the elements of @b are passed with a :rvalue
attribute, so that foo can care if it wants to, but if it doesn't, the
lvalue call will "simply work" without any further ado.  Note also that this
means that :no_lvalue can be written in pure perl.

-=- James Mastros

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Nathan Torkington]

Karl Glazebrook writes:
> Well said!
> 
> My take: I like perl, I don't mind it the way it is. But I'd be happier if
> it was a lot more like python! (indentation aside)

This begs the question of why you're not using python.  If it's just
indentation, that's silly.  Surely there are patches to the Python
parser to permit curlies.  If there aren't, surely it's on the table
for python3000.

> I guess the question arises - how radical is perl6 allowed to be?

Only Larry can say how different from perl5 perl6 will be, and he can
only say that after he's seen how radical it *might* be.  My personal
suspicion is that it won't be so different from perl5 that it feels
like a different language.

What makes Perl feel like Perl is, of course, subjective, but to me
the punctuation is a lot of it.  We're trying to improve Perl, not
replace it.  At some point you run into the grandfather's axe syndrome
("I have my grandfather's axe.  My father replaced the blade, and I
replaced the shaft").

Larry will probably also have to consider ease of adoption: if current
Perl programmers can't migrate a lot of what they know, they'll be
starting from scratch.  That's hardly embodying Laziness.  Perl's got
a long history of stealing from other languages.  Are you sure you
aren't trying to create another language and steal from Perl?  Because
if you are, Python already did that :-)



It occurrs to me that for some kinds of RFCs, it's very important to
put the WHY into your RFCs, not just the how.  Your suggested
implementation might be rejected, but Larry might be able to find
another way to permit what you want.

Nat

Re: RFC 91 (v1) Builtin: partition

[Jeremy Howard]

Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and Perl6 RFC Librarian
<[EMAIL PROTECTED]>
>  whispered:
> | =head1 TITLE
> |
> | Builtin: partition
> |
> | =head1 ABSTRACT
> |
> | It is proposed that a new function, C, be added to Perl.
> | C would return @list broken into
> | references to sub-lists, each one $list_size in size.
>
> This is very similar to what unzip does.

Yes. The new version of the partition RFC (posted overnight) makes the
distinction clear.

> Would it be better to combine
> them into a single function that could do both operations (and possibly
> others) with a flag?

Nathan Wiger is currently following up this path. If he can find acceptable
syntax we'll consider it. I'm worried about making this functionality more
confusing than it has to be though, so we'll have to see what it looks like.

> In fact, couldn't all this (zip, unzip, partition) be
> handled as part of pack and unpack?
>
No. They are lazily evaluated and require special optimisations to allow
them to work on like iterators on subsets of sparse, masked, or sliced
arrays. They can all be handled (sort of) by using lazily evaluation list
generation functions (RFC 81), but these three functions are so fundamental
to using 1d arrays as n-dim matrices that requiring complex code to roll
your own would be less than ideal. The narrow scope of these functions also
makes them much easier to optimise.

They are likely to end up in a module, however.

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Jon Ericson]

Karl Glazebrook wrote:
> Nathan Wiger wrote:
> > Yeah, and isn't it cool that Perl gives you easy access to using and
> > understanding such complex data structures:
> >
> >print @{ $cars->{$model} };
> >
> > That "junk" makes it easy to see that you're derefencing a hashref that
> > contains a key which is pointing to an array. How is this:
> 
> it's a list of stuff - but a list of WHAT stuff? The @ is essentially
> useless.

It's a list of scalars.  

> >print cars->model;
> >
> > any clearer? Nicer to look at? Maybe for some. Not for me, I like the
> 
> yep. yep, and easier to teach.

See my sig.  Try to make knowing easy even at the cost of making
learning hard.

> > former. Maybe it doesn't let you know exactly what you're getting, but
> > you're a lot closer. And this:
> >
> >print "Welcome back, $fullname, to $website!\n";
> >
> > is MUCH better than this:
> >
> >print "Welcome back " . fullname . " to " . website . "!\n";
> 
> I agree. That's why I believe in retaining the $. The distinction between
> variable and non-variable is still useful.

And I think the distinction between a variable and a list of variables
is still useful as well.

> > Not true!! Only $scalars can hold objects. Now, @arrays and %hashes can
> > hold groups of objects, but only $scalars can hold objects.
> 
> "Groups" is a meaningless concept. You have particular objects which store stuff.
> Is an image of a distant galaxy singular (one image) or plural (ten zillion pixels).

That depends.  Do you want to think about a galaxy or a collection of
pixels?

> My argument, based on my practical experience, is that all the @% are essentially
> useless now.

Then your practical experience is radically different than mine.

> > To summarize, you should read RFC's 49, 73, 28, and the link to TomC's
> > email I sent you. These address the real problems, and not the symptoms.
> 
> Yes. And I read TomC's stuff on those lines at least 6 years ago. Which
> was why I got annoyed.

What does that have to do with anything?  What has changed in the last
six years that renders these concepts obsolete?  

> The point remains - why treat hashes and arrays as special prefix types?
> It just confuses the language to have to use $ for one kind of collection
> and @ for another.

Why not let @ be used for other types of collections?  

> ok we could use @ for everything - but @ implies 1D ness.

Why?  (Answer: C)

Jon
-- 
Knowledge is that which remains when what is
learned is forgotten. - Mr. King

Re: RFC 82 (v2) Apply operators component-wise in a list context

[Jeremy Howard]

Nathan Torkington wrote:
> Perl6 RFC Librarian writes:
> > It is proposed that in a list context, operators are applied
> > component-wise to their arguments. Furthermore, it is proposed that
> > this behaviour be extended to functions that do not provide a specific
> > list context.
>
> I don't mind making Perl's builtins do this.  Making my own functions
> do it gives me the willies.
>
> You'd require subroutine authors to label their subroutines as capable
> of having this rule applied.  Subroutine users are still going to have
> to read the docs to work out how to use the subroutine.  You're not
> really making anything automatic, just trading one set of typing for a
> different set.
>
> Context is weird enough without trying to add more magic to it.  Stick
> with "make Perl's builtin operators apply themselves to list elements
> when in list context".
>
I know what you mean. I'm not crazy about it myself. However, it seems like
it shouldn't be necessary to explicitly incorporate this feature into all
Perl functions.

Maybe we could add an attribute: 'listable', 'loop', ...? This attribute
would be required to get the implicit looping behaviour in a list context.
Then Perl functions could use this attribute to get the behaviour
automatically, as could module authors who took the time to think about it.
This would follow the mind-set of the lvalue attribute quite closely.

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Karl Glazebrook]

Well said!


Nathan Torkington wrote:
> 
> Dan Sugalski writes:
> > Unfortunately, I think you're somewhat under-informed as to the inherent
> > capabilities of people's brains.
> 
> Ok, at this point I think all parties have to step away and let the
> RFCs fall where they will.
> 
> It's obvious that there are two types of people: those who don't mind
> the punctuation, and those who do.  We already know what Perl is like
> with punctuation.  Let the anti-punctuation folks make their RFCs,
> and let Larry decide.
> 
> I think they're wasting their time, but it's not about what I think.
> 
> And somewhere within those python-esque convolutions, there may be
> some ideas that Larry will adopt.
> 
> Nat

Re: RFC 76 (v1) Builtin: reduce

[Jeremy Howard]

Nathan Torkington wrote:
> Piers Cawley writes:
> > > > The $a and $b of the sort comparator were A Bad Idea to begin with.
> > >
> > > Ditto. Can we ditch these in Perl 6? Don't see why $_[0] and $_[1]
can't
> > > be used, or even a more standard $1 and $2. Either one makes it more
> > > obvious what's being operated on.
> >
> > $1 & $2 could be somewhat dangerous in a sub that might have regexen
> > in it...
>
> $1 and $2 are a poor choice because of regexps.
>
> $a and $b were done for speed: quicker to set up those global
> variables than to pass values through the stack.  The documentation
> for perl5's sort function says that passing as arguments is
> considerably slower.  I don't think you can handwave and say "oh,
> that's an implementation detail".  I think it's an implementation
> detail that's bloody hard to fix, especially for things like code
> references passed to sort:
>
>   sort $some_ref @unordered
>
> Perl can't do anything at compile-time to tell sort where lexicals
> in the sort sub are.
>
> So I don't have a solution, I just have more detail on the problem.
>
The solution is to pass args in as $_[0] and $_[1]. Using higher-order
function notation allows these args to be named however you like:

  sort ^left cmp ^right, @list;
  sort ^1 cmp ^2, @list;
  sort ^_ cmp ^_, @list;

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Karl Glazebrook]

Jon Ericson wrote:

> I've spent almost a day trying to come up with a polite response to this
> suggestion.  I have started this mail 3 or 4 times but deleted what I
> wrote because it was too sarcastic, angry or dismissive.  This RFC

Thanks! 

> strikes to the very heart of Perl as far as I'm concerned.

What's wrong with that? There are no rules as to what we are allowed
to discuss.

 > Judging from your posts, you use perl largely in conjunction with PDL
> [1].  As I understand the situation, PDL uses objects (blessed scalar

This is true.

> references) to manipulate arrays because the standard perl array is
> inadequate for the task.  Therefore, in your experience '@' is only used
> for a limited, rarely needed array and '$' for a wide variety of useful
> arrays.  Hence this RFC.

Please don't think the RFC is PDL-porters derived - there are enough of those
to come :) This one is personal and based on how I view doing things.
 
> It seems to me that you could have picked a different slant on this
> RFC.  Instead of forcing Perl to look like PDL, you could have proposed
> that perl allow PDL to look like Perl.  PDL wouldn't exist if there
> wasn't something about Perl that people love.  Otherwise, they would be
> working on FORTRAN or C or IDL.  If perl can make another group of

Well FORTRAN and C are not array languages, and IDL costs N*$1000. Now
there IS Numerical Python if you can put up with indents!

> people happy, so much the better.  But you have to realize that this
> change would make a large number of people miserable.
> 
> Could you rework this RFC to be a pragma?  Or propose making @ work with
> other types of arrays?  Or withdraw it?  The current form is offensive
> to me (and I suspect many other perl programers as well).

Offensive is a strong word for what is essentially a discussion about
computer lingo syntaces!

I am proposing what I think is a good long term improvement in perl, my
own view. Even if it doesn't go through (and I'd be very surprised if
it did) there are still good cases for making PDL arrays look like perl
arrays to abolish user confusion. There will probably be less-earthshaking
RFCs from pdl-porters along these lines.

Karl

Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument

[Nathan Torkington]

Chaim Frenkel writes:
> CN> Can we please cut down on the traffic to perl-announce, maybe make it
> CN> moderated?  Thanks,
> 
> Perhaps, the esteemed Librarian could make the -announce a Bcc?

One of the moderators was a little too approval-happy.  I believe
this has been fixed as of a few hours ago.

Nat

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Karl Glazebrook]

Well said!

My take: I like perl, I don't mind it the way it is. But I'd be happier if
it was a lot more like python! (indentation aside)

I guess the question arises - how radical is perl6 allowed to be?

Karl

Kai Henningsen wrote:
> And context dependency is bad for people.
> 
> There is a reason that no language after Algol68 used a context dependant
> grammar.
> 
> There is a reason that nearly all modern computer languages don't make
> expression evaluation dependant on expression context.
> 
> The reason is *not* that this is easier for computers. It is easier, sure,
> but not all that much.
> 
> But it is *a lot* easier for humans.
> 
> A rose is a rose is a rose. Human minds really don't like context
> dependancy.
> 
> MfG Kai

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Nathan Torkington]

Dan Sugalski writes:
> Unfortunately, I think you're somewhat under-informed as to the inherent 
> capabilities of people's brains.

Ok, at this point I think all parties have to step away and let the
RFCs fall where they will.

It's obvious that there are two types of people: those who don't mind
the punctuation, and those who do.  We already know what Perl is like
with punctuation.  Let the anti-punctuation folks make their RFCs,
and let Larry decide.

I think they're wasting their time, but it's not about what I think.

And somewhere within those python-esque convolutions, there may be
some ideas that Larry will adopt.

Nat

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Karl Glazebrook]

Damien Neil wrote:

> What makes you presume this?  Perhaps snrub() is something like this:
> 
>   sub snrub {
> foreach (@_) {
>   frobnicate $_;
> }
>   }
> 
> You appear to arguing that expressions in function argument lists should
> not be evaluated in a list context.  Is this really what you mean?

I guess I do. I guess I just hate contexts!

If a function does stuff to lists it should take a list prototype.


> One of the fundamental concepts in Perl is context.  Would you care to
> address the point of what happens to context when you remove @ and %
> prefixes?

I think I just did :)

Re: RFC 114 (v1) Perl resource configuration

[Nathan Wiger]

> Think on this:
> 
> use perlrc qw/Resource1 Resource5/; # Import only named 'Resources'
> 
> use perlrc qw/:all/;# Import all 'Resources'

> This sounds much more managable than a .perlrc that get's applied globaly
> without asking for it.

Bingo. This feature should be off by default if it exists. It should
only be turned on if the user specifies it explicitly.

Otherwise you can write a module that accidentally uses your ~/.perlrc
settings, publish it to CPAN (or commercially!), and wind up with a
horribly broken module in the real world. Or, you can download a script,
and it doesn't work because of your ~/.perlrc. Either one is bad.

-Nate

Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)

[Graham Barr]

On Wed, Aug 16, 2000 at 01:51:09PM -0600, Nathan Torkington wrote:
> Nathan Wiger writes:
> > Nonetheless, I think a better thing would be to figure out if it's
> > possible to "fix" this issue. I would *really* like lvalue subs ==
> > rvalue subs.
> 
> I think conflating:
>foo(@vals)
> and
>foo() = @vals
> 
> is misleading and going to cause more confusion that it solves.

Yes, how will the sub be able to tell between

  foo(1) = 2;

and

  foo(1,2);

ie how does it know where its arguments stop and it's assignments start ?

Graham.

Re: RFC 114 (v1) Perl resource configuration

[Steve Simmons]

On Wed, Aug 16, 2000 at 08:03:31PM -, Perl6 RFC Librarian wrote:

> Perl should provide a mechanism to have common code autoloaded from a
> file. . . .

> A C file could be used to set system-wide defaults that
> the system administrator would like to promote.  For instance,
> C could turn on stricture or warnings.
> 
> This RFC proposes that Perl 6 support 2 "rc" files: a per-user file
> located in the user's home directory C<~/.perlrc> and a global "rc"
> file, C, that affects all instances of perl running on
> the machine.

This proposal needs to be rethought keeping multiple simultaneously
installed versions of perl in mind.  For example, when site policy
that 6.0 uses module X and not Y, but 6.1 uses Y and not X, well,
the site and user rc files had better be able to handle that with
minimal complexity.

Some tools divide their initializations into two classes, fixed
and changable.  This is a big win, and should be considered as part
of the process as well.

Re: Permanent sublists (was Re: Language WG report, August 16th 2000)

[Steve Simmons]

On Wed, Aug 16, 2000 at 02:38:33PM -0400, Uri Guttman wrote:

> i see problems with overlapping areas. I/O callbacks fall under both io
> and flow IMO. some of the error handling like dying deep in eval and
> $SIG{DIE} also fall under error and flow.

This is true, and inevitable.  But IMHO it'd be a helluva lot easier to
follow two lists (error, flow) than the uber-language-list.  So while
I don't think sublists are a perfect solution, they're a better solution
than not sublisting.

Wasn't somebody going to set up a news server?  Newsgroups and
crossposting, yeah, that's the ticket.

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Russ Allbery]

Kai Henningsen <[EMAIL PROTECTED]> writes:

> That would be nice if the punctuation actually *were* part of the
> variable name.

> However, it isn't: to access 'second', you'd say $args[1], NOT @args[1].
> It's one of the Perl features that most confuses newcomers.

Well, I think it is; it's just that $args[1] is a different variable than
@args.  Maybe people think that's an odd notion of what a variable is, but
I think of @args as a collection containing a bunch of individual
variables, each of which has its own name that's disambiguated from $args
by [].  You can operate on the collection, or you can address the
variables individually.

This makes even more sense when you look at %args, and start looking at
multi-level hashes.

> If there's no better argument than this, I'd throw this distinction away
> in a heartbeat.

It's always easy to throw away other people's distinctions.  :)

> If the syntax can be changed so I never have to write @{some array ref}
> again to explain to perl that yes, I really want to use this array as an
> array, I'll be a happy man.

Now this I'll agree with; I find the @{ $$hash{value} } syntax rather
bletcherous.  But I think that's a separate problem and could well have a
separate solution.

Perhaps @->$$hash{value} as has been proposed before, and Perl 6 can deal
with the issue of the @- array in some other way.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Jon Ericson]

Karl Glazebrook wrote:
> 
> Jon Ericson wrote:
> > But @ and % provide important context clues (if not to perl than
> > certainly for programmers).  We could also eliminate the plural case in
> > English, but this would be endlessly confusing for native speaker
> > (err... speakers).  Why not change @x so that it can represent other
> > types of arrays?  For instance:
> >
> >   my @x;# standard Perl array
> >   my @y[2, 3];  # 2x3 matrix (syntax guess)
> >   my FIFO @z;   # FIFO stack (another guess)
> 
> or one could just *use* english plurals...
> 
> my $speaker = 'Jim';
> my $speakers = ('Fred','Bill','Sally','Betty');
> 
> my $male_speakers = $speakers[0:1]; # If perl supported this style of range - see 
>RFC coming soon
> 
> # BUT:
> 
> my $image = read_huge_2d_list_of_numbers('file');
> 
> my $favorite_pixels = $image[10:20,50:100];
> my $best_pixel  = $image[11,55];

I've spent almost a day trying to come up with a polite response to this
suggestion.  I have started this mail 3 or 4 times but deleted what I
wrote because it was too sarcastic, angry or dismissive.  This RFC
strikes to the very heart of Perl as far as I'm concerned.  

Judging from your posts, you use perl largely in conjunction with PDL
[1].  As I understand the situation, PDL uses objects (blessed scalar
references) to manipulate arrays because the standard perl array is
inadequate for the task.  Therefore, in your experience '@' is only used
for a limited, rarely needed array and '$' for a wide variety of useful
arrays.  Hence this RFC.

It seems to me that you could have picked a different slant on this
RFC.  Instead of forcing Perl to look like PDL, you could have proposed
that perl allow PDL to look like Perl.  PDL wouldn't exist if there
wasn't something about Perl that people love.  Otherwise, they would be
working on FORTRAN or C or IDL.  If perl can make another group of
people happy, so much the better.  But you have to realize that this
change would make a large number of people miserable.

Could you rework this RFC to be a pragma?  Or propose making @ work with
other types of arrays?  Or withdraw it?  The current form is offensive
to me (and I suspect many other perl programers as well).

[1] "PDL (``Perl Data Language'') gives standard Perl the ability to
compactly store and speedily manipulate the large N-dimensional data
arrays which are the bread and butter of scientific computing." --
)

Jon
-- 
Knowledge is that which remains when what is
learned is forgotten. - Mr. King

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Dan Sugalski]

At 09:49 PM 8/16/00 +0200, Kai Henningsen wrote:
>[EMAIL PROTECTED] (Dan Sugalski)  wrote on 15.08.00 in 
><[EMAIL PROTECTED]>:
>
> > At 06:04 PM 8/15/00 -0400, John Porter wrote:
> > >Dan Sugalski wrote:
> > > > >Generality good.
> > > >
> > > > For many things, yes. For computers, say. For people, no. Generality
> > > > bad. Specificity and specialization good. People aren't generalists.
> > > > They're a collection of specialists. The distinction is important.
> > >
> > >I'm sorry if I don't find this argument convincing.
> > >This argument suggests that *every* type carry a distinguishing
> > >prefix symbol -- including ones to distinguish between numbers and
> > >strings, say.
> >
> > Numbers and strings really aren't different things, at least not as far as
> > people are concerned.
>
>Bovine excrement. Numbers and strings completely different things to
>people.

After a certain point, yes, more or less. Up until then, no. And most 
numbers are, in most contexts, treated as adjectives by people, where they 
have little more meaning than any other adjective. They're just mental 
symbols tacked on as a modifier to other symbols.

>Hashes and arrays, OTOH, really aren't different for people. The concept
>of an index needing to be a nonnegative number is a computer concept.

Arrays are essentially sequences of things--first thing, second thing, 
third thing, and so on.

Hashes, on the other hand, are named things--the person that's Bob, the 
person that's Jim, the person that's Jason.

It's the difference between position and identity. Those are very, very 
different concepts.

> >They are for machines, but computer languages
> > ultimately aren't for machines, they're for people.
>
>I agree that computer languages are for people - in fact, that's the sole
>reason they were invented. Otherwise we'd still program in machine
>language.

This statement isn't, strictly speaking, true. Very few computer languages 
are actually designed *for* people. Most of them are designed to map over a 
particular problem space, be it theory or hardware. C wasn't designed for 
people. Neither was Lisp, or Fortran. COBOL, oddly enough, was, though it 
shows the limitations of the machines and techniques of the era. People are 
generally an afterthought.

>However, I do think your ideas about what does and does not come naturally
>to people are incredibly warped.

Perhaps, but then again perhaps not. I've got two young children. Watching 
kids as they grow lends a certain perspective on things. I see what does 
and doesn't come naturally.

When designing perl, a book on cognitive psychology or early childhood 
education may be as (if not more) useful than a CS text.

> > I'm not presuming that, though there are plenty of languages already that
> > have no symbols. Perl's not one of them, though.
>
>I presume you mean $@% when you say symbols (and not, for example, the
>stuff that goes into a symbol table, because I certainly don't know any
>language that doesn't have those).

Yep.

>It's an open question if these are a good idea. I'm not convinced.
>Personally, I see them as one of the ugly warts in Perl.
>
> > > > Even assuming highlander types, the punctuation carries a rather
> > > > significant amount of contextual information very compactly.
>
>s/significant/in&/ IMNSHO, even ignoring the "even" part.

A single small picture, and one that can be easily picked out by your 
visual cortex, carries an awful lot of contextual information with it, and 
carries it quickly. YHO is, I think, incorrect.

> > It's going to always be more difficult. You need to *think* to turn a word
> > into a symbol. = is already a symbol. Less effort's needed.
>
>Maybe *you* have to think to turn a word into a symbol. Most people seem
>to grow up with that concept.

I'll have to check, but I'm not sure 'most' is appropriate here, as a large 
portion of the world uses iconographic languages.

Regardless, more mental effort is needed to turn the word "rock" into the 
concept of a rock than a picture of a rock does. It's not conscious, 
generally speaking, but more of your brain is involved in dealing with 
words than with pictures.

>As for *recognizing* the stuff, ever heard of redundancy? It's the stuff
>that makes recognizing stuff easier.

No, redundancy is the stuff that makes recognizing things more reliable.

>Words, by being longer, are easier to recognize than non-alphabetic
>symbols.

Non-alpha symbols are *faster* to recognize. That's their advantage. 
Overloading them with too much meaning is bad, as then you end up needing 
to think more.

When you see something like:

   $foo

the first thing that happens is your brain picks out the whole 
space-separated  thing as a single 'thing'. That happens in your visual 
cortex, it's fast, and takes very little effort. That gets stripped down 
into pieces. Your brain's already dealing with a perl context, and $ gets 
recognized as the 'single thing' marker. 'foo', meanwhile, is wending its 
w

Re: RFC 114 (v1) Perl resource configuration

[Casey R. Tweten]

Today around 8:03pm, Perl6 RFC Librarian hammered out this masterpiece:

: This and other RFCs are available on the web at
:   http://dev.perl.org/rfc/
: 
: =head1 TITLE
: 
: Perl resource configuration
: 
: =head1 VERSION
: 
:   Maintainer: Jonthan Scott Duff <[EMAIL PROTECTED]>
:   Date: 16 Aug 2000
:   Version: 1
:   Mailing List: [EMAIL PROTECTED]
:   Number: 114
: 
: =head1 ABSTRACT
: 
: Perl should provide a mechanism to have common code autoloaded from a
: file.
: 
: =head1 IMPLEMENTATION
: 
: Make perl look for the rc files.

I'm not sure about this.

Rather than perl looking for it.  Perhaps the pragma perlrc* should look
for it.

Think on this:

use perlrc qw/Resource1 Resource5/; # Import only named 'Resources'

use perlrc qw/:all/;# Import all 'Resources'

use perlrc qw/:punc_vars/;  # Import userdefined group of 'Resources'

This way, it's a 'use it if you ask for it' type of mechanism.  On the
command line, the default action may be to import all 'Resources' defined
( Can we do that? )

perl -Mperlrc -nle 'print "Blah"'

Or some such.

This sounds much more managable than a .perlrc that get's applied globaly
without asking for it.

* No, this doesn't exist right now.  I know.
-- 
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce 

Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument

[Chaim Frenkel]

> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:

CN> Can we please cut down on the traffic to perl-announce, maybe make it
CN> moderated?  Thanks,

Perhaps, the esteemed Librarian could make the -announce a Bcc?


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

Re: RFC 82 (v2) Apply operators component-wise in a list context

[Nathan Torkington]

Perl6 RFC Librarian writes:
> It is proposed that in a list context, operators are applied
> component-wise to their arguments. Furthermore, it is proposed that
> this behaviour be extended to functions that do not provide a specific
> list context.

I don't mind making Perl's builtins do this.  Making my own functions
do it gives me the willies.

You'd require subroutine authors to label their subroutines as capable
of having this rule applied.  Subroutine users are still going to have
to read the docs to work out how to use the subroutine.  You're not
really making anything automatic, just trading one set of typing for a
different set.

Context is weird enough without trying to add more magic to it.  Stick
with "make Perl's builtin operators apply themselves to list elements
when in list context".

Nat

Re: RFC 111 (v1) Whitespace and Here Docs

[Michael Fowler]

On Wed, Aug 16, 2000 at 03:05:23PM -, Perl6 RFC Librarian wrote:
> With a here doc print < the text of the here doc, is processed verbatum.  This results in Here Docs
> that either stick out in the code, or result in unwanted leading whitespace.
> There are several FAQs that relate to this problem.  This proposal tidies
> this up.

[snip]

> This will ignore all leading white space on each line until the end terminator
> is found.  It effectively does s/^\s*// before processing each following line.
> It also ignores whitespace (but not the line termination) after
> the terminator.

So what's insufficient about:

print <<"EOF";
Stuff
More stuff
Even more stuff
EOF


Michael
--
Administrator  www.shoebox.net
Programmer, System Administrator   www.gallanttech.com
--

Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)

[Nathan Wiger]

> I think conflating:
>foo(@vals)
> and
>foo() = @vals
> 
> is misleading and going to cause more confusion that it solves.

In simple cases, yes. The above looks misleading. Advanced stuff like
chaining though would be really cool. I could come up with oodles of
examples. :-)

> What kinds of problems can you possibly have with my()?

You'd think that, eh? Not understanding what lexical scope means, where
the nearest block is, thinking that my() is per-package, etc, etc,
etc...

> No, you work with what you have.  Modules, like Perl, don't have to
> be all things to all people.  This idea that it "ought to work" is
> what's broken.

Sorry, I've done *way* too much work with user-interface research and
design to agree to an RTFM argument. This doesn't work for me. Not for
something as "simple" as assignment. Function names, DB interfaces, yes.
"=" (which is all people will see), no.
 
>  * Andy's RFC on lvalue subs getting the rvalue as arguments reworked
>to account for the possibility of multiple rvalues.

This sounds great to me.
 
I'm not trying to create a commotion. I'm just trying to contribute some
different (what I feel to be useful) angles to this discussion. Most
everyone on this list is an expert. Most Perl users aren't. Something
like this should "just work", consistently. Just like all other forms of
assignment.

-Nate

RFC 117 (v1) Perl syntax support for ranges

[Perl6 RFC Librarian]

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

=head1 TITLE

Perl syntax support for ranges

=head1 VERSION

  Maintainer: pdl-porters team <[EMAIL PROTECTED]>
  Date: 16 August 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: 117

=head1 ABSTRACT

This RFC proposes syntactic support for ranges. Range objects
would be especially useful to specify indexing ranges of compact
numerical arrays (currently implemented by PDL) in a concise
manner, e.g.

  $y = $x->slice(0:$n-1:4);
  
Note that currently (perl5) we have to say

  $n1 = $n-1;  # since we need to stringify
  $y = $x->slice("0:$n1:4");

This should be contrasted with the less cluttered syntax offered
by numerical Python and commercial systems such as Matlab and IDL:

  y = x[0:n-1:4]; 
  
In perl we desire to say:

 $y = $x[0:$n-1,4];  
 
or even 

 @y = @x[0:$n-1,4]; 
 
If there is a more general unification of PDL arrays and normal
perl arrays. (See L).

This RFC proposes ranges as part of the syntax cleanup,
L proposes a default method for objects. This RFC is
closely linked to RFC 81: C
(and proposes a subset of the features of that RFC) but emphasizes
two additional aspects: Motivation by requirements of
PDL and the important implementation aspect of I.


=head1 DESCRIPTION

A range would be an object that is different from current perl5
lists but could be interpolated into one if desired. The C<:> operator
would be the range generating operator.

The behaviour would be similar to the '..' operator but generally
no explicit in-memory list would be generated. These ranges would be
very useful to concisely specify subslices into multi-dimensional
numerical arrays.

Perhaps the '..' operator can be recycled as
something else and ':' used for all ranges (or ':' simply be an alias
for '..').

=head2 Examples:

 :   # all the things on this dimension: full span
 5:-1# 5..last
 5:-1:2  # Every second item, up to the last or second last
 -1:7:3  # Start with last item, then fourth last, etc. until 7

  for (0:7) { ... }
  for (0.1:1.0:0.1) { ... }

  $pdl->slice(-1:$n:3) .= 5;
  $pdl->slice(:,::2) *= 2;

An issue is the treatment of potentially infinite ranges of the form

  :
  :5

and similar cases. Those could raise an error if used in a context
where actual list items are generated, e.g.

   for (:) { $a *= $_ }

but be allowed in circumstances where no explicit list item is
ever created, e.g.

  $a->slice(:)

which might actually be written in perl6 as

  $a[:]


=head1 IMPLEMENTATION

Possible. A range should probably be a lazily evaluated list which
functions can choose to accept without the need to actually generate
the list in memory. Compare the RFC on lazy list generation.

A detail that is crucial from our point of view that is not mentioned
in RFC 81 is the ability for a function to inquire the C
parameters of the range and do its own thing without ever generating
a list or list iterator -- an implementation aspect we refer to as
I.

=head1 REFERENCES

L (http://pdl.sourceforge.net/PDLdocs)

http://pdl.perl.org

RFC 24: Semi-finite (lazy) lists

RFC 81: Lazily evaluated list generation functions

RFC 115 (v1) Default methods for objects

[Perl6 RFC Librarian]

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

=head1 TITLE

Default methods for objects

=head1 VERSION

  Maintainer: pdl-porters team <[EMAIL PROTECTED]>
  Date: 16 August 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: 115

=head1 ABSTRACT

This RFC proposes syntactic support for default methods
that can be defined for blessed references. This would
allow the brackets C<()>, C<{}> and C<[]> to be used
for a variety of convenient syntaxes for objects and
allow abolition of tie's.

=head1 DESCRIPTION

=head2 Motivation

Currently, PDL objects have to use quite an unwieldy syntax
for the all important slicing and indexing. In perl5 the syntax is

  $n1 = $n-1;  # since we need to stringify
  $y = $x->slice("0:$n1:4");
  
This should be contrasted with the less cluttered syntax offered
by numerical Python and commercial systems such as Matlab and IDL:

  y = x[0:n-1:4]; 
  
In perl we desire to say:

 $y = $x[0:$n-1,4];  
 
or even 

 @y = @x[0:$n-1,4]; 
 
If there is a more general unification of PDL arrays and normal
perl arrays. (See L). 

Note that we need to keep l-value subs in perl6 to avoid related
types of syntactical clumsiness if C<$x[]> can invoke a subroutine
(see below).

  $x[0:$n-1:4] *= 2;

should be allowed, as well as the long form


  $x->slice(0:$n-1:4) *= 2;

Also it is important to be able to do multi-dimensional lookups
efficiently with compact arrays:

  $y = $x[1:10,5:99];
  

L proposes introducing ranges as part of the
syntax cleanup, this RFC proposes default methods for 
objects.

=head2 Default methods

If classes allowed the definition of a default method that
is invoked with a syntax akin to one used with sub refs we
could have the cake and eat it. The default method notion
seems general enough to be useful for other classes. If normal
perl arrays become able to be represented by objects then one might wish
to say C<@x[0:$n-1,4]>

=head2 Examples:

A possible scenario could be as follows. The class PDL
defines a default method that is invoked when a syntax
like

  $[args]

is used, where C<$Evariable_nameE> is supposed to be an
instance of the class in question (here PDL).

The PDL package would contain the definition of the
method C and  C:

  package PDL;

   

  sub DEFAULT_SQUARE_FETCH {
my $this = shift;
$this->slice(@_);
  }

  # In this case store/fetch are the same.

  *DEFAULT_SQUARE_STORE = \&DEFAULT_SQUARE_STORE;


In a more complex case (for example an array object tied to a 
database) the FETCH/STORE methods would be different code.

Similar methods would be provided for C<{}> and C<()>. This
would allow for the creation of a variety of powerful syntaxes
for different kinds of objects. For example in PDL we might
wish to use C<[]> to slice by index value and C<{}> to slice
by physical real-value coordinate.

All this would probably make implementation of tied classes
a lot more straight forward and makes the tieing mechanism
more closely unified with the object mechanism. The current
tie mechanism is unwieldy and inelegant.

One could also think of this as saying  C<()>, C<{}> and C<[]> 
are operators which can be overloaded.

=head1 IMPLEMENTATION

Changes to the parser to allow the new syntax. Other issues?

Maybe all 3 of these are unnecessary - but at least 2 would
be darn useful.

=head1 REFERENCES

RFC 117: Perl syntax support for ranges

L (http://pdl.sourceforge.net/PDLdocs)

http://pdl.perl.org

Numerical Python: 
http://starship.python.net/~da/numtut/

Re: RFC 114 (v1) Perl resource configuration

[Jonathan Scott Duff]

On Wed, Aug 16, 2000 at 01:07:24PM -0700, Peter Scott wrote:
> At 08:03 PM 8/16/00 +, Perl6 RFC Librarian wrote:
> >Perl should provide a mechanism to have common code autoloaded from a
> >file.
> 
> Please, no.  It's the ultimate scary action-at-a-distance.

If the programmer *wants* action-at-a-distance, Perl has never stood
in the way.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 83 (v2) Make constants look like variables

[John Siracusa]

On 8/16/00 3:55 PM, John Siracusa wrote:
> On 8/16/00 12:37 PM, Perl6 RFC Librarian wrote:
>> This RFC proposes that the current constant.pm module removed, and
>> replaced with a syntax allowing any variable to be marked as constant.
> 
> Unfortunately, I submitted an nearly identical RFC yesterday because I
> didn't see the existing one (I searched for "const" on the RFC homepage, I
> swear! :)
> 
> I'm not sure if mine will end up getting posted...

...and three messages later it appears.  Typical.  Anyway, sorry if
it's redundant.  You can take a look for yourself: RFC 113

-John

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Mike Pastore]

On 16 Aug 2000, Kai Henningsen wrote:

> > This is very Perlish to me; the punctuation is part of the variable name
> > and disambiguates nicely.  I'd be very upset if this idiom went away.
> 
> That would be nice if the punctuation actually *were* part of the variable  
> name.
> 
> However, it isn't: to access 'second', you'd say $args[1], NOT @args[1].  
> It's one of the Perl features that most confuses newcomers.
> 
> If there's no better argument than this, I'd throw this distinction away  
> in a heartbeat.
> 
> If the syntax can be changed so I never have to write @{some array ref}  
> again to explain to perl that yes, I really want to use this array as an  
> array, I'll be a happy man.

Would @$obj->method make you happy? Is it just the braces that's the
problem?

$args[1]   # one whutzit
@args[2..3]# more than one whutzits
@args  # all whutzits

What's so complicated about that?

$hashish{'dog'}# one whutzit
@hashish{'dog', 'cat'} # more than one whutzits
each %hashish  # one whutzit, indexed
%hashish   # all whutzits, indexed
keys %hashish  # all indices
values %hashish# all whutzits

(/me notes that we need a way to take an indexed slice... hmm)

I know I'm being terribly redundant, but the point I'm trying to make is
that the contextual clues (@$%) don't tell you what IT is, but what you're
getting from IT. That's what's so important.

Take this away and Perl becomes C.

int a;
struct b;

*cough* No, thank you.

--
Mike Pastore
[EMAIL PROTECTED]

Re: RFC 114 (v1) Perl resource configuration

[Peter Scott]

At 08:03 PM 8/16/00 +, Perl6 RFC Librarian wrote:
>Perl should provide a mechanism to have common code autoloaded from a
>file.

Please, no.  It's the ultimate scary action-at-a-distance.

I spent several years doing X programming.  Ever seen the flowchart for how 
resources are resolved?  Let's not start down that path.

--
Peter Scott
Pacific Systems Design Technologies

RFC 114 (v1) Perl resource configuration

[Perl6 RFC Librarian]

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

=head1 TITLE

Perl resource configuration

=head1 VERSION

  Maintainer: Jonthan Scott Duff <[EMAIL PROTECTED]>
  Date: 16 Aug 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: 114

=head1 ABSTRACT

Perl should provide a mechanism to have common code autoloaded from a
file.

=head1 DESCRIPTION

Many other programs have so called "resource configuration" files (at
least that's what I call them) that are loaded and interpretted upon
program startup.  Some example programs that have this ability include
bash, mutt, and python.  Perl should do the same.

A C file could be used to set system-wide defaults that
the system administrator would like to promote.  For instance,
C could turn on stricture or warnings.

This RFC proposes that Perl 6 support 2 "rc" files: a per-user file
located in the user's home directory C<~/.perlrc> and a global "rc"
file, C, that affects all instances of perl running on
the machine.

Note that this is couched in terms of a Unix-ish filesystem.  Perl
should support the analogous concept for the other platforms on which
it compiles. 

=head1 IMPLEMENTATION

Make perl look for the rc files.

=head1 REFERENCES

Perl 5.6.0 Documentation

python documentation

bash documentation

mutt documentation

RFC 113 (v1) Better constants and constant folding

[Perl6 RFC Librarian]

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

=head1 TITLE 

Better constants and constant folding

=head1 VERSION 

Maintainer: John Siracusa <[EMAIL PROTECTED]>
Date: Aug 15 2000
Version: 1 
Mailing List: [EMAIL PROTECTED]
Number:  113

=head1 ABSTRACT 

There are many ways to use named "constants" in Perl, but they all have
drawbacks: runtime initialization costs, the extra overhead of loading
another module, the inability to use the constants in certain situations,
and so on.

Constants should be first-class citizens in Perl, and should be constant
folded with a vengeance by a clever compiler.

=head1 DESCRIPTION 

An ideal Perl constant can be used anywhere that a Perl variable of the
same type can be used: a constant scalar can be used in place of any
scalar, a constant array can be used in place of any array, and so on.
These constants should not incur runtime inefficiencies or undue
compile-time overhead.  Performance should be should be exactly as if the
data was hard-coded in place.

=head1 IMPLEMENTATION

The simplest solution is something like:

constant $PI = 3.14159265;

This looks shockingly similar to the current, much maligned (by me, anyway)
constant module:

use constant PI => 3.14159265;

but the former has many syntactic advantages.  First, there's no "use"
directive to reveal the constant's second-class citizenship.  Second, it
uses the assignment operator instead of the "fancy comma."  Third, context
is determined by the left-hand-side of the assignment operator instead of
always being forced into list context.

Using these constants is simple.  They behave just like variables of the
same type.

print "Would you like some apple $PI?"; # A constant string

That whole string is converted to a single constant at compile time.
Collections behave in a similar manner:

constant @FISH = (1, 2, 'red', 'blue');

print @FISH;   # prints "12redblue"
print "@FISH"; # prints "1 2 red blue"

print "$FISH[2] head"; # prints "red head"

Again, each argument to C is converted to a constant string at
compile time.

Modification of a constant is a compile-time error:

$PI = 5;   # Bzzt!
$PI =~ s/\.\d+$//; # Sorry
$#FISH = 15;   # Nice try

The C keyword should work when combined with C and C:

package Foo;

our constant $GOO = 5;

if(...)
{
  my constant $GOO = 10;
  
  print $GOO; # Prints 10
}

As an added implementation bonus, "constant methods" should be supported
in the same way that "constant subroutines are now.

package MyConstants;
constant $PI = 3.14159265;

package MyClass;
...
sub method { $MyConstants::PI }

package MyLib;
...
sub func { $MyConstants::PI } # Shouldn't have to be sub func() ...

Both C and C should know that they return constants,
and the compiler should optimize them away whenever possible, even without
explicit hints like an empty "()" prototype after C.  Yes, there
are issues with turning a method call into a constant at compile time, but
it's possible if Perl can determine with certainty that C
is the actual code that will be executed by an object or class method call.
Example:

my $obj = MyClass->new;

print $obj->method();# Converted to the constant 3.14159265
print MyClass->method(); # Ditto

Again, this magic is accomplished by a clever compiler that does not need
this type of help:

my MyClass $obj = MyClass->new; # Not necessary, ideally

As should be clear by now, I'm not too familiar with the perl internals
that are required to support this stuff.  It just "seems possible" to me.
And hey, there are no "perl internals" to speak of yet in a "clean-sheet"
implementation, right?

=head1 REFERENCES 

Perl's C pragma documentation.

RFC 108 (v2) Scope of Polymorphic References and Objects

[Perl6 RFC Librarian]

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

=head1 TITLE

Scope of Polymorphic References and Objects

=head1 VERSION

Maintainer: Syloke Soong <[EMAIL PROTECTED]>
Mailing List: [EMAIL PROTECTED]
Date: 15 Aug 2000
Last-Modified: 16 Aug 2000
Version: 2
Number: 108

=head1 ABSTRACT

Syntax for Polymorping and Scoping References

=head1 DESCRIPTION

This is a proposal to define the scoping and overloading of Perl
references.  The polymorphic signature is proposed to comprise the arglist
members, candidate operators and the return list members. In other words,
rather than the tradition of using just the head (java) or head+operator
(c++), the proposal is for head+tail or head+operator+tail polymorphic
signatures .

=head1 IMPLEMENTATION

Reference to RFC89 is recommended to relate to fixating or constraining
the data type of a variable.

For comprehension of this proposal, the following terms are held within
the bounds of this document. The concept stays, notwithstanding.

  var $a;
  our $b;
  my $c;
  $d = 0;

$a is defined to be referentiable as public.
$b is defined to be referenced within protected bounds of a package .
$c is defined to be referentiable only privately within a function.
$d is defined implicitly to be referentiable privately within a file.


=head2 A new object module declaration method

Allow function arg list but continue to use @_;
The following would be equivalent forms in Perl5 and Perl6, respectively:

  package Pine::Tree::State;
  sub genesis
  {
   my ($pkg, $oak, $maple) = @_;
   my $a = {};
   bless $a, $pkg;
   return $a;
  }

  package Pine::Tree::State;
  var genesis:(\new);
  function new ($oak :int, $maple: double)
  {
   bless $a:const={}, genesis;
   our $world={};

   return $a;
  }
  function aux ($spruce:int)
  {
   my $world = this->$world; # this is instance handle of self object

  # my $world = our->$world; # how about using our?
  # my $world = my->$world; # or what about my?
  }


=head2 Overloading of references

A reference may be overloaded with a search list, thus acting as a container.

  my $a1:(int) = 3;
  my $a2 = 4;
  my $a3:(int);
  my $a:($a1, $a2, $a3, double);

$a is constrained in the following precedence 
- references $a1 if an integer evaluation is done 
- references $a2 if a liberal evaluation is done
- references double if a double evaluation is done
- $a3 is unreachable because $a1 is precedent in the search list

  $a = 11; #equivalent to $a1 = 11;
  $b:(int) = $a ; #equivalent to int $b = $a1;
  $a = 11.1; $c:(double) = $a ; #equivalent to double $c = 11.1;
  $a = 11.1; $c:(varchar) = $a ; #equivalent to varchar $c = '11.1';
  $a = 11.9; $d:(int) = $a ; #equivalent to int $c = 11;
  $a = 11.9 + 0.5 ; $ceiling:(int) = $a ; #equivalent to int $ceiling = 12;

=head2 Overloading of object containers

  package Pine::Tree::State;

  var genesis:(\new_a, \new_b, \new_c); 
  var habakuk:(\new_b, \new_c);
  var getab:(\new_a, \new_b);

  function new_a ($oak int, $maple double)
  {
   return bless $a:const={}, genesis;
  }

  function new_b ($oak:(varchar,int), $maple)
  {
   bless $a={},genesis;
   bless $b={},habakuk;
   my $c={};
   var $r:($a,$b,$c); 

   return $r;
  }

  function new_c (varchar $oak, $maple, $pine)
  {
   bless $a:const={}, (genesis,habakuk); 
   return $a
  }

  #!/usr/bin/perl
  use Pine::Tree::State;

  my $a:(varchar,int);
  my habakuk $pineapple = genesis Pine::Tree::State($a, 'Banana');
  my $melon = genesis Pine::Tree::State($a, 'Banana');

Blessing genesis confers it a constructor container. genesis is overloaded with
two function references stored in an array. Refer to RFC89 for fixating the
data type of a variable. getab is an overloaded function container but not of
constructors.  new_c acts as a constructor through genesis or habakuk but not
through getab.

Matching a call to a member of a container is by means of a signature due to
the combination of the function argument list and return list. RFC89
suitability and precendent rules apply to matching signatures. The order of the
array dictates the search order to match a call to the members of an overloaded
reference.

habakuk is an alternate constructor within the package.

new_b is an insteresting constructor/function. Can you theorise what happens
when new_b is activated through constructor container genesis, or constructor
container habakuk, or object container getab?

Notice new_b has arglist member $oak:(varchar,int), while new_c has varchar
$oak.  Effects of type casting and contraint are propagated into the function
body.

Signature of new_b is invoked by the genesis of Pine::Tree::State by
$pineapple. $new_b->$r is an overloaded reference. Return of $r is a
polymorphic return. $pineapple invokes new_b through genesis but has a casted
reception for habakuk. So even though it is genesis'ed it becomes a habakuk
object. Meanwhile $melon becomes a genesis object by having the value of
new_b->$r:$c returned

Re: RFC 83 (v2) Make constants look like variables

[John Siracusa]

On 8/16/00 12:37 PM, Perl6 RFC Librarian wrote:
> This RFC proposes that the current constant.pm module removed, and
> replaced with a syntax allowing any variable to be marked as constant.

Unfortunately, I submitted an nearly identical RFC yesterday because I
didn't see the existing one (I searched for "const" on the RFC homepage, I
swear! :)

I'm not sure if mine will end up getting posted, but in case it doesn't,
here are my comments/additions to RFC 83:

> It is proposed that a new syntax for declaring constants be introduced:
> 
> my $PI : constant = 3.1415926;
> my @FIB : constant = (1,1,2,3,5,8,13,21);
> my %ENG_ERRORS : constant = (E_UNDEF=>'undefined', E_FAILED=>'failed');
>
> Constants can be lexically or globally scoped (or any other new scoping
> level yet to be defined).

I'm not crazy about the "attribute" syntax's use for constants.  I prefer
this:

constant $PI = 3.1415926;

which nicely cleans up the my/our situation if you're not opposed to
chaining operators:

our constant $PI = 3.1415926;

if($urban_legend)
{
  my constant $PI = 3.0;
  ...
}

> If an array or hash is marked constant, it cannot be assigned to, and its
> elements can not be assigned to:
> 
> @FIB = (1,2,3);   # Compile time error
> @FIB[0] = 2;  # Compile time error
> %ENG_ERRORS=();   # Compile time error
> %ENG_ERRORS{E_UNDEF=>'No problem'} # Compile time error

I also extended this to ensure that nothing but reading can be done to
constant collections.  So this is also true:

$#FIB = 100; # Compile-time error

(Not sure if that was implied in the examples given.)

> To create a reference to a constant use the reference operator:
> 
> my $ref_pi = \$PI;
> 
> To create a constant reference use a reference operator in the
> declaration:
> 
> my $a = 'Nothing to declare';
> my $const_ref : constant = \$a;

I didn't address references, but I figured they would look like this:

my $a = 'Nothing to declare';
my constant $ref = \$a;
 
> EXTENSIONS
> 
> It may be desirable to have a way to remove constness from a value. This
> will not be covered in this RFC--if it is required a separate RFC should
> be written referencing this one.

I didn't address this issue either, but my feeling is that it definitely
should NOT be possible to "remove const-ness" from a variable.  Part of the
motivation for my constants RFC was the ability to do clever constant
folding at compile-time, even going so far as to fold this:

print $obj->method_returning_constant();

into the run-time equivalent of printing a constant string, when possible.
(A bit more detail is in my RFC, which, of course, is "in my other
computer" at the moment...and/or lost in the ether on its way to the RFC
address.  I'd post the relevant section if I had it.)

-John

Re: RFC 17 (v2) Organization and Rationalization of Perl

[David L. Nicol]

   s/PSEUDO\S?HASH/STRUCT/g

Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)

[Nathan Torkington]

Nathan Wiger writes:
> Nonetheless, I think a better thing would be to figure out if it's
> possible to "fix" this issue. I would *really* like lvalue subs ==
> rvalue subs.

I think conflating:
   foo(@vals)
and
   foo() = @vals

is misleading and going to cause more confusion that it solves.

> I strongly disagree with this. You know how many people have problems
> with my? Lots.

What kinds of problems can you possibly have with my()?

> The concept isn't that hard ":lvalue makes it so you can assign to
> subs". But the hard part is deciding *where* it should be used. I think
> it puts an unfair burden on a CPAN author to try and forsee all the
> possible uses of a sub.

My turn to strongly disagree.  Module programmers must decide on an
interface to that module.  Programmers wanting to use the module must
read its documentation to see what that interface is.  There might be
thousands of possible interfaces, and module authors are *NOT* under
any obligation to implement them all.  Lvalue subs do not change this.

> If the author doesn't forsee this, then I have to ask them to patch it.

No, you work with what you have.  Modules, like Perl, don't have to
be all things to all people.  This idea that it "ought to work" is
what's broken.

Here's what I want:

 * Andy's RFC on lvalue subs getting the rvalue as arguments reworked
   to account for the possibility of multiple rvalues.

 * A separate RFC saying what I want.

I'll write the separate RFC now.  Then we can shut up and let Larry
sort it out.

Nat

Re: RFC 112 (v1) Assignment within a regex

[David L. Nicol]

Glenn Linderman wrote:
> 
> This deserves a "me too".
> 
> Perl6 RFC Librarian wrote:
> 
> > The camel and the docs include this example:
> 
> >if (/Time: (..):(..):(..)/) {
> > $hours = $1;
> > $minutes = $2;
> > $seconds = $3;
> > }
> >
> > This then becomes:
> >
> >   /Time: (?$hours=..):(?$minutes=..):(?$seconds=..)/
> >
> > This is more maintainable than counting the brackets and easier to understand
> > for a complex regex.  And one does not have to worry about the scope of $1 etc.

imagine its strength along with defined record structures and a Pascal-like C


-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
 Useless use of a void in constant context

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Kai Henningsen]

[EMAIL PROTECTED] (Dan Sugalski)  wrote on 15.08.00 in 
<[EMAIL PROTECTED]>:

> The ultimate target of a program's source code is the *programmer*.

True.

> Programmers, being people (well, more or less... :), work best with symbols
> and rich context.

This particular programmer *hates* what Perl does with @ and %.

>Stripping contextual clues out of code does the
> programmer a disservice.

You mean like when you access members of @x, you have to write $x?

>We're at the point where we don't have to cater to
> the limitations of the computer hardware. That means we'll be better off if
> we cater to the limitations (and strengths!) of people's wetware.

Please do, and get rid of this particular language misfeature.


MfG Kai

Re: RFC 105 (v1) Downgrade or remove "In string @ must be \@" error

[Kai Henningsen]

[EMAIL PROTECTED] (Nathan Wiger)  wrote on 15.08.00 in 
<[EMAIL PROTECTED]>:

> > I'd say, if the variable exists, interpolate it.  If not, print it as
> > it stands.
>
> I initially was thinking this too, but there's a major problem:
>
>print "Your stuff is: @stuff\n";
>
> I want this to *always* print out the _value_ of @stuff, even if it's
> unititalized.

Uninitialized != doesn't exist. Not arguing for or against the RFC, just  
pointing out the difference.

MfG Kai

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

[Kai Henningsen]

[EMAIL PROTECTED] (Jonathan Scott Duff)  wrote on 15.08.00 in 
<[EMAIL PROTECTED]>:

> You're right, there should be just one date/time routine.  But it is
> *extremely* difficult to incorporate time zones in a portable fashion.
> They change at legislative whim.  But if utcdate() (or whatever we
> call it) had a way to specify an offset from UTC, that would be just
> fine.

There's a reason why the Olson timezone routines&data exist.

Use them. Make the data easily updatable (actually, it would be hard to  
make it *not* easily updatable).

Problem solved.

MfG Kai

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Kai Henningsen]

[EMAIL PROTECTED] (Russ Allbery)  wrote on 15.08.00 in 
<[EMAIL PROTECTED]>:

> > All variables should be C<$x>. They should behave appropriately
> > according to their object types and methods.
>
> No thanks.  I frequently use variables $foo, @foo, and %foo at the same
> time when they contain the same information in different formats.  For
> example:
>
> $args = 'first second third';
> @args = split (' ', $args);
> my $i = 0;
> %args = map { $_ => ++$i } @args;
>
> This is very Perlish to me; the punctuation is part of the variable name
> and disambiguates nicely.  I'd be very upset if this idiom went away.

That would be nice if the punctuation actually *were* part of the variable  
name.

However, it isn't: to access 'second', you'd say $args[1], NOT @args[1].  
It's one of the Perl features that most confuses newcomers.

If there's no better argument than this, I'd throw this distinction away  
in a heartbeat.

If the syntax can be changed so I never have to write @{some array ref}  
again to explain to perl that yes, I really want to use this array as an  
array, I'll be a happy man.

MfG Kai

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Kai Henningsen]

[EMAIL PROTECTED] (Nathan Torkington)  wrote on 15.08.00 in 
<[EMAIL PROTECTED]>:

>  * you misunderstand the purpose of $ and @, which is to indicate
>singular vs plural.

Yes. That's one of the things that's wrong with it - maybe the biggest of  
all.

It's one of the things that require constant attention to get right for  
me. It's *not* natural.

Yes, singular and plural per se are natural. But an array element *is not*  
singular to an array.

Look at that sentence. It contains two singulars: an array, and an array  
element. There's no plural in there.

Perl "plural" is a very different concept from natural language plural,  
and *that* is why it's bad.

$ vs. @ is not really about singular or plural. It's about context  
dependency.

And context dependency is bad for people.

There is a reason that no language after Algol68 used a context dependant  
grammar.

There is a reason that nearly all modern computer languages don't make  
expression evaluation dependant on expression context.

The reason is *not* that this is easier for computers. It is easier, sure,  
but not all that much.

But it is *a lot* easier for humans.

A rose is a rose is a rose. Human minds really don't like context  
dependancy.

MfG Kai

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Kai Henningsen]

[EMAIL PROTECTED] (Nathan Torkington)  wrote on 15.08.00 in 
<[EMAIL PROTECTED]>:

> Stephen P. Potter writes:
> > Why is it silly?  Hashes and arrays are *conceptually* very similar
> > (even if they are extremely different implementation-wise).
>
> If that were the case, I think students would have an easier time
> grasping hashes.  It seems very common (yes yes, you all got them
> immediately, but merely by piping up and saying so, you do not
> invalidate my point, so please don't) that beginners take a long time
> to use hashes because they find them hard to get their heads around.

I see two possible reasons for that:

1. Hashes aren't explained right.
2. They already know about computers and arrays.

To someone who doesn't know about computers and arrays, hashes are the  
more natural concept, because they are how you do stuff like that in real  
life, and arrays are just a special case of hashes.

There's a reason symbol tables are hashes and not arrays: people are  
better with names than with numbers.

(Of course, one of the problems with hashes is the name. For most  
purposes, the fact that a (non-tied) hash uses hashing is completely  
irrelevant to someone learning the language.)

Perl really goofed here. The generic concept should be the collection.  
Collections can be indexed in lots of different ways, and (Perl) hashes  
and arrays are just two of many options. (Think of trees, for example.)

> This isn't why it's silly, just a comment on the idea that hashes
> and arrays are conceptually very similar.

Well, they are.

> world.  I like Perl being able to optimize internally based on my
> simple one-character data typing (%).

I'd actually prefer if the computer could work that out for itself. That's  
the type of stuff computers are supposedly good at.

MfG Kai

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Kai Henningsen]

[EMAIL PROTECTED] (Dan Sugalski)  wrote on 15.08.00 in 
<[EMAIL PROTECTED]>:

> At 06:04 PM 8/15/00 -0400, John Porter wrote:
> >Dan Sugalski wrote:
> > > >Generality good.
> > >
> > > For many things, yes. For computers, say. For people, no. Generality
> > > bad. Specificity and specialization good. People aren't generalists.
> > > They're a collection of specialists. The distinction is important.
> >
> >I'm sorry if I don't find this argument convincing.
> >This argument suggests that *every* type carry a distinguishing
> >prefix symbol -- including ones to distinguish between numbers and
> >strings, say.
>
> Numbers and strings really aren't different things, at least not as far as
> people are concerned.

Bovine excrement. Numbers and strings completely different things to  
people.

Hashes and arrays, OTOH, really aren't different for people. The concept  
of an index needing to be a nonnegative number is a computer concept.

>They are for machines, but computer languages
> ultimately aren't for machines, they're for people.

I agree that computer languages are for people - in fact, that's the sole  
reason they were invented. Otherwise we'd still program in machine  
language.

However, I do think your ideas about what does and does not come naturally  
to people are incredibly warped.

> I'm not presuming that, though there are plenty of languages already that
> have no symbols. Perl's not one of them, though.

I presume you mean $@% when you say symbols (and not, for example, the  
stuff that goes into a symbol table, because I certainly don't know any  
language that doesn't have those).

It's an open question if these are a good idea. I'm not convinced.  
Personally, I see them as one of the ugly warts in Perl.

> > > Even assuming highlander types, the punctuation carries a rather
> > > significant amount of contextual information very compactly.

s/significant/in&/ IMNSHO, even ignoring the "even" part.

> It's going to always be more difficult. You need to *think* to turn a word
> into a symbol. = is already a symbol. Less effort's needed.

Maybe *you* have to think to turn a word into a symbol. Most people seem  
to grow up with that concept.

As for *recognizing* the stuff, ever heard of redundancy? It's the stuff  
that makes recognizing stuff easier.

Words, by being longer, are easier to recognize than non-alphabetic  
symbols.

Now, as always, you have to strike a balance. We don't want COBOL. But we  
also don't want APL.

> > > ...exploiting instinct and
> > > inherent capabilities give you faster response times, and quicker
> > > comprehension.
> >
> >Sure.  But "instinct and inherent capabilities" do not apply here.
>
> Yes, they do. People write source. People read source. People are the most
> important piece of the system. The computer can be made to cope with the
> syntax, whatever the syntax is. People can't be made to cope nearly as
> easily, nor to nearly the same degree.

I completely agree with this point. Which is exactly why I disagree with  
most of your other points.


MfG Kai

Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)

[Nathan Wiger]

Nathan Torkington wrote:
>
> > Then I think both of these should act exactly the same:
> >
> > somesub(@values);
> > somesub = @values;
> 
> EUGH.  No way!
> 
> Assignment should be used to reflect (get this) assignment.  Using
> it as argument passing is disgusting.  I'm assuming you're not
> *advocating* this, merely pointing out that it's a side-effect of
> the RFC's suggested implementation.

Not in this ridiculously trite example, no. It's silly and stupid. And
misleading.

However, chaining together lvalue subs is a very useful shortcut:

   @output = ($title, $x, $f->xml_extract) = ;

Agreeably, this is not a 1:1 on the assignment front. But I'd like to be
able to do this. "Disgusting" is a matter of taste. :-)

As for the other arguments about "magical $LVALUE" stuff, I'm firmly
against those. I am 100% behind the RFC - everything should go into @_.
I just think the above is a useful extension that shouldn't be
overlooked. It's really powerful.

-Nate

Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)

[Nathan Wiger]

Nathan Torkington wrote:
>
> I think I failed to explain Damian's use of the word 'dangerous'.
> 
>   my $var;
>   sub routine {
>  $var;
>   }
> 
> This, by virtue of rvalue subs being default, keeps the lexical $var
> private.  Damian's big on privacy.

> (2) Changing variables in the subroutine's scope is a BIG THING, and
> ought to be explicitly enabled, rather than explicitly disabled.

Ok, this a good issue. And I wasn't trying to be rhetorical. :-) The RFC
states that "lvalue subs will be directly equivalent to rvalue subs".
That's what I was basing my statements off.

If that's not true, and stuff like variable scoping is still going to be
a tricky concern, then the RFC should mention this. In that case, I'll
certainly put up with Andy's "use lvalue" pragma idea.

Nonetheless, I think a better thing would be to figure out if it's
possible to "fix" this issue. I would *really* like lvalue subs ==
rvalue subs.

> (3) :lvalue is hardly rocket science.  You drastically overstate its
> complexity.

I strongly disagree with this. You know how many people have problems
with my? Lots.

The concept isn't that hard ":lvalue makes it so you can assign to
subs". But the hard part is deciding *where* it should be used. I think
it puts an unfair burden on a CPAN author to try and forsee all the
possible uses of a sub.

A later example I sent out shows, I think, how someone could miss a
really great use of a sub that seems like it should only be rvalue-able:

   @result = ($first, $second, $r->fix_chars) = split /:/, ;

If the author doesn't forsee this, then I have to ask them to patch it.
What if they're busy? Or aren't interested? Do I have to hack the module
to make something that works just fine actually work?

If lvalue subs are *exactly* like rvalue subs (as the RFC says
currently) then keeping the :lvalue makes no sense. I think this should
be the goal: to truly make them "directly equivalent" as the RFC states.
If we can't do this, then we can fall back to a "use lvalue" pragma at
the last minute.

-Nate

Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)

[Nathan Wiger]

Jonathan Scott Duff wrote:
>
> Hrm.  Perhaps you aren't explaining yourself clearly.  Let's pretend
> that there is a magical value called $LVALUE that contains the thing
> being assigned.  Are you saying that in
> 
> somesub = $value;
> 
> the subroutine C, being lvaluable by default is free to use
> or ignore $LVALUE?  If so, how does one detect errors?  When
> C is ignoring $LVALUE the above would silently fail, yes?

That's similar to what I'm saying. If you had the sub:

sub somesub {
my(@stuff) = @_;
# do nothing
}

Then I think both of these should act exactly the same:

somesub(@values);
somesub = @values;

According to the RFC, the lvalue sub gets @values in @_ like an rvalue
sub. The two should walk and talk identically. (Scoping aside, see my
email to Nat). In this case, there's nothing special about lvalue subs,
so we should drop :lvalue.

I know that's not how 5.6 works, but it's what the RFC says. See what
I'm saying?

-Nate

Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)

[Nathan Torkington]

Nathan Wiger writes:
> sub somesub {
> my(@stuff) = @_;
> # do nothing
> }
> 
> Then I think both of these should act exactly the same:
> 
> somesub(@values);
> somesub = @values;

EUGH.  No way!

Assignment should be used to reflect (get this) assignment.  Using
it as argument passing is disgusting.  I'm assuming you're not
*advocating* this, merely pointing out that it's a side-effect of
the RFC's suggested implementation.

> I know that's not how 5.6 works, but it's what the RFC says. See what
> I'm saying?

Yeah.  I think the RFC is wrong wrt how the lvalue subroutines get
their arguments.

If a subroutine can be passed a list of parameters, and can receive
any number of parameters via assignment, how do you tell them apart?
It's the same problem as:
  subcall(@a, @b);
You can't tell where @a stops and @b begins.  And you have to be able
to, because the values may be serving completely different roles
(keys into a database for @a, values stored there for @b).

The RFC should tackle this.

Nat

remember the "penguin" module?

[David L. Nicol]

The penguin module, as written about in an early TPJ

http://cpan.valueclick.com/authors/id/F/FS/FSG/

is a way to mask off part of the functionality of your perl
in order to "sandbox" with very fine grained control.


Let's put that into the core of perl6, the ability to
turn features off, particularly within evals.


-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
 Useless use of a void in constant context

Re: RFC 56 (v2) Optional 2nd argument to C and C

[Glenn Linderman]

Seems like the results of

@b = 1 .. 10;
for ( 1 .. 3 )
{ push @a, pop @b;
}

and

@b = 1 .. 10;
push (@a, pop ( @b, 3 ));

But this RFC makes it seem like they produce different results in @a.  One could
argue that the current definition of unshift has a similar problem, and that you
are "preserving" that behavior.  i.e. shouldn't:

unshift ( @a, 1, 2, 3 );

produce the same result as

for ( 1 .. 3 )
{ unshift ( @a, $_ );
}

So while your proposed pop and the current unshift can be easily defined in terms
of splice, I think that produces unexpected results.

I'd like to see this RFC modified so that both the above two sequences are
equivalent.  p52p6 can convert

   unshift @x, ...

to

   unshift @x, reverse ...

and all will be well.

> What should happen when the expression given to C, or
> C evaluates to a negative number?  I see three options:
>
> 1) Nothing.  We can only pop/shift positive amounts
> 2) Act as if the number were positive  (i.e. pop @array, abs(EXPR))
> 3) C would then act as C and C would
>act as C
>
> The responses to this RFC so far haven't seen any consensus on this
> matter (unless you call one person voting for option #3 a consensus).
> However, I propose that option #3 be adopted since it seems the most
> Perlian to me.

I like #3 too, does that make a better consensus?

--
Glenn
=
There  are two kinds of people, those
who finish  what they start,  and  so
on... -- Robert Byrne



NetZero Free Internet Access and Email_
Download Now http://www.netzero.net/download/index.html
Request a CDROM  1-800-333-3633
___

Re: Permanent sublists (was Re: Language WG report, August 16th 2000)

[Nathan Wiger]

> i see problems with overlapping areas. I/O callbacks fall under both io
> and flow IMO. some of the error handling like dying deep in eval and
> $SIG{DIE} also fall under error and flow.

True. But it should be up to the RFC author to choose the relevant list.
I think RFC authors have been pretty good at this in general if there's
an established sublist (-io and -subs have several unsolicited RFC's)

> but in any case why am i still seeing error stuff if i am not subscribed
> to that list? people are not reading the relevent new list posts and
> moving their email threads (the third overload of threads!) to the
> proper list. i agree with skud, there is too much on the main language list.

It's hard to keep up. That's why some type of permanent list structure
is good. Right now, people are hopping in 500 emails behind, replying to
something in the middle of the stream, and only later reading the
"please move this to -errors" post.

Stuff started on the proper sublist, though, has done a good job of
staying there overall.

-Nate

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Russ Allbery]

John Porter <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:

>> $args = 'first second third';
>> @args = split (' ', $args);
>> my $i = 0;
>> %args = map { $_ => ++$i } @args;

>> This is very Perlish to me; the punctuation is part of the variable
>> name and disambiguates nicely.

> No, it's not.  Where are we taught this?  It's a myth.

> The punctuation imposes context on the variable expression.

>   $foo[0]

> accesses an array.  Where's the "@"?

Now the [0] is disambiguating.  Same difference.  I'm not interested in
nit-picking semantics.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: error handling and syntax extension

[Jonathan Scott Duff]

On Wed, Aug 16, 2000 at 12:15:30PM -0500, David L. Nicol wrote:
> If "catch" can be defined DURING PARSING
> 
> and SYNTAX ERRORS are catchable
> 
> 
> error handling can be used to define otherwise
> undefined syntax, becoming a macro language.

And AUTOLOAD can go away too!  :-)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Permanent sublists (was Re: Language WG report, August 16th 2000)

[Uri Guttman]

> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:

  NW> I agree. I think the trend should be to establish some permanent
  NW> sublists, which we're informally leaning towards already. Something
  NW> like:

  NW>-io   = ALL I/O issues, like open/socket/filehandles
  NW>-subs = ALL sub/method/func issues, like lvalue subs
  NW>-strict   = ALL lexical/global variable scoping issues
  NW>-objects  = ALL OO and module issues
  NW>-flow = ALL flow/threading issues
  NW>-errors   = ALL error handling issues
  NW>-datetime = ALL date/time/etc issue

i see problems with overlapping areas. I/O callbacks fall under both io
and flow IMO. some of the error handling like dying deep in eval and
$SIG{DIE} also fall under error and flow.

but in any case why am i still seeing error stuff if i am not subscribed
to that list? people are not reading the relevent new list posts and
moving their email threads (the third overload of threads!) to the
proper list. i agree with skud, there is too much on the main language list.

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: English language basis for "throw"

[David L. Nicol]

Bart Lateur wrote:
> 
> To me, a program is much like a maze, a
> multilevel walk in an old castle. 

And if you commit a faux pas of some kind, the guards show
up and "throw" you off the north tower.

-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
 Useless use of a void in constant context

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Peter Scott]

At 11:17 PM 8/15/00 -0400, Chaim Frenkel wrote:
> > "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
>
>NT> Chaim Frenkel writes:
> >> Why? What is the gain? Perl only runs on the local machine.
>
>NT> Epoch seconds are a convenient representation for dates and times.
>NT> Varying epochs make it an unreliable representation when data are
>NT> shared.  A consistent epoch would fix this.
>
>Sorry, I don't buy that. Not every program will be perl. Plus you are
>assuming that epoch seconds are good everywhere. And even if it were
>why should any other program use the same epoch.
>
>The only valid interchange would be to specify the date unambiguously,
>for example the ISO MMDDHHMMSS.fff

ISO 8601.  http://www.cl.cam.ac.uk/~mgk25/iso-time.html

--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 110 (v1) counting matches

[Uri Guttman]

> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:

  GB> On Wed, Aug 16, 2000 at 10:49:16AM -0500, Jarkko Hietaniemi wrote:
  >> On Wed, Aug 16, 2000 at 04:41:33PM +0100, Graham Barr wrote:
  >> > On Wed, Aug 16, 2000 at 10:20:28AM -0500, Jonathan Scott Duff wrote:
  >> > > > m//gt would be defined to do the match, and return the count of matches, 
this 
  >> > > > leaves all existing uses consistent and unaffected.  /t is suggested for
  >> > > > "counT", as /c is already taken.  Using /t without /g would be result in
  >> > > > only 0 or 1 being returned, which is nearly the existing syntax.
  >> > > 
  >> > > Better would be to redefine what m//g means in a scalar context. 
  >> > > 
  >> > >$_ = "foofoofoofoofoofoofoo";
  >> > >$count = m/foo/g;
  >> > > 
  >> > > 1 is just as true as 7.
  >> > 
  >> > But you would loose the functionality of \G starting where the last match
  >> > left off. This is very useful.
  >> 
  >> /gg to "count 'em all"? :-)

  GB> Fine with me.

might as well use a different modifier like the proposed /t. this is not
like /ee which does the eval twice. you can't do 'global' twice.

another point might be to make /g and /t in scalar context mutually exclusive
(fatal error) since /g means remember where we matched for the next time
and /t means count all the matches.

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 84 (v1) Replace => (stringifying comma) with =>

[Russ Allbery]

Stephen P Potter <[EMAIL PROTECTED]> writes:

> What stops us from imposing order on this chaos?  If they are currently
> defined as not having any specific order, why can't we say they always
> return in numeric || alphabetic || ASCII || whatever order we want?

Because the fewer guarantees you make, the more efficiency you can get.
The above would prevent a hypothetical future smart Perl interpretor from
reordering your hash behind the scenes in another thread while your
program is using it to optimize for the usage pattern that it's seeing,
for example.

If you have to guarantee a sorted traversal of the hash keys, your choices
of data structures are *far* more limited.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

pascal-like "with" was Re: Default filehandles(was Re: command line option: $|++)

[David L. Nicol]

The poll can't have been exhaustive.

I like these magic variables that depend on currently selected
fie handles, they remind me of Pascal's C construction
for entering the name space of a record structure.


Anyone for generalizing "select" to a more general "with" keyword
which would operate on a limited hash and be syntactic sugar for
replacing all appearances of unqualified variables that match
the hash's keys with references into it?


%record = loadrecord($studentID);
with %record {
print < http://www.mail-archive.com/perl6-language-io@perl.org/msg00094.html
> 
> This is a succinct summary of the basic conclusions thus far:
> 
>1. a default filehandle IS needed sometimes, but only
>   for stuff like print
> 
>2. $|, $\, $/, etc will probably go away entirely in
>   favor of object methods such as $handle->autoflush
> 
> That's the current thinking. As always, this is subject to change.
> However, most everyone seems to agree that "having global $| vars that
> aren't really global but actually depend on what the currently selected
> filehandle is which depends on what select() was called on" is bad. So,
> setting stuff like autoflush will probably be object methods only.
> Setting stuff like the default for print will probably still be via the
> default filehandle.
> 
> -Nate

-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
 Useless use of a void in constant context

Re: RFC 110 (v1) counting matches

[Nathan Torkington]

Jarkko Hietaniemi writes:
> > Better would be to redefine what m//g means in a scalar context. 
> > 
> > $_ = "foofoofoofoofoofoofoo";
> > $count = m/foo/g;
> > 
> > 1 is just as true as 7.
> 
> I like this.  No extra //modifiers to learn.

scalar context of /g is already defined to be something useful.  You'd
have to make a new modifier to indicate you want the old /g behaviour,
which seems ... suboptimal.

Doubling the modifier /gg is not an option.  Doubling a modifier
shouldn't make it do something completely different.

I suggest /n if you want the match to always return the [N]umber of
matches.

Nat

Re: RFC 74 (v2) Proposal to rename C and C

[Nathan Wiger]

> And I'm not proposing that this should change, just that import should
> be spelled "IMPORT".  The perl5 to perl6 translator would simply do
> s/import/IMPORT/g (okay, not *simply*, but you get the drift)

So in your code, if you wanted to explicitly import something you'd have
to write:

   require Module;
   IMPORT Module;

??? Don't like it at all, sorry. It would be the only uppercase keyword
in Perl. The syntax should remain 

   import Module;   # yes, I do this, you need to sometimes

Think of other cases, they all do something similar to what I proposed:

   tie *STDOUT, 'Apache'; # TIEHANDLE
   print STDOUT;  # PRINT
   close STDOUT;  # DESTROY

and so on...

-Nate

Re: subroutines ==? methods

[David L. Nicol]

Say we allow instantly tied lazy subroutine definitions
like so:


@naturals = (? { my $x=1; yield $x++ while 1 })


Is the code block in there a subroutine or a method?


And why?


How about using the eminently deprecatable "reset" operator
to start a tied lazy array back at it's "original" state
(as long as the array's name is more than one letter, of course,
for backwards compat.)




-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
 Undefined use of void in constant context

Permanent sublists (was Re: Language WG report, August 16th 2000)

[Nathan Wiger]

"Bryan C. Warnock" wrote:
>
> ... is the cause for this.  All the discussion is taking place in the
> master list before the sublists are spawned.  You can only express the
> opinion that foo is not bar and never should be so many times.

I agree. I think the trend should be to establish some permanent
sublists, which we're informally leaning towards already. Something
like:

   -io   = ALL I/O issues, like open/socket/filehandles
   -subs = ALL sub/method/func issues, like lvalue subs
   -strict   = ALL lexical/global variable scoping issues
   -objects  = ALL OO and module issues
   -flow = ALL flow/threading issues
   -errors   = ALL error handling issues
   -datetime = ALL date/time/etc issue

The general language list can still be an "else" case. This is already
in place, I'm just proposing these be made permanent, and that the RFC
author choose a sublist for their discussion. General stuff like "chomp
changes" should still go to the main list probably.

If a person doesn't care or trusts others' judgment, they only have to
join those discussions they want to contribute to. If they see a really
juicy RFC come out on perl6-announce, they can always join the sublist
then.

Anyways, that's my input. I don't think topical lists have or will be
effective because, as Bryan notes, most discussions are largely finished
by the time a sublist is created. Plus, with permanent sublists people
can establish a feel for the group and perhaps provide better input.

-Nate

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[John Porter]

Nathan Torkington wrote:
> John Porter writes:
> > foo $= ( bar, quux );  # provide scalar context to both sides
> > foo @= ( bar, quux );  # provide list context to both sides
> 
> I assume you've dropped this idea as well, given the argument that you
> would be dropping prefix symbols but creating a lot of new operators
> to do the same task?

Sure.  It was just an idea.

But who knows, maybe I'll take it up again some day... :-)

-- 
John Porter

Re: RFC 82 (listops in list context)

[Nathan Torkington]

Peter Scott writes:
> >You're right. If RFC 45 is implemented they would however be inconsistent.
> 
> No, || is half-consistent at the moment: the left hand side is forced into 
> scalar context but the result context propagates down the right hand 
> side.  I challenge anyone to come up with a rationalization for this that 
> does not invoke implementation expediency.

As Damien observed, it's by the very definition of a compound assignment:

  X OP= Y
is defined to be
  X = X OP Y

So the only thing tested for truth with ||= is the LHS.  Nothing to do
with implementation.

Nat
(PS, loved the obscenity analogy :-)

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[John Porter]

Jonathan Scott Duff wrote:
> As for $a[$something], if @a had been declared as
> "my @a : assoc;", then perl should stringify $something, otherwise
> numify.  Hmm.. I guess this implies that all hashes need to be
> pre-declared.  :-(

That was kinda along the lines of my suggestion; that the behavior
of an "array" be defined by a bound implementation.  Just like tie,
but without a syntactically supported distinction between arrays 
and hashes.  

Perhaps

sub ARRAY::assoc::FETCH {
my $self = shift;
# I'm an associative array, so stringize the key:
my $index = "$_[0]";
...

-- 
John Porter

Re: RFC 68 (v1) Eliminate the optional C for C

[Peter Scott]

At 10:53 AM 8/16/00 -0400, Stephen P. Potter wrote:
>Lightning flashed, thunder crashed and Perl6 RFC Librarian 
><[EMAIL PROTECTED]>
>  whispered:
>| =head1 TITLE
>|
>| Eliminate the optional C for C etc block declarations
>
>It seems to me it makes more sense to require the sub, but to move them
>into a different namespace (CORE:: or Perl:: or INTERNAL:: or whatever).

My RFC initially started out that way, but reversed its sense after 
feedback before it got published.  There are messages in the archives 
explaining why this should be so (they don't act like normal subroutines).

--
Peter Scott
Pacific Systems Design Technologies