listing all files in all sub directories

[steve]

I am trying to list all files in all sub-directories and have the code
below but this is listing the . directories as well as the directories
themselves. I just want the full path filenames and not the individual
directories out. Here is what I have

#!c:/Perl/bin/Perl.exe

@ARGV = qw(.) unless @ARGV;

use File::Find;

find sub { print $File::Find::name, -d && "/", "\n"}, @ARGV

for example if structure is
c:\file.txt
c:\file2.txt
c:\one\teo.txt
c:\two\text.bmp

the output of the script when run from c:\ would be
./
./script.pl
./file.txt
./file2.txt
./one/
./one/teo.txt
./two/
./two/text.bmp

all I want is
./script.pl
./file.txt
./file2.txt
./one/teo.txt
./two/text.bmp

Thanks!

Re: formats and localtime

[Steve Simmons]

On Tue, Aug 01, 2000 at 01:17:25PM +1000, Damian Conway wrote:

> My (limited) understanding of the aims of Perl 6 were to start again with a
> clean slate and fix the things that are broken, or that could be designed
> better with hindsight.  Backwards compatibily was to be fed to the lions.
> 
> If that isn't the case, I'll be unsubscribing immediately -- if Perl 6
> is to be a mere exercise in featuritis, I'm not interested.

Seconded.

Removing/fixing $[line noise here] variables

[Steve Simmons]

In re the discussion of $^O, etc, etc, I'd like to throw out
some ideas on these line noise features and (for lack of a better
name) perl control values.

IMHO there are two distinct sets of problems here.  One is that
the existing $[linenoise] vars are horrible names and really need
some syntactic sugar.  `use English' is a help, but it's limited
and requires Yet Another Module be loaded when you compile.   The
other set is that some vars are:

   o  useless
   o  unused (as far as we know)
   o  duplicated by other features
   o  standing in the way of advance because of backwards compatibility
   o  hard to deprecate without nagging the crap out of users running
  the programs

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

These ought to be `protected' in the sense that one could change
the value of an entry, but not remove/add an entry to these hashes.
The result in some sense this mimics what `use English' does, but
gives us some additional wins:

  o  no need for Yet Another Module to be loaded
  o  it promotes code readability
  o  probably promotes core Perl maintainability
  o  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 (this idea shamelessly ripped off from
 common TCL usage)
  o  solves problems with $ variable proliferation
  o  promotes introspection - its easy to determine what's possible in
 a given `module' via ``foreach $key ( %PERL_CTL )''.  Then you can
 just look them up in the manual.  :-)
 
`use strict foo' should set $PERL_STRICT{foo}, etc.  Then we dynamicly
manipulate it by manipulating the hash, not by sprinkling `use strict'
lines around the place.

For deprecation, we should have a %PERL_DEPRECATED{mod}{thing} hash as
well.  `mod' is `CORE', `FORMATS', etc, as above.  A value of 0 means the
function is actually gone, 1 means it's disappearing next major release,
2 mean next minor, etc.  The programmer can control what happens when
the feature is used by setting a %PERL_DEPRECATED{mod}{warning} value
to 0 for default, 1 for once, 2 for never, etc, etc.

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

[Steve Simmons]

On Tue, Aug 01, 2000 at 04:47:47PM -0400, Dan Sugalski wrote:

> Put together an RFC for it. (Soon!) This is a language topic, but it will 
> impact internals a touch, and I'd like to get as many of the "impact 
> internals" things spec'd out as soon as possible . . .

Uh, OK - but how about we wait 24 hours to see who screams bloody murder?

Module versioning changes

[Steve Simmons]

Despite my throw-it-over the transom comments on global vars, that's
not really why I came here (tho I will pitch in on the topic).

The perl features that most bites me in the ass is how module versioning
and searching works.  The easiest way to describe what I want is by
examples, so here are several of them.  And yes, I'm volunteering to
write the RFC -- but consider this note a request for any other ideas
or requests which came up before I was paying attention.  Like, say,
before Monday of last week.

Recovery from discovery of older versions:


Currently
  use  foo 1.2;
will fail if a version prior to 1.2 (including a versionless version)
is found in @INC.  Instead, perl should ignore any version which does
not match the users requirements.


Version Capping

One should be able to specify bottom and tops of version ranges, eg:

  use   foo "=<1.23";   # Any version up to and including 1.23
  use   foo "<1.23";# Any version prior to 1.23
  use   foo "==1.23";   # Version 1.23 and only version 1.23
  use   foo "=>1.23";   # Any version from 1.23 forward
  use   foo ">1.23";# Any version after 1.23

Do we want to require the quotes?  I dunno, see below.


Version Listing, Ranging

One should be able to specify any of a range of versions:

  use   foo 1.0 .. 2.0  # standard perl range syntax
  use   foo 1.0 ... 2.0 # standard perl range syntax
  use   foo 1.0..2 ;# Barewords are interesting - is this a
# missing 3rd-level var, or a range?
# IMHO, it's an error - dots should balance
  use   foo 1.0..2.0# But this is OK, 1.0 .. 2.0

or a list of versions:

  use   foo 1.0,1.1,>1.3;

Versioning in namespaces/modules:

Let us suppose that module foo requires module bar v1.0, while module
baz requires module bar 2.0.  This should be permitted, eg:

foo.pm  baz.pm

use bar '==1.0';use bar '==2.0' ;

bar::op();  # Uses bar 1.0 op   bar::op();  # Uses bar 2.0 op
bar::1.0::op(); # Same  bar::2.0::op(); # Same

In general, if a version-qualified use of a package is done, it must
be with the version explicitly loaded.

This implies one could do:

use bar 1.0 ;
use bar 2.0 ;

bar::op() ;  #Uses highest version loaded
bar::1.0::op() ; #Same
bar::2.0::op() ; #Same

IMHO, this opens incredibly ugly cans of syntatic and semantic worms.
However, IMHO it has to be allowed -- the bar::version packages are
treated as if they had separate names.  Why?  Because we want foo.pm
amd baz.pm to work right when the mainline says:

my $handle1 = new foo ;
my $handle2 = new bar ;
my $var1 = $handle1->op();  # Always gets op 1.0
my $var2 = $handle2->op();  # Always gets op 2.0

Clearly both versions must be loaded simultaneously, and we need the
possibility of that main going on to do

   my $opval1 = op::1.0() ;
   my $opval2 = op::2.0() ;

Note this might prove to be invaluable in testing new versions of modules.


General notes:

Subversion defaults should be well-defined - does "<=2.0" succeed or
fail with "2.0.1"?  IMHO any unspeicifed ranges should be assumed to
be `0', then the >/=/< applied.  Thus 2.0.1 would not satisfy "<=2.0".

And that's my over-the transom thoughts on the matter.

RFC: type inference

[Steve Fink]

=head1 TITLE

type inference

=head1 VERSION

  Maintainer: Steve Fink <[EMAIL PROTECTED]>
  Date: 1 Aug 2000
  Version: 0 (unreleased)
  Mailing List: [EMAIL PROTECTED]
  Number: (unassigned)

=head1 ABSTRACT

Types should be inferred whenever possible, and optional type qualifiers
may be used to gain whatever level of type stricture desired.

=head1 DESCRIPTION

For large systems, and often for small ones, type checking is
extremely valuable as a way of eliminating bugs at compile time and
avoiding errors while making global changes. I propose that we create
a type hierarchy, such as

   any
  list
 list(T)
  hash
 hash(T -> T)
  scalar
 reference
 ref(T)
 nonref
 number
integer
  void

(This is just a sketch; there are many ways of skinning this cat.)
By default, only constants would be assigned a type. Every node in the
parse tree would be assigned a type. Variables would not have a single
type; they would have a possibly different type after every
assignment. So using the default rules

   1 $x = 3;
   2 $x .= "x";
   3 $h{$x} = \$x;
   4 $h{foo} = "bar";
   5 $x = f();

I<$x> would have type C after line 1 and C after
line 2. I<%h> would have type C<< hash(nonref -> ref(nonref)) >> after
line 3, and then would find the nearest ancestor in the next line,
resulting in C<< hash(nonref -> scalar) >>. Line 5's effect depends on
whether C's type is known. If not, then I<$x> will have type
C after line 5.

Notice that so far, all existing programs will always typecheck
successfully, so no burden has been placed on the programmer who does
not want types.

Now say we insert C at the beginning of the example
(or some other syntax). That means that we are asserting that I<$x>
will I be of type C, and we will flag a type error on
line 2 and an optional warning on line 5 if the return type of C
in scalar context is unknown.

Note that error messages are only generated when two things with
strong types collide. So C will not
complain, but C will.

(I am leaving out a lot of details, such as what happens to the type
of I<%h> if just after line 3 you say C<$x = [[]]>. Or what happens to
the types of all accessible variables on an eval"", or function types,
or a hundred other messy problems. But even if lots of stuff gets
promoted to type C, I still think that types will be very useful
within individual subroutines and other isolated areas.)

=head1 IMPLEMENTATION

I propose not changing runtime behavior at all; in the case of 
C, I<$x> may actually end up containing a
non-integral string with no warning issued. If you want a warning,
write your own RFC. ;-)

Implementation for the most part is straightforward type inference
using unification. The wrinkles come in from how complicated the type
hierarchy is, and where we want to place the balance between false
positives and false negatives. (Type theorists do not allow false
negatives, but I'm not a type theorist and their motivation for that
stance is allowing safe run-time behavioral differences.)

Re: type-checking [Was: What is Perl?]

[Steve Fink]

Tom Christiansen wrote:
> 
> >Several people have suggested strong typing as a feature, and have been shot
> >down one by one.  However, I think it can be done without forcing it on
> >everyone.
> 
> Can it?  Are you prepared to make everyone declare the full, formal, and
> fancy types for the return values of all their functions?

I think it can, but don't have proof. See my recently posted RFC for my
opinion of the right direction to go.

> Consider how nasty "strong typing" will really become if you really
> get it all the way, or how slipshod it will be if you only partway.

I agree that the first won't work, but am unconvinced that a partway
solution is so bad. If it catches a large set of errors, then as long as
you don't rely on it for doing your thinking for you, what's the harm?

> You now have to enforce typing of expressions.  (Gasp!)

Define what you mean by "enforce". I think it should warn when it's
certain of a problem, or when you've asked it to divulge its misgivings.

> For example, consider a function that is expected to return a list
> of two values, the first a reference to a hash of arrays of integers
> and the second a floating point number.

I find that to be one of the easier ones, since it's a fixed-length
tuple. The hard ones are lists of an unknown number of values. But you
can always punt and fall back to a "list of any" type.

You can get partway, though -- I once worked on a project where we had a
list type "if there is at least one element, the first one is of type
T1. If there are at least two, the first is type T1 and the second is
type T2. If there are three or more, then as before but the third and
all subsequent are of type T3." The notation was something like LIST(T1,
T2, T3...). It worked out well, but may be more effort than it's worth
here. Although multiple known return values _would_ be nice to catch,
rather than just falling back to LIST(least common ancestor(T1,T2,T3)).

Re: RFC: type inference

[Steve Fink]

Ken Fox wrote:
> 
> IMHO type inference is the best way to get typing into Perl.
> We don't lose any expressiveness or hurt backwards compatibility.
> About the only thing we need to make visible are a few additional
> pragmas to enable type inference warnings.
> 
> Steve Fink wrote:
> > Types should be inferred whenever possible, and optional type qualifiers
> > may be used to gain whatever level of type stricture desired.
> 
> This will impact the bytecode storage format because we don't
> want to lose any type information present in the op tree. Reverse
> engineering source from bytecode is easier, but I think performance
> and distribution (not obfuscation) is driving the need for bytecode
> format.

There are many possible goals for any typing-related stuff we do. I'd
say the top three are:

- compile-time warnings
   - definitely unsafe operations
   - probably unsafe operations
- runtime storage optimization
- runtime time optimization

I was shooting for only the first. But "compile-time" is perhaps too
simplistic. We have BEGIN{}, bytecode, AUTOLOAD, etc. We probably ought
to agree on the goals of any typing first.

> > I propose that we create a type hierarchy, such as
> >
> >any
> >   list
> >  list(T)
> >   hash
> >  hash(T -> T)
> >   scalar
> >  reference
> >  ref(T)
> >  nonref
> >  number
> > integer
> >   void
> 
> The top level types you sketch are easily deduced from Perl's
> syntax alone -- we don't need any deep analysis. In order to
> produce anything useful, global dataflow analysis is required
> with all the optimization stages delayed until all the source
> has been seen. That's not a small thing to bite off and I don't
> see any way to move the decision to a module -- it's got to be
> in the core.

I was thinking much less radically -- no global analysis, just local
inference that throws up its hands when calling unseen functions. And
then mitigating the drawbacks by explicit type declarations. It seems
too constraining to require seeing all of the source. I don't agree that
you can't do useful stuff without global analysis, but I can't prove it
yet.

> Many Perl operators are polymorphic, so they don't reveal a whole
> lot about their operand types (++$a is a good example). I propose
> that we abandon the typical view of a type hierarchy like the one
> listed above and adopt a capability-oriented one. It would be
> relatively easy for a sub to publish it's prototype in terms of
> what operations must be defined on the arguments.

Just to confirm: so with capabilities, it would be something like

preincrement: (T such that T is incrementable) -> T
and addable(T) implies incrementable(T)

as opposed to

preincrement: number -> number
| preincrement: string -> string

?

Hm, really need to sit down and play with some examples.

> Warnings would be more like "numeric comparison required" instead
> of "integer required".

It does sound promising.

> > Now say we insert C at the beginning of the example
> > (or some other syntax). That means that we are asserting that I<$x>
> > will I be of type C
> 
> Type inference and static typing are two different issues. I think
> they should be proposed in different RFCs.

Only if you think that it's possible to do global analysis. If you
assume that there are areas where you just won't be able to figure out
the type of f(), then you need some way of telling the system what it
can't figure out, in order to hang onto some benefit. But then, I wasn't
doing static typing -- that was intended to just be a directive to the
type inference system, telling it to warn if the user's declaration were
ever _known_ to be violated. Which is backwards from your usual type
inference, which *must* trigger an error whenever a type rule is
suspected of being violated (either because it really is or because the
system isn't powerful enough). Otherwise, you end up with an unsound
system, and your generated code is incorrect because it depends on the
inferred types being correct.

I don't know if this upside-down sort of inference would actually work,
but it doesn't sound completely crazy to me yet. I was shooting for
something that would be incrementally applicable, so I thought it would
be nice to have the default behavior accept all programs, and only
complain about those things (variables) that the user specifically asked
for, but only when it's sure that something is going wrong.

> > Note that error messages are only generated when two things with
> > strong types collide. So C will not
>

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

[Steve Simmons]

On Wed, Aug 02, 2000 at 03:34:56PM -0400, John Porter wrote:

> Brust, Corwin wrote:

> > I want perl's error (and warning) messages to be specific to each program I
> > write.
> 
> Isn't this covered by locales?

Completely different beast.  I don't claim to fully understand locales,
but that's not what they're for.

RFC: variable usage warnings

[Steve Fink]

Hey, this RFC stuff is fun!

=head1 TITLE

variable usage warnings

=head1 VERSION

  Maintainer: Steve Fink <[EMAIL PROTECTED]> for now
  Date: 2 Aug 2000
  Version: 0 (unreleased)
  Mailing List: [EMAIL PROTECTED]
  Number: (unassigned)

=head1 ABSTRACT

"VARIABLE used only once: possible typo" should be replaced with
warnings on uses of uninitialized variables (including lexicals).

=head1 DESCRIPTION

Perl6 should distinguish between uses and assignments to variables,
and warn only when a variable is used without being assigned. In
perl5 the complete program

 $x = 3

complains, but

 $x = 3; $x = 3

does not, nor does

 my $x = 3

nor

 use vars qw($x $y); $x = $z; $y = $z;

It would be more useful to have a complaint for both lexical and
package variables, and only when a variable is used without ever being
assigned to (or having its reference taken).

The warning message "use of uninitialized value" should also
disappear, to be replaced with "use of undefined value", and the
warning for the purpose described in this RFC should be "use of
uninitialized variable C<$x>".

Note that if you currently depend on lexical variables having
undefined values, you would need to change C to C. This is a Good Thing.

=head1 IMPLEMENTATION

I have no idea how difficult this would be to implement. You just need
to distinguish between lvalue and rvalue uses of a variable, I guess?
But hey, this is a language RFC, not an internals RFC. :-) There's
also the question of whether to properly track uses and definitions so
that C<$::z = $x; $x = 3> is a warning, as well as C<$x = 3 if f();
print $x>. Though the latter would require renaming the warning to
"possible use of uninitialized variable C<$x>".

Re: RFC: Filehandle type-defining punctuation

[Steve Simmons]

On Wed, Aug 02, 2000 at 11:46:15AM -0700, Peter Scott wrote:

> =head1 TITLE
> 
> Filehandles should use C<*> as a type prefix if typeglobs are eliminated.

I could go for this, given the `if typeglobs are eliminated' caveat.

Re: RFC: variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> >The warning message "use of uninitialized value" should also
> >disappear, to be replaced with "use of undefined value", and the
> >warning for the purpose described in this RFC should be "use of
> >uninitialized variable C<$x>".
> 
> What about if there's only an expr, not a variable?
> 
> For example:
> 
> print $$x->methop()
> 
> If the return list of the object whose ref ref is in $x is (a, undef, b),
> what are you supposed to say?
> 
> --tom

"use of undefined value". You misunderstand; I am *not* addressing the
perennial complaint that the "use of uninitialized value" doesn't
identify the source of the undefined value. The only reason why I
mentioned that warning is because it sounds too similar to the warning
I'd be adding, so I renamed the existing warning to better reflect what
it means. (And that's not a new proposal either -- didn't you suggest
that once?) So, roughly

"symbol $main::x used only once" -> "use of uninitialized variable
$main::x"
"use of uninitialized value" -> "use of undefined value"

except that the semantics of the first are slightly different. I'm not
touching the second other than to reword it to be more accurate.
Personally, I think that it ought to be possible to provide more
information there in limited cases, but that's for another RFC that I
don't care enough about to write.

I'll rephrase the RFC to make this more clear. On rereading it, it does
sound like I'm implying changing the undef warning.

Re: RFC: variable usage warnings

[Steve Fink]

Updated RFC.

---

=head1 TITLE

variable usage warnings

=head1 VERSION

  Maintainer: Steve Fink <[EMAIL PROTECTED]> for now
  Date: 2 Aug 2000
  Version: 0.2 (unreleased)
  Mailing List: [EMAIL PROTECTED]
  Number: (unassigned)

=head1 ABSTRACT

"VARIABLE used only once: possible typo" should be replaced with
warnings on uses of uninitialized variables (including lexicals).

=head1 DESCRIPTION

Perl6 should distinguish between uses and assignments to variables,
and warn only when a variable is used without being assigned. In
perl5 the complete program

 $x = 3

complains, but

 $x = 3; $x = 3

does not, nor does

 my $x = 3

nor

 use vars qw($x $y); $x = $z; $y = $z;

It would be more useful to have a complaint for both lexical and
package variables, and only when a variable is used without ever being
assigned to (or having its reference taken).

The warning for the purpose described in this RFC should be "use of
uninitialized variable C<$x>". This message is too close to the
existing "use of uninitialized value", but that message is badly
phrased anyway, so it will change to "use of undefined value" to
better reflect its actual meaning. (The two are related; "use of
undefined value" can be thought of as encompassing the runtime
counterpart to the compile-time "use of uninitialized variable"
proposed here.)

Note that if you currently depend on lexical variables having
undefined values, you would need to change C to C. This is a Good Thing.

=head1 IMPLEMENTATION

I have no idea how difficult this would be to implement. You just need
to distinguish between lvalue and rvalue uses of a variable, I guess?
But hey, this is a language RFC, not an internals RFC. :-) There's
also the question of whether to properly track uses and definitions so
that C<$::z = $x; $x = 3> is a warning, as well as C<$x = 3 if f();
print $x>. Though the latter would require renaming the warning to
"possible use of uninitialized variable C<$x>".

Re: RFC: variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> >"symbol $main::x used only once" -> "use of uninitialized variable
> >$main::x"
> >"use of uninitialized value" -> "use of undefined value"
> 
> Perhaps then
> 
> "use of uninitialized value" -> "use of undef as discrete value"
> or
> "use of uninitialized value" -> "discrete use of undef value"
> 
> --tom

Maybe, but I prefer to think of undef as an operator rather than a
value, and those message sound to me like they're implying that undef is
a value. "Discrete" also misleads me; I would ask "so you'd rather I
used undef as a list?"

Re: perl 6 requirements

[Steve Fink]

"Randal L. Schwartz" wrote:
> 
> > "Martyn" == Martyn Pearce <[EMAIL PROTECTED]> writes:
> 
> Martyn> Possibly, although I must ask: since everything is up-for-grabs, I ask
> Martyn> (without implying any feeling one-way-or-tother):
> Martyn> How useful is the , operator in it's C-style statement separator, as
> Martyn> opposed to list separator guise?  It seems to be a common cause of
> Martyn> confusion.
> 
> I use it a lot, in places where I want two expressions executed,
> especially as one part of "EXPR while EXPR" or "EXPR if EXPR".
> Yeah, I could use a do-block on either side, but then I might
> as well go to a full while statement.
> 
>warn("too much information"), return 3 if $some_condition;
> 
> Very handy.

warn("too much information") and return 3 if $some_condition;

works, but depends on the return value of warn. I bet it would cover
most uses, though. I'd love to eliminate the comma ambiguity.

We could add a 'then' keyword.

Re: Where must you 'no strict'?

[Steve Simmons]

Summary:

There is no circumstance in which I have had to do `no strict.'

Background:

I've spent much of the last six months cleaning up bad perl (let's
hope none of my co-workers are on this list...).  When I'm done with
a tool or module, it runs silently under -w and under strict.  100%.
I've got all the standard reasons for doing so, plus one more -- part
of my job here is to act a mentor to a lot of 2[0-5]-year-olds who've
never had to deal with maintenance of code.  So even in a case where
*I*, with 20 years of coding, might trust myself to do `no strict',
I'm proving by example that (a) you can do that and (b) you get more
reliable, reusable code by doing so.

So when I say "there is no circumstance in which I have had to do `no
strict'", it should be interpreted as ``I've always been able to find
a workaround that means I can continue using strict.''  Thus far, all
of those workarounds have been (IMHO) roughly equal in quality (speed,
readability, maintainability) to the `no strict' versions.

That said, there are a few cases (such as the grepish example previously
cited) where I'd do a `no strict'.  But I'd mark myself down for it in
my annual review.  :-)

[[ An aside - one nice side-effect of this part of my job is that
I'm developing an informal set of guidelines and boiler plate
on writing *maintainable* code in perl.  If this process continues
far enough, I'll take the collected departmental wisdom and
stick it on the web.  Right now it's too early - I keep finding
that I'm re-inventing wheels from the public perl world.  Gotta
read Damians contract module Real Soon Now. ]]

Re: BiDirectional Support in Perl6

[Steve Simmons]

On Thu, Aug 03, 2000 at 02:31:01PM +0300, Roman M . Parparov wrote:

> This is quite unexplored field. I, being an Israeli resident, am forced
> to deal once in a while in applications that should output RTL languages,
> both as plain text output and hypertext output.

By RTL, do you mean the intermediate representation used in the GNU
compiler family?  If not, could you provide a pointer to the RTL you're
referring to?  Acronyms are overloaded so easily...

Re: RFC stuff

[Steve Simmons]

On Thu, Aug 03, 2000 at 12:51:10PM +1000, [EMAIL PROTECTED] wrote:

> Programer Modifiable Warnings and Error Messages  
>   Brust, Corwin" <[EMAIL PROTECTED]>
 . . .

> Removing/fixing $[line noise here] variables
>   Corwin Brust <[EMAIL PROTECTED]>

That second is actually mine.  Barring people harassing me too much
to actually work at work, I'll have a rough cut out this afternoon.

At the moment, the suggested implementations for these two things 
overlap a lot, so Corwin and I will stay in close touch.

Re: RFC stuff

[Steve Simmons]

On Wed, Aug 02, 2000 at 08:27:19PM -0600, Tom Christiansen wrote:

> What you're doing here is recreating USENET.  But badly . . .

> Is there an open NNTP server running with all these as the perl.*
> groups?  That would help a lot.

Please, please, please.  I'm already considering moving these
subscriptions to my home machine, as the bandwidth loss may be
worth the killfile gains.  H, maybe I could start reading 
these mail folders with nn..

Re: BiDirectional Support in Perl6

[Steve Fink]

Steve Simmons wrote:
> 
> By RTL, do you mean the intermediate representation used in the GNU
> compiler family?  If not, could you provide a pointer to the RTL you're
> referring to?  Acronyms are overloaded so easily...

"Right To Left". This is the first I've seen it; RTL means many many
other things too.

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: 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: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)

[Steve Simmons]

On Fri, Aug 04, 2000 at 09:10:38AM +0200, Johan Vromans wrote:

> You missed the point.
>
> If you need 6+ lines of code for each elementary error check, this is
> what is going to happen . . .

You're correct, but that's not what I was suggesting.  The magic words are
`for each elementary error check.'  Many (most?) functions do fine with
a simple error codes returned.  But there are some cases where things
go wrong deep inside modules and it's not easy/reasonable/feasible to
return anything meaningful in the error code.  For circumstances like
that, a try/catch mechanism is wonderful.  It's superior to if (eval)
in expressiveness and flexibility as well.

Those who write all their code like this with try/catch (as Johan
suggested):

> try {
>open file
>while read a record
>   process its contents
>finalize file processing
> }
> catch (Exception e) {
>error message: something went wrong
> }

are also probably writing their (pseudo-perl) code like

if ( ! ( $err = open file ) ) {
error message: something went wrong
} else while ( $err = read a line ) {
if ( $err ) {
error message: something went wrong
} else {
   process it's contents
}
if ( ! $err ) {
   finalize file processing
}
}

Bad code and (in this case) feature abuse are independent of features.
I for one would like a try/catch for the tough cases that need it.
If people want to screw themselves over with abusing it for trivial uses,
that's fine.

PROPOSAL: we should add try/catch to perl, with the caveat that uncaught
exceptions are ignored and an error code returned as per current
functioning.

Or Fri, Aug 04, 2000 at 05:09:13AM -0600, Tom Christiansen wrote:
> >> If you do it the C++ way, you can say:
> >>   try {
> >> first_sub_that_throws_exceptions();
> >> second_sub_that_throws_exceptions();
> >>   } catch {
> >> it went wrong
> >>   }
>
> >How does 'it went wrong' know _which_ of the subs went wrong?
> 

As was pointed out elsewhere, the object provided to the catch has
that data.  But that's a not really relevant to the clarity, obscurity,
or brevity of code using try/catch.  The following working perl code
has recently been removed from some of our tools:

   die "Couldn't open database\n" if (!$dhb = open_db("bdconfig", get_dbms("Oracle", 
get_host_addr("woody";

This statement appeared in the code twice, widely separated, with
different db/dbms/host but the same error message.  Needless to say,
it leaves you pretty clueless as to what went wrong.  I've directed
our programmers here that such statements should be rewritten to

my $dbh;
my $host = "woody";
my $dbms = "Oracle";
my $db   = "bdconfig";
my $why  = "why you want it";
my $addr;
if ( ! $addr = get_host_addr( $host ) ) {
die "Couldn't find host '$host' for $why.\n";
} elsif ( ! $dbms = get_dbms( $dbms, $addr ) ) {
die "Couldn't access DBMS '$dbms' on $host for $why.\n";
} elsif ( ! $dbh = open_db( $db ) ) {
die "Couldn't access $dbms db '$db' on $host for $why.\n";
}

or encapsulated in a function which returns an appropriately
informational error string:

if ( "" ne ( $errstr = opendb( "bdconfig", "woody", "Oracle", \$dbh ) ) ) {
print STDERR $errstr;
}

Both the large code block in the first and the implementation of opendb
(not shown) are pedantic as all hell, but now when the NOC pages me at
3AM, I know where to start looking.  I submit that both the above call
to opendb with a string error code and the try/catch version:

try {
$db_handle = opendb "bdconfig", "woody", "Oracle" ;
} catch {
it went wrong
}

are about equally readable, and the try/catch is ultimately more powerful.

Jeez, don't tell me I've just started writing another RFC  smiley/2.
--
   ``Just imagine we are meeting the aliens for the first time.  Most
people would just shoot them to see how many points they are worth.''
  Simon Cozens in msg <[EMAIL PROTECTED]>

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

[Steve Simmons]

On Fri, Aug 04, 2000 at 12:07:00PM -0400, John Porter wrote:

> I don't mind cpp too much; but I'd really like something much
> more powerful than cpp.  Hmm -- cpp++??

m4.

IMHO perl6 should continue the rich tradition of stealing from the best
rather than re-inventing an only marginally better wheel.  m4 is better
than cpp, and was intended to be a general macro package.  Are there
versions available which are not strongly unfettered by license issues?

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

[Steve Simmons]

On Fri, Aug 04, 2000 at 01:18:36PM -0400, John Porter wrote:

> O.k., what I really meant was, When they're both incapable of doing
> the sorts of things I want a macro language to do, does it matter
> that one is gobs more powerful than the other?

I freely admit to knowing very little about macro languages other
than m4 and cpp; if you've got a set of features that you think
would be better it'd make grist for an RFC.  There seems to be
moderate sentiment for a macro language and no strong opposition,
go for it.

Re: Language RFC Summary 4th August 2000

[Steve Simmons]

On Fri, Aug 04, 2000 at 03:37:08PM +1000, [EMAIL PROTECTED] wrote:
> 
> 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

> Drafts, etc
> ---
> Removing/fixing $[line noise here] variables
>   Corwin Brust <[EMAIL PROTECTED]>

That one is now out as RFC 16.  An updated version will be out to you
tonight, the `up-to-the-instant' version is available at
  http://http://www.nnaf.net/~scs/Perl6/RFC17.html
but it's literally changing minute by minute.  A new version will be
submitted to the librarian once I've integrated the current comments.

My hand is also in the air for module versioning, I should have it banged
out tonight as well.

$DEITY, how does Damien do it?

Re: RFC 37 (v1) Positional Return Lists Considered Harmf

[Steve Simmons]

> Functions like stat() and get*ent() return long lists of mysterious
> values.  The implementation is assumedly easy: just push some values
> out of C structs into the Perl return stack.
 . . .
> Firstly, who can remember which one of the stat() return values was
> the atime is or which is the 4th return value of localtime()?  The
> perlfunc documentation makes this difficulty painfully obvious by
> having to list the indices alongside the values.

I must respectfully disagree.  The following line of code was
written by doing `man perlfunc', a few keystrokes to find the
right instance of `  stat ', and a cut and paste:

($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,
$atime,$mtime,$ctime,$blksize,$blocks)
= stat($filename);

For everyone who knows they need to make a stat() call, that
line tells them everything they need to know.

A few more keystrokes changes it to

(undef,undef,undef,$nlink) = stat($filename);

which informs the reader than yes, the program really meant to throw
away everything else from the stat call.  In a well-optimised
compiler, it would even pass only the one data element actually used.

Returning pre-parsed lists is a win, especially if one needs some
large subset of the values returned.  I use this feature regularly,
and would not wish to see it go away.

> Secondly, the current solution is seriously non-extensible.  One
> cannot easily add new return values to the APIs because someone may be
> expecting an exact number of return values, or someone may be
> accessing the values by position from the end of the list Obsoleting
> values (or marking them as non-applicable to the current platform) has
> to be done by for examples returning undef.

The above is a more telling criticism, but I that `stat()' is a
poor example -- it's not likely to change much.  I'm sure there are
better, but have not bothered to look.  :-)

> =head1 IMPLEMENTATION

I strongly support Damiens suggestion on a hashref, and would go so
far as to say it should be a pseudo-hash, with all the attendant
misspelling protections and speed obtained.

Passing lists around can be expensive, manipulating hashes can be
expensive.  I'd extend Damiens suggestion to allow the programmer
to specify only the sub-data desired, eg:

# undef context, store results in passed hashref

my %data_wanted = \(mode => 0, nlink => 0);
stat( $filename,\$data_wanted);

This could even be done in a list context, with a possible
implementation suggested:

# List context, return only the two values requested in order

($mode,$nlink) = stat($filename,\('mode','nlink'));

Re: RFC Archive

[Steve Fink]

What about updating RFCs? Should I increment the version number and send
each new revision to perl-rfc? Do I need to be careful about the RFC
number when submitting updates?

Also, I assumed the intention of the RFCs was to stimulate focused
discussion and to keep a record of the decisions made during that
discussion in the RFC. Is that true? Or, asked another way, is the
maintainer of an RFC automatically responsible for tracking the related
discussions and recording the decisions made in them?

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

[Steve Simmons]

On Thu, Aug 03, 2000 at 11:27:27AM -0600, Nathan Torkington wrote:
> Steve Simmons writes:

> > . . .  IMHO the RFC editor should be responsible for this.
> 
> IMHO someone should write an RFC on why perl6 should NOT have
> comments.  The RFC editor doesn't have time to follow these zillions
> of discussions and write documents based on them.

Ooog, horrible phrasing on my part.  That should read ``the editor
of the RFC which is rejected.''  Sorry

RFC17 (v1) comments and responses

[Steve Simmons]

This is an omnibus response to those who've commented on RFC17 (v1).
The version I'm about to submit to the librarian is now available
as html at .

General note -- please look over the abstract.  Some folks have made
really good suggestions to change things which are (IMHO) outside of the
scope of this effort.  RFC focuses on a suggestion to the developers
that a naming scheme be adopted which is more mnemonic and which
makes it immediately visible which variables are related.

Ted Ashton <[EMAIL PROTECTED]> kindly provided the formal
objection to:

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

Not to disagree with Teds claim of what he spends his time on, but
*this* programmer is far less likely to turn to the manual when he
sees
$WARNING = 0;
than when he sees
$^W = 0;
And $^W is one of the more mnemonic ones (shudder).  But regardless of
*my* opinion, his comments are now incorporated into the about-to-be
submitted new version of the RFC.


"J. David Blackstone" <[EMAIL PROTECTED]> wrote:

> ...Larry implied that there might not be much left when all these
> variables are cleaned up...

Yes.  Renaming is only proposed for what's left.
If not much is left, that's a Good Thing.

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

I'm of two minds on this.  On one hand, it would be useful for us to set
some sort of direction for the language developers to follow.  On the
other, they're the ones who are going to have to decide what lives and
dies, and how the remaining ones should be grouped.  IMHO the proposal
as it stands describes the policy sufficiently; the the developers are
the ones


Bart Lateur <[EMAIL PROTECTED]> asks responsed to a suggestion by
David Blackstone:

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

> I have only one problem with this solution, and that is with the <>
> magic file handle. Would it's private $/ stick across files?  Well, er,
> yes...

This RFC is on the reorganization and potential renaming of these
variables, not on changing their function.  IMHO this suggestion (while
interesting) belongs elsewhere.  It's a suggestion on modifying the
scope of modified settings in perl.  Each of those needs to be discussed
in some topic relative to the feature which is modified by the variable,
not in their renaming and potential removal.


Tom Christiansen <[EMAIL PROTECTED]> writes:

> If we were selecting dubious features to shoot (and I think we are),
> then the fact that $^F and $^F are the same is one I'd kill--by zapping
> the latter, too.

Again, grist for the mill for the folks who work on those particular
features.


William Setzer <[EMAIL PROTECTED]> made a comment on loss of
distinctiveness which I have taken almost in its entirety into the
new document.


Mark-Jason Dominus <[EMAIL PROTECTED]> kicked off an excellent discussion on
the general wisdom of having these variables at all.  I tend to agree with
his core points, and have added a small section on the topic to the RFC.
It concludes with ``Notwithstanding, should the core team continue to
allow global variables for these purposes, the names and categorization
should be improved.''


Many thanks to all.

Re: wildcard includes

[Steve Simmons]

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

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

[Steve Simmons]

On Tue, Aug 08, 2000 at 10:59:40PM -0400, Dan Sugalski wrote:
> On Wed, 9 Aug 2000, Damian Conway wrote:
> 
> >> > If you take this, I won't be able to port the forthcoming Klingon.pm
> >> > module to Perl 6!!!
> >> 
> >> And this would be a bad thing how, exactly? :)
> > 
> > I SHOULD KILL YOU WHERE YOU STAND
> 
> But, but... I'm sitting! :-P

I think he means he's going to cut you off at the ankles, regardless
of their actual location.

Re: Things to remove

[Steve Simmons]

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

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

Running and ducking,
 
 --Steve

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

[Steve Simmons]

On Wed, Aug 09, 2000 at 10:44:03AM -0700, Larry Wall wrote:

> : Note that it may not be possible to satisfy conflicting requests.  If
> : module C and module C demand two different versions of the same
> : module C, the compiler should halt and state the module conflicts.
>
> Pardon me for sniping at a great RFC . . .

No problem, I don't feel sniped at.

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

Near the end of the RFC this topic does come up; see it directly at
.
That section was much longer in my unreleased drafts, but did include
some discussion on disambiguation when multiple versions of the same
module are loaded.  In the RFC I wrote off this idea with ``In This Way
Lies Madness, but perl has done stranger things.''

If we want to open that can of worms I'm willing to pitch in.  I'll even
continue on with the task of maintaining the RFC, or starting another
if appropriate.  But I'd barely started thinking about this issue with
respect to perl until a couple of days ago, so folks who are much more up
to speed on language/inheritence/etc are going to have to carry the load.

Turning back to some specific comments made by Larry and by Dan Sugalski:

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

Package aliasing should certianly be allowed; the RFC already contains
a suggestion for it:

use foo <3.0 as foo_old;
use foo =3.0. as foo;
use foo >3.0. as new_foo;

Using the alias gets you what you need.

Your comment above implies that CPAN may (will be allowed to) contain
modules of the same name and same version by different authors.  Is this
correct?  If so (shudder), what happens currently when both are installed?
I presume one simply overwrites some or all of the other.

If that's the intent, then yes, author name must become part of the
package identifier.  Rather than change the meaning of "ref $object"
unexpectedly, I'd add one or more alternate forms of ref.  Off the
top of the head, something like

( $version, $class ) = vref $object;  # ref with version
$version = vref $object;  # scalar context gets version
( $author, $class ) = aref $object;   # ref with author
$author = aref $object;   # scalar context gets author
( $version, $author, $class ) = fref $object;   # get all
# Scalar context gets a string suitable for select the
# exact object in use
$fq_name = fref $object;

if ( $fqname eq fref $other_object )...

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

If we include author name along with the version number in the file system
namespace (gawd, I can't believe I just wrote that), then clobbering
won't happen.  IMHO this feature is no more difficult to add to the
install process than adding version numbers; it implies tho that we
need a $AUTHOR var in all modules and to allow for it in module `version'
specifications.  Again, off the top of the head, we could allow a string
(any string that would not be confused with a version number) to indicate
the author:

use foo CONWAY <=1.3  as foo_good;
use foo GATES   >1.3  as foo_bad;
use foo * as foo_desperate;

As long as there's no author names `as', we're cool.  I suspect the
proposed syntax in the RFC could be extended to handle this unambiguously
both for run/compile-time module naming and for installation, but need
to think it thru.

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

LW> Presumably.

Yes, that's how I'd see it too.  Which creates a real problem for
modules which do things like

package foo;

{
my $hidden_var;

sub new {
if ( $hidden_var ) {
do x;
} else {
do y;
}
}
}

Now there are two copies of $hidden_var while the module clearly expects
only one.  Either this kind of construction will have to be avoided,
or some mechanism developed which allows multiple version of a module
to somehow share important data which is otherwise hidden by such tricks.

IMHO, module authors should be able to forbid multi-loads across
sufficiently different versions

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

[Steve Simmons]

I'm pretty much opposed to this idea.  It's pushing OO too far onto perl.

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

[Steve Simmons]

On Wed, Aug 09, 2000 at 05:53:44PM -0400, Ted Ashton wrote:

> I'll take that as my cue ;-).

Ah, nothing like a man who knows when to pick up his cues.

> <*shudder*>  This whole business is getting pretty scary . . .
  [[ discussion of ugly implicatations elided ]]

The short answer is that (assuming I understand Larry's statement)
he'd like these issues addressed.  If the resulting `best' answer
is so complex and so ugly that he decides it's a bad idea, that's
fine -- but (if I recall correctly) tcl has addressed this problem
and come up with workable solutions.  I'm not intimately familiar
with them, but will get so.

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

[Steve Simmons]

On Thu, Aug 10, 2000 at 11:01:39AM -0400, Bennett Todd wrote:

> Rather than proliferating the number of keywords eaten with all
> these *ref varients, this sounds like a useful place for returning
> an object with a default stringification of the class:
>  . . .
> Ref RFC 37, RFC 73.

I have no problem with this or any other solution that gets the
data back.  I'll add a comment to RFC78 that should those RFCs
prevail, we'll follow them.

For the record, I prefer hashes for that sort of thing too.  But
perl has traditionally done ordered list returns, and I followed in
that vein.

My opposition to RFC20, and an alternative

[Steve Simmons]

Overloading an existing operator such that it changes the performance
in prior situation is evil, evil, evil.  Yes, I know it can have some
wins, and I agree they're big ones.  But no win is worth having to
debug this (admittedly contrived for the example) situation:

if ( ( $ares = A() ) && ( B() ) ) {
# A and B succeeded, go do something
} elsif ( $ares ) {
# A succeeded but B failed, do B cleanup
} else {
# Do B differently because A failed
}

If the overload means that now A() and B() will now both be processed
no matter what, that block of code is going to go south in a deeply
undetectable way.  And finding the bug is going to be bloody hell.  This
argues that overloading should be restricted in its scope.

Now consider some poor maintenance coder.  He's looking at his main
and a module, trying to figure out why something doesn't work.  Both
contain a test like

if ( A() && B() ) . . .

In main it works one way, in the module it works the other.  Is it
reasonable to expect that?  I submit not.

With humble acknowledgement of my debt to Socrates, I submit that
this dilemma shows that either solution - universal overloading or
localized overloading - leads to extreme difficulties in maintenance.

IMHO, overloading is just syntactic sugar - `it looks cool.'  If
we need an &&/|| operator that always tests both sides, lets
make them -- &&& and |||.  That's a tiny new thing in perl, while
avoiding deep, deep problems introduced from overloading standard
operators.  If someone wants a &&/|| that does something wildly
different, then write a module-specific or general function for
it

Overloading existing operators is evil, evil, evil.  Operators are
not class-specific functions.  They're core language constructs
and the programmer should be able rely on them to remain fixed
in function.

And in conclusion I'm opposed to this.  What I tell you three**3
times is true**3.  :-)

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

[Steve Simmons]

> Perhaps Damian's want() (RFC 21) can be used to allow allow either return
> type? 

Yes indeed.

> Assuming that's adopted, of course.

Sure looks to me like a good idea; I hope it does.

RFC 78 and shared vs unshared modules/data

[Steve Simmons]

On Thu, Aug 10, 2000 at 05:46:14PM -0400, Bennett Todd wrote:

> Today there's no difference. If the proposal under discussion were
> to pass, and packages' namespaces were to become local to the
> namespace where the "use" occurred, then perhaps main::whatever
> could be a common, stable, global that they could use for these rare
> variables that really need to be common from multiple invokers.

There's a strong implication here that we've just made package namespaces
heirarchical.  I don't disagree (how's that for a wimpy statement?), but
think we need to go further.  hbrain racingmmmaybe this is
a good idea

How does this sound --

Modules (packages) should have the option of declaring themselves to be
either rooted or relative in the name space.  Thus a module which wanted
to guarantee it would have one and only one copy in residence could
declare itself

   <>
   package foo; # preserves current usage
   my $var; # only one copy ever exists no matter how many
# modules load foo

while a relative would do

   <>
   package &foo;
   my $var; # one copy per instance of loading of foo

In either case, main would load it with a simple

   use foo;

and the package has control over what is shared and what is not.  One
could even have mixes of shared and unshared with

   package &foo;
   use  foo_shared;
   my $var = "x";   # per-instance copy set
   $::foo_shared::var = $var;   # cross-instance copy set
   local $::foo_shared::var as $var;# wow!

Yes, I like this.

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

[Steve Simmons]

I really like the idea of constants in perl, but think the RFC should
go a lot further.  C/C++ has solved this problem; we should follow in
their footsteps.  Spinning off from Larrys syntactic comment and Mike
Pastores example, how about some of the following:


A constant struct with constant values:

my %jane : const = (
 Name =>'Jane',
 Age => 30,
 Gender =>  'Female'
 Kids =>2.5
) : const ;

%jane = %janet; # Not allowed
%jane{Kids}++;  # Not allowed
%jane{Husband} = \%bob; # Not allowed


A non-constant struct with fixed members and constant values:

my %jane = (
 Name =>'Jane',
 Age => 30,
 Gender =>  'Female'
 Kids =>2.5
) : const ;

%jane = %janet; # Not allowed
%jane{Kids}++;  # Not allowed
%jane{Husband} = \%bob; # Not allowed
%jane = %janet; # Allowed


A constant struct with unremovable members, extensions allowed to
members, and variable values:

my %jane : const = (
 Name : const =>'Jane',
 Age : const => 30,
 Gender : const =>  'Female'
 Kids : const =>2.5
) ;

%jane = %janet; # Not allowed
%jane{Kids}++;  # Allowed
$jane{Husband} = \%bob; # Allowed
delete $jane{Husband};  # Allowed
delete $jane{Kids}; # Not allowed


A constant struct with a mix of removable and unremovable members
and a mix of constant and variable values:

my %jane : const = (
 Name : const =>'Jane',
 Age : const => 30 : const,
 Gender : const =>  'Female'
 Kids =>2.5
) ;

%jane = %janet; # Not allowed
%jane{Kids}++;  # Allowed
%jane{Age}++;   # Not allowed
$jane{Husband} = \%bob; # Allowed
delete $jane{Husband};  # Allowed
delete $jane{Kids}; # Allowed


It would also be useful to have a mostly constant item that one
or two changes are allowed in with a `var' antonym for `const':

my %jane : const = (
 Name =>'Jane',
 Age => 30 : var,
 Gender =>  'Female'
 Kids =>2.5
) : const ;

%jane = %janet; # Not allowed
%jane{Kids}++;  # Not allowed
%jane{Kids}++;  # Allowed
$jane{Husband} = \%bob; # Not allowed
delete $jane{Husband};  # Not allowed
delete $jane{Kids}; # Not allowed


This could also be used to allow the hash to be extended:

my %jane : const = (
 Name =>'Jane',
 Age => 30 : var,
 Gender =>  'Female'
 Kids =>2.5,
 : var =>
) : const ;

%jane = %janet; # Not allowed
%jane{Age}++;   # Not allowed
%jane{Kids}++;  # Allowed
$jane{Husband} = \%bob; # Allowed
delete $jane{Husband};  # Allowed
delete $jane{Kids}; # Not allowed

The programmer should be able to use `const' and `var' in element
creation and modification as well.  Using the same structure
as in the previous example:

my %jane = (
 Name =>'Jane',
 Age => 30 : var,
 Gender =>  'Female'
 Kids =>2.5,
 : var =>
) : const ;

$jane{Husband} = \%bob; # Allowed
delete $jane{Husband};  # Allowed
$jane{Husband : const} = \%dave;# Allowed
delete $jane{Husband};  # Now not allowed
$jane{Husband : const} = \%jeff : const;# Allowed
delete $jane{Husband};  # Now not allowed
$jane{Husband : const} = \%bill;# Now not allowed

$jane{Religion} = "Catholic" : const;   # Allowed
$jane{Religion} = "Protestant"; # Not allowed
delete $jane{Religion}; # Allowed
$jane{Religion} = "Protestant" : const; # Now allowed
$jane{Religion} = "Catholic";   # Not allowed
delete $jane{Religion}; # Allowed
$jane{Religion : const};# Allowed
delete $jane{Religion}; # Now not allowed
$jane{Religion} = "Protestant"; # Allowed
$jane{Religion} = "Catholic" : const;   # Allowed
$jane{Religion} = "Protestant"; # Now not allowed

The same sort of thought process should be applied to lists, arrays,
references, and objects.  IMHO the RFC should be updated to reflect
all these issues before we can properly consider it.  Sorry to rain
all over your parade, Jeremy.  The core idea is great, but the
implementation section really needs expansion.

And of course, the above only reflects my opinion.

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

[Steve Simmons]

On Thu, Aug 03, 2000 at 11:40:24AM +0900, Simon Cozens wrote:

> On Wed, Aug 02, 2000 at 07:34:36PM -0700, Nathan Wiger wrote:

> > > That Perl should stay Perl

> > Do we need an RFC for this? Seems like this is more of a "guiding
> > concept" that should be intergrated into everything. Just my opinion.

> Then we need to enshrine it. I'll cook something up soon.

This idea is both important and more general.  If we go thru a huge
discussion of, say, multi-line comments and decide *not* to do it,
we don't want to have the whole thing repeated with perl 6.1, 7.0,
etc, etc.  When something reaches RFC stage but is rejected, part of
the process should include archiving the gist of the arguements for 
and against.  IMHO the RFC editor should be responsible for this.

Unify the Exception and Error Message RFCs?

[Steve Simmons]

On Sun, Aug 13, 2000 at 07:35:06PM -0700, Peter Scott wrote:

> At 03:30 PM 8/13/00 -0500, David L. Nicol wrote:

> >Whose RFC deals with this?

> 63, 70, 80, 88 and 96.  There would appear to be a groundswell of interest :-)

Well yes, but they represent three authors with (as best I can tell)
pretty similar views of what needs done.  With advance apologies for
the over-simplification, these RFCs very briefly summarize to:

   63 - Error handling syntax to be based on fatal.pm, a Java-ish
try/catch (Peter Scott).
   70 - Allow full error handling via exception-based errors based on
expansion of and addition to fatal.pm (Bennett Todd)
   80 - Builtins should permit try/throw/catch as per Java/fatalpm
style (Peter Scott).
   88 - Propopses error handling via mechanisms of try, throw, except,
etc. (Tony Olekshy).
   96 - Proposes establishing a base class for exception objects,
which could work with either of the two groups above and
might subsume RFC3 as well (Tony Olekshy)

I'd like to see these throw into a post (possibly including RFC3 (Brust)
as well), and pulled out a single proposal with

  o  a unified proposal for a general try/throw/catch error handling
 mechanism for perl
  o  a recommended object-based implementation of it
  o  recommended areas where it should be applied in the perl core
  o  a mechanism allowing programmers to take over error message
 production for the above group of items

and a separate proposal for

  o  a mechanism allowing programmers to take over error message
 production for other types

I'm assuming that not all errors would move to the object or try/catch
sort of arrangement; there are lots of times that return values or
unrecoverable errors are all you really need.  For the last, one should
use `eval' if you really need to catch them; but an ability to override
the error message may well be sufficient in most cases.  And should the
first proposal fail, the second becomes even more critical.

IMHO trading six RFCs for two will greatly improve the chance of passing.

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

[Steve Simmons]

On Sat, Aug 12, 2000 at 06:18:08AM +1000, Damian Conway wrote:

> Please, please, please, PLEASE, let us not replicate the debacle that is
> C++'s const modifier!

It doesn't feel like a debacle to me, it feels like it put the control
in the programmers hands.  Yes, the syntax is often unweildy -- but IMHO
that's because when one marries the idea of constants to complex data
structures and references, the world becomes an unweildy place.

On the other hand, many of the uses of constants are better-satisfied
by having hidden or inaccessible members.  If constants were limited
to `core' perl data types (scalars, lists, arrays and hashes) and
*completely* freezing the data element, that'd be enough for me.  I lust
to be able to do things like

if ( $HOME =~ /indiana/ ) {
local $::PI : const = 3; do_trig();
} else {
local $::PI : const = 3.14159...; do_trig();
}

(I'm from Indiana and claim right to use that joke without being
insulting).  Constants are good, and I'm damned tired of fixing code like

if ( $PI = 3  ) {
# We're not in Kansas any more, Toto.
}

Constants have a place, and belong in perl.

Now, one may argue that my suggestion was too flexible or too broad.
But the initial proposal left an awful lot of gray areas.  If my proposal
is felt to be too unweildy, I don't have a problem with that.  Let's
either

  o  decide where to draw the line, define it cleanly, and say
 that more complex usage is better done with objects; or
  o  permit both complex constants and object-based manipulations
 on the practice that TMTOWTDI.

I lean towards the latter (complex constants) myself, but wouldn't
go off and storm the barricades to get it.  On the other hand, I
*would* campaign strongly for constant scalars, lists, arrays, hashes
and refs.  If the only way to get them meant `completely constant',
ie, no addition or removal or members, no re-orderings, etc, that's
fine -- composition of complex constants with complex vars would let
one do most of what was suggested in my longer posting, and I'd be
happy to say the odder features should be done via object methods.

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

[Steve Fink]

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

It's already withered away some in perl5. Functions can return lists or
scalars with no distinguishing marks, which was harmless until the
advent of lvalue subs. Now you have $object->listmember = (1,2,3);
$object->scalarmember = 42;. Anyone up for an RFC on allowing a leading
@, $, or (?) % to set the context of a function call? ;-) (Maybe there's
one already, I haven't been keeping track.)

I would very much hate to see the prefixes go away or merge into a
single one, but I'm not so sure I agree with Russ. I've had to teach
lots of beginners that even though $x refers to scalar x, $x{...} refers
to %x, but don't think of it that way because the $ is saying what value
you're getting back, not which variable you're using, unless you're
calling a function, or...

I'll just say I wouldn't mind having a stricture forbidding $x and %x in
the same package. I've fairly frequently used code like the above, but I
don't really like that code in the first place because the only purpose
for the $args and @args is as temporaries. I like the way mjd describes
it:  this is "synthetic" code. If you really did have distinct
long-lived variables with the same name, then I bet it would be
confusing. Either you're maintaining some consistency invariant between
them, and you have to do that manually, or they're unrelated and they'll
collide in readers' brains.

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

[Steve Simmons]

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

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

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

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

Re: RFC 114 (v1) Perl resource configuration

[Steve Simmons]

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

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

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

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

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

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

[Steve Fink]

Ted Ashton wrote:
> 
> Thus it was written in the epistle of Russ Allbery,
> >
> > This falls firmly in the category of things that are powerful for
> > experienced users of the language but may be somewhat difficult to learn.
> > I don't think Perl has being easy to learn as it's primary goal, nor
> > should it.
> 
> Russ,
>   Would mind saying that again?  It's been said much too seldom around here
> and it's really refreshing to heard it put into works.
> 
>   Being easy to learn is not Perl's main goal.
> 
> That goes in with
> 
>   Being a perfect CS language is not Perl's main goal.
> 
> I don't know for sure what Perl's main goal is, but it's definitely significant
> to Perl to make life easier and it has done that.  The prefixes and context
> sensitivity make Perl easier to read and to write and the fact that it makes
> better use of the entire printable set is an asset and not otherwise :-).

Bah. I will claim neither that being easy to learn is Perl's main goal,
nor that I know what Perl's main goal is, but I have enough of an
intuition (or did I misspell "opinion"?) to assert that ease of learning
is a far more important _benchmark_ than, say, orthogonality or
buzzword-compliance or computer sciency coolness.

My standpoint is that Perl strives to be something that fits naturally
in your head and allows you to write code that pertains directly to your
problem, as opposed to spending a lot of time building abstractions and
twiddling bits and types and worrying about the "cleanliness" of your
code. "Fitting naturally into your head" means borrowing from natural
languages, creating shortcuts for common problems, and using a healthy
dose of DWIMmery. But the most direct way to measure how well the
language slides into people's heads is by seeing how hard it is for them
to get the hang of it. People shouldn't have to "Think Different" to get
their jobs done, they should be able to write their existing thoughts
down as code. Yes, they'll need to learn the language first, but it
shouldn't require too much real estate in their heads. I think we should
be arguing over "conceptual bloat" at least as strenuously as code
bloat.

Whew. That went a long way away from whether to allow %x and $x in the
same program. And I don't even want to argue that too strongly, because
use strict 'vars' provides a pretty good electroshock teaching method
for my $x = { a => 10, b => 20 }; print $x{b}. I just wouldn't mind
being able to tell the compiler that I mean $x when I say x independent
of the dollar signs and {'s surrounding it, and in turn it could tell me
"hey, you're trying to use $x as a hash, stupid!" instead of "I haven't
heard of that %x you're talking about". Or worse, the actual message
"Global symbol "%x" requires explicit package". What %x? I didn't say
%x. And how do I give it an explicit package?

It's true that I personally don't make that mistake any more. But I did,
for a long time, and so did (or does) every other perl programmer I
know.

And I still can't keep $$x{phbbtt} straight in my head.

Re: Ideas that need RFCs?

[Steve Fink]

> On Thu, Aug 17, 2000 at 01:07:30PM -0400, Stephen P. Potter wrote:
> > * Replace C, C, and C with equivalent regularized
> >   functions that take mulitple arguments instead of using specialized
> >   syntax.  It would be best if the names could be more "complete", like
> >   match(), translate(), and substitute() (although translate and substitute
> >   are rather long).

I was thinking of this too. Well, not quite -- I certainly don't want m,
tr, or s to go away (or /regex/ either.) But the =~ bothers me. How
about disallowing m{...} and using m{expr}/.../?

foreach $line (@foo) {
m{$line}/pattern/;
}

That seems better than $line =~ ... but not by much. How about
disallowing m(...) and using

m($line, /pattern/) ? (similar to split)

Hm. Tough to parse. Where do you look for the opening delimiter? More
similar to split:

m(/pattern/, $line)

I like that one. As long as split,m,tr,s can all handle non-/ delimiters
(as split currently cannot). And as long as I can still say

while(<>) { print "found it!" if /needle/ }

when I don't need to specify the variable.

Re: Ideas that need RFCs?

[Steve Fink]

(I'm assuming you intended this for perl6-language)

"Myers, Dirk" wrote:
> 
> > I certainly don't want m,
> > tr, or s to go away (or /regex/ either.) But the =~ bothers me. How
> > about disallowing m{...} and using m{expr}/.../?
> 
> How about this, for the really compact way to do it:
> 
> $line/pattern/ ;

What's the difference between matching $number/17/ogs;, and dividing
$number by 17, and the result by ogs()?

> or make the patterns themselves work like subs in this way:
> 
> /pattern/ ($line) ;
> 
> s/pattern/replacement/ ($line) ;
> 
> (In this case, the presence of the $line disambiguates the /foo/ ; case, so
> these could also work as:
> /pattern/ $line ;
> s/pattern/replacement/ $line ;
> )

Now that's cool! I guess /pattern/ + 3 is a little ambiguous -- is it
adding a 3, or applying to +3? Anything worse than that?

It's a little strange in that the default argument is $_ instead of the
empty list, but that doesn't seem so bad.

Would it make sense to then make \&m/pattern/ mean something akin to
qr/pattern/? If so, then we'd probably want \&s, which means that in
\&s/pattern/repl$1$acement/ the $1 and the $acement are bound at
different times. Hmm, too much trouble?

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

[Steve Fink]

Ted Ashton wrote:
> 
> >   But the most direct way to measure how well the
> > language slides into people's heads is by seeing how hard it is for them
> > to get the hang of it.
> 
> Nope.  I've yet to be convinced that "fits in your head" is the same as
> "went in easily".  Hang it all, English is hard to get at first--just ask my
> seven-month-old (and my 4-year-old).  But once in there, it's so blooming
> useful.

True, and an important thing to keep in mind. But there are many
different levels of mastery of English. Going up those levels enables
one to express things more easily and/or precisely. I don't want Perl to
be as difficult to learn as English or any other natural language. A
person has a certain budget of time and effort to expend for a given
payoff, and Perl just isn't going to command the resources devoted to
one's native language. So the learning curve, from beginning to end, is
critically important in language design -- people will distribute
themselves along the learning curve, and you'd like to give them as much
benefit as possible for their trouble. It's as precise a measure of
"success" as I can come up with.

Which has next to nothing to do with any particular issue. And it's too
hard to argue when we agree.

> It seems to me that we're arguing about multiple things here.  We seem to all,
> grudgingly at least, agree that $a, @a and %a when they are simple straight
> forward things are useful.  It appears that the big problems come in two
> places.  First, there's some confusion about the $,@,%.  Programmers coming
> from elsewhere think that they are part of the variable name and just specify
> what type of variable it is, as in other languages.  They need to be taught
> rather that those things are context.  That's a learning-curve issue and, I
> contend, worth the learning.

If I asked you which variable $x[4] is accessing, I bet you'd say @x.
Which is one source of the confusion -- in one case, you use $@% to name
the variable, and in the other, to provide context. Which leads to the
other source -- $x[4] leaves unstated which variable is being
manipulated; you have to infer it from the manipulation. And that's a
set of rules that must be memorized. Which isn't that hard, but it's why
I'd like to put a ladder up that little cliff on the learning curve by
asking the compiler to tell you what you're screwing up instead of a
seemingly unrelated message.

> The other big problem is that crazy @{} and $a->[] stuff and while I don't have
> any particular solution, I agree that that is confusing and ugly.  Even once I
> got my brain around what it all means, it still looks downright ugly as far as
> I'm concerned.  Anyone have solutions to that?

My proposal would be what I implemented for perl5 a while back (Sarathy
didn't dislike it, but wasn't convinced enough to put it in): all
dereferencing can be done with ->.

$x->@ is the same as @$x
$x->% is the same as %$x
$x->@[1,2,3] is the same as @$x[1,2,3]
$x->@{a,b,c} is the same as @$x{a,b,c}
f()->@ is the same as @{ f() }

more problematically,

$x->$ is the same as $$x

($object->$methodname causes trouble, eg $x->$s/ Is that division or
regex substitution?)

But it's not a big step forward.

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

[Steve Fink]

Karl Glazebrook wrote:
> 
> Ariel Scolnicov wrote:
> >
> > Karl Glazebrook <[EMAIL PROTECTED]> writes:
> >
> > [...]
> >
> > > o Why do I think perl has too much line noise? Because of code like this:
> > >
> > >   @{$x->{$$fred{Blah}}}[1..3]
> >
> > This is indeed horrible.  However, I fail to see how cutting out the
> > "line noise" would make it easier to decipher (I can, however, see how
> > splitting it into several expressions, possibly after signing travel
> > papers for the programmer, would improve it immeasurably).  Could you
> > post the proposed "new code", along with explanations of the proposed
> > syntax?

I propose EXPR->@ for @{EXPR}.

So that would be $x{ $fred->{Blah} }->@[1..3]

Note that $$fred{Blah} can currently be written as $fred->{Blah}, and
look a lot better IMHO.

Another example (since this is what I thought the above did at first):

@{$x->{${$fred{Blah[1..3]

(with spaces)

@{ $x->{ ${$fred{Blah}} } }[1..3]

becomes

$x->{ $fred{Blah}->$ }->@[1..3]

(without spaces)

$x->{$fred{Blah}->$}->@[1..3]

It's still not pretty, but at least you can read it left to right.

"Take x, dereference and look up something in its referenced hash. What
something? Well, lookup Blah in the %fred hash and dereference it to get
a scalar. Now take the result of that %$x lookup and grab elements 1..3
out of the array it references."

Re: Ideas that need RFCs?

[Steve Fink]

Nathan Wiger wrote:
> 
> We're getting deluged with RFC's and emails. We should start thinking
> "will this RFC or idea *add value* to Perl 6?". If not, and it just
> makes something work differently, it _might_ not be worth an RFC.

I disagree completely. For one thing, there's no such thing as Perl6. It
doesn't exist. What does exist is Perl5, and the primary motivation here
should be to clean up and streamline Perl5. Mainly, removing the special
cases, bad syntax, and backwards-compatibility swamps that make it so
difficult to continue improving it.

We are NOT here to construct a radically better language. We are here to
design the underpinnings of one. If you have an idea that will "add
value" to Perl6 but can just as well be done after the groundwork for
the language has been laid out, then please do not write up an RFC on
it. It'll just distract. If you have an idea that will help unify
disparate mechanisms, or one that will require syntactic or
infrastructural changes, then please DO submit an RFC. Otherwise, Perl6
from its inception will prevent your idea from being realized. It's
always too late for backwards compatibility breakage with an existing
language, and there's a limited time window before Perl6 exists.

Removing =~ and making m// behave like a sub qualifies -- an
incompatible change could easily prevent this from happening. Even
moreso for \&m-abc-, not that I'm in love with that idea. This would
even free up =~, though it's so ugly I'm not sure why anyone would want
it. Maybe let it be a user-defined equality test, to take inspiration
from your comment about approximate equality? Dunno, but killing off two
unintuitive punctuation characters seems worthwhile by itself.

Re: Ideas that need RFCs?

[Steve Fink]

Decklin Foster wrote:
> 
> [replying from here since this is the only way I received it]
> 
> > "Myers, Dirk" wrote:
> > >
> > > $line/pattern/ ;
> >
> > > /pattern/ ($line) ;
> 
> I don't think these should be changed. Here's how I tend to pronouce
> things:
> 
>   $x = 'foo';   # "x gets foo"
>   /bar/;# "match on bar"
>   $x =~ /baz/;  # "x gets matched on baz"
> 
> C<=~> is a special case of "getting" something, where the something in
> question is an action instead of an expression. This symmetry should
> be kept.

Bleckth! You want to preserve it because of a coincidental double
meaning of the English verb "to get"?! $x is not "getting" anything in
that example. By that argument, pretty much every operator should have
an equals sign in it. @$x is "x gets dereferenced". foo() is "foo gets
called".

=~ meaning approximate equality makes some sense to me, but this
doesn't.

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

[Steve Fink]

Damien Neil wrote:
> 
> On Thu, Aug 17, 2000 at 03:10:44PM -0700, Steve Fink wrote:
> > My proposal would be what I implemented for perl5 a while back (Sarathy
> > didn't dislike it, but wasn't convinced enough to put it in): all
> > dereferencing can be done with ->.
> >
> > $x->@ is the same as @$x
> > $x->% is the same as %$x
> > $x->@[1,2,3] is the same as @$x[1,2,3]
> > $x->@{a,b,c} is the same as @$x{a,b,c}
> > f()->@ is the same as @{ f() }
> 
> The big objection to this is that this destroys one of the great
> advantages of the current punctuation: the ability to tell the
> context of an expression by examining the first character.
> 
>   @{$foo{@bar{1..20}}
> 
> The above is complex and filled with line noise, but one glance tells
> me that the result is a list.  If you look at your third and fourth
> examples above, the expression context is buried in the middle.  And
> you haven't removed a single character of line noise, either -- indeed,
> you've added two more characters.

I think of -> as a single digraph, so my count is a little better. :-)
But really, providing context is the least of what @{...} does. It's
actually performing a dereferencing _action_. And ->@ visually describes
that better, to my eyes at least. As for the return value, I'd prefer
not to rely on that when I have to examine the entire expression to see
if it really holds anyway -- which I must, because of $x->f().

(I think you meant "return value" where you said "context", since you
don't seem to be talking about f() getting called in list context in
@{f}. Unless you're using a different meaning of the word that perl's
expression contexts.)

The main cleanup this provides is the overloading of {} with both hash
lookup and @{EXPR} dereferencing, which tend to be used in close
proximity. Or at least, it no longer requires it -- I think @{EXPR}
still works better in some situations, like @{ foo() || bar() }.

For completeness, I should mention someone else's suggestion of @<-$x
and @[1,2,3]<-$x->f(). It preserves the
first-character-gives-return-type-in-most-cases property, at the expense
of being (IMHO) really bizarre-looking. I guess it makes for good ASCII
art, though: @<-$x->Q

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

[Steve Fink]

Ted Ashton wrote:
> 
> >   all
> > dereferencing can be done with ->.
> 
> Is that "can be done with" or "must be done with"?
> 
> Either way, I like the idea.  To me it reads more smoothly, and as I seldom
> dare to use the double-punctuation form ($$ and so on) and use instead the
> ${$} form, it would be an equal number of characters and fewer curlies (which,
> I think, is a win).

Can be done with. @{ foo() || bar() } seems preferable to, say,
[scalar(foo() || bar())]->[0]->@. :-)

Re: RFCs (Re: Ideas that need RFCs?)

[Steve Fink]

Nathan Torkington wrote:
> 
> Steve Fink writes:
> > We are NOT here to construct a radically better language. We are here to
> > design the underpinnings of one.
> 
> Perhaps.  And by "perhaps", I mean "no".
> 
> We're here to say what we'd like to see in the next version of Perl.
> These can be big things (currying) or small (hashes returned by
> functions instead of long lists).  We're giving input to Larry, who
> will then design the language.  We are just telling Larry what we
> would like, and why (i.e., which itch it would scratch).

And both those examples apply to the underpinnings. Ok, maybe I have an
unusually broad definition of the word "underpinnings". Think "anything
that can't be done with a pure perl module".

> > If you have an idea that will "add value" to Perl6 but can just as
> > well be done after the groundwork for the language has been laid
> > out, then please do not write up an RFC on it. It'll just distract.
> 
> I completely disagree.  If you want something in Perl, now's the time
> to ask.  We're going to have to nail down the language so people can
> begin writing grammars, data structures, regex engines, and so on.
> There's no such thing as a small change if that change comes *after*
> people have begun coding.  That's called "feature creep", as I'm sure
> you know.

Which is why I wrote the rest of that paragraph, saying that people
should write RFCs for anything that requires, or might require, changes
in the Perl6 language. My message was *encouraging* RFCs; I was
disagreeing with a message discouraging them. You happened to quote the
two sentences where I was agreeing that not all RFCs need to be brought
up just now, if the change they propose would still be possible after
the Perl6 core was set in stone (namely, you could just write a module
to do that using "existing" primitives at no significant loss in
performance or clarity. Which usually implies that you could do it today
in Perl5, but nobody's bothered to.)

> So I want to encourage people to submit RFCs.  Yes, there are a lot of
> them.  That's Larry's problem, not ours.  It's one problem he's glad
> to have, I'm sure.

I agree. At least, to the extent possible without having Larry's brain
sitting in front of me in a jar, and I'm pretty sure this one is
somebody else's.

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

[Steve Fink]

"Casey R. Tweten" wrote:
> 
> This looks counter intuitive, my brain says to dereference the reference at the
> begining, just like you make the reference, in other words, keep it all the
> same:
> 
> $hashref->{key}->@ # Deref
> $hashref->{key}->$ # Deref
> $hashref->{key}->% # Deref
> $hashref->{key}->* # Deref
> $hashref->{key}->& # Deref
> $hashref->{key}->\ # Reference

I think of dereferencing something as an action applied to something; it
requires only the thing that you're dereferencing. I do not think of
referencing as an action, because it's really operating on the
environment in which the thing you're referencing exists. Trying to make
it operate only on its argument would be like trying to take the address
of a value in a register. So I don't see a conflict.

As for $x->\ specifically, I'm also thinking of -> as a dereferencing
operator, not a labelling operator, so I would find $x->\ rather bizarre
but I guess it should be a no-op, because you're referencing the result
of dereferencing $x. (In that order, so it would be an error if $x were
not a reference to begin with.)

Hm. I never considered that possibility before. I think of the @ in ->@
as specifying the type of dereferencing to perform, or equivalently, the
"context" in which to evaluate the result of (generic) -> dereferencing.
I guess you're thinking of @ as the dereferencing operator, and -> is
just separating things out? So it's like our legs, in that they're two
bony things that keep our torsos away from the ground. I guess that way
of thinking is more in line with the usage of @ in @$x.

Well, then, what do you think of promoting -> from a pretty prop to an
actual dereferencing operator? :-)

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

[Steve Fink]

Nathan Torkington wrote:
> 
> Don't forget that the rationale behind the infix dereferencing is
> this:
> 
>   @variable_name
>   @{variable_name}
>   @$scalar_containing_variable_name @$scalar_containing_value_ref
>   @{ code evaluating to variable name } @{ code giving value ref }

True. Would anyone mourn @$scalar_containing_variable_name if it died?
I've never used it, and I'm rather glad I haven't. Perl5's -w doesn't
notice $x="var"; print @$x either -- it'll complain if you mention @var
once.

Or leave it, but make ->@ always dereference an array ref. If you ask
for explicit dereferencing with ->, you always get it. And you get a
nice understandable warning otherwise, instead of the undefined value of
a nonexistent variable.

Damn, learn something new every day... perl really is incestuous with
its symbol table, isn't it?

Re: Extended Regexs

[Steve Fink]

Robert Mathews wrote:
> 
> > James Mastros wrote:
> > > [/f for fast DFA regexen]
> Jeremy Howard wrote:
> > The choice of algorithms is a great idea, but why do we need a modifier?
> > Isn't it a pretty straightforward set of rules that allow us to decide if a
> > DFA matcher will work? It would be a lot nicer if Perl could just notice
> > that the regex could be handled by its DFA matcher, all by itself.
> 
> That would be nice, too, but a modifier would let you ensure that the
> DFA matcher was being used.  You wouldn't have to guess whether a
> particular construct was DFA-able or not.

I'd rather have it figure it out by itself. It seems strange to be
telling the regex engine to be using a specific optimization. Though a
more general mechanism for requesting (forcing? suggesting?)
optimizations might make sense.

There would still be a use of a /f like flag, though -- treat all (...)
like (?:...). That would make the regex more likely to be DFA-able, and
is often what I want but I don't want to clutter up my regex with those
nasty ?:'s everywhere.

Even better would be to infer this from the lack of list assignment or
use of $1 etc. I'd be willing to accept having to explicitly use a $1
somewhere if I wanted $n to be accessible via eval"". Or even easier,
I'd forgo using eval"" if I wanted the optimization. This would require
$n to be lexical, which seems like a good thing anyway.

Re: RFC 23 (v3) Higher order functions

[Steve Fink]

Damian Conway wrote:
> 
> It was simply attempting to explain why I choose to ignore what are (to
> me, at least) trivial implementation issues, well documented in the
> compiler literature. I choose to ignore them because I *have* to ignore
> them or my brain is going to melt.

So perhaps you should ask people to contribute implementation notes
sections to your RFCs rather than entire RFCs? And no sense in requiring
that for the initial version, though a solicitation in the text of the
RFC itself might hasten their appearance.

And if the worst happens, I've found that those rubber test tube
stoppers fit quite snugly in the ears for cases of severe brain
meltdown.

Re: RFCs (Re: Ideas that need RFCs?)

[Steve Fink]

Jeremy Howard wrote:
> 
> > Steve Fink writes:
> > > And both those examples apply to the underpinnings. Ok, maybe I have an
> > > unusually broad definition of the word "underpinnings". Think "anything
> > > that can't be done with a pure perl module".
> >
> Say "anything that can't be done *fast*enough* with a pure perl module" and
> you're closer.

Right. What he said.

Or maybe add "cleanly enough" too. And "easily enough". Or maybe just
"anything that wouldn't be better done as a pure perl module." After
all, we're shooting for better than "easy things possible, hard things
barely possible."

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

[Steve Fink]

(thread intentionally broken)

Nathan Torkington wrote:
> 
> Steve Fink writes:
> > True. Would anyone mourn @$scalar_containing_variable_name if it died?
> > I've never used it, and I'm rather glad I haven't. Perl5's -w doesn't
> > notice $x="var"; print @$x either -- it'll complain if you mention @var
> > once.
> 
> These are symbolic references.  You can forbid them with the strict
> pragma.  Yes, I'd miss them.  So would the Exporter.
> 
> > Damn, learn something new every day... perl really is incestuous with
> > its symbol table, isn't it?
> 
> Yes.  That's what makes it useful.

Ouch. I need to know more. I'm looking at what a type inference engine
for perl would look like, and these symbolic references would incur some
massive pollution. Clearly, the inferencer will at least depend on
people using strict 'refs' to prevent every $$x="bleck" from trashing
the type of every scalar variable in the program. So can someone explain
to me what the actual uses are, so I can dream up some form of manual
annotation that will limit the scope of their effects? (If the
functionality of Exporter becomes more 'core', its usage should no
longer matter.)

My code for doing what I thought Exporter did is:

sub import {
my $p = caller(1);
*{"${p}::E"} = \%{"${p}::E"};
}

but that doesn't run afoul of use strict 'refs'. Can you point me to the
passage in Exporter.pm that uses this?

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

[Steve Fink]

Thanks! Ok, from a type inferencing perspective...

Nathan Torkington wrote:
> 
> Symbolic references are used for dynamic function generation:
>foreach my $func (qw(red green blue)) {
>  *$func = sub { "@_" }
>}

Probably have to punt on checking user code in a main routine that does
this. But if it's in a module, the inferencer should just get fired up
after all use's and other BEGIN's have been processed so the names and
code for all of those are known.

If you want user code to still get some inference, then you can have no
strict 'refs' everywhere but right here and have a pragma
assume_sub_in_source_is_never_overridden, so that $x = unknown_sub()
pollutes all package vars and all lexical vars captured anywhere by
anything. Though that's tough to verify. But subs would be okay. And
eval"", as usual, would kill pretty much everything.

> Also lazy function generation (similar thing but from within an
> AUTOLOAD).

Same, except known subs will never be overridden.

> Class::Struct does it to mechanically create the subroutines for a
> class.

Same.

> Any object code that gets a class name (package) as an argument and
> uses it to inspect variables in the package does it.

"Inspect", as in, read-only access? Then it's not bad. Does accessing
$p=<>;$x=${"${p}::foo"} activate $foo's tied FETCH? I suppose so. Then
it's bad.

> (off the top of my head)

That's a nasty set of things that I was planning on looking at later to
see what can be salvaged (probably not much), but I was wondering more
about uses of $$x as a symbolic ref access as opposed to scalar
dereferencing. General symbol table manipulation is probably just going
to make the inferencer assume that any function call can rewrite all
other subroutines and piss on all visible variables, file descriptors,
etc., but scalar and array symbol table manipulation may be more
survivable.

I guess it doesn't matter that much, you just don't get any type
inferencing if you don't use strict 'refs' or you do use runtime eval""
or require. But maybe

my $Bob : might_be_accessed_symbolically

would be convenient enough to enable the type inferencer for more
programs.

Filtering rules

[Steve Fink]

(Off-topic for this list, but I'm not sure where else to send it)

Could we have a discussion somewhere of useful filtering rules for all
these perl6 lists? Specifically, I'm looking to steal other people's
.procmailrc snippets. I imagine that a lot of people have written their
own, and everything I do in that @#$!! config language breaks the first
four times I try it (partly because my mail directory is NFS mounted in
a place where NFS locks permanently hang any process attempting to use
them).

Ask posted a very nice rule to perl6-announce:

=for procmail

I added another header to the perl6-all mails. X-Mailing-List-Name
will contain the original list name, san -help and whatnot.

So the recommended procmail filter rule would now be:

:0:
* ^Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
* ^X-Mailing-List-Name: \/(.*)
perl/$MATCH

or something like that.


Enjoy,

 - ask

=cut

(perhaps there is a discussion on perl6-all, which I do not subscribe
to?)

Just for perl6-language, I use:

=for procmail

:0:/tmp/sfink.locks/language.lock
* ^[EMAIL PROTECTED]
{
SUBJECT=`formail -xSubject:`

:0 c
* ^TOsfink
| formail -f -i "Subject: (COPY) $SUBJECT" >>$HOME/mbox

:0
perl6-language
}

=cut

That's so if anyone is replying to a message I posted deep in some
subthread, I don't miss it (because I *always* read the group threaded;
the traffic would overwhelm me otherwise.) But I probably have the locks
backwards or something.

I think I may have to subscribe to the firehose (perl6-all) and use
something closer to Ask's filter, though.

Can someone tell me how to fetch a digest of an existing subgroup and
split it into separate messages? I know, there are examples that do
things like this, but I'm hoping to be lazy and just steal someone
else's working rule.

Thanks!

Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types

[Steve Fink]

Tom Christiansen wrote:
> 
> I happen to strongly appreciate that the invocant in
> 
> $a->blah
> 
> can be of either sort; that is:
> 
> $a = "MyClass";
> $a->blah;
> 
> or
> 
> $a = MyClass->generate();
> $a->blah();
> 
> In fact, who knows what generate() returned?  It could have
> been a class name.
> 
> There is beauty and power in this transparency, which you would see
> obliterated.  I don't understand that.

Ooh, somebody else to bug about this! And the best example of where this
is really useful that I've seen.

I want to be able to get rid of STRING-> dereferencing with a pragma,
for type inferencing purposes. Specifically, $x = $a->blah() requires
"value inference" on $a, which is impossible in general though perhaps
adding all known class names as separate types to the type system will
make it possible some of the time. So I'm trying to collect examples of
where symbolic dereferencing is useful in order to figure out how best
to fence it off and keep it away from those poor sheep.

MyClass->f() is not a problem, of course. How often is nonref $a->f()
useful, and when it is, would 

Cisa('MyClass') including string values of $a)>

ignoring the syntax, be acceptable if you want type-related warnings and
optimizations? (It's still not as good as requiring $a to be a
reference, because concrete type inference will produce the set of
actual subtypes that $a might hold, which may be able to eliminate
virtual dispatch unlike my MyClass $a or somesuch that allows any
subclass. But it's far better than allowing any subroutine named f to be
called, especially with AUTOLOAD lurking.)

And what other uses of symbolic references could you not live without in
a large application where you care about type warnings and type-based
optimizations? (I don't think anyone will want types in one-liners.)

Thanks!

Re: Do we really need eq?

[Steve Simmons]

I'd like to see eq and it's brethen retained, as dammit there are times
I want to know (-w) if numbers are turning up when there should be
words and vice-versa.  However, spinning off of something Randal wrote:

> Yes, but what about:
> 
> $a = '3.14'; # from reading a file
> $b = '3.1400'; # from user input
> 
> if ($a == $b) { ... } # should this be string or number comparison?

Since we have distinct comparison operators for strings and numbers, and
since we have explict casting for those who wish it, IMHO one can do

if ( int( $a ) == int( $b ) ) 

to force int (or float) compares, and

if ( "$a" eq "$b" )

to force string compares, 

IMHO the code

$a = '3.14'; # from reading a file
$b = '3.1400'; # from user input
if ($a == $b) { ... }

should see the two args being tested in numeric context, do the numeric
casting, get floats, and do a floating compare.  Durned if I know what it
does now.

HERE construct

[Steve Simmons]

General comment on all the discussion of HERE docs.

When HERE docs cause you a problem, don't use 'em.  There is little win
if any over

  print << HERE;
  Dear Sir:

 You owe me bucks.  Pay up.

  Me.
  HERE

and

$msg =
'Dear Sir:

You owe me bucks.  Pay up.

Me.
';

In all the straining at gnats over whitespace, filtering, etc, I have yet
to see a single proposal that isn't accomplished by just using variables
and manipulating them appropriately.  And it avoids all the problems with
whitespace on the HERE word.

Re: RFC 143 (v1) Case ignoring eq and cmp operators

[Steve Simmons]

On Thu, Aug 24, 2000 at 03:40:00PM -, Perl6 RFC Librarian wrote:
> This and other RFCs are available on the web at
>   http://dev.perl.org/rfc/
> 
> =head1 TITLE
> 
> Case ignoring eq and cmp operators

IMHO this problem is better solved by using =~ and its brethren,
which already allow you to do the right thing for a far wider set
of cases than just this one.

Re: Multiple for loop variables

[Steve Simmons]

On Mon, Aug 28, 2000 at 04:10:01PM -0400, Eric Roode wrote:
> Peter Scott wrote:
> >Graham Barr once allowed as how he thought it would be neat if you could say
> >
> > for my($x, $y, $z) (@list) { ... }

I too am pushing for this feature, to the point where I'm considering
an rfc on the topic.

> ObLanguageMinimalist:
> 
> Um. Is this so frequently-used that the above syntax is preferable to:
> 
> while ( ($x, $y, $z) = splice (@list, 0, 3) )   {...}
> 
> ? (notwithstanding the destructive nature of splice)

I contend that being able to say

   foreach ( $height, $width, $depth ) ( @dimensions ) { ...  }

is considerably more intuitive (reader-friendly, writer-friendly)
and considerably more efficient than the `while' equivelent.  It
also dovetails very nicely with RFC120 on index vars.

Allowing list assigns in the loop also gives you other nice
terse perlisms like:

   my @dim = ( undef, undef, undef );
   foreach ( @dim ) ( @dimensions ) { &func( \@dim ) }

and 

   my @dim1 = ( undef, undef, undef );
   my @dim2 = ( undef, undef, undef );
   foreach ( @dim1, @dim2 ) ( @dimensions ) { &compare( \@dim1, \@dim2 ) }

Re: RFC 110 (v3) counting matches

[Steve Fink]

[redirected to perl6-language]

Tom Christiansen wrote:
> 
> Note the difference between
> 
> my $var = func();
> 
> and
> 
> my($var) = func();
> 
> Those are completely different in that they call func() in scalar
> and list contexts.  Why?  Because of hte presence or absence of (),
> of course.  If they can't learn that adding () to the LHS of an
> assignment makes it list context, then they will be forever miserable.
> 
> Perl does context.  Perl does *IMPLICIT* context.  Cope.

What bothers me is that () is used both for list context and grouping,
so:

% perl -le 'sub w { print wantarray ? "list" : "scalar" }; ($y=$x) = w'
list

and this doesn't work:

% perl -le 'sub w { print wantarray ? "list" : "scalar" }; scalar($y=$x)
=
w' 
Can't modify scalar in scalar assignment at -e line 1, at EOF

(Which isn't that big of a deal, since you can say ($y=$x)=scalar(w).)

I don't have perl5.6, so I'm not sure what context sub f : lvalue;
(f=$x)=1 would call f() in. List, I'd guess. But those parens do seem to
be annoyingly overloaded (yes, I have run into this in actual code.) I
wonder if it would be a good idea to make another way of grouping that
only did grouping and not provide list context. Or to be more extreme,
if () should be changed to do one or the other. The proposed list()
would be much too verbose for such a common task, though. And nobody
wants to lose either behavior of () anyway. (I hope.)

How about making {BLOCK} lvaluable by default? Then it would be
{$x=$y}=w. But that seems dangerously close to {}'s other overloaded
meaning of anonymous hash ref construction. Or is it?

Re: RFC 175 (v1) Add C keyword to force list context (like C)

[Steve Fink]

> for reality here.  That should be written more like:
> 
> 1 while ;  $burp = $.;
> 
> or even:
> 
> for ($burp = 0; my $line = ; $burp++) {}

I'd go for

my $burp = 0; $burp++ while ;

> This proposal should be dropped.

I read your message and agree. Not that I liked the idea that much even
before considering the ramifications. But do you agree that even
seasoned perlers have trouble anticipating how a list/array is going to
be converted to a scalar?

I'd vote for no C operator, but for adding a count operator and a
last element operator. I suggest ()= for the first and C for the
second. I wouldn't mind if the first were spelled C, either. Tom,
does this make sense, or am I confusing "lists" with "the comma operator
in parentheses" again?

And would we want a C to make shift/first, pop/peek?

> One should eschew the temptation to write
> 
> () = ; $burp = $.;
> 
> for the memory concerns given above.

I'd also vote for $burp = () =  to be recognized by the optimizer,
just to encourage *all* counting to be done via ()=. It makes assigning
 to () in scalar context a special case, but only to the optimizer,
and that's what an optimizer is there for -- optimizing special cases.
Or it could be extended to assigning  to a finite-sized list, I
guess? Ack! Okay, I admit it, lvaluable list assignments make my head
hurt.

Quantum computing

[Steve Fink]

Can't quite run perl yet.

http://www.tomshardware.com/cpu/00q3/000901/index.html

Re: $a in @b

[Steve Fink]

Damian Conway wrote:
> 
>> > I would propose that the C operation should short-circuit if the
>> > block throws an exception, with the value of the expection determining
>> > whether the final invocation of the block should accept the element it
>> > was filtering:
>>
>> Otherwise nice but until now die() has been a serious thing, now it's
>> being downgraded to "oh, well, never mind (the rest)" status...
> 
> No. C has for a long time now been the exception throwing mechanism
> as well. Nowadays C is only "serious" if you're too lazy to catch the
> exceptions it throws.
> 
> This proposal just suggests that C, C, etc. should catch
> exceptions emanating from their control BLOCKs and act on them. :-)
> 
> Damian

Ick.

>From the standpoint of die() being something serious and fatal unless
caught, this weakens die() considerably, because you'll need to do
another die() after the grep or map or whatever.

>From the standpoint of die() being the exception throwing mechanism,
this weakens die() considerably because lots of things can now catch
your exceptions, and if you want to be sure they get propagated all the
way up to the appropriate handler, you have to keep re-throwing the damn
things.

Both are pretty much the same. Combining them, I'd say that exceptions
should remain exceptional.

Counterproposal: grep, map, etc. define two implicit magic labels
'ACCEPT' and 'REJECT' that behave in the expected way, so you use
($first_small) = grep { ($_ < 2) and last ACCEPT } @list.

To get small numbers and primes, use

@list = grep { goto ACCEPT if isprime($_); $_ < 10 } 0..100;

or, equivalently,

@list = grep { next ACCEPT if isprime($_); $_ < 10 } 0..100;

and to produce qw(bed feed feed): (new capability)

@list = grep { /e/g and redo ACCEPT } qw(cat bed dish feed)

A bare 'last' within such a block would be, implicitly, 'last REJECT'.
Or leave it an error?

You wouldn't be able to escape the innermost enclosing grep or map with
this. I'm not sure if that's good or bad.

Re: $a in @b

[Steve Fink]

Damian Conway wrote:
> 
>> Both are pretty much the same. Combining them, I'd say that exceptions
>> should remain exceptional.
> 
> I'd say short-circuiting a vector operation was exceptional enough. :-)

I'd say it's exceptional sometimes, and very ordinary other times, and
I'd prefer to be the one deciding which is which.

>> Counterproposal: grep, map, etc. define two implicit magic labels
>> 'ACCEPT' and 'REJECT' that behave in the expected way, so you use
>> ($first_small) = grep { ($_ < 2) and last ACCEPT } @list.
> 
> I considered this solution, but rejected it precisely because...
> 
>> You wouldn't be able to escape the innermost enclosing grep or map
>> with this. I'm not sure if that's good or bad.
> 
> Bad, I think.

I'm not so sure about that. And note that any die()-related proposal
doesn't give you multilevel exits either.

But if it's necessary, I suppose you could always make

Loop1Accept:Loop1Reject: grep {
Loop2Accept:Loop2Reject: map { ... }
}

work. Though those labels really aren't in the right place.

grep { ... } @list accept1: reject1: ;

is an idea. I'd probably pick

loop1: grep { ... last ACCEPT(loop1) } @list

over either of those, though.

In the back of my mind, I keep thinking that it would be cool to have
similar control over the flip-flop operator too. I can never remember
whether C will print the line containing "bar"
or not, but half the time I want the other one. But I doubt that's
related enough to tie into this.

Re: RFC 103 (v1) Fix print "$r->func" and $pkg::$var precedence

[Steve Fink]

Nathan Wiger wrote:
> 
> > Foo::Bar->stickysnort()
> 
> Right, knew I forgot something...
> 
> > I wonder whether the "I want to expand arbitrary expressions within
> > strings even when there aren't any $ or @ symbols about" people
> > just need better familiarity with the alternatives.
> 
> This was all spawned by a consistency argument brought up by Bart on
> "where to draw the line" with having -> interpolate:
> 
> http://www.mail-archive.com/perl6-language@perl.org/msg03658.html
> http://www.mail-archive.com/perl6-language@perl.org/msg03659.html
> 
> If instead we chose to draw the line at needing a $, I'm fine with that,
> as long as the line is well-defined and allows for class methods to
> interpolate in qq// strings.

Not entirely unrelated:

Last weekend I got tired of writing

print "Reduced symbol ".$parser->dump_sym($sym)." via rule
".$parser->dump_rule($r).", went to state
".$parser->dump_kernel($k)."\n";

and wrote a very simple module, let's call it Magic:

use Magic;
my (%DSym, %DRule, %DKernel);
register_magic(\%DSym, 'dump_sym', $parser);
register_magic(\%DRule, 'dump_rule', $parser);
register_magic(\%DKernel, 'dump_kernel', $parser);
.
.
.
print "Reduced symbol $DSym{$sym} via rule $DRule{$r}, went to state
$DKernel{$k}\n";

Much nicer. You can even use this to replace map:

register_magic(\%Size, sub { -s $_[0] });
@sizes = @Size{@filenames};

Define the map function once, use it all over the place. (Slowly. This
is using tie()).

More relevant to the current discussion,
register_magic(\%ID, sub { $_[0] });
print "f(1,2,3) = $ID{f(1,2,3)}\n";

Does anyone remember who I stole this idea from? mjd, I think. Ah, yes,
here it is: Interpolate.pm.
. Some minor
differences.

Re: $a in @b (RFC 199)

[Steve Fink]

Jarkko Hietaniemi wrote:
> 
> Allow me to repeat: instead of trying to shoehorn (or piledrive) new
> semantics onto existing keywords/syntax, let's create something new.
> The blocks of grep/map/... are special.  They are not quite looping
> blocks, they are not quite sub blocks, they are different.  Well, to
> be frank they are just very plain, ordinary, blocks that return their
> last value, but if we want to introduce both flow control

So, why not get rid of the specialness? Why can't all blocks return
their last value? The ones that currently do not return a value would
just be given void context. (Just because there's nowhere for the value
to go doesn't mean they can't return a value.) And if that's done, then

$val = 1;
$fact = while ($n) { $val *= $n--; } || $val;

might not be a horrible idea either.

Then we would have sub BLOCKs and loop BLOCKs. 'return' would escape the
nearest enclosing sub BLOCK and return a value. last/redo/next would
escape/repeat/continue the enclosing BLOCK of any sort, and would be
extended to specify the value returned. 'last $value' would be
equivalent to 'return $value' inside a subroutine unless it were
enclosed in a loop BLOCK.

Extension idea: just use last LABEL, $value:

last LABEL => $value
or
last => $value

(last, $value seems like it wouldn't be terribly useful otherwise,
right?)

Oh yeah. do BLOCK is still a third kind, which is transparent to all
control constructs.

What am I missing?

Re: types that fail to suck

[Steve Fink]

Mark-Jason Dominus wrote:
> 
> Maybe I should also mention that last week I had a dream in which I
> had a brilliant idea for adding strong compile-time type checking to
> Perl, but when I woke up I realized it wasn't going to work.

What do you see as the major obstructions?

eval "" isn't too bad, because you can just forget about type inference
until after all use's and BEGIN{}'s have finished and you're about to
start the final run. Then you can allow any remaining eval""'s to trash
the inference.

Symbolic references are ok for user programs, because you can punt on
inference unless they use strict 'refs'. import() is much worse; you'd
need to alter Perl to either do those before the inferencer runs or make
a built-in Exporter that the typechecker is buddies with.

$class->$method may be survivable if you can infer the possible values
of $method most of the time.

Closures are tough, but they exist in many languages that people have
written inference engines for. You have to play some tricks to avoid
infinite loops in the inferencer.

Subroutine arguments cause trouble. They're a list, and most type
systems only allow a single type in lists. But if we use a list type
like (T1, T2, T3...) meaning the first element, if it exists, is of type
T1, the second of type T2, and the third and all remaining of type T3,
then we might be able to stem the precision hemorrhaging somewhat.

References scare me.

$b = 17;   # $b(0) : integer
$b++;  # $b(1) : number
$b .= "fish";  # $b(2) : string
$c{1000} = $b; # %c(0) : hash{integer -> string}
$c{2000} = \%c;# %c(1) : hash{integer -> string | integer ->
ref(hash)} + %c is exposed
$c{$$}->{$b} = 42; # %c(2) : hash{nonref scalar -> scalar?}

Tying is ok as long as it can be reduced to FETCH etc. calls.

When I get some time, I'm planning on prototyping a perl5 type
inferencer that handles the easy stuff and correctly punts on the harder
stuff. I should have it done by Christmas.

Christmas 2023 sounds about right.

Re: Conversion of undef() to string user overridable for easy debugging

[Steve Fink]

> > This reminds me of a related but rather opposite desire I have had
> > more than once: a quotish context that would be otherwise like q() but
> > with some minimal extra typing I could mark a scalar or an array to be
> > expanded as in qq().
> 
> I have wanted that also, although I don't remember why just now.  (I
> think have some notes somewhere about it.)  I will RFC it if you want.
> 
> Note that there's prior art here: It's like Lisp's backquote operator.

Reminds me of m4's changequote.

$command = q$^"PATH=$PATH:^installdir dosomething";
equiv to $command = "PATH=\$PATH:$installdir dosomething";

q$![That'll be $20, !name.];

Hm... no, that wouldn't handle @ or %.

qp(^&*)[string with scalar ^var, array &var, hash *var]

(p for prefix)

I guess your suggestion would look something like

quote("That'll be $20, $title $name", qw(name title));

Re: RFC 226 (v2) Selective interpolation in single quotish context.

[Steve Fink]

Nathan Wiger wrote:
> 
> Andy Dougherty wrote:
> >
> > How do you turn it off?  I want to keep a way to specify stuff without any
> > interpolation whatsoever. I see the usefulness of this sort of quoting,
> > but I also see the usefulness of being absolutely able to turn all
> > interpolation off.
> 
> Yes, I agree with this point, also raise by Glenn and others. Currently,
> there is very nice semantics in shell-style quoting:
> 
>q//  ==   ''  ==  *NO* interpolation

I agree. I'd like q/.../ to stick as close to giving me ... as possible.
I can live with the current 'foo\\bar' having only one backslash in it,
but I'd rather not have to worry about anything else. I'd vote for
Glenn's allowing the disabling of interpolation in qq// and <<""
instead.

Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'?

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> >The warning for the use of an unassigned variable should be "use of
> >uninitialized variable C<$x>".
> 
> The problem with that idea, now as before, is that this check happens
> where Perl is looking at a value, not a variable.  Even were it possible
> to arduously modify Perl to handle explicitly named simple variables,
> there's much more to consider.
> 
> if ( fx() == fy() ) { }
> 
> For one.
> 
> --tom

Yes, we've been through this before. :-) And now, as before, that's not
what the RFC is saying. Your fx() example would produce the warning "use
of undefined value". No variable name. Same for the code C. I am not changing the existing warning at all,
just rewording it from "uninitialized" to "undefined", because that's
what it is. 'Initialized' means you've assigned something to it at least
once; undefined means defined() returns false.

I am merely suggesting that the compiler detect, when it can, that
you're trying to use the value of a variable without ever having
assigned a value to that variable. And in THAT message, you had better
know the name of the variable, since it's the basis of the analysis. And
yes, it only handles simple named variables.

Example:

1 my ($x, $y, $z);
2 $z = 1;
3 my $logfile = "/tmp/log";
4 $x = 1 if cond();
5 print $x+$y;
6 undef $z;
7 print $z;

--> use of uninitialized variable $y in line 5 (compile time)
--> possible use of uninitialized variable $x in line 5 (compile time)
--> variable $logfile defined in line 3 but never used (compile time)
--> use of undefined value in line 7 (run time)

I'll add this example to the RFC.

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Eric Roode wrote:
> 
> Steve Fink wrote:
> >I am merely suggesting that the compiler detect, when it can, that
> >you're trying to use the value of a variable without ever having
> >assigned a value to that variable. And in THAT message, you had better
> >know the name of the variable, since it's the basis of the analysis. And
> >yes, it only handles simple named variables.
> 
> Um, "when it can"? Isn't this considered a Hard Problem by the
> computer scientists?

The halting problem is unsolvable. That doesn't mean you can't figure
out whether the complete program

$x = 1

halts.

But that doesn't even matter that much here; I'm saying that if the
compiler can definitely determine that you are using an uninitialized
variable, it should warn. If you're using something that appears like it
might be uninitialized, but can't be proven either way without solving
that pesky halting problem, then it (if you ask it) says "you might have
screwed up." 90% of the time, it's right -- if the right set of freak
occurrences happen, you really do use the value of an uninitialized
variable. As an example, this may produce a spurious warning:

$y = 1 if $x;
$y = 2 if ! $x; 

...because the compiler is unable to be sure that ($x) || (!$x) is
definitely true. (And in fact, it might not be in the presence of tying.
Which is why, when doing this sort of thing, compilers usually
completely ignore the actual conditions being tested, and assume that
they're independent and sometimes true, sometimes false.)

> >Example:
> >
> >1 my ($x, $y, $z);
> >2 $z = 1;
> >3 my $logfile = "/tmp/log";
> >4 $x = 1 if cond();
> >5 print $x+$y;
> >6 undef $z;
> >7 print $z;
> >
> >--> use of uninitialized variable $y in line 5 (compile time)
> >--> possible use of uninitialized variable $x in line 5 (compile time)
> >--> variable $logfile defined in line 3 but never used (compile time)
> >--> use of undefined value in line 7 (run time)
> 
> How about:
> 
> foo();
> $x = 1  unless defined($x);
> print $x;
> 
> Generate a warning, or not?

$x is a global. The compiler cannot detect all possible assignments to
or accesses of globals, so it never warns about them.

If you inserted my $x at the top of that code, it would most likely
produce the "possible use" warning. Or not; this is a simple enough case
that it might be able to infer the right answer.

I am certainly not saying that the "possible use" warning should be
enabled by default. But please, argue over that one separately from the
others. It's the most likely to annoy.

> Or:
> foo();
> print $x;
> 
> Generate a warning, or not?  Which one? Remember, foo() may initialize $x.

Same thing. If $x is lexical, it gives a definite warning. If $x is a
global, it says nothing. You're right; I need to point this out in the
RFC.

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

Michael Fowler wrote:
> 
> On Wed, Sep 20, 2000 at 07:45:16PM -, Perl6 RFC Librarian wrote:
> > "VARIABLE used only once: possible typo" should be replaced with
> > warnings on uses of uninitialized variables (including lexicals).
> 
> >  $x = 3
> 
> I don't understand, who's to say you didn't misspell $x?  If you're only
> using it once wouldn't that be likely?  Who writes a program consisting of
> only assignments to variables that are never used, and expects not to see
> the "VARIABLE used only once: possible typo" warning?

My new warnings are more specific than the old warning. Perhaps I should
make the "variable initialized but never used" warning suggest a
possible typo?

> > complains, but
> >
> >  $x = 3; $x = 3
> 
> As it shouldn't; you've mentioned $x twice, which means you probably didn't
> misspell it.  That your mentioning twice in this manner is silly is beyond
> perl's grasp.

Actually, it isn't. I've often written $x = $x = 3 simply to avoid this
warning, because in the current implementation perl can't several of the
different ways of using a variable.

But I think you're missing the point. Why would you assign a value to a
variable, but then never use that variable's value? All typos would be
caught by the "initialized but never used" warning, as well as other
mistakes.

> > does not, nor does
> >
> >  my $x = 3
> 
> I would say that this should complain just as $x = 3 would.

Yes.

> > Note that if you currently depend on lexical variables having
> > undefined values, you would need to change C to
> > C. This is a good thing.
> 
> Whoa, are you saying that saying 'my $x' no longer means $x has the value
> undef?  What value does it have?  How can this be a good thing?

No. No semantics change. This RFC is... what's the opposite of
far-reaching? It changes no semantics. It only adds warnings. 'my $x'
still means $x's value is undefined (but please do not say "the _value_
undef").

This is probably the most controversial part of the RFC. I'm saying that

my $x;
...some code that might set $x to some value...
if (defined ($x)) { ... }

is bad, but

my $x = undef; # or my $x; undef $x;
...some code that might set $x to some value...
if (defined ($x)) { ... }

is ok. That's because I want to distinguish between initialized
variables and variables whose values are undefined, because I think I
can catch a lot of mistakes by doing so. But this distinction is only in
the compiler. This is the same as in gcc; in gcc, the compiler remembers
whether an integer variable has been initialized, and complains when you
use it. But at runtime, that variable has some numeric value (a junk
value, zero more often than not.) Perl's runtime specifically tracks
variables and expressions whose value is undefined, and does it well
enough that most people think of 'undef' as being just another value.

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> And what about $$x?
> 
> Dang, are we back to this incredible confusion about what it is to be
> defined in Perl.?
> 
> undef $a;
> 
> That is now UNINITIALIZED.  So is this:
> 
> $a = undef;
> 
> You have initialized it to undef.  There is no reasonable difference.
> 
> Solution:
> 
> Remove all references from the language to defined and undef.
> People just aren't smart enough to understand them.  Change
> defined() to read has_a_valid_initialized_scalar_value().  Change
> undef() to "operator_to_uninitialize_a_variable".  Touch luck
> on the chumps who can't type well.  They pay for their brothers'
> idiocy.
> 
> repeat until blue:
> 
>   INITIALIZED ==   DEFINED
> UNINITIALIZED == UNDEFINED

Thank you, that's a better way of describing part of the intent of this
RFC. I want to distinguish between variables that are uninitialized, and
expressions whose values are undefined.

my $x; # $x is uninitialized. Also, the value of $x is undefined.
undef $x; # $x has now been initialized. The value of $x is still
undefined.

This is *not* adding a new sort of value to perl. It is adding a
different state for the compiler to think of a variable as being in.
Initialization of a variable means you've done something that influenced
the value of that variable -- either by setting it, or blowing it away
and making it undefined.

You aren't interpreting the last part of the DESCRIPTION section ("you
need to do my $x= undef") as meaning that

my $x;
and
my $x = undef;

have a runtime difference, are you? I think this is confusing some
people, and I really shouldn't say "you would need to" do anything
different; I meant "you would need to say my $x = undef if you have this
warning turned on and you don't want to see it."

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> >Same thing. If $x is lexical, it gives a definite warning. If $x is a
> >global, it says nothing. You're right; I need to point this out in the
> >RFC.
> 
> Careful:
> 
> sub ouch {
> my $x;
> my $fn = sub { $x++ };
> register($fn);
> print $x;
> }

Thanks. I forgot about that one. So either I can punt and treat
capturing a lexical in a closure the same way I'd treat taking a
reference (i.e., assuming that it's both initialized and used), or get a
little more clever and say that getting captured in a closure means you
have to throw out all beliefs about control flow, and fall back to
counting the number of uses and initializations.

Anything else? Any opinion on whether eval "" should do what it does
now, and be invisible for the purposes of this analysis; or if it should
be assumed to instead both use and initialize all visible variables? The
former produces more spurious warnings, the latter misses many errors.

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

> >Which is silly, because you shouldn't have to say '$x = $x = 3' when you
> >mean '$x = 3'.  Just because there's a real reason behind it doesn't make it
> >any less silly.
> 
> I'd like to see where this can happen.  Sounds like someone forgot to
> declare something:
> 
> our $x;
> $x = 2;

It happens when I don't bother to declare something. My company has
several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
a pain. As is $My::Package::Name::x.

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

Michael Fowler wrote:
> 
> On Wed, Sep 20, 2000 at 03:25:11PM -0700, Steve Fink wrote:
> > > > complains, but
> > > >
> > > >  $x = 3; $x = 3
> > >
> > > As it shouldn't; you've mentioned $x twice, which means you probably didn't
> > > misspell it.  That your mentioning twice in this manner is silly is beyond
> > > perl's grasp.
> >
> > Actually, it isn't. I've often written $x = $x = 3 simply to avoid this
> > warning, because in the current implementation perl can't several of the
> > different ways of using a variable.
> 
> Which is silly, because you shouldn't have to say '$x = $x = 3' when you
> mean '$x = 3'.  Just because there's a real reason behind it doesn't make it
> any less silly.

Ok, I can't argue with that. :-)

> > But I think you're missing the point. Why would you assign a value to a
> > variable, but then never use that variable's value? All typos would be
> > caught by the "initialized but never used" warning, as well as other
> > mistakes.
> 
> So, in the code:
> 
> $foobal = 3;
> if (@ARGV) {
> $foobar = @ARGV;
> }
> 
> print $foobar;
> 
> Only warn me that $foobar is uninitialized?  I always prefer it when the
> actual source of my problem is pointed out, rather than its symptoms.

It's exactly the same behavior as now, if you add in the "maybe it's a
typo?" guess. Which sounds fine to me.

> > > Whoa, are you saying that saying 'my $x' no longer means $x has the value
> > > undef?  What value does it have?  How can this be a good thing?
> >
> > No. No semantics change. This RFC is... what's the opposite of
> > far-reaching? It changes no semantics. It only adds warnings. 'my $x'
> > still means $x's value is undefined (but please do not say "the _value_
> > undef").
> 
> I'm saying the value undef now, because that's exactly what it is, now.  I
> have learned that 'my $foo' is an implicit 'my $foo = undef', for all
> intents and purposes.

And undef is short for the function call undef(), which could be
implemented

sub undef {
my $var;
return $var;
}

(except undef can optionally take parameters, as in undef $x)

Something that isn't defined() means that either nobody bothered to
assign a value to it, or somebody took away its value.

> > my $x;
> > ...some code that might set $x to some value...
> > if (defined ($x)) { ... }
> >
> > is bad, but
> 
> This is an idiom I use all the time, and I don't see anything wrong with it.
> The value is undef, and I don't want to see this change at all.
> 
> > my $x = undef; # or my $x; undef $x;
> 
> I just have to say, ick.  'my $x' is easy, 'my $x = undef' is slightly
> annoying.  'my $x; undef $x;' is confusing; declare a variable, and then
> immediately undefine it, so I can avoid uninitialized value warnings?
> Blech.  What of a list of declarations, 'my($foo, $bar, $blah)'? do I get
> lots of warnings unless I assign undef to, or undef, all of those?

Yes. Note that I wasn't suggesting that anyone "should" use C over C, it's just more clear given that undef is
a function call.

With my style of programming, my($foo,$bar,$blah) would rarely trigger
warnings, because I would do something with those variables before using
them. I rarely use defined() to mean "if the control has happened to
take a route that never affected the values of this variable". In those
cases, I wouldn't mind using an explicit undef.

It sounds like your style of programming is different. So you wouldn't
enable those warnings. And also that you find the existing warning
useful, which means the control over the warnings must be more
fine-grained than all or nothing. Sounds reasonable to me. And you might
want to temporarily turn on full warnings mode, ignore the spurious
messages, fix the bugs uncovered, and turn the warnings back off.

The question is whether there are enough people who use either my style
of programming or want the temporary warnings firehose to warrant
implementing it. I haven't been able to determine yet whether this is
the case. People largely ignored this RFC when it first came out.

> I never particularly liked this feature of C, that a variable had junk in it
> naturally until you assigned something to it.  I much prefer how Perl does
> it; give it a sane value, but warn whenever that value is used unless it was
> intentional (by using defined or conditionals).

No argument there. But do you like the feature of C where it warns you
at compile time when this is going to happen?

> > Perl's runtime specifically tracks variables and expressions whose value
> > is undefined, and does it well enough that most people think of 'undef' as
> > being just another value.
> 
> It is just another value AFAIK, PL_sv_undef.

That's implementation. The semantics are determined by the effects of
various operations on objects whose values are undefined. And those
effects reveal that it isn't just another value; no other value behaves
anything like it.

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> >It happens when I don't bother to declare something. My company has
> >several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
> >a pain. As is $My::Package::Name::x.
> 
> Far, far easier to fix behavioral problems than to hack Perl.
> 
> --tom

Not sure what you mean, since this RFC _adds_ a warning in this case. In
fact, with the proposed change, my trick to avoid punishment for my
misbehavior would no longer work.

The point is that if

$x = 3;

elicits a warning, then the problem that the warning is pertaining to is
not fixed by

$x = 3;
$x = 3;

so the warning should not go away either. In general: when possible, the
compiler should not change its behavior when your code does not change
in a way relevant to the problem it's complaining about.

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> >Anything else? Any opinion on whether eval "" should do what it does
> >now, and be invisible for the purposes of this analysis; or if it should
> >be assumed to instead both use and initialize all visible variables? The
> >former produces more spurious warnings, the latter misses many errors.
> 
> You have to assume eval STRING can do anything.
> 
> --tom

"have to"? Perl5 doesn't.

% perl -we '$x = 3; $v = "x"; eval "\$$v++"'
Name "main::x" used only once: possible typo at -e line 1.

I'd rather think of it as a cost-benefit tradeoff.

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

Michael Fowler wrote:
> 
> On Wed, Sep 20, 2000 at 05:20:54PM -0700, Steve Fink wrote:
> > > $foobal = 3;
> > > if (@ARGV) {
> > > $foobar = @ARGV;
> > > }
> > >
> > > print $foobar;
> > >
> > > Only warn me that $foobar is uninitialized?  I always prefer it when the
> > > actual source of my problem is pointed out, rather than its symptoms.
> >
> > It's exactly the same behavior as now, if you add in the "maybe it's a
> > typo?" guess. Which sounds fine to me.
> 
> Except for the line number reported, which is the important part.

Oh. Certainly you'll get the line number. My description didn't include
it because it didn't seem to aid to the understanding. I have it in the
examples that I added to the RFC.

I suppose it could even give both line numbers for declared variables:
"use at line 7 of uninitialized variable declared at line 3."

> I would.  I have not done it personally, but I do maintain code that has
> something along the lines of:
> 
> my($foo, $bar, %baz, @qux, $quux, $blah ... ad nauseum);
> 
> This new warning would make life difficult for me.

It's not just having my($long, $list, $of, $variables). It's never
saying $long = f().

Ah well. It would be interesting to have this and see how many things
complain. I know my code is littered with abandoned 'my $var's that are
no longer used, because I'm lazy and used to relying on a C compiler to
tell me when I can delete an obsolete local variable. Perl won't do that
for lexicals.

> > But do you like the feature of C where it warns you at compile time when
> > this is going to happen?
> 
> Yes, and Perl currently has the very same thing, except with the additional
> warning when I use a variable that has not been declared.  This being Perl,
> it's natural; you cannot use a variable in C without declaring it, so the
> issue never comes up.

Where it catches things for me in C is in places like:

int somefunc() {
int status;
while (...) {
status = syscall();
if (status < 0) break;
...
}
return status;
}

Before I started using -Wall all of the time, I was often puzzled when
somefunc() returned -813714631.

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> >Tom Christiansen wrote:
> >>
> >> >It happens when I don't bother to declare something. My company has
> >> >several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
> >> >a pain. As is $My::Package::Name::x.
> >>
> >> Far, far easier to fix behavioral problems than to hack Perl.
> >>
> >> --tom
> 
> >Not sure what you mean, since this RFC _adds_ a warning in this case. In
> >fact, with the proposed change, my trick to avoid punishment for my
> >misbehavior would no longer work.
> 
> >The point is that if
> 
> >$x = 3;
> 
> >elicits a warning...
> 
> that you should declare the variable properly, of course.

I want a similar warning for a file containing only

my $x = 3;

And for a file containing only

my $x = 3;
$x = 3;

Do you think this would be useless? Or do you think that it would report
too many spurious warnings? Or do you think it would confuse people? I'm
having trouble figuring out what your position is, other than not
wanting uninitialized values to be any different from undefined values.
In your opinion, is the RFC without merit, or are you objecting only to
parts of it?

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Tom Christiansen wrote:
> 
> >Tom Christiansen wrote:
> >>
> >> >Anything else? Any opinion on whether eval "" should do what it does
> >> >now, and be invisible for the purposes of this analysis; or if it should
> >> >be assumed to instead both use and initialize all visible variables? The
> >> >former produces more spurious warnings, the latter misses many errors.
> >>
> >> You have to assume eval STRING can do anything.
> >>
> >> --tom
> 
> >"have to"? Perl5 doesn't.
> 
> You mean "perl".
> 
> >% perl -we '$x = 3; $v = "x"; eval "\$$v++"'
> >Name "main::x" used only once: possible typo at -e line 1.
> 
> Non sequitur.  And no, I don't have time.

It is relevant in that perl's existing behavior has proven to be useful
even though the implementation is not correct. The correct
implementation would not have issued the above warning, because an
eval"" was present in the code. However, the correct implementation
would also fail to warn in many legitimate cases. The current heuristic
seems to strike a pretty good balance:

% perl -le '$x = 3; eval "\$x++"'
(no warning issued)

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

Eric Roode wrote:
> 
> Steve Fink, via the Perl6 Librarian, wrote:
> >=head2 EXAMPLE
> >
> >1 my ($x, $y, $z, $r);
> >2 $z = 1;
> >3 f(\$r);
> >4 my $logfile = "/tmp/log";
> >5 $x = 1 if cond();
> >6 print $x+$y;
> >7 undef $z;
> >8 print $z;
> >
> [...]
> >No warning is issued for C<$r> because any variable whose reference is
> >taken may be used and/or assign to through the reference.
> 
> Perl is not C.  Perl passes parameters to subroutines by reference.
> Example:
> sub initialize_to_seven
> {
> $_ = 7  foreach @_;
> }
> 
> my ($a, $b, $c);
> initialize_to_seven ($a, $b, $c);
> print "$a, $b, $c\n";

Right. Thank you.

Lines 2 & 3 should be combined to $z = \$r (I just wanted to take a
reference in something besides void context!), and passing a variable to
a function should be treated as both a use and a definition.

Re: RFC 12 (v3) variable usage warnings

[Steve Fink]

Michael Fowler wrote:
> 
> Ok, at this point I'm trying to clear up misunderstandings.  I believe you
> know where I stand with relation to your RFC.

Thanks, you caught several of my mistakes.

> 
> On Wed, Sep 20, 2000 at 06:41:52PM -0700, Steve Fink wrote:
> > Michael Fowler wrote:
> 
> > > Except for the line number reported, which is the important part.
> >
> > Oh. Certainly you'll get the line number. My description didn't include
> > it because it didn't seem to aid to the understanding. I have it in the
> > examples that I added to the RFC.
> >
> > I suppose it could even give both line numbers for declared variables:
> > "use at line 7 of uninitialized variable declared at line 3."
> 
> Yes, you could do that, but it wouldn't catch this problem.
> 
> The example code:
> 
> $foobal = 3;# This $foobal is an intentional typo.
> if (@ARGV) { $foobar = @ARGV }
> print $foobar;
> 
> I want perl to tell me that $foobal, declared on line 1, was never used.
> You want perl to tell me that $foobar, used on line 3, and declared on line
> 1 (!), was used uninitialized.  I'm going to assume you didn't mean perl
> should do code analysis to see exactly where I first misspelled the
> variable.  If it could, great!  Somehow I doubt we're going to go there,
> though.

I don't think of an assignment to a global as a declaration. Only C is a declaration. I need to rewrite the RFC to pertain to both
lexicals and globals. I think I may have to leave current behavior
unchanged (it only considers globals), but add the simple flow analysis
for lexicals.

Typos in uses or assignments would then be caught by existing
mechanisms, because they wouldn't be declared lexical. Typos in
declarations would be caught by "use of uninitialized value", as well as
(probably) the existing mechanisms for the uses and assignments of the
correctly spelled variable.

So I guess I finally get what you've been trying to tell me: for typos,
the existing mechanisms are sufficient.

For lexicals, a use without a declaration makes no sense, because
variables default to global (non-lexical). A use without an
initialization is of arguable utility, because your defined() tests may
already be intended to check for that case, so you'd really rather that
not be a warning. Do I have that right? Then perhaps the warning
*should* be on by default, but suppressed if defined() is ever called on
the variable? That would still warn unnecessarily on

my $x;
...
$y = $x;
...
if (defined($y)) ...

Ugh. I'll have to think about that some more.

Declaring a (lexical) variable without using it still seems like a
useful addition; it's nearly the same as the existing "used once"
warning. And I know it would be useful in my code, because it'll let me
find obsolete local variables in my subroutines.

I'm still wondering if it would be useful to heuristically warn if a
global's value is never used, ignoring possible symbolic references,
eval""s, etc. It might be a useful incremental improvement over the
current use strict 'vars' analysis. But the current analysis already
gives me spurious warnings at times, and this would increase their
frequency.

> Yes, I realize that.  But more often than not the variables are used
> undefined to indicate a certain state, and you want me to either insert a
> "no warnings 'whatever'", or initialize all of those variables to undef
> explicitly.  I'm saying I want the code to work the same, because perl
> already tells me about the use of uninitialized values, and my having used a
> variable only once.
> 
> In fact, I don't want it to mention I've used it only once when I use use
> strict and declare my variables; strict catches my misspellings, and at
> compile-time, no less.

Got it. I think.

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Daniel Chetlin wrote:
> 
> On Wed, Sep 20, 2000 at 07:20:44PM -0700, Steve Fink wrote:
> > % perl -le '$x = 3; eval "\$x++"'
> > (no warning issued)
> 
>   [~] $ perl -wle'$x = 3; eval "\$x++"'
>   Name "main::x" used only once: possible typo at -e line 1.

Doh! Thanks.

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Dave Storrs wrote:
> 
> On Wed, 20 Sep 2000, Eric Roode wrote:
> 
> > foo();
> > print $x;
> >
> > Generate a warning, or not?  Which one? Remember, foo() may initialize $x.
> 
> My suggest (FWIW) would be that, if there is no execution path
> which leads to $x being defined in the second line, then a "Use of
> uninit'd variable $x" warning should be thrown at compile time.  If there
> is at least one path that will result in $x being defined AND at least one
> path that will result in it being undefined, the compile-time warning
> could be something like "Possible use of undefined variable $x" or "Not
> all execution paths leave $x defined".

Makes sense. Just have to be careful to describe all this stuff without
mixing together initialization vs definedness, globals vs lexicals, flow
control analysis vs counting occurrences, compile time vs run time, and
definite problems vs possible problems. Makes my head hurt.

Re: RFC 12 (v2) variable usage warnings

[Steve Fink]

Eric Roode wrote:
> 
> Allow me to throw another log on the fire:
> 
> my $x;
> if (something)
> {
> $x = 1;
> }
> my $y = $x;
> 
> This would give a compile-time warning under your RFC, warning the
> user of a possibly uninitialized $x. Okay. Next:

Yes.

> my $x;
> if (something)
> {
> $x = 1;
> }
> else
> {
> $x = 2;
> }
> my $y = $x;
> 
> Would this give the same warning? Would it notice that $x is set
> in both branches of the condition?

Yes, it would notice this and not warn. All paths of flow control
leading to the final statement contain an initialization.

> Worse:
> 
> my $x;
> if (something)
> {
> $x = 1;
> }
> if (!something)
> {
> $x = 2;
> }
> my $y = $x;
> 
> I presume this would generate a warning under your RFC, right?

Yes. And not necessarily a spurious one: consider using $dsoifjd++ for
'something'.

> Since I would guess the compiler shouldn't be required to notice
> that one condition is the inverse of the other?

It would also have to prove that the value of 'something' does not
change from one call to the next.

> I'm not sure I like the above construct not behaving identically
> to the second case (if...else...) above...

The "possibly" version would need to be optional (or more optional) than
the others. As soon as it gave me even one spurious warning, I would
immediately turn it off except to periodically turn on all warnings full
blast to get a "lint"-like effect.

> Moving on:
> 
> my $x;
> if (thing1)
> {
> $x = 1;
> }
> elsif (thing2)
> {
> $x = 2;
> }
> elsif (thing3)
> {
> $x = 3;
> }
> else
> {
> $x = 4;
> }
> my $y = $x;
> 
> Warnings, or no?

No warnings.

> How about:
> 
> my ($x, $i);
> for ($i=0; $i<10; $i++)
> {
> $x .= $i;
> }
> my $y = $x;
> 
> Now, I can look at that and see that $x will be '0123456789', but
> the compiler can't be expected (imho) to know whether the loop
> condition will ever execute, so under your RFC it will generate a
> "possibly uninitialized" warning, right?

Right. We could stray from correctness here and assume any for loop is
executed at least once, but I'd rather not -- this is the code pattern
where it is most useful (because often the programmer doesn't notice
that, in fact, that for or while loop might not execute, in some weird
case.)

In this particular case, it might not be unreasonably difficult to ask
the question of "is COND true immediately after INIT in for(INIT; COND;
INCR)?" But the compiler certainly won't be that smart in version 1.

Re: my and local

[Steve Fink]

Tom Christiansen wrote:
> 
> As we sneak under the wire here, I'm hoping someone
> has posted an RFC that alters the meaning of my/local.
> It's very hard to explain as is.  my is fine, but local
> should be changed to something like "temporary" (yes, that
> is supposed to be annoying to type) or "dynamic".

my's runtime/compile-time schizophrenia is rather bizarre too. I'd like

my $x if 0;

to be equivalent to

my $x;

Re: Acceptable speeds (was Re: TIL redux (was Re: What will thePerl6 code name be?))

[Steve Fink]

Most of the time, perl's performance is a total non-issue for me. When
it is, I'm generally doing the same things as Dan (ie, things resembling
dd if=/dev/hda | perl -e ...). I posted some vague benchmarky ideas to
perl6-meta at one point. Here they are again:

-

You did ask at one point for some suggestions of other speed goals. So
here are example subgoals:

1. Methods are close enough in speed to subroutine calls (<=20% slower?)
that nobody will avoid using them for performance reasons.

2. A fairly tight loop with a subroutine call is N% faster.

6. Grepping for a variable-sized regular expression on a nonblocking
pipe is >N% faster (with incremental regular expression matching, N can
be superlinear.)

-

They're all too ill-defined to test, but maybe the first step is to
enumerate a bunch of general tasks where performance is likely to
matter. Let's see...:

1. Binary parsing
2. Sucking data off of disk and spewing it back out (presumably
modifying it on the way through)
3. Calling subroutines
4. Calling methods
5. Matching
6. Matching variable-length things while juggling buffers
7. use'ing big modules
8. Math
9. General parsing (something requiring a mixture of code and regexes)
10. Tk-style callback frenzies and mark/tag manipulation (?)
11. external (XS) code in tight loops
12. Lots of concurrent instantiations of things with big shareable stuff
(eg CGI.pm) (more of a space than speed issue, though the former tends
to turn into the latter)

If I were to write up a Perl5 benchmark addressing one or a few of
these, where should I put it?

(Crossposted to -internals)

Re: RFC on Coexistance and simulaneous use of multiple module version s?

[Steve Simmons]

On Fri, Jan 26, 2001 at 02:08:01PM -0600, Garrett Goebel wrote:

> Discussion of RFC 271 and 194 on pre and post handlers for subroutines
> reminded me of Larry's desire for Perl 6 to support the coexistence of
> different versions of modules.
> 
> Besides http://dev.perl.org/rfc/78.pod, are there any RFC's which directly
> or indirectly relate to this?

Speaking as the author of RFC78, my official answer is ``I don't think
so.''  :-)  And RFC78 doesn't go as far as Larry has promised Perl6 will.

Advance apologies for being away so long; after a month I assumed things
had been wrapped up and there was no point in trying to catch up on the
old perl6-language mail.  Silly me.  Then I got a note from Mike Schwern
asking one of those ugly questions that spins out of this whole ugly
problem.

Sigh.

I believe that the versioning problems are solvable without doing major
damage to the existing modules structure.  This is detailed in the last
version of the RFC, but I am not certain if that version is available at
www.perl.org/perl6 - it is giving `access denied' at the moment.  The
last version is available at http://www.nnaf.net/~scs/Perl6/RFC78.html
(my version 1.3, stated in the text); I will update the perl.org one
once I can see if it's behind the times.

Shortly after the posting of RFC78, Larry replied:

> Quoting RFC78

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

[[ . . . other details elided . . . ]]

Version 2.0 of RFC78 would have been an attempt to address the items
Larry raised.  It stalled out because (dammit), it's *hard*.  But it
seems the issue is still open, and I've had a few more ideas.  This
note lays out some issues and ideas.  If there's good discussion and
any sort of there's any sort of near-consensus or coherent streams of
thought it'll get rolled up into RFC78 2.X.

BUT: That's essentially the same comment I made Aug 9, and discussion
ground to a halt about four messages later.  So if you want me to
work, you gotta respond.  :-)

Read http://www.nnaf.net/~scs/Perl6/RFC78.html to see the starting
point.  And remember that all of this below is open to change if
anybody has a better idea.

Now that you've read RFC78, throw much of it out.  We'll retain
the ideas, but the current (perl5.6) version rules will continue
as they currently do.  Instead, I propose a new mechanism below.

Our goals are to do that while allowing:

  o  At load time for a module, a programmer must be able to specify
 vendor, author, and version on a per-module basis.  
  o  At execution time, a programmer must be able to specify vendor,
 author, and version for use in a script for when multiple versions
 may be present.
  o  There must be a clean, clear mechanism to install these modules
 by vendor/author/version without requiring the module actually
 be loaded (parsed).
  o  At load time, modules must be able to influence their sharability

RFC78 proposes a mechanism for specifying versions down to a very
fine grain of detail.  I propose that we retain the current perl
syntax/search model as it works today, but add an alternative form:

  use module (version; author; vendor);

Version numbers and search rules are as defined in RFC78, null means
'first found'.

Author is a comma- and/or whitespace-separated list.  Commas separate
preference order groups, whitespace separates no-preference order
groups (similar to version, see RFC78).  If the author field is null
the author list is used.  The default author list is null.  Pragmas
to manipulate the author list are needed.

Vendor works like author in most ways.  However, the default vendor
list for vendors is (PERL, site), consisting of the current perl
and site library trees.

Precedence and other rules are needed so that this can be understood
and so we don't break existing functionality:

Search precedence is by vendor, by author within vendor, by version
within author.

Author-specific modules are installed by author name within vendor
trees.

If we grant this rules, *all current CPAN functionality and perl
installations are preserved.*  IMHO this is a huge win.


A first cut at vendor/author pragmas:

These manipulate the vendor list:

  use vendor 'foo'; # Push vendor name 'foo' onto the vendor list
  use popvendor;# Pop top of vendor list and discard
  use popvendor 'foo';  # Remove the topmost instance of 'foo'
  use rmvendor 'foo';   # Remove all instances of 'foo'
  use rmvendor '