Re: RFC: type inference

[Ken Fox]

Chaim Frenkel wrote:
> The Bytecode representation should be mutable and contain enough iformation
> for type/data flow analysis.

What do you mean by "mutable"? Wouldn't the dataflow analysis for a
given bytecode be immutable? Or do you mean the implementation should
be hackable?

> (Do you think this is possible? If it is a question of speed, would
> making it optional still have it work?)

I was thinking that dataflow information collected during compilation
would be saved in the bytecode format. The interpreter would generally
ignore it, but if the compiler read a bytecode file, it could just use
the information already there and not worry about having to analyze
bytecode.

- Ken

RFC: Rename local() operator

[J. David Blackstone]

  Since no one else has taken this up, I'll start an initial draft.

=head1 TITLE

Rename the C operator

=head1 VERSION

  Maintainer: J. David Blackstone <[EMAIL PROTECTED]>
  Date: 4 Aug 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: not yet assigned

=head1 ABSTRACT

The C operator of Perl5 and earlier does not do what it claims
to and should be renamed.

=head1 DESCRIPTION

New Perl programmers are often confused by the behavior of the
C operator, especially since a great deal of old educational
material exists showing the obsolete practice of using C to
create subroutine arguments and local variables.

C does not provide variables that are local to the enclosing
scope.  Instead it permits what is known as dynamic assignment, the
ability to temporarily assign a value to a variable such that the
variable's original value will be restored when the current scope is
exited.  Relying on this mechanism to provide what most people think
of as local variables (lexical scoping) can sometimes fail.

C is useful in many cases and should be retained but renamed to
reflect its action.

=head1 IMPLEMENTATION

Many replacement names have been proposed for local on the
perl6-language list, and I am sure there are others that were proposed
on p5p in earlier days.  My current favorite name is C to
reflect that a variable will undergo dynamic assignment.  I am certain
that better alternatives exist and that very few people will like that suggestion.

A list of other proposed replacement names includes (but is not
limited to, since I certainly have forgotten some):

C (to reflect the fact that the variable's old value is
pushed onto a stack and popped off when the scope containing the use
of the operator is exited)

C

C

C (not a good idea, in my opinion.  I think that means making
an exact copy of an object.)

C

C

C

C

C

C

C

C

C

C

C

C

C

C

C  (I'm not sure this was a proposal)

None of these completely satisfies me, at the moment, and there does
not appear to be any consensus among the group.

=head1 REFERENCES

The perlfunc manpage

=cut


J. David




-
On the flip side, we need to be Very Careful not to get our egos
irrevocably tied to our proposals.  I have a particular distaste for
the sort of argument that goes, "If I can't have it my way, I'm going
to take all my marbles and go home."
  -- Larry Wall

Re: Stackable ties

[Simon Cozens]

On Fri, Aug 04, 2000 at 12:36:35AM -0500, J. David Blackstone wrote:
>   Perhaps stackable tie-ing and stackable filehandles can both be
> implemented as specific examples of something more general.

Perhaps, but I find it unlikely; stackable filehandles has to happen
at a much lower level. Although a stackable vtable approach to both
ties and filehandles may kinda make sense. Or I may be grabbing words out of
the air and putting them together in random patterns.

-- 
"Everything's working, try again in half an hour."-chorus.net tech
support

Re: RFC: lexical variables made default (revised)

[Ariel Scolnicov]

Nathan Wiger <[EMAIL PROTECTED]> writes:

> > You've taken the wrong approach.  If you're writing a big program then
> > there should be *no* default scope.  Any variable access is an error
> > unless that variable was my()ed or our()ed.  That's basically what
> > 'strict' gives us.
> 
> Fair enough. I've heard several good analyses against my idea, so I'll
> fold. Notice I never claimed it was a *good* idea (hence the lack of
> RFC), but just an idea worth pondering.
> 
> However, I do think there's something to be said for a "quick-and-dirty"
> script out of the box that can distinguish between sub{} vars and other
> vars ala C:
> 
>$user = 'nwiger';
>sub whois {
>($user) = @_;# different var
># ...
>}
>print whois($user);

Uhmm, but now you've killed off *any* chance of whois (or any other
sub) *ever* setting $user -- the first time it tries to do that, it
gets a `different var' and the original remains unchanged.

In particular, one of Perl's greatest advantages over Python -- the
existence of real closures -- softly and silently vanishes away.
Consider this code (Perl/Tk code tends to be similar):

   sub make_summer {
 my $x = 0;
 sub { $x += shift }
  }

Then we can say:
  DB<2> $a = make_summer

  DB<3> $b = make_summer
 
   DB<4> x $a->(2)
  2
  DB<5> x $a->(3)
  5
  DB<6> x $b->(11)
  11
  DB<7> x $b->(-1)
  10

But it is impossible to write make_summer with your suggestions in
effect!  Suddenly, the `$x' in the anonymous sub make_summer is trying 
to create becomes a *new* variable, and all state goes away.

What you're proposing seems to be the abolition of *all* scopes from
Perl, except the innermost-sub scope.  This is worse than Pascal.

But here's an idea: suppose you spelt `my' V-A-R.  Then you could say
Perl is forcing you to declare all your variables (which I claim is
essential in a language with useful scopes).  Of course, it's one
character longer, so I suppose `var' is out of the question...

[...]

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

Re: RFC 16 (v1) Keep default Perl free of constraints su

[Ariel Scolnicov]

I eighth this (or whatever).  Perhaps, though, in addition to adding a 
zillion new command-line switches, Perl could check the name of the
executable?

funperl -pe 's/foo/bar/'

- vs. -

#!/usr/local/bin/bdperl # (-w, `use strict', etc. implied)

Rationale: The one thing a one-liner doesn't need is to add a
`-nobondage-and-discipline' flag, so we can't put any compulsory flags 
*there*.  And `-w' should be the default, as we all know, so we can't
put any compulsory flags on the serious programs, either!

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

new list: perl6-language-strict

[Ask Bjoern Hansen]

subscription information at http://dev.perl.org/

WORKING GROUP:  perl6-language-strict
CHAIR:  J. David Blackstone <[EMAIL PROTECTED]>
Daniel Chetlin <[EMAIL PROTECTED]>
MISSION:Discuss the use of the strict pragma in Perl 6
DEADLINE:   18 August 2000
DESCRIPTION:Redrafted versions of Perl RFCs 6 and 16, sent to the
librarian and hence to the perl6-language list


 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

Re: New Group proposed: subs (was Re: named parameters)

[skud]

On Fri, Aug 04, 2000 at 01:36:02AM -0400, Uri Guttman wrote:
>it looks like typechecking and named params should fork off into a subs
>subgroup. all of you with an itch to write an rfc, here is your chance.

Anyone want to put their hand up as a chair of such a sublist?  Damian's
got the closest related RFC in the works (named params), but I think
he's fairly busy already :)  Though if he wants it, that's OK too.

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

perl6-language-strict sublist

[skud]

Ask, can we please have the following list:

Name:   perl6-language-strict
Chairs: J. David Blackstone <[EMAIL PROTECTED]>
Daniel Chetlin <[EMAIL PROTECTED]>
Charter:Discuss the use of the strict pragma in Perl 6
Timescale:  2 weeks (finish August 18th)
Deliverables:   Redrafted versions of Perl RFCs 6 and 16, sent to the
librarian and hence to the perl6-language list

Thanks in advance,

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: New Group proposed: subs (was Re: named parameters)

[Spider Boardman]

Before anyone writes an RFC on names sub parameters, they should look
at the archives of perl5-porters where it has been discussed a fair amount.

A sample of what appeared to be rough-consensus syntax then:

sub myfoo(Dog $spot : alias, String $str : readonly, $bar);

Note the (more-or-less existing in v5.6.0) optional type declarations and
attribute lists.  In particular, note ":alias" to keep the current p5 $_[0]
aliasing in effect for the one parameter.

That sample pulls together enough of what was discussed that it probably
actually goes a bit beyond what had been rough consensus after all, but
it should serve to help keep from re-hashing *all* of the same old ground
over again.

-- 
Spider Boardman (at home) [EMAIL PROTECTED]
The management (my cats) made me say this.http://www.ultranet.com/~spiderb
PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89  F6 B2 C2 A0 1C AB 1F DC

Re: Language RFC Summary 4th August 2000

[Nathan Wiger]

> 1. put their hands up to write the "up for grabs" RFCs

I'll grab:

   unlink() renamed

I believe the "Renaming line noise" one is already covered in RFC 17.

The localtime() one's still coming, I promise! It'll be good (I hope),
lots of great input.

> I'm *very* close to suggesting a "strict" sublist.  Thoughts?

I'm there.

-Nate

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

[J. David Blackstone]

  Before jumping in on this, keep in mind that Larry Wall has already
stated his intent to just plain _eliminate_ many of these special
variables.  Most of them suffer from the "action-at-a-distance"
problem, meaning you change something somewhere and unexpected changes
occur elsewhere.

  For example, for years old perl4 libraries that accessed arrays had
to do unwieldy arithmetic with $], which was used to control the
number at which array subscripts started.  This was, in some sense, a
great feature since you could select array behavior closest to the
language you came from (0-based for C folks; 1-based for BASIC folks;
or whatever), but once people tried to create libraries it became
apparent that this variable caused code authors to stomp all over each
other, and so it is deprecated.

  As another example, at work we are in love with the $/ variable,
since we often deal in multi-line records delimited with control-Y's. 
However, changing this variable affects _everything_, meaning modules
you want to use might not work unless you only modify $/ with local()
within a subroutine.  The solution is for the concept of $/ to become
a per-filehandle value, as in, encapsulation and object-orientation.

  Larry implied that there might not be much left when all these
variables are cleaned up, but if there are, the approach suggested
earlier of putting them in a more descriptively-named hash might be
all right.


  I suggest that the most productive thing to do right now is go
through the special variables manpage and make a list of how the
*feature* provided by each variable should be re-implemented to avoid
action-at-a-distance problems.  Any volunteers?


J. David

Re: Language RFC Summary 4th August 2000

[Uri Guttman]

> "s" == skud  <[EMAIL PROTECTED]> writes:

  s> 1. put their hands up to write the "up for grabs" RFCs

i am working on one for flow control (event loops, threads, signals). i
should have a draft by this weekend. put it in the list of promised RFCs.

  s> 3. let me know if you think an RFC needs a sublist to discuss it

  s> I'm *very* close to suggesting a "strict" sublist.  Thoughts?

do it. quickly!

  s> Up for grabs:
  s> -
  s> Formats out of core

damian (hog!) grabbed that one (he has a good formatting module). it got
lost in the noise.

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 16 (v1) Keep default Perl free of constraints su

[Jeremy Howard]

Bryan C.Warnock wrote:
> On Thu, 03 Aug 2000, Simon Cozens wrote:
> > On Thu, Aug 03, 2000 at 08:36:01PM -0700, Nathan Wiger wrote:
> > > > Keep default Perl free of constraints such as warnings and strict.
> > >
> > > I second this.
> >
> > I third this. Perl is not, nor do I believe it ever should become, a B&D
> > language by default. "Making easy things easy", remember that?
>
> I'll go a step further and state that Perl shouldn't mutate any of its
> features, at least on the language side.

OK, so maybe I'm taking up an unwinnable cause, but I
un{fourth,third,second,nominate} this. Maybe it's my mod_perl bias
speaking--the CGI scripts people post to the mod_perl list and say 'will
this work under mod_perl?' sometimes make me need a cup of tea and a good
lie down...

When I'm showing someone how to program for the first time, they more often
get things right the first time with 'use strict', and when something goes
wrong, they tend to find what's gone wrong faster. More importantly, when
they haven't had the mentoring to learn to 'use strict', and eventually
manage to cobble together a program that works, attempting to maintain that
down the track is near impossible.

Hey, I'm just as Lazy as the next perl hacker. But how hard is it to write
'no strict' if you want to? As I said in another thread, the People Who Know
What They're Doing know when it's OK to do this, whereas Mere Mortals can
use some hand holding, particularly when they're starting off.

Not sit down before I share with you this...--I've heard a nasty rumour that
there are even some people that think perl is a write-once, read many
language . Well, we all know it doesn't have to be. So, let's
encourage the use of the perl we respect, while still making the perl we
keep in a dark place for when we're feeling naughty available for when we
want it.

Or wouldn't perl without the bad reputation really be perl anymore?...

Language RFC Summary 4th August 2000

[skud]

OK, here's my summary of language RFCs as they currently stand.  As
I said before, this list will always be available from
http://infotrope.net/opensource/software/perl6/

I would appreciate if people could do the following:

1. put their hands up to write the "up for grabs" RFCs
2. work towards getting the "requested/promised" and "draft" RFCs up to
   the point where they can be submitted to the librarian.
3. let me know if you think an RFC needs a sublist to discuss it

I'm *very* close to suggesting a "strict" sublist.  Thoughts?

I've also specifically asked Damian to send me a list of the RFCs he's
planning to write.

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


The Perl 6 Language RFC summary:

Up for grabs:
-
Formats out of core
Renaming linenoise perlvars (into a package?)
unlink() renamed

Requested/promised:
---
an option for strong typing
Michael Fowler <[EMAIL PROTECTED]>
Programer Modifiable Warnings and Error Messages
Brust, Corwin" <[EMAIL PROTECTED]>
List operations eg interleaving
Graham Barr <[EMAIL PROTECTED]>
That Perl should stay Perl
Simon Cozens <[EMAIL PROTECTED]>
Switch statement
Damian Conway <[EMAIL PROTECTED]>
Deprecate localtime() and replace with 
Nathan Wiger <[EMAIL PROTECTED]>
want()
Damian Conway <[EMAIL PROTECTED]>
named parameters 
Damian Conway <[EMAIL PROTECTED]>

Drafts, etc
---
loop control and do
Nathan Torkington <[EMAIL PROTECTED]>
Enhanced pack/unpack
Edwin Wiles <[EMAIL PROTECTED]>
Removing/fixing $[line noise here] variables
Corwin Brust <[EMAIL PROTECTED]>
RFC for recursive regexps
[EMAIL PROTECTED] (Andrew Greene)
Filehandle type-defining punctuation
Peter Scott <[EMAIL PROTECTED]>
Elements of @_ should be read-only.
John Tobey <[EMAIL PROTECTED]>

Submitted to librarian:
---
RFC 2: Request For New Pragma: Implicit
Bryan C. Warnock <[EMAIL PROTECTED]>
RFC 4: Type inference
Steve Fink <[EMAIL PROTECTED]>
RFC 5: Multiline comments
Michael J. Mathews <[EMAIL PROTECTED]>
RFC 6: Lexical variables made default
 J. David Blackstone <[EMAIL PROTECTED]>
RFC 7: Higher resolution time values
Gisle Aas <[EMAIL PROTECTED]>
RFC 8: The AUTOLOAD subroutine should be able to decline a request 
Leon Brocard <[EMAIL PROTECTED]>
RFC 9: Highlander variables
Andy Wardley <[EMAIL PROTECTED]>
RFC 10: Filehandles should use * as a type prefix if typeglobs are eliminated.
Peter Scott <[EMAIL PROTECTED]>
RFC 12: Variable usage warnings
Steve Fink <[EMAIL PROTECTED]> for now
RFC 14: Modify open() and opendir() to return handle objects 
Nathan Wiger <[EMAIL PROTECTED]>
RFC 15: Stronger typing through tie
Michael Fowler <[EMAIL PROTECTED]>
RFC 16: Keep default Perl free of constraints such as warnings and strict.
Daniel Chetlin <[EMAIL PROTECTED]>
RFC 17: Organization and Rationalization of Perl State Variables
Steve Simmons <[EMAIL PROTECTED]>

Re: Stackable ties

[J. David Blackstone]

Peter Scott wrote:
> 
> I'll say up front that I have no good idea as to how to implement this,
> hence the lack of RFC, but I think it's worth getting the ball rolling to
> see if there's enough collective intelligence and inclination to make
> something happen.
> 
> OO inheritance is well defined and the ways of implementing it well
> known.  What if you want to tie a variable to more than one behavior at a
> time?  (I called this multiple inheritance at first, but Damian Conway
> calls it 'stacking' and that's a better term.)  A concrete example would be
> wanting something tied to MLDBM and IxHash at the same time.  The code to
> handle this at present is... interesting.
> 
> Is it at all possible to define interfaces for tie-ing that would
> facilitate stacking?  Do we care?
> --
> Peter Scott
> Pacific Systems Design Technologies


  Perhaps stackable tie-ing and stackable filehandles can both be
implemented as specific examples of something more general.

Re: RFC 16 (v1) Keep default Perl free of constraints su

[J. David Blackstone]

Nathan Wiger wrote:
> 
> > =head1 TITLE
> >
> > Keep default Perl free of constraints such as warnings and strict.
> 
> I second this. If the current definition of "lexical" remains unchanged
> (which I strongly suspect it will),

  Lexical scope has a standard non-Perl definition.  It means you can
tell which variable an identifier refers to simply by looking at the
context, i.e., a lexical variable declared within a function is in
scope only within that function; this is in contrast to dynamic scope,
where an identifier refers to a variable from the current scope or the
scope of the caller.  In other words, with lexical scoping a variable
lookup starts in the current block and proceeds outwards according to
the scope in which the block was declared, while with dynamic scoping
a variable lookup starts in the current scope and proceeds outwards
according to the scope in which the subroutine was called.

  That's not exactly a textbook definition (probably more confusing,
actually), but the end result is that dynamic scope varies at runtime:

$x = 5;

sub one_x {
 $x *= 3;
}

sub two_x {
 local($x) = @_;
 $x += 2;
 one_x();
}

Notice that the $x in one_x refers either to the global $x if called
from the main program, or to the "local" $x in two_x when called from there.

> I think Perl should remain loosely
> typed by default.

  "Loosely typed" is not a synonym for the types of scoping under
discussion.  Loosely typed refers to whether a variable can just be a
scalar (integer, real, object, string, whatever) or whether you have
to declare a type for it, like in C.  It doesn't have anything to do
with lexical scoping.

  (I'm pointing all this out to avoid confusion.  When issues get
confused, we can all wind up on a bandwagon we didn't intend to be on.)

  For the record, I'm very much in favor of keeping Perl loosely
typed, too.

J. David

New Group proposed: subs (was Re: named parameters)

[Uri Guttman]

named parameters seem to be a popular item. i haven't seen much more
than a simple example syntax. how would the named params map onto or
modify @_? would the equivilent perl5 code just be

sub func {
my( $foo, @bar ) = @_ ;
blah ;
}

becomes:

sub func( $foo, @bar ) {
blah ;
}

are we looking for lexical and pass by value params? what if any type
checking (another popular subject) will be applied? what will be the
state of @_ afterwards?

it looks like typechecking and named params should fork off into a subs
subgroup. all of you with an itch to write an rfc, here is your chance.

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: lexical variables made default (revised)

[J. David Blackstone]

Tom Christiansen wrote:
> 
> >  I have retained the title of "Lexical variables made default,"
> >because I still feel that that is the primary purpose of this change,
> >meaning that in future Perl documentation (books, manpages, classes (I
> >hope)) new Perl users will first be presented with variables declared
> >as lexicals with my().
> 
> Illustrative snippets of tiny code should not confuse the reader
> with gratuitous my/our declarations unless these are themselves
> central to what is being illustrated.
> 
> --tom

  I disagree.  In my personal transition from Perl4 to Perl5, I would
not have thought there to be a value in the my() operator if I hadn't
seen it used so pervasively in documentation.  The fact that almost
*every* POD and module reference I read used my() weighed deeply
enough on me to investigate the issue and learn what I was missing.

  I use my() like second nature.


  At some point in time, the perl5 manpage included "the -w switch is
not on by default" as a "bug."  I would put this issue in a similar
class.  The vocabulary has already changed, at least in most of the
documentation I read.  The documentation and books I see that don't
start with my() very early on often don't use it at all, making a
tough re-education necessary for new Perl programmers.


J. David

Re: RFC 16 (v1) Keep default Perl free of constraints su

[Peter Scott]

At 11:04 PM 8/3/00 -0500, J. David Blackstone wrote:
>   As the initial proponent of the opposing RFC, I feel I should make a
>response.  Let the will of the Perl6 community and Larry Wall prevail.
>  I'm sure we'll all be mostly happy, no matter where that takes us.

I will hitch my wagon to your opposing RFC in no uncertain terms.  (I am 
rewriting this message several times to tone down the language here, 
because I feel strongly about it but flames won't help.)  A constant topic 
of discussion is how to make Perl more accessible and friendly to the the 
newcomer, and evidently not enough people or resources are explaining as I 
do to my classes that -w and strict are essential for everything they 
write.  I won't even show them one-liners without them, I'm that adamant 
about promoting the practice.

Make Perl as safe as possible by default; let people turn off the safety as 
they get more experienced.  Not the other way around.

I move for this change to the opposing RFC: Make -w and strict the default 
in everything except -e and -z. (New flag.  Mnemonic: zero 
protection.)  Then living on the wild side will cost one extra character in 
the shebang line and nothing in one-liners.

--
Peter Scott
Pacific Systems Design Technologies

Re: named parameters

[Nathan Wiger]

> Nathan Wiger wrote:
> > Because it has opportunity for bloat, I would suggest it should be in a
> > pragma:
> >
> >use strict 'prototypes';
> 
> Bloat? What bloat? I don't want to *bloat* all my programs by sticking
> a zillion pragmas in just to turn on all the features that makes Perl 6
> different from Perl 5. If you want Perl 5 you know where to find it...

Point taken. But part of the goal was moving a lot of stuff out of CORE
and making Perl faster. New features are great, but we should figure out
whether or not they're truly CORE-worthy. Sticking it in a pragma like
strict helps to solve this issue, but as always TMTOWTDI.

My suggestion assumed that you'd probably be 'use strict'ing anyways if
you wanted strict sub prototypes, and since 'all' would include
'prototypes', you'd get this automatically.

-Nate

BTW, I use CORE to mean "perl" and not "perl.tar.gz".

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

[Peter Scott]

At 12:26 AM 8/4/00 -0400, Ted Ashton wrote:
>Thus it was written in the epistle of Perl6 RFC Librarian,
> >
> > =head2 Disadvantages
> >
> > Literally none have been broached on the various C mailing lists.
>
>Well, I'll take my shot at providing one:  An at least %800 increase in the
>characters used to make up these names.  For quick hacks, this is a pain and
>from my experience with English.pm, I had to spend just as much time looking
>up which word I have to use as I ever did looking up which punctuation.

The punctuation versions do at least have the merit of i18n :-)  I don't 
see any "use French" scripts out there yet...

Aside from that, though, there is the virtue of rationalization in the 
English proposal... plus never having to worry about this:

http://www.segfault.org/story.phtml?mode=2&id=3905b40e-05c0a760

:-)

--
Peter Scott
Pacific Systems Design Technologies

Re: named parameters

[Ken Fox]

Nathan Wiger wrote:
> Because it has opportunity for bloat, I would suggest it should be in a
> pragma:
> 
>use strict 'prototypes';

Bloat? What bloat? I don't want to *bloat* all my programs by sticking
a zillion pragmas in just to turn on all the features that makes Perl 6
different from Perl 5. If you want Perl 5 you know where to find it...

Named parameters would be really nice BTW. I definitely hope they go in.

- Ken

Re: proto-rfc. Elements of @_ should be read-only.

[Ken Fox]

John Tobey wrote:
> The Perl 5 (and older) behavior may preclude some optimizations.

I can't think of any optimizations @_ assignment precludes.
If we don't analyze dataflow to figure out if a sub modifies its
args, then we just assume it will.

Is this just a style issue? Why would you allow it with a
prototyped function? The following is fully prototyped and
still hard to optimize without dataflow:

sub make_setter ($) {
  my $x = \$_[0];
  sub { $$x = $_[0] }
}

{
  my $x = 1;
  my $f = make_setter($x);
  print "x = $x\n";
  &$f(2);
  print "x = $x\n";
}

Or do you mean that only prototypes taking a reference are
allowed to modify their arguments? So make_setter becomes

sub make_setter (\$) {
  my($x) = @_;
  sub { $$x = $_[0] }
}

How would you do vararg subs that have in/out args?

- Ken

Re: Recording what we decided *not* to do, and why

[skud]

On Thu, Aug 03, 2000 at 02:03:13PM -0400, Dan Sugalski wrote:
>
>I'd expect either the chair of the WG, or the person responsible for the 
>broader area the WG lives in, will be ultimately responsible for saying No 
>definitively.

I would expect that the WG head could somehow mark an RFC as unwanted 
if it was pretty much universally despised by the WG, but that any RFC
which presents a good case for the feature should at least be allowed to
live to pass on to Larry for consideration.

As the WG head for what appears to be the busiest WG around, I'd hate to
have to read, understand, and remember every single posted argument for
or against an RFC, to figure out whether it should be accepted or
rejected.

My aims at this point are 

1. to get all the vague speculation that's going on turned into RFCs and 
submitted to the librarian, and

2. to encourage RFC maintainers to redraft a second or higher version 
after discussion on perl6-language or on a sublist

Hopefully when the RFC writing/discussion phase is ended, the RFCs in
the library will reflect the discussion that's occurred.

I agree with the suggestion that anyone who opposes an RFC vehemently
should write a counter-RFC.

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 16 (v1) Keep default Perl free of constraints su

[Bryan C . Warnock]

On Thu, 03 Aug 2000, Simon Cozens wrote:
> On Thu, Aug 03, 2000 at 08:36:01PM -0700, Nathan Wiger wrote:
> > > Keep default Perl free of constraints such as warnings and strict.
> > 
> > I second this.
> 
> I third this. Perl is not, nor do I believe it ever should become, a B&D
> language by default. "Making easy things easy", remember that?

I'll go a step further and state that Perl shouldn't mutate any of its
features, at least on the language side.  Delete deprecated (or heavily
warned against) features?  Sure, if they're that old or that bad.  Add
features?  Sure, that's okay, too.

But change how Perl reacts, when nothing else has changed?   The
previous discussion about localtime had it right - if you want to
change the indexing, or the semantics, create something other than
localtime().

(I even disagree with changing the return value of system(), the
blasphemer I am.)

Change will be inevitable, I'm sure, and the changes that the Perl
community and Larry want I'll support.  I'm probably suggesting
changes myself that will change the look of feel of "classic" Perl,
rather than extending it, though I try hard not to.  It's more than
just backwards compatibility for a myriad scripts that concerns me - I'm
sure we'll come up with a software solution for that.  I'm concerned
about the myriad scriptors that we aren't going to be able to patch.  

To make a bad analogy, it's like a TV show amidst a recast.  Add a new
character out of the blue?  Well, okay, I can buy that.  Kill a
character off?  Umm, I can live with that too, I guess.  But to tell me
that Dick York and Dick Sargent are the same Darrin Stephens?  It's a
little disconcerting to look at.

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

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

[Ted Ashton]

Thus it was written in the epistle of Perl6 RFC Librarian,
> 
> =head2 Disadvantages
> 
> Literally none have been broached on the various C mailing lists.

Well, I'll take my shot at providing one:  An at least %800 increase in the
characters used to make up these names.  For quick hacks, this is a pain and
from my experience with English.pm, I had to spend just as much time looking 
up which word I have to use as I ever did looking up which punctuation.

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
It is easier to square the circle than to get round a mathematician.
-- De Morgan, Augustus (1806-1871)
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: wantarray() should be named wantlist() (was Re: date interface (was Re: perl6 requirements, on bootstrap))

[skud]

On Thu, Aug 03, 2000 at 07:27:18PM -0700, Nathan Wiger wrote:
>> if (want 'hash') { return %hash }  # rather than eq
>
>I like this alot.

Works for me.

K.

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

Re: RFC 2 (v1) Request For New Pragma: Implicit

[Bryan C . Warnock]

On Thu, 03 Aug 2000, Chaim Frenkel wrote:
> What would be the method to _avoid_ emitting something?
> 
> What would be the result of
> 
>   open(Foo, "Bar")# Prints FILEHANDLE=0xdeadbeef
>   $x++;   # Prints 3
> 
> What makes something a 'real' void so that it would print. Vs. not
> having something that would catch the return value?

no implicit;  

(Or 'no implicit print;' after rev 2 comes out.  ;-)

If you really only wanted to turn it off for one line, you could assign
the result to undef.

undef = open(Foo, "Bar");
undef = $x++;

I tend to use this in a variety of places, but not for a big block of
code.  (Mostly because I don't have the scoping issue fixed, so I get
all the spurious dumps from calls I make as well.  I'll have an RFC for
that, too, which will hopefully allow me to impliment this as a module
vice a pragma; I've another RFC coming with a similar, (but more
valid, you'll be glad to know) issue); mumkin tomorrow.)


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

Re: RFC: Request For New Pragma: Implicit

[Bryan C . Warnock]

On Thu, 03 Aug 2000, Chaim Frenkel wrote:
> Its my maintainence hat on.
> 
> Picture some poor shmo, the regular guy is off on his two week vacation,
> in some out the way place without his cell phone. And a production problem,
> or the million dollar client, needs this yesterday.
> 
> And he doesn't notice the use printvoidvalues.
> 
> So the previous occupant was real careful never to use grep in void context,
> and sprinkled (void) all over the perl code.
> 
> But there he will be having strange output show up from nowhere.
> 
> Yes, its fixable, yes, he should know what he is doing, yes, its the
> same issue with all pragmas.
> 
> But this effect bothers me.
> 
> I'll slink off now.
> 
> 

And that two-week vacation will be muuuch longer, I bet.
I don't think even I'd be crazy enough to ab^H^Huse this in production
code, but I guess anything and everything can be dangerous.

(Hence the warning on the Pop-Tart sleeves that tell you to remove the
wrapper before putting them in the toaster.)

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

Re: RFC 16 (v1) Keep default Perl free of constraints su

[J. David Blackstone]

  As the initial proponent of the opposing RFC, I feel I should make a
response.  Let the will of the Perl6 community and Larry Wall prevail.
 I'm sure we'll all be mostly happy, no matter where that takes us.

Daniel Chetlin <[EMAIL PROTECTED]> wrote:
> Perl5 is usable with no hassle as a quick-and-dirty problem-solver by default.
> It is ideal for one-liners, short scripts, and quick hacks that have no need
> for extra protection or error-checking. It is also great for large projects
> by making use of the C and C pragmas.

  Well, there's a really diverse community, here.  Many of us use Perl
almost exclusively as a command-line utility.  In my work, we use Perl
as a primary programming language and expect a lot of things that make
more sense for larger, more permanent programs.

  If your scripts are one-liners that involve the -e switch and we go
with "strict 'vars' in all cases except -e," then you have no need to
worry; the proposed changes will not affect you.  If your scripts are
slightly larger, then part of the Perl5 -> Perl6 translation process
should cover this for you.  We'll keep hashing this out to try to
satisfy everyone, so keep talking.

> In large projects which require the constraining pragmas, it is not an issue
> to take the extra steps and 'use' them.

  How many of those large projects have you participated in?  How many
people do you work with that you have to constantly cajole and prod to
"use strict;"?  It is indeed an issue, in several ways.

  What if the default strictness of vars was a compile-time option to
be decided by the administrator of each site?

> This RFC is particularly concerned with the idea of having C on
> by default. This is an attempt to get around Perl's design of having all
> variables global by default, and lexical only when declared.

  Some would say that Perl wasn't exactly designed aroung all global
variables; it was more of an accident.  In fact, the Camel book 2 all
but says so.


J. David

Re: named parameters

[Tim Jenness]

On Fri, 4 Aug 2000, Damian Conway wrote:

>> > Fair enough. If we were going to do it I would like to see it extend to:
>> > 
>> >  sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) {
>> > 
>> >  }
>> 
>> Is there an RFC for this yet? If not, I think there needs to be. I think
>> this would be really cool. 
> 
> I'll have a proposal out later today or tomorrow.
> But others ought to consider putting one in too.
> 
> Damian
> 

I was going to wait until this RFC came out and comment on it rather than
writing an RFC that might duplicate things in less than 24 hours.

-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj

Re: RFC: lexical variables made default (revised)

[J. David Blackstone]

Nathan Wiger wrote:
> 
> >   I have retained the title of "Lexical variables made default,"
> > because I still feel that that is the primary purpose of this change
> 
> First off, I think this is a great idea in principle. However, I don't
> think it goes nearly far enough in the implementation. I'd like to
> propose something radical.

  You've got what I had in version 1 of the RFC (still available from
the archive, earlier today, or if you want, I'll send it to you).  I
left it in the alternate implementation at the bottom of the RFC.  You
are welcome to submit an expanded alternate section, if you are still
interested after hearing the arguments.  (Or, if you feel like you
have a lot of time, you can take over maintenance of the RFC :).

> However, the code is still littered with what I would argue are
> "useless" my()'s that serve as workarounds for a fundamental flaw in the
> langauge: all variables are global by default.

  Well, yes, the fact that the language was designed around dynamic
variables is a fundamental flaw.  However, what swung me over to my
current view was the fact that not declaring variables (at least for a
script of a certain size and permanence) is also a fatal flaw.  The
proposal you made (and that I made before) still does not force
declarations, resulting in a whole new territory which we have never
explored.  Some have already pointed out a few interesting scoping
questions.  Making strict vars behavior the default gives us all the
benefits of dynamic variables and required declarations with very few
new questions to resolve.  Everything is familiar and follows the path
of evolution Perl programming has been traveling in since the
beginning of Perl5.

> Before you write me back and claim heresy, let me explain what I mean.

  No, we won't shoot you for heresy.  At least, I won't.  I've
committed a couple, already.  (Some seriously and some hypothetically.)

> I argue we should fundamentally shift this thinking in Perl 6. Let's
> truly have "lexical variables made default".

  Well, let's keep talking about it, and I'm sure Larry Wall will give
us a decision that will make everyone happy.

J. David

Re: RFC 16 (v1) Keep default Perl free of constraints su

[Simon Cozens]

On Thu, Aug 03, 2000 at 08:36:01PM -0700, Nathan Wiger wrote:
> > Keep default Perl free of constraints such as warnings and strict.
> 
> I second this.

I third this. Perl is not, nor do I believe it ever should become, a B&D
language by default. "Making easy things easy", remember that?

-- 
Wouldn't it be wonderful if real life supported control-Z?

Re: RFC: lexical variables made default (revised)

[Nathan Wiger]

> Besides, named arguments will solve this (in fewer chars even :-)...
> 
>$user = 'nwiger';
>sub whois ($user) {
># ...
>}
> 
> Damian

Great point. I'll "settle" for that (it's what I'm looking for anyways).
:-)

So will these be "automatically-my()ed"? Or will you have to say:

   sub whois (my $user) {
   # ...
   }

This seems more consistent (but there's that dang my() again!) :-)

-Nate

RFC 17 (v1) Organization and Rationalization of Perl

[Perl6 RFC Librarian]

=head1 TITLE

Organization and Rationalization of Perl State Variables

=head1 VERSION

  Maintainer: Steve Simmons <[EMAIL PROTECTED]>
  Date: 3 Aug 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: 17

=head1 ABSTRACT

Perl currently contains a large number of state and status variables.
Some of these are (or should be deprecated), and the naming methods for
the rest are obscure.  Since we are (potentially) adding, removing, and
changing the functionality of these vars with Perl6, we should seize the
opportunity to rationalize the names and organization of these variables
as well.  These variables need to be made available with mnemonic names,
categorized by module, be capable of introspective use, and proper
preparation made for deprecation.  A partial backwards compatibility
mechanism is suggested.

=head1 DESCRIPTION

Perl allows for the runtime examination and setting of a number of
variables.  These existing C<$> vars are horrible names and
really need some cleanup and syntactic sugar.  Different variables
have different problems, with some having one or more of the
following problems:

=over

=item *

unused (as far as we know)

=item *

useless, but still appear in older programs

=item *

duplicated by other features

=item *

standing in the way of advance because of backwards compatibility

=back

In the pre-rfc discussion of this issue, it was also pointed out
that these variables are hard to deprecate without nagging the crap
out of users running the programs.  The proposed solution was
broadly applicable, and has been spun off into RFC 3.

The use of the C module is an attempt to solve the anti-mnemonic features
of these variables.  A better solution is to do it right in the
first place, with a number of attendant wins:

=over

=item *

no need for Yet Another Module to be loaded

=item *

promotes code readability

=item *

probably promotes core Perl maintainability

=item *

grouping sets of variables together by function gives
the code writer strong hints as to variables that might
affect each other

=item *

should we move formats (or any similar current core functionality)
to a loadable module, this neatly encapsulates all the data with
a single referenced name

=item *

solves problems with C<$> variable proliferation

=item *

potentially promotes introspection - see below.

=back

In addition, many features which are now (re)set by other calls should
set appropriate state variables as well.  Thus a perl script which
contains:

use strict foo;

might set a var C<$PERL_STRICT{foo}>, and so forth (this is probably
a poor example).

Credit where it is due: the idea of putting related values together into
an appropriately tagged hash is shamelessly ripped off from common C usage.

=head2 Advantages and Non-Loses

=head2 Clean Backwards Compatibility

To promote backward compatibility, one could write a C
module which would alias the old names to the new ones.  That Would Be
Wrong, but someone will probably do it - so it may as well be us.
Obviously we cannot provide backwards compatibility for a variable
whose meaning has changed or which has vanished, but most of the
rest can be captured cleanly.

=head2 Promoting Removable Core Modules

It has been strongly proposed that `core perl' be broken down internally
into a number of modules such that one could build smaller or larger
custom perls.  This feature would ease that work, and possibly set a
standard for how well-behaved non-core modules should implement such
things.

=head2 Provide Possible Guidelines To Core-able Modules

The discussion of removable core modules has strongly implied (sometimes
explicitly stated) that sites could take modules which are not currently
in the core and move them there.  Having a standard which those modules
could follow for variable setting and exposure would be a major win.

=head2 Disadvantages

Literally none have been broached on the various C mailing lists.

=head2 Other Possible Features

It has been suggested by Alan Burlison <[EMAIL PROTECTED]>
that this allow for localizable settings.  Thus module A might
turns warnings off when its features are in use, while module
B is unaffected by the setting done by module A.  This is a change
in the functionality of such settings, and has the potential for
broadly changing what happens in perl.  I suggest that this
issue is actually independent of how the variables are named,
and should be taken to another RFC if anyone is interested.


=head1 IMPLEMENTATION

=head2 Internal Implementation

The internal representation of these is largely irrelevant(!).
This RFC prescribes what the I interface looks like;
the implementation team should select whatever mechanism they
prefer for internal use.  It's probably a maintenance win if
the same is used, but the proposers don't intend to dictate
to the developers.

=head2 External Implementation

Variables should be sorted into functional areas which may or
may not have a one-to-one correspondence wi

Re: RFC 16 (v1) Keep default Perl free of constraints su

[Nathan Wiger]

> =head1 TITLE
> 
> Keep default Perl free of constraints such as warnings and strict.

I second this. If the current definition of "lexical" remains unchanged
(which I strongly suspect it will), I think Perl should remain loosely
typed by default. Make people add

   use strict;
   use warnings;

If they want clean code. It makes it more obvious what's going on, too.
Otherwise, "quick-and-dirty" 5-liners become 6-liners with

   no strict;

chewing up an extra line.

-Nate

Re: RFC: lexical variables made default (revised)

[Damian Conway]

   > However, I do think there's something to be said for a "quick-and-dirty"
   > script out of the box that can distinguish between sub{} vars and other
   > vars ala C:
   > 
   >$user = 'nwiger';
   >sub whois {
   >($user) = @_;# different var
   ># ...
   >}
   >print whois($user);

Are two extra chars really so much to ask?...

   $user = 'nwiger';
   sub whois {
   my($user) = @_;# different var
   # ...
   }

Besides, named arguments will solve this (in fewer chars even :-)...

   $user = 'nwiger';
   sub whois ($user) {
   # ...
   }

Damian

Re: RFC: lexical variables made default (revised)

[Nathan Wiger]

> You've taken the wrong approach.  If you're writing a big program then
> there should be *no* default scope.  Any variable access is an error
> unless that variable was my()ed or our()ed.  That's basically what
> 'strict' gives us.

Fair enough. I've heard several good analyses against my idea, so I'll
fold. Notice I never claimed it was a *good* idea (hence the lack of
RFC), but just an idea worth pondering.

However, I do think there's something to be said for a "quick-and-dirty"
script out of the box that can distinguish between sub{} vars and other
vars ala C:

   $user = 'nwiger';
   sub whois {
   ($user) = @_;# different var
   # ...
   }
   print whois($user);

Maybe a

   use scope 'subs';


True, many people need strict. I use it all the time. But the main
reason I use it is to keep my sub{} vars straight (except in modules,
but that's different).

However, I would argue vehemently *against* turning strict on by default
if the current definition of lexical scoping is kept.

-Nate

Re: named parameters

[Damian Conway]

   > > Fair enough. If we were going to do it I would like to see it extend to:
   > > 
   > >  sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) {
   > > 
   > >  }
   > 
   > Is there an RFC for this yet? If not, I think there needs to be. I think
   > this would be really cool. 

I'll have a proposal out later today or tomorrow.
But others ought to consider putting one in too.

Damian

Re: named parameters

[Nathan Wiger]

> Fair enough. If we were going to do it I would like to see it extend to:
> 
>  sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) {
> 
>  }

Is there an RFC for this yet? If not, I think there needs to be. I think
this would be really cool. 

Because it has opportunity for bloat, I would suggest it should be in a
pragma:

   use strict 'prototypes';

-Nate

RFC 6 (v2) Lexical variables made default

[Perl6 RFC Librarian]

=head1 TITLE

Lexical variables made default

=head1 VERSION

 Maintainer: J. David Blackstone <[EMAIL PROTECTED]>
 Date: 1 August 2000
 Version: 2
 Mailing List: [EMAIL PROTECTED]
 Number: 6

=head1 ABSTRACT

Prior to version 5, all implementations of Perl were designed with
only dynamic (global) variables in mind.  Perl5 provided lexical
variables in a backward compatible way, along with a pragma to force
either declaration of variables or import of dynamic variables.  Perl6
should make lexical variables and required variable declarations the default.

=head1 DESCRIPTION

Dynamically-scoped variables can have many effects which are
counterintuitive and undesirable.  In Perl5, lexically-scoped
variables are available with the C operator.  Without C, a
variable is assumed to be dynamic.

Perl5 provides the C pragma, which forces the programmer to do
one of three things: 1) declare a variable to be lexical with C;
2) declare a variable to be dynamic with C; 3) import a dynamic
variable from another namespace with C or otherwise.  This
forced declaration of variables is generally desirable as good
programming practice, although the ability does exist to turn off the
pragma when necessary.

There are very few circumstances in which dynamic variables have a
distinct advantage over lexicals.  Most modules in the standard
library are deliberately written with C to avoid
interfering with other modules or the application programmer's code. 
More recent and enlightened documentation and educational material
teaches the use of lexical variables as preferred.

In Perl6, the concept of C should on by default.  Every
variable should be declared either as lexical with C or dynamic
with C.  New Perl6 programmers should be immediately introduced
to lexical scoping and its benefits.  The ability to disable the
strictness should be retained through C or an
equivalent, for "quick-and-dirty" programs, backward compatibility,
and where otherwise necessary or desired by those who Know What They
Are Doing.

This RFC is not suggesting that any of the other features of the
C pragma be on by default (such as C<'refs'> or C<'subs'>). 
If that is desired, it should be submitted in a separate RFC.

The C operator is misnamed, since it operates on dynamic
(global) variables.  This operator should be removed or renamed, but
this should be the subject of a separate RFC.

=head1 IMPLEMENTATION

I don't know enough about internals to say anything about
implementation from that standpoint.

The following program examples show how declarations would work.

 my $name = "J. David";   # lexical variable
 our($VERSION) = 5.31;# dynamic variable in current package
 $this *= 7;  # illegal; variables must be
  # declared lexical or dynamic
 my($arg1, $arg2) = @_;   # lexical (traditional for a subroutine)
 {
  no strict 'vars';   # or something new
  $quick = 7; # legal in this scope =
  # dynamic variable in current package  
  $quick *= $main::var;
  print "$quick\n";
 }
 $package::count++;   # always legal (I presume?)

=head2 Alternative

Although the implementation above is currently considered to be the
best, an alternative would allow undeclared lexical variables.  In
this approach, C would become C,
requiring declaration of all variables.  Without C,
undeclared variables would be considered to be lexical, or variables
could be declared dynamic with C or some other syntax.

This approach would require more complexity in Perl5 -> Perl6
translation and be a much larger step in a new direction for the
language.  Since the state-of-the-practice of Perl5 programming has
evolved to generally include C, it makes more sense to
simply make that the default than to modify the language any further.

=head1 REFERENCES

The section on "Private Variables via my()" in the perlsub manpage.

The Camel book.

Re: RFC: Filehandle type-defining punctuation

[Ted Ashton]

Thus it was written in the epistle of Nathan Wiger,
> I don't know of an easy solution. I don't think we should touch chomp or
> chop. Maybe someone should write a module that offers alternate versions
> for those that want them?

How often does the return value from chomp or chop get used?  The confusion
would cleared up considerably, I think, if they didn't return a value.

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
One of the endlessly alluring aspects of mathematics is that its thorniest
paradoxes have a way of blooming into beautiful theories.
-- Davis, Philip J.
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC: Filehandle type-defining punctuation

[Nathan Wiger]

> I think I'd prefer that ->pid return 0 only to the child of a fork,
> but undef on a handle that were not the product of a fork, irrespective
> of direction.

Great analysis. I think this sounds like an excellent idea.
 
> Some related issues:
> 
> 1) Did Larry or did he not mention something about dealing with
>indirect object more cleanly?

Maybe clarify this just a little. I don't think I was present for this
discussion.

> 2) What if any reasonable use could be put to a list context
>return from open(), or from ->pid()?

This one's still in pre-pre-pre-alpha, but I could forsee stuff like
"type"-specific data, depending on the class. For an HTTP object, maybe
the HTTP Status, Content-Type, Content-Length? I.e., stuff that would be
in objects for those that don't want objects.

Or maybe something else. I like the possibilities but I haven't
attempted to firm anything up.
 
> 3) Isn't it about time to start saving the string argument to open?
> $fh = open("< /etc/motd");
> print $fh->filename;
> print $fh->mode;
> print $fh->fileno;

Yes, yes, and yes!
 
> 4) This may become interesting for fdopens and dups.
> 
> $fh = open("<=STDIN");
> $fh = open("<&=STDIN");

Yeah, this is going to need a little thought...see my next email...

> or more clearly
> 
> $fh2 = $fh1->dup;

Yeah! That's cool.

-Nate

Re: Removing/fixing $[line noise here] variables

[Steve Simmons]

In writing up the RFC on removing/fixing $[line noise here] variables,
I've decided to leave out the following suggestion:

On Tue, Aug 01, 2000 at 06:47:41PM -0700, Nathan Wiger wrote:
> Alan Burlison wrote:
> > 
> > Steve Simmons wrote:
> > 
> > > I'd prefer that we break these vars out into a set of hashes with
> > > appropriate names:
> > >
> > >   $PERL_CORE{warnings}  vs  $^W
> > >   $PERL_CORE{version}   vs  $^V
> > >   $PERL_FORMATS{name}   vs  $^
> > >   $PERL_FORMATS{lines_left} vs  $-
> > 
> > Hmm - I quite like this.  I'd like it even more if they were package
> > scoped and/or localisable.  My choice of warning level in my package
> > shouldn't affect your choice in your package.
> 
> Now *that's* an advantage I like! Being able to turn on certain warnings
> just for certain packages (rather than just a global all-or-nothing $^W)
> would be really cool.
> 
> As for nitty-gritty, I like the $PERL::CORE::Warnings or
> $perl::core::warnings syntax others have mentioned a little better.

The renaming to use hashes or module-form variables is not intended
to *change* the meanings of the variables, it's an attempt to seize
the opportunity to go to a more rational naming structure.  The
scoped/localizable use of those variables would potentially be a
major change.  Rather than mix them together, I'd prefer to see
scoping/localizing broken out into a separate RFC.  Have at it, folks.  :-)

Re: RFC: lexical variables made default (revised)

[Nathan Torkington]

Nathan Wiger writes:
> I argue we should fundamentally shift this thinking in Perl 6. Let's
> truly have "lexical variables made default".

Ugh.  Baby, bathwater.

If I'm writing a big program, then I want to have to declare all
variables so that Perl can catch errors for me.  That's the big
benefit of strict.  Otherwise you're still going to make typos and
have a bugger of a time tracking them down, because the compiler won't
be helping you do it.

You've taken the wrong approach.  If you're writing a big program then
there should be *no* default scope.  Any variable access is an error
unless that variable was my()ed or our()ed.  That's basically what
'strict' gives us.

The only thing I think we should argue is whether strict should be
default or not.  I could fall both ways.  If there was a command-line
switch to turn it off, then I'd be happy with strict as the default.

Nat

Re: RFC: Filehandle type-defining punctuation

[Nathan Wiger]

> The suggestion was the open() return a filehandle object, so may
> I suggest
> 
>$fh = open("| cat -v | sort | lpr") or die ;
>$pid = $fh->pid;

I like. I'll add it.

Version 2's gonna be *huge*...

-Nate

Re: RFC: Filehandle type-defining punctuation

[Nathan Wiger]

> I'd've written that more like
> 
> $data_axed = chop($var);
> $charcount = chomp($var);
> 
> Or something.  People really do find those two functions confusing.
> Is this something we'd like to address by having versions that don't
> take LVALUES?

I don't know. It is true that this is somewhat confusing. 
 
> But people always think of it as working
> 
> $newstring = chomp $oldstring;
> 
> where $oldstring is untouched, analogous to nearly all the
> other functions, like

Yeah, you're right. Again, it is confusing. However, there are some
benefits to the atomic version(s):

   while() {
   chomp;   # would have to be $_ = chomp
   ($user, $pass) = split ':';
   }

When you use defaults alot, it all seems really well designed. But if
you like to use your own values for $lines, it is more confusing.

I don't know of an easy solution. I don't think we should touch chomp or
chop. Maybe someone should write a module that offers alternate versions
for those that want them?

   use NonAtomicChomp qw(chomp);
   $newstring = chomp $oldstring;

(No, I don't think this is a good idea :-).

-Nate

RFC 16 (v1) Keep default Perl free of constraints su

[Perl6 RFC Librarian]

=head1 TITLE

Keep default Perl free of constraints such as warnings and strict.

=head1 VERSION

  Maintainer: Daniel Chetlin <[EMAIL PROTECTED]>
  Date: 3 Aug 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: 16

=head1 ABSTRACT

Perl5 is usable with no hassle as a quick-and-dirty problem-solver by default.
It is ideal for one-liners, short scripts, and quick hacks that have no need
for extra protection or error-checking. It is also great for large projects
by making use of the C and C pragmas.

Perl6 should not make the one-liners, short scripts and hacks need to jump
through extra hoops to get the "lax" behaviour which is default in Perl5; the
point of using Perl as a quick-and-dirty tool is that you don't have to do
anything extra.

=head1 DESCRIPTION

Perl provides two main ways to ensure "safer", cleaner, more maintainable
code: the C<-w> switch/C pragma and the C pragma. It appears
likely that Perl6 will improve upon, expand, or add to this area. Extra
functionality and power for these pragmas as well as additional pragmas (such
as the C pragma mentioned at TPC) seem to be a good thing, but none
should become default for Perl.

In large projects which require the constraining pragmas, it is not an issue
to take the extra steps and 'use' them. But in quick solutions and one-liners,
it is a major drawback to have to add C or C<-M-strict> for every
quick hack or one-liner that would violate the C pragma. Some have
suggested a shortcut command-line switch that would disable the constraining
pragmas, and others have suggested that one-liners be exempt from the default.
Both of these solutions would make things somewhat better, but it still does
not fit what seems to have been the philosophy of Perl from day 1: be _lax_ by
default, and allow constrictions to be added by hand.

Perl6 is intended to make the easy things easier and the hard things possible,
just like Perl5 only moreso. While making the constraining pragmas the default
might make hard things very slightly more possible, it would also make lots of
easy things harder, and that is something to avoid at all costs.

This RFC is particularly concerned with the idea of having C on
by default. This is an attempt to get around Perl's design of having all
variables global by default, and lexical only when declared. It seems that a
much better solution would be to redefine Perl's default behaviour in the case
of undeclared variables, and cause those to be lexical. Making 
C default appears to be an attempt to fix a hole in the floor
by permanently barring access to the room in which the hole is, rather than
just patching the hole.

=head1 IMPLEMENTATION

There should be no implementation issues.

=head1 REFERENCES

perlrun(1), strict(3)

Re: RFC: lexical variables made default (revised)

[Jeremy Howard]

Nathan Wiger said:
> > What lexical scope should $x be _implicitly_ declared in?  Maybe, just
> > maybe, we need a my $x at the top to tell us it is outside the scope of
the
> > first reference.  Otherwise we get three different lexical variables,
and an
> > undefined value warning at run time.
> ...
> For example, one solution might be that the default lexical scope is
> only delimited on function boundaries:
> ...
This doesn't fix the problem of:
{
  $somevar = 0;
  $someVar++; # oops, wrong case!
}

Forcing 'my' by default allows these errors to be caught.

I'd like to see perl 6 encourage 'clean code' out-of-the-box. Then, People
Who Know What They're Doing can choose to turn on shortcuts as necessary,
but Mere Mortals are encouraged to create mantainable and readable programs.
In this case, 'use strict "vars"' becomes the default behaviour, and a new
'use implicitdeclare "functionlevel"' provides the Lazy behaviour.

Re: wantarray() should be named wantlist() (was Re: date interface (was Re: perl6 requirements, on bootstrap))

[Nathan Wiger]

> if (want 'hash') { return %hash }  # rather than eq

I like this alot.

-Nate

Re: RFC: Modify open() and opendir() to return handles

[Nathan Wiger]

> In fact, you may as well go the whole way and say that all IO is done via
> optimised IO objects (ie include sockets etc). IO::File and friends
> without the overhead. All of the current open functions simply pass these
> objects around.

I'll stick this in there, definitely. This is just what I was shooting
for.

-Nate

Re: RFC: Modify open() and opendir() to return handles

[Nathan Wiger]

> Are you saying they don't look Perlish now?
> 
> And no, all you guys, I'm not trying to shoot down a monadic,
> object-returning open.  Please don't assume that.

As funny as it sounds, yes. Mind you, they're not really too weird. But
compared to how most other functions have turned out working, well, yes.
At least a little.
 
> What I *would* like to shoot down is this nutty assumption that
> these quasi-constructors be named new().  Choose something in the
> proper domain.  Is that a new client or a new server?  Is it
> preconnected or not?  etc.
> 
> Avoid new().  Use something descriptive of what's happening.

Right, I agree. I used new() in the examples as of *existing* code and
modules and how things are done now. You're right, new() is something
from C++ that makes Perl look similar on the surface, but ends up being
self-defeating in a way because it works so differently in reality.

I would say one use of new() that I think is a good one is when you
return a $ref that is simply a clone of the class, with no initialized
values or special features. But I agree that Apache->request gives you a
better idea of what you're getting.

-Nate

Re: RFC: lexical variables made default (revised)

[Nathan Wiger]

> What lexical scope should $x be _implicitly_ declared in?  Maybe, just
> maybe, we need a my $x at the top to tell us it is outside the scope of the
> first reference.  Otherwise we get three different lexical variables, and an
> undefined value warning at run time.

You're right, great point. There's a lot of details implicit in the
email I sent out, which would have to be worked out.

For example, one solution might be that the default lexical scope is
only delimited on function boundaries:

   # all these are in the same scope
   $x = 2;
   if ( $x ) {
  $y = $x;
   } else {
  $y = 5;
   } 
   print "y = $y\n";# 2

   sub compute {
   ($x, $y) = @_;   # but these aren't
   }

Remember, though, my() remains for use, so if you wanted to partition it
off, you could:

   # separate scopes via my()
   $x = 2;
   if ( $x ) {
  my $y = $x;
   } else {
  my $y = 5;
   } 
   print "y = $y\n";# compile error for $y


I don't intend this to be accepted without a knock-down, drag-out fight
(if at all). However, rather than just set pragmas to different values,
my point is that we shoule re-examine what the goal is, and our
assumptions.

-Nate

Re: RFC 2 (v1) Request For New Pragma: Implicit

[Chaim Frenkel]

What would be the method to _avoid_ emitting something?

What would be the result of

open(Foo, "Bar")# Prints FILEHANDLE=0xdeadbeef
$x++;   # Prints 3

What makes something a 'real' void so that it would print. Vs. not
having something that would catch the return value?


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

Re: RFC: lexical variables made default (revised)

[Glenn Linderman]

The problem with lexical variables being made default, in earnest, is
simple, and error-prone:

code;
if ( condition )
{ more code;
   $x = 'did then'';
} else
{ more code;
  $x = 'did else';
}
print $x;

What lexical scope should $x be _implicitly_ declared in?  Maybe, just
maybe, we need a my $x at the top to tell us it is outside the scope of the
first reference.  Otherwise we get three different lexical variables, and an
undefined value warning at run time.

Nathan Wiger wrote:

> >   I have retained the title of "Lexical variables made default,"
> > because I still feel that that is the primary purpose of this change
>
> First off, I think this is a great idea in principle. However, I don't
> think it goes nearly far enough in the implementation. I'd like to
> propose something radical.
>
> Consider code like this, which is not uncommon:
>
>use strict;
>my $var1 = 'some val';
>my $var2 = 'some other val';
>
>sub mysub {
>my($arg1, $arg2) = @_;
>(my $result = $arg1) =~ s/some/every/g;
>return ($result, $arg2);
>}
>
>my @stuff = mysub($var1, $var2);
>
> You get the idea. Dang there's a lot of my()'s in there! The only thing
> I see this RFC changing is the need for the "use strict" statement.
> However, the code is still littered with what I would argue are
> "useless" my()'s that serve as workarounds for a fundamental flaw in the
> langauge: all variables are global by default.
>
> Before you write me back and claim heresy, let me explain what I mean.
> When the usage of Perl was basically only as "shell scripting on
> steroids", all global variables worked fine. However, as Perl 5 became
> more and more powerful and extensible, and classes and OOP became
> mainstays, this no longer worked. So, my() is now used pervasively to
> manually impose much needed compartmentalization of code.
>
> I argue we should fundamentally shift this thinking in Perl 6. Let's
> truly have "lexical variables made default". Let's change the above code
> to:
>
>#use strict;  # unneeded, now implied
>$var1 = 'some val';   # my() now default
>$var2 = 'some other val';
>
>sub mysub {
>($arg1, $arg2) = @_;
>($result = $arg1) =~ s/some/every/g;
>return ($result, $arg2);
>}
>
>@stuff = mysub($var1, $var2);
>
> One basic rule of user interface is that "if something's easy and
> repetitive, have the computer do it". I would argue my() is such a
> beast. I propose these changes:
>
>1. "use strict" as default
>2. my() the default scope of vars
>
> If Perl 6 is going to be successful and hailed (as I'm sure we all hope
> it is), I think it has to offer some clear advantages that make things
> easier. Consider which of these sounds more like a benefit:
>
>1. setting "use strict" on by default, forcing
>   users to formally declare all their variables
>   as my()'s
>
>2. making it so that they don't have to anymore
>
> I would argue that (1) is a burden, but (2) is a benefit. Doing it this
> way doesn't break scripts either - in fact it makes it easier to avoid
> accidental errors, even in "quick-and-dirty" scripting:
>
>sub square {
>($x) = @_;
>$x *= $x;
>}
>$x = 2;
>$ans = square($x);
>print "$x squared is: $ans\n";  # uh-oh
>
> One could argue that "you shouldn't make this mistake", but c'mon. We're
> human, and I'm sure everyone on this list has done this. Let's make Perl
> 6 do the hard work for us. :-) Moreover, we can leave my() just as-is,
> so if someone wants to explicitly use it for clarity they're welcome to.
>
> -Nate
>
> P.S. I know that square() example is trite, but it's the best I could do
> in 30 seconds. :-)

--
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: RFC: Modify open() and opendir() to return handles

[Tim Jenness]

On Thu, 3 Aug 2000, Nathan Wiger wrote:

> > sysopen() should probably be included in the list as well.
> 
> Good point.
> 

In fact, you may as well go the whole way and say that all IO is done via
optimised IO objects (ie include sockets etc). IO::File and friends
without the overhead. All of the current open functions simply pass these
objects around.

-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj

Re: RFC: Modify open() and opendir() to return handles

[Nathan Wiger]

> sysopen() should probably be included in the list as well.

Good point.

-Nate

Re: RFC: lexical variables made default (revised)

[Nathan Wiger]

>   I have retained the title of "Lexical variables made default,"
> because I still feel that that is the primary purpose of this change

First off, I think this is a great idea in principle. However, I don't
think it goes nearly far enough in the implementation. I'd like to
propose something radical.

Consider code like this, which is not uncommon:

   use strict;
   my $var1 = 'some val';
   my $var2 = 'some other val';
  
   sub mysub {
   my($arg1, $arg2) = @_;
   (my $result = $arg1) =~ s/some/every/g;
   return ($result, $arg2);
   }

   my @stuff = mysub($var1, $var2);

You get the idea. Dang there's a lot of my()'s in there! The only thing
I see this RFC changing is the need for the "use strict" statement.
However, the code is still littered with what I would argue are
"useless" my()'s that serve as workarounds for a fundamental flaw in the
langauge: all variables are global by default.

Before you write me back and claim heresy, let me explain what I mean.
When the usage of Perl was basically only as "shell scripting on
steroids", all global variables worked fine. However, as Perl 5 became
more and more powerful and extensible, and classes and OOP became
mainstays, this no longer worked. So, my() is now used pervasively to
manually impose much needed compartmentalization of code.

I argue we should fundamentally shift this thinking in Perl 6. Let's
truly have "lexical variables made default". Let's change the above code
to:

   #use strict;  # unneeded, now implied
   $var1 = 'some val';   # my() now default
   $var2 = 'some other val';
  
   sub mysub {
   ($arg1, $arg2) = @_;
   ($result = $arg1) =~ s/some/every/g;
   return ($result, $arg2);
   }

   @stuff = mysub($var1, $var2);

One basic rule of user interface is that "if something's easy and
repetitive, have the computer do it". I would argue my() is such a
beast. I propose these changes:

   1. "use strict" as default
   2. my() the default scope of vars

If Perl 6 is going to be successful and hailed (as I'm sure we all hope
it is), I think it has to offer some clear advantages that make things
easier. Consider which of these sounds more like a benefit:

   1. setting "use strict" on by default, forcing
  users to formally declare all their variables
  as my()'s

   2. making it so that they don't have to anymore

I would argue that (1) is a burden, but (2) is a benefit. Doing it this
way doesn't break scripts either - in fact it makes it easier to avoid
accidental errors, even in "quick-and-dirty" scripting:

   sub square {
   ($x) = @_;
   $x *= $x;  
   }
   $x = 2;
   $ans = square($x);
   print "$x squared is: $ans\n";  # uh-oh

One could argue that "you shouldn't make this mistake", but c'mon. We're
human, and I'm sure everyone on this list has done this. Let's make Perl
6 do the hard work for us. :-) Moreover, we can leave my() just as-is,
so if someone wants to explicitly use it for clarity they're welcome to.

-Nate

P.S. I know that square() example is trite, but it's the best I could do
in 30 seconds. :-)

Re: Recording what we decided *not* to do, and why

[Tom Christiansen]

>While a function style or quoted form
>comment might seem clever, and even Perlish due to its syntax, it doesn't help
>the author of the code/comments readily distinguish them.  What good are
>comments if you can't find them when you need them?

Sounds like an argument for :10,20s/^/###/ style comments.

--tom

Re: Recording what we decided *not* to do, and why

[Glenn Linderman]

Larry Wall wrote:

> A less obvious strategy is to try to see where various marginal
> features could be subsumed under some more powerful feature.

In general, this is a good^Wgreat concept to avoid multitudinous small features.

> To some extent,

I'm glad you qualified this...

> you see this with the ability to use pod for multiline
> comments.

There's a certain relationship between documentation via pod and documentation
via comments.   If pod and comments could be totally unified, this might be a
good idea.  But they already have separate syntaxes: so unifying them would
require changes to one or both.  Without total unification and uniform syntax
for both, I think it better to leave comments and pod as separate features:
documentation for publication is often at a different level, and better not
mixed with internals documentation anyway: the different syntaxes for code, pod,
and comments helps the author keep them visually separate.

> For embedded comments, we might rather see some kind of
> macro facility that could turn qc// or any other quoted form into a
> list of zero or more tokens.

There's a number of us that have been arguing about that topic.  We wish the
-mlc list would become responsive.  While a function style or quoted form
comment might seem clever, and even Perlish due to its syntax, it doesn't help
the author of the code/comments readily distinguish them.  What good are
comments if you can't find them when you need them?

> Larry

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


___
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html

Re: RFC: Modify open() and opendir() to return handles

[Steve Simmons]

On Thu, Aug 03, 2000 at 08:54:35PM +0200, Johan Vromans wrote:
> Peter Scott <[EMAIL PROTECTED]> writes:

> > If we get a good-looking exception throwing/catching mechanism and
> > syntax, this may not matter.

>try {
>   java
>}
>catch (Exception e) {
>   think again
>}

I like this.  It's perlish in that it builds off of a well-defined and
proven mechanism, and it even *looks* perlish.

Re: RFC: Request For New Pragma: Implicit

[Chaim Frenkel]

Its my maintainence hat on.

Picture some poor shmo, the regular guy is off on his two week vacation,
in some out the way place without his cell phone. And a production problem,
or the million dollar client, needs this yesterday.

And he doesn't notice the use printvoidvalues.

So the previous occupant was real careful never to use grep in void context,
and sprinkled (void) all over the perl code.

But there he will be having strange output show up from nowhere.

Yes, its fixable, yes, he should know what he is doing, yes, its the
same issue with all pragmas.

But this effect bothers me.

I'll slink off now.



> "BCW" == Bryan C Warnock <[EMAIL PROTECTED]> writes:

BCW> On Wed, 02 Aug 2000, Chaim Frenkel wrote:
>> (Walks away shaking head, in wonder and amazement.)

BCW> Hey, it took me two weeks to hack the parser into doing this
BCW> at work.  (Well, to some extent.  It isn't module friendly.)

BCW> But you may as well kill-file me now, 'cause there are sure to be more.
BCW> My Perl didn't come with instructions, just a little tag that said,
BCW> "Use me."  





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

Re: Multi-line comment sub list?

[Chaim Frenkel]

This should be automated, with the Chair (or her henchman) triggering
the creation, initial members, and announcment.

(What about a timebomb, that needs to be reset regularly, sort of to
encourage coming to a completion)



> "s" == skud  <[EMAIL PROTECTED]> writes:

s> Yes indeed:
s> List name:   perl6-language-mlc
s> Chair:   Michael J. Mathews <[EMAIL PROTECTED]>
s> Charter: Discuss and redraft the multiline comments RFC
s> Timescale:   1 week (end Thursday 10th August)
s> Deliverables:Michael to post the redrafted RFC back to perl6-language

s> Ask, can you please set this up?

s> When this is set up, can all multiline comments discussion please go
s> there instead of here :)

s> Thanks,


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

Re: date interface (was Re: perl6 requirements, on bootstrap)

[Chaim Frenkel]

Versions, dear boy. Versions. Don't forget versions.

We will need them.

(This really belongs on -internals. Reply-to: adjusted)

And while were here, does anyone understand kpathsea? Would it be a
win. I think it would.



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

DS> lexer saw a name on the list it'd automagically mark that shared library 
DS> for loading.

DS> So if the list had:

DS> localtime|$|@|op|time.so|localtime

DS> perl would know that the localtime function took a scalar, returned a list, 
DS> is called like an opcode, and lives in time.so with a name of localtime. If 
DS> (and only if) you used localtime, perl would load in time.so for you. In 
DS> the optree (or bytecode stream or whatever) perl would have the 
DS> I_cant_believe_its_not_an_opcode opcode with a pointer to the function we 
DS> loaded in from time.so.

DS> This way it looks like an opcode, talks like an opcode, looks like an 
DS> opcode, but isn't an opcode taking up valuable space. (Not to mention 
DS> making the optimizer more complex--the fewer the opcodes the easier its 
DS> likely to be)

DS> I've got an RFC started on this.

DS> The list would presumably be added to occasionally when a module is installed

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

Re: RFC: type inference

[Chaim Frenkel]

> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:

KF> That's the beauty of the entire existing Perl code base -- every
KF> program presents its complete source code to the interpreter. Once
KF> bytecode and native function calls arrive it will be a lot harder
KF> to get dataflow analysis implemented. (Especially since Perl 6 is
KF> supposed to have a very stable extension API.)

Calling Mr. Dan.

The Bytecode representation should be mutable and contain enough iformation
for type/data flow analysis.

(Do you think this is possible? If it is a question of speed, would
making it optional still have it work?)


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

Re: named parameters

[Damian Conway]

I have an RFC coming on this.

(I know, I know, I keep promising, but none appear.
 I'll unload the first 10 or so later today, the gods willing)

Damian

Re: proto-rfc. Elements of @_ should be read-only.

[John Tobey]

Peter Scott <[EMAIL PROTECTED]> wrote:
> So user subroutines should not be able to reproduce the semantics, of, 
> e.g., sysread()?  I was hoping for more equality in this respect (user subs 
> being able to do anything builtins can) rather than less.

Let me clarify.  Only unprototyped subs are affected.  my_sysread()
just needs a prototype, and it can work just like sysread().

-- 
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\   ///
]]] With enough bugs, all eyes are shallow.   [[[
///   \\\

Re: RFC: lexical variables made default (revised)

[Tom Christiansen]

>  I have retained the title of "Lexical variables made default,"
>because I still feel that that is the primary purpose of this change,
>meaning that in future Perl documentation (books, manpages, classes (I
>hope)) new Perl users will first be presented with variables declared
>as lexicals with my().

Illustrative snippets of tiny code should not confuse the reader
with gratuitous my/our declarations unless these are themselves
central to what is being illustrated.

--tom

Re: named parameters

[Tim Jenness]

On Fri, 4 Aug 2000, Simon Cozens wrote:

> On Thu, Aug 03, 2000 at 09:39:30AM -1000, Tim Jenness wrote:
> > Reading through the docs for perl prototypes I see that there is a
> > reference to "named parameters" being a possibility in future versions of
> > perl.
> > 
> > Does anyone have a more concrete example of what was intended there? 
> 
> sub marine ($sailor, $captain) {
> $captain->say("One ping only");
> }
> 

Fair enough. If we were going to do it I would like to see it extend to:

 sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) {

 }

or somesuch, so that we can automatically dereference array and hash refs
and make sure that argument 4, for example, is a IO::Handle object, @y has
to have N elements etc [my syntax is not meant to be all that well thought
out just at the moment.]

I find that I spend quite a lot of code checking that arguments are in the
correct class, that I have array refs and things so anything that would
save typing is a good thing IMHO.

Of course, type checking can be done as 

  use Type::Checking qw/ checkargs /;

  sub test {
checkargs( "$x, @y:[N], %z", @_);
or die "Incorrect args";

  }

[where Type::Checking is a mythical module] without extending the language 
at all...


-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj

Re: proto-rfc. Elements of @_ should be read-only.

[Peter Scott]

At 08:18 PM 8/3/00 -0400, John Tobey wrote:
>Unprototyped subs should not be allowed to modify their callers' data
>simply by assigning to elements of the arg array.  This form of
>passing by reference is obsolete now that Perl has hard references and
>C<\$> in prototypes.  The feature is confusing, since it means that
>the recommended convention for naming parameters (by assigning C<@_>
>to a C list) alters semantics.

So user subroutines should not be able to reproduce the semantics, of, 
e.g., sysread()?  I was hoping for more equality in this respect (user subs 
being able to do anything builtins can) rather than less.

--
Peter Scott
Pacific Systems Design Technologies

Re: switch/case (c) vs. case (pascal)

[Tom Christiansen]

>if you want to have something like switch/case it is a good idea to use
>the 'case' of pascal, because it is easy to use and it is really clear.
>the 'switch/case' of c is (in my opinion) is not good for a language
>like perl which claims to be practical.

Please, please, *PLEASE* read through Damian's fine paper on this 
entire matter before rendering judgment.

--tom

proto-rfc. Elements of @_ should be read-only.

[John Tobey]

This is not quite finished yet, as I read the rest of the C-- garbage
collection paper.

-John

=head1 TITLE

Elements of @_ should be read-only

=head1 VERSION

  Maintainer: John Tobey <[EMAIL PROTECTED]>
  Date: 3 Aug 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: 

=head1 ABSTRACT

Unprototyped subs should not be allowed to modify their callers' data
simply by assigning to elements of the arg array.  This form of
passing by reference is obsolete now that Perl has hard references and
C<\$> in prototypes.  The feature is confusing, since it means that
the recommended convention for naming parameters (by assigning C<@_>
to a C list) alters semantics.

The Perl 5 (and older) behavior may preclude some optimizations.

=head1 DESCRIPTION

Bla bla bla, optimization.  Bla, bla, native code, pass by value.  C--
is cool.

=head1 IMPLEMENTATION

A fascist implementation would emit a compile-time error any time
C<@_> or one of its elements were assigned to, taken a refernce to,
etc.  A friendlier version would automatically copy the arg value to a
new temporary.

This change would mean a moderate Perl 5 compatibility breakage.  The
Perl-5-to-Perl-6 converter could insert whatever trick is used to
obtain the Perl 5 behavior (perhaps a C<(@)> prototype) when it
detects argument modification.

If the optimization suggested above is implemented, it would cause
another wave of breakage, as arg-modifying subs would have to be
defined or prototyped above the places where they are called.  A
pragma to restore the old behavior would be the safest guarantor of
compatibility.

=head1 REFERENCES

L, The C-- homepage - http://www.cminusminus.org/

Re: multiline comments

[Tom Christiansen]

>Tom Christiansen wrote:
>> #if 0
>> ...
>> #endif

>Ahem, has somebody already mentioned -P (perldoc perlrun)?
>If you want 'em, you already got 'em!

I'm in the choir, preacher!  IWTFM. :-)/3

--tom

Re: RFC: Modify open() and opendir() to return handles

[Tom Christiansen]

>If we were to agree to make the basic syntax of open() something like:

>   $object = open [$filename], [$class];

>There's a lot of cool stuff we could do. In the simplest "mostly looks
>like Perl5" cases, open() can work like shown above. In fact, I'd be
>plenty happy with just this, since it makes open() and opendir() look a
>lot more Perlish to me.

Are you saying they don't look Perlish now?

And no, all you guys, I'm not trying to shoot down a monadic,
object-returning open.  Please don't assume that.  

>However, if we extended this some more, there's some interesting
>possibilities. Currently, if you want to open an FTP connection, you
>have to do something like this:

>   use Net::FTP;
>   my $ftp = new Net::FTP ("ftp.perl.com");
>   $ftp->login("user", "pass");

>And so on. Same for HTTP connections, etc. However, you could make
>open() extensible, almost like tie() or new()[1] in that it can bind
>objects to classes. So, to open a new FTP connection, maybe Perl6 could
>let you do this:

>   $ftp = open "ftp.perl.com/pub", Net::FTP;

>[1] I *know* new() is "just a function", but you know what I mean. :-)


What I *would* like to shoot down is this nutty assumption that
these quasi-constructors be named new().  Choose something in the
proper domain.  Is that a new client or a new server?  Is it
preconnected or not?  etc.

Avoid new().  Use something descriptive of what's happening.

--tom

Re: RFC: lexical variables made default (revised)

[J. David Blackstone]

John Tobey wrote:
> 
> "J. David Blackstone" <[EMAIL PROTECTED]> wrote:
> >   Thanks for the feedback, everyone.  I now believe that what we
> > really want is what so many have suggested, i.e., making strict 'vars'
> > the default (in essence, at least).
> 
> Sorry if this was mentioned already.  If this change is adopted, I
> would make it conditional on C<$0 ne "-e"> so as not to disturb my
> one-liners. (which are about 99% of the Perl programs I write...)
> 
> --
> John Tobey, late nite hacker <[EMAIL PROTECTED]>


  I agree.

  Some might prefer a single-character switch to disable or enable
strictness for one-liners.  The name and meaning of the switch would
depend on whether we decide strict 'vars' should be on or off for
one-liners by default (still up for grabs, though I prefer off). 
Anyone who actually uses strict 'vars' for a one-liner (I think I did,
once) might appreciate the ability to

$ perl -_ -e '...'

instead of the longer

$ perl -Mstrict -e '...'

where -_ (replace the underscore with any letter that might be left)
is a hypothetical switch to turn on strict vars.


  Actually, the sheer act of typing the above has made me think that's
sort of ridiculous.  strict just shouldn't be the case in one-liners, period.

  It's hard to run your code through a Perl5 -> Perl6 translator when
your code isn't saved in a file, but only in your head (and fingers :).



J. David

Stackable ties

[Peter Scott]

I'll say up front that I have no good idea as to how to implement this, 
hence the lack of RFC, but I think it's worth getting the ball rolling to 
see if there's enough collective intelligence and inclination to make 
something happen.

OO inheritance is well defined and the ways of implementing it well 
known.  What if you want to tie a variable to more than one behavior at a 
time?  (I called this multiple inheritance at first, but Damian Conway 
calls it 'stacking' and that's a better term.)  A concrete example would be 
wanting something tied to MLDBM and IxHash at the same time.  The code to 
handle this at present is... interesting.

Is it at all possible to define interfaces for tie-ing that would 
facilitate stacking?  Do we care?
--
Peter Scott
Pacific Systems Design Technologies

Re: RFC: lexical variables made default

[Tad McClellan]

On Fri, Aug 04, 2000 at 05:27:59AM +1000, Damian Conway wrote:
>> > Perl's similarity to English is one of the things that makes it Fun.
>> 
>> OTOH, being fun (which I admit it is) is one of the reasons many
>> people don't want to think Perl is a serious language.
>> 
>> Not saying we should eliminate all the fun; but keeping something
>> on the merit of it's being fun is probably at odds with the goal
>> of make Perl more widely acceptable.
> 
> Someone want to RFC a "fun" pragma:
> 
>#! /usr/local/bin/perl -w
> 
>no fun;# for you!


Yes. I will write this up RSN (by early next week).


> Actually, Tim Maher and I were discussing something not entirely dissimilar
> for the purpose of teaching:
> 
>   use Training::Wheels;
> or:
>   no Weird::Stuff;


This idea is what I asked Larry about from the open mike at the
TPC Town Meeting. It was something like:

Me: 

Will you consider a switch/pragma to remove short-cuts and
DWIMery in Perl 6, so that when asked:

"Is Perl a good first programming language?"

We can say "with the -nodwim switch it is."

Larry:

Yes.


So I better write it up so he doesn't forget to consider it   :-)


> Hm. I feel a paper coming on...

N!

You don't have time for no stinkin' papers!

(unless you put it in the "*after* Christmas" bin)


We're expecting an (yeah, right) RFC from you.

I want RFC printouts in the smallest room in my house
for when I, errr... need them...



-- 
Tad McClellan  SGML consulting
[EMAIL PROTECTED] Perl programming
Fort Worth, Texas

Re: RFC: lexical variables made default (revised)

[John Tobey]

"J. David Blackstone" <[EMAIL PROTECTED]> wrote:
>   Thanks for the feedback, everyone.  I now believe that what we
> really want is what so many have suggested, i.e., making strict 'vars'
> the default (in essence, at least).

Sorry if this was mentioned already.  If this change is adopted, I
would make it conditional on C<$0 ne "-e"> so as not to disturb my
one-liners. (which are about 99% of the Perl programs I write...)

-- 
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\   ///
]]] With enough bugs, all eyes are shallow.   [[[
///   \\\

Re: switch/case (c) vs. case (pascal)

[Tom Hughes]

In message <[EMAIL PROTECTED]>
  [EMAIL PROTECTED] (Stefan Moch) wrote:

> if you want to have something like switch/case it is a good idea to use
> the 'case' of pascal, because it is easy to use and it is really clear.
> the 'switch/case' of c is (in my opinion) is not good for a language
> like perl which claims to be practical.

Is there any difference, besides the default fall through of
the C switch statement?

Just as important a point to my mind is whether to require case
labels to be constants or whether to allow expressions which is
much more flexible but which isn't what C or pascal do.

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
...Are we THERE yet?  My MIND is a SUBMARINE!!

Re: Removing/fixing $[line noise here] variables

[J. David Blackstone]

Larry Wall wrote:
> Some of these concepts are not going to be global concepts in Perl 6.
> The per-filehandle variables will be attached to filehandle objects.

  THANK YOU!!  (Breathes a sigh of relief.)

  I still remember the fateful day when I discovered $", which made my
CGI script output prettier but broke my work with DBD::CSV.  Suddenly,
I understood what all that documentation meant when it said,
"action-at-a-distance," and a whole host of deprecated features exited
my "Why are they taking that away?  Are they just making life
difficult?" list.

  I thought for a long time that the IO::* modules were a solution to
this, but haven't experimented with them until recently.  I still
wonder why the methods in IO::* classes don't just start out with

 local($/) = $self->input_record_separator;

and so on, but I presume there's a good reason (or at least, an
insurmountable problem I don't see), and the prospect of Perl6 makes
everything better, now, anyway.

  J. David Blackstone

Re: named parameters

[Simon Cozens]

On Thu, Aug 03, 2000 at 09:39:30AM -1000, Tim Jenness wrote:
> Reading through the docs for perl prototypes I see that there is a
> reference to "named parameters" being a possibility in future versions of
> perl.
> 
> Does anyone have a more concrete example of what was intended there? 

sub marine ($sailor, $captain) {
$captain->say("One ping only");
}

-- 
Pray to God, but keep rowing to shore.
 -- Russian Proverb

Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)

[Nathan Wiger]

> Several people have requested strong typing as a feature, but have been shot
> down with reasons such as "it's un-Perl-like", with an added "it'll slow
> everything down for those who don't want it".

Definitely.

> Unfortunately, accessing and manipulating tied variables is incredibly slow,
> so improving their speed is a large part of making this proposal feasible.

I think a lot of effort should be put into improving tie(). There are
tons of advantages to tie, and it could be used in incredibly flexible
ways in Perl6 as I see it. While this is mainly an internals issue, I
think it should be pretty high on the priority list.

-Nate

RFC: lexical variables made default (revised)

[J. David Blackstone]

  Thanks for the feedback, everyone.  I now believe that what we
really want is what so many have suggested, i.e., making strict 'vars'
the default (in essence, at least).

  I have retained the title of "Lexical variables made default,"
because I still feel that that is the primary purpose of this change,
meaning that in future Perl documentation (books, manpages, classes (I
hope)) new Perl users will first be presented with variables declared
as lexicals with my().

  I want to state up front that I'm not saying anything about the
other uses of use strict.  I think some people would probably want
those on by default, but I consider each piece of strictness to be a
separate issue.  I can also keep up with only so many discussions and
RFCs at once. :)

=head1 TITLE

Lexical variables made default

=head1 VERSION

 Maintainer: J. David Blackstone <[EMAIL PROTECTED]>
 Date: 1 August 2000
 Version: 2
 Mailing List: perl6-language
 Number: 6

=head1 ABSTRACT

Prior to version 5, all implementations of Perl were designed with
only dynamic (global) variables in mind.  Perl5 provided lexical
variables in a backward compatible way, along with a pragma to force
either declaration of variables or import of dynamic variables.  Perl6
should make lexical variables and required variable declarations the default.

=head1 DESCRIPTION

Dynamically-scoped variables can have many effects which are
counterintuitive and undesirable.  In Perl5, lexically-scoped
variables are available with the C operator.  Without C, a
variable is assumed to be dynamic.

Perl5 provides the C pragma, which forces the programmer to do
one of three things: 1) declare a variable to be lexical with C;
2) declare a variable to be dynamic with C; 3) import a dynamic
variable from another namespace with C or otherwise.  This
forced declaration of variables is generally desirable as good
programming practice, although the ability does exist to turn off the
pragma when necessary.

There are very few circumstances in which dynamic variables have a
distinct advantage over lexicals.  Most modules in the standard
library are deliberately written with C to avoid
interfering with other modules or the application programmer's code. 
More recent and enlightened documentation and educational material
teaches the use of lexical variables as preferred.

In Perl6, the concept of C should on by default.  Every
variable should be declared either as lexical with C or dynamic
with C.  New Perl6 programmers should be immediately introduced
to lexical scoping and its benefits.  The ability to disable the
strictness should be retained through C or an
equivalent, for "quick-and-dirty" programs, backward compatibility,
and where otherwise necessary or desired by those who Know What They
Are Doing.

This RFC is not suggesting that any of the other features of the
C pragma be on by default (such as C<'refs'> or C<'subs'>). 
If that is desired, it should be submitted in a separate RFC.

The C operator is misnamed, since it operates on dynamic
(global) variables.  This operator should be removed or renamed, but
this should be the subject of a separate RFC.

=head1 IMPLEMENTATION

I don't know enough about internals to say anything about
implementation from that standpoint.

The following program examples show how declarations would work.

 my $name = "J. David";   # lexical variable
 our($VERSION) = 5.31;# dynamic variable in current package
 $this *= 7;  # illegal; variables must be
  # declared lexical or dynamic
 my($arg1, $arg2) = @_;   # lexical (traditional for a subroutine)
 {
  no strict 'vars';   # or something new
  $quick = 7; # legal in this scope =
  # dynamic variable in current package  
  $quick *= $main::var;
  print "$quick\n";
 }
 $package::count++;   # always legal (I presume?)

=head2 Alternative

Although the implementation above is currently considered to be the
best, an alternative would allow undeclared lexical variables.  In
this approach, C would become C,
requiring declaration of all variables.  Without C,
undeclared variables would be considered to be lexical, or variables
could be declared dynamic with C or some other syntax.

This approach would require more complexity in Perl5 -> Perl6
translation and be a much larger step in a new direction for the
language.  Since the state-of-the-practice of Perl5 programming has
evolved to generally include C, it makes more sense to
simply make that the default than to modify the language any further.

=head1 REFERENCES

The section on "Private Variables via my()" in the perlsub manpage.

The Camel book.

=cut

  J. David Blackstone


-
In fact, I'd go as far as to say that it's imperative that you
overstuff your brain to the point where you no longer feel tempted to
overstuff the language.  Hypotheticality is your friend.
 

RE: RFC: lexical variables made default

[Brust, Corwin]

--snip--
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]

>[EMAIL PROTECTED] wrote:
>> Perl's similarity to English is one of the things that makes it Fun.

>OTOH, being fun (which I admit it is) is one of the reasons many
>people don't want to think Perl is a serious language.

So what?

--sinp--

What he said.

-Corwin

Re: RFC 15 (v1) Stronger typing through tie.

[John Porter]

Michael Fowler <[EMAIL PROTECTED]>:
> 
> use typing;  # place your fingers on the home row..
> 
> my integer $quux = 4;

I believe that would have to be 

integer my $quux = 4;

at least in perl5...

-- 
John Porter

RFC 15 (v1) Stronger typing through tie.

[Perl6 RFC Librarian]

=head1 TITLE

Stronger typing through tie.



=head1 VERSION

Maintainer: Michael Fowler <[EMAIL PROTECTED]>
Date: 02 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 15


=head1 ABSTRACT

Strong typing of variables can be implemented through the already-existent
tie mechanism.



=head1 DESCRIPTION

Several people have requested strong typing as a feature, but have been shot
down with reasons such as "it's un-Perl-like", with an added "it'll slow
everything down for those who don't want it".  However, I think it can be
done in a fairly simple way through the use of the tie mechanism, which
makes the feature optional to those who want an even stricter environment.

Through a pragma or core module one gets various subroutines that produce
tied variables that verify they're only set to allowable values. 
Unfortunately, accessing and manipulating tied variables is incredibly slow,
so improving their speed is a large part of making this proposal feasible.



=head1 IMPLEMENTATION

I envision syntax like this:

use typing;  # place your fingers on the home row..

integer $foo, $bar, $blah;
string($baz, $qux) = ("bazarific", "quxaroni");

# and even..

my integer $quux = 4;

integer and string are subroutines automatically exported by typing.pm; they
simply tie their arguments to an appropriate class.

The last is a little questionable; it would require some magic on perl's
part to invoke some method or constructor for initializing C<$quux>.  A
suggested alternative is something like C, but it
requires some manipulation on perl's part as well.


There is a drawback: exceptions raised ("That's not an integer!" *croak*)
are made at run-time, rather than compile-time (as would be more useful). 
As a result you have to test all code paths if you are to use this as any
sort of internal sanity checking; I assume most everyone does this, but it
would be useful for it to be a compile-time check, so that perl -c would
catch all of your errors. This could possibly be accomplished by allowing
arguments to the pragma or variable initialization.

use typing qw(very-strict);
my integer $foo : very-strict = 4;

Which would enforce that you can only assign integer constants to $foo
(which are seen at compile-time), or other similarly declared integers (or
possibly promoted floats, chars, etc. if you wanted to get C-like).  This,
then, could allow you to do checking at compile-time.

Which then raises a few more problems (whew): how do you coax user input
(which is an SV) into a value $foo can accept with very-strict on?; what
happens when an external function (say, from a module) is being very-strict,
but is passed arguments from code that doesn't do type checking?



=head1 REFERENCES

perldoc perltie

Re: Reduce [was: Re: Random items (old p5p issues)]

[Jeremy Howard]

Martyn J. Pearce wrote:
> <...> what I would like to discuss adding to the language is
>
> 1) a means to signal an early exit to the iterator,
> 2) a means to tell we're at the end of a list without having to
> evaluate the list length as we start
> 3) a much more lightweight, and language built-in, mechanism for
> currying these functions.

Would the changes you're discussing support:
- Infinite lists
- Reducing to an array rather than a scalar?

The first of these is pretty obvious--sometimes you want to define a mapping
without restricting the domain.

The second is about writing something like:
  @a = sumover(@b[$index::j]
to get column sums. $index::j is in this case an iterator defined as
operating over the second index of an array. Of course you can always do
this with a loop, but to me the whole point of adding iterators, matrix ops,
and reduce/fold is that you can write your code the way a mathematician
writes a function. Having to put explicit loops in is a bit messy.

I'm sorry if this is obvious. I can see the pieces of perl that are missing
in terms of what I'd like to do with it, but I can't yet see how specific
proposed changes to the language fit together to make these things possible.

BTW, I'd like to see a more lightweight currying mechanism too. The
challenge is to find a 'perlish' but not heavyweight approach...

Re: wantarray() should be named wantlist() (was Re: date interface (was Re: perl6 requirements, on bootstrap))

[Tad McClellan]

On Fri, Aug 04, 2000 at 05:24:43AM +1000, Damian Conway wrote:
> Tad pointed out:

>> I will RFCify this within the next few days (unless someone
>> can shoot it down right now).
> 
> http://www.csse.monash.edu.au/~damian/Perl/want.proposal


I withdraw my threat of RFCification, and bow to you, Oh Prolific One.


-- 
Tad McClellan  SGML consulting
[EMAIL PROTECTED] Perl programming
Fort Worth, Texas

Re: Where must you 'no strict'?

[Michael Fowler]

On Thu, Aug 03, 2000 at 05:57:45PM +0100, Hildo Biersma wrote:
>'AMQ9506' => [ "Channel '($channel_patt)' has ended because",
>   "Channel" ],
> 
>'AMQ9508' => [ "The connection attempt to queue manager '(.*?)'
> failed with reason code ($reason_patt)\\.",
>   "QMgr", "Reason" ],
> 
>'AMQ9509' => [ "The attempt to open either the queue or queue manager
> object '(.*?)' on queue manager '($qmgr_patt)' failed with reason code
> ($reason_patt)\\.",
>   "Object", "QMgr", "Reason" ],
> 
>'AMQ9510' => [ "The attempt to get messages from queue
> '($qname_patt)' on queue manager '($qmgr_patt)' failed with reason code
> ($reason_patt)\\.",
>   "QName", "QMgr", "Reason" ],
> 
> Now, I run every message by the description, and then I need to store
> $1, $2, $3, etc into the "appropriate" object field.  If you want to do
> this without hard-coding for $1, $2, $3, $4 etc and without doing an
> eval, you need symbolic references - the part of the foreach() loop that
> does this contains "no strict 'refs'".
> 
> If you want to do this in a B&D fashion, you will end up with
> $match_result->ExtractPattern(1) for $1, which is pretty nasty.

It doesn't have to be as "nasty" as a method call, simply store your results
in an array:

(@matches) = ($string =~ /regex/)

Now, reference the elements of @matches as you would do your symbolic
lookups.  strict refs again, yay!


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

Re: Recording what we decided *not* to do, and why

[John Porter]

Buddha Buck wrote:
> I suggest that the last be 
> "Status: postponed" instead of "Status: tabled".

"deferred"

-- 
John Porter

Re: Recording what we decided *not* to do, and why

[John Porter]

Larry Wall wrote:
> 
> As long as everyone realizes that I might reject a good many "Good"
> things ...

Oh, natch!


> For embedded comments, we might rather see some kind of
> macro facility that could turn qc// or any other quoted form into a
> list of zero or more tokens.

This is precisely what I had in mind, except
s/macro facility/the compiler/, since qw() is handled there,
if I'm not mistaken.  But a standardized macro facility would
be nice.  Although -- wouldn't it have to parse perl?  Or else
have a wholly distinct grammar?

-- 
John Porter

Aus tiefem Traum bin ich erwacht.

Re: named parameters

[Damian Conway]

   > Reading through the docs for perl prototypes I see that there is a
   > reference to "named parameters" being a possibility in future versions of
   > perl.
   > 
   > Does anyone have a more concrete example of what was intended there? (I'm
   > assuming that since it was mentioned that there was a debate on the issue
   > some time ago).

Intending to RFC a proposal for that too...

Dear Mum and Dad,

Having a wonderful time on perl6-language.
Please send more tuits!

Damian

Re: Recording what we decided *not* to do, and why

[Buddha Buck]

At 01:11 PM 8/3/00 -0500, Jonathan Scott Duff wrote:

>BTW, I propose that RFCs have a Status: field as part of the VERSION.
>Here are some possible values that I can see:
>
>Status: accepted # we all agree that it should go in
>Status: rejected # we all agree that it shouldn't go in
>Status: tabled   # shelved, put away for now

Since I have been lead to believe that in standard US practice, "to table" 
means to stop talking about something for now, and in standard UK practice 
"to table" means to bring up for discussion, I suggest that the last be 
"Status: postponed" instead of "Status: tabled".

But then, I'm so far behind on my perl6 mail that someone else may have 
suggested that.


>-Scott
>--
>Jonathan Scott Duff
>[EMAIL PROTECTED]

named parameters

[Tim Jenness]

Reading through the docs for perl prototypes I see that there is a
reference to "named parameters" being a possibility in future versions of
perl.

Does anyone have a more concrete example of what was intended there? (I'm
assuming that since it was mentioned that there was a debate on the issue
some time ago).

-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj

Re: Recording what we decided *not* to do, and why

[Damian Conway]

   > I don't care particularly if you ignore dissenters.  They can have
   > their own counter-RFC.  All we're doing is making suggestions to
   > Larry, not regulating nuclear weapons or planning a space mission.

I used to feel like that too, until folks from the space agencies of
two countries told me they were using Parse::RecDescent.  SCARY!

Damian

Re: Ops versus subs (Was: Re: RFC: Higher resolution time values)

[Dan Sugalski]

At 09:06 PM 8/3/00 +0200, Johan Vromans wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > At 07:21 PM 8/3/00 +0200, Johan Vromans wrote:
> > >Larry Wall <[EMAIL PROTECTED]> writes:
> > > > Theoretically, we'd like to make subs run as fast as ops.
> > >I'd say that the distinction between subs and ops should be dropped
> > >completely. Ops can be used as subs, subs as ops. The only
> > >distinction in the way either is used.
> >
> > Whoa there. I don't think that's possible. (Not the least of which
> > because subs are written in perl, and ops are in some compiled
> > language)
>
>Thats implementation. This is perl6-language.
>
>My point is that from language perspective, there is (or should be) no
>difference.

Ah, I was looking bottom up, not top down. (It was the speed comment that 
got me) Wrong set of glasses, sorry. :)

Dan

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

Re: Expanding the language primitives (was: Re: Reduce [was: Re: Random items (old p5p issues)])

[Dan Sugalski]

At 09:03 PM 8/3/00 +0200, Johan Vromans wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > More importantly, the more primitives that perl provides, the wilder
> > and more useful things people will be able to do.
>
>Not quite. Its the functions that are provided that matter, not
>whether they are primitives or not[1].

Ah, I was using primitive in the "it's a conceptual black box that Does 
Something". In the same way that, say, LWP::Simple::get is a primitive. 
Sloppy terminology, I know.


Dan

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

switch/case (c) vs. case (pascal)

[Stefan Moch]

hi,

if you want to have something like switch/case it is a good idea to use
the 'case' of pascal, because it is easy to use and it is really clear.
the 'switch/case' of c is (in my opinion) is not good for a language
like perl which claims to be practical.

cu stefan


-- 
Diese eMail wurde unter Zuhilfenahme eines guten eMailProgramms
und eines richtigen Betriebsystems erstellt.

Re: Recording what we decided *not* to do, and why

[Michael Mathews]

Larry Wall wrote:
> Note in particular that multi-line comments
> are something we *could* have added at any time, but chose not to.
> This means you're gonna have to argue a little harder for it than you
> would for something that wasn't possible before, but that we think
> might become possible with the redesign.

Gee, and I really thought I was the first person to come up with that idea!
:-)

--Michael

Re: RFC: lexical variables made default

[Damian Conway]

   > > Perl's similarity to English is one of the things that makes it Fun.
   > 
   > OTOH, being fun (which I admit it is) is one of the reasons many
   > people don't want to think Perl is a serious language.
   > 
   > Not saying we should eliminate all the fun; but keeping something
   > on the merit of it's being fun is probably at odds with the goal
   > of make Perl more widely acceptable.

Someone want to RFC a "fun" pragma:

   #! /usr/local/bin/perl -w

   no fun;  # for you!

Actually, Tim Maher and I were discussing something not entirely dissimilar
for the purpose of teaching:

use Training::Wheels;
or:
no Weird::Stuff;
  
Hm. I feel a paper coming on...

Damian