Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.
> >Damian's Text::Balanced does a pretty good job of tokenizing Perl > >as it is. / by itself requires a lot of lookahead, and it's still > >a guess. > > I don't get it. What makes it so hard? If you see a "/" when you're > expecting an operator, or end of statement, then it's division. If you > were expecting an expression, it's a regex. Ain't it? Yes. And that's what makes it hard. Because somethimes you can be expecting *either* of those :-) Consider the statement: wash / my / gimsox; Division or pattern match? Damian
Re: User-defined quoting operators
>THING =~ OTHER_THING > > is translated to > >bind(THING,OTHER_THING) > > with bind() having user-defined semantics. > > I think Damian has an RFC in-the-works on operator overloading that > will address this. That one's been passed to brian d foy and (if memory serves) Nate. Damian
Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.
> Do we have an RFC yet that proposes Perl to be easier parsable? > Damian? Working on it. Damian
Re: RFC 76 (v1) Builtin: reduce
Making 0 the first element makes as much sense as 1- just a convention.
However there is precedence for letting the user decide. Does anyone else
remember
)ORIGIN 1
? So we establish a var $something=n where n is the array origin.
I don't think I'd ever use it personally, having been a c "kinder", but I
don't presume to thinkk like everyone else and others may be more strongly
fixated on another origin.
>From: Nathan Wiger <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>CC: [EMAIL PROTECTED], Glenn Linderman <[EMAIL PROTECTED]>
>Subject: Re: RFC 76 (v1) Builtin: reduce
>Date: Sun, 27 Aug 2000 19:02:25 -0700
>
>Damian Conway wrote:
> >
> > But ^1, ^2, etc. have *nothing* to do with $1, $2, except analogically.
> > And I'm removing that analogy from the next version of the RFC! ;-)
> >
> > They have *everything* to do with $_[0], $_[1], $_[2], etc.
>
>I realize this, but I don't think most people will see it that way. I
>see the analogy part much more clearly. Having ^1 and $1 be the same
>makes a lot more sense than having $1 and ^0 both be the start.
>
>Why? Consistency is key. With arrays, people understand that [0] is the
>first element because they're dealing with a computer.
>
>But with regexps (and HOFN), we're now into stuff that's good for
>humans. And the "First" element should be "^1", just like for regexps.
>Unless you want to start telling people that the "Zeroeth" element is
>"^0".
>
>But having the "First" element be "0" makes *no* sense. Not for humans.
>It never has.
>
> > In fact, every kind of indexing in Perl -- *except* $1, $2, etc. --
> > starts at zero. Fixing $0's semantics would be far more consistent than
> > breaking ^0.
>
>That's fine too - if we want to do this, let's! Honestly. I say:
>
>1. Make $ARGV[0] have the program name
>
>2. Make $0 be the first regexp match
>
>But I see two problems with this:
>
>1. Now "for (@ARGV) breaks"
>
>2. The "first" argument is now "0" again
>
>Please! Make the "first" be ^1. It's more consistent and makes more
>sense for us humans.
>
>We're not "breaking ^0" either - it doesn't exist yet. Rather, we're
>fixing it before the bug hits the customer. I guarantee you this will be
>a common mistake, I've done tons of work in real-life user-interface
>testing. Users see *simple* analogies, not deep ones ("^1 like $1, the
>first one")
>
>If I ask you to count to ten, which number do you start with?
>
>-Nate
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.
> =head1 ABSTRACT > > C and C are ...part of... > what makes Perl hard to tokenize. Requiring > them to be written C and C would ...help to... > solve this. Damian
Re: RFC 76 (v1) Builtin: reduce
Damian Conway wrote:
>
> But ^1, ^2, etc. have *nothing* to do with $1, $2, except analogically.
> And I'm removing that analogy from the next version of the RFC! ;-)
>
> They have *everything* to do with $_[0], $_[1], $_[2], etc.
I realize this, but I don't think most people will see it that way. I
see the analogy part much more clearly. Having ^1 and $1 be the same
makes a lot more sense than having $1 and ^0 both be the start.
Why? Consistency is key. With arrays, people understand that [0] is the
first element because they're dealing with a computer.
But with regexps (and HOFN), we're now into stuff that's good for
humans. And the "First" element should be "^1", just like for regexps.
Unless you want to start telling people that the "Zeroeth" element is
"^0".
But having the "First" element be "0" makes *no* sense. Not for humans.
It never has.
> In fact, every kind of indexing in Perl -- *except* $1, $2, etc. --
> starts at zero. Fixing $0's semantics would be far more consistent than
> breaking ^0.
That's fine too - if we want to do this, let's! Honestly. I say:
1. Make $ARGV[0] have the program name
2. Make $0 be the first regexp match
But I see two problems with this:
1. Now "for (@ARGV) breaks"
2. The "first" argument is now "0" again
Please! Make the "first" be ^1. It's more consistent and makes more
sense for us humans.
We're not "breaking ^0" either - it doesn't exist yet. Rather, we're
fixing it before the bug hits the customer. I guarantee you this will be
a common mistake, I've done tons of work in real-life user-interface
testing. Users see *simple* analogies, not deep ones ("^1 like $1, the
first one")
If I ask you to count to ten, which number do you start with?
-Nate
Re: RFC 76 (v1) Builtin: reduce
> > "Array and placeholder indices both start at *zero*!" > > Sorry for being late, but "why?!" > > It makes more sense in a vacuum, but given $1, $2, etc, I'd *much* more > expect them to start with ^1, ^2, and so on. It's much more consistent. But ^1, ^2, etc. have *nothing* to do with $1, $2, except analogically. And I'm removing that analogy from the next version of the RFC! ;-) They have *everything* to do with $_[0], $_[1], $_[2], etc. In fact, every kind of indexing in Perl -- *except* $1, $2, etc. -- starts at zero. Fixing $0's semantics would be far more consistent than breaking ^0. Damian
RFC 168 (v1) Built-in functions should be functions
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Built-in functions should be functions
=head1 VERSION
Maintainer: Johan Vromans <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 168
=head1 ABSTRACT
RFC 26 proposes to eliminate the distinction between functions and
operators from a language perspective.
This RFC proposes that all Perl built-in functions should be usable in
all ways normal functions can be used. It is part of a big consipracy
to remove the number of cases with exceptional behaviour in Perl.
=head1 DESCRIPTION
Named operators, like C, can be called like functions in which
case they behave like functions. However, that's where the similarity
ends. You cannot override most builtins, and cannot tack a reference
to them.
There is no reason why the built-ins should be treated differently. A
famous Perl saying reads "if it looks like a function, it B a
function." So be it.
In particular, it is desired that every built-in
=over 4
=item *
can be overridden by a user defined subroutine;
=item *
can have a reference taken;
=item *
has a useful prototype.
=back
=head2 Overriding
The principle of least surprise dictates that
sub I { return 10 }
print I();
should call I() and print "10" for all I.
Currently, most built-ins are excluded from this. For example:
sub system { return 10 }
print system();
Instead of calling the user defined system(), the built-in is used.
The second line may give a warning, but only if warnings are enabled:
Ambiguous call resolved as CORE::system(), qualify as such or use &
=head2 References
You can call a built-in, but not take a reference.
$a = \&system;
print $a->(-1)
This gives an error:
Undefined subroutine &main::system called
This should return a reference to the built-in instead.
Since C<&>I implicitly refers to the current package, it would be
acceptible to require
$a = \&CORE::system;
Note that this currently (5.7.0 DEVEL6806) results in the error:
Undefined subroutine &CORE::system called
which is surprising, if not misleading.
=head2 Prototypes
Currently, several built-ins do not provide prototype information.
prototype("CORE::abs") ==> ;$
prototype("CORE::shift") ==> undef
This must be fixed. One might even call this a bug, although the
current prototype mechanism is not powerful enough to cope with all
built-ins.
=head1 REFERENCES
RFC 26: Named operators versus functions
Tom Christiansen in <12231.967154045@chthon> (perl6-internals, Aug 24, 2000).
RFC 162 (v1) Filtering Here Docs
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Filtering Here Docs =head1 VERSION Maintainer: Richard Proctor <[EMAIL PROTECTED]> Date: 27 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 162 =head1 ABSTRACT With a here doc print <
RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Here Docs Terminators (Was Whitespace and Here Docs) =head1 VERSION Maintainer: Richard Proctor <[EMAIL PROTECTED]> Date: 16 Aug 2000 Last Modified: 27 Aug 2000 Mailing List: [EMAIL PROTECTED] Version: 2 Number: 111 =head1 ABSTRACT With a here doc print <
RFC 45 (v2) C<||> and C<&&> should propagate result context to both sides
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE C<||> and C<&&> should propagate result context to both sides =head1 VERSION Maintainer: Peter Scott <[EMAIL PROTECTED]> Date: 5 Aug 2000 Last-Modified: 26 Aug 2000 Mailing List: [EMAIL PROTECTED] Version: 2 Number: 45 =head1 ABSTRACT Currently the expressions lvalue = expr_A || expr_B lvalue = expr_A && expr_B evaluate C in scalar context, regardless of the type of C, only propagating list or scalar context to C. This proposal is that the context of C should be propagated to C as well. =head1 DESCRIPTION It would be nice to be able to say @a = @b || @c instead of having to resort to @a = @b ? @b : @c The reason that it is not currently possible is that C<@b> (or the list expression in its place) has to be evaluated in scalar context to determine whether to evaluate C<@c>, and that propagating context to C<@b> would require reevaluating it, which might have undesirable side effects (instead of C<@b>, it might be C). Tom Christiansen pointed out that for consistency, both C<||> and C<&&> need to be changed, since in the latter case, if C<@b> is empty, then C<@a> will currently get the single element 0. We want it to get an empty list. =head1 IMPLEMENTATION It seems that it ought to be possible to evaluate something in a list context and test whether there are any entries in the resulting list without having to reevaluate the expression in a scalar context. The work-around with the trinary operator also evaluates C<@b> twice (which H.Merijn Brand pointed out could even be tied and hence evaluation not idempotent). It's true that we are evaluating something in list context and then applying a boolean interpretation to the result (empty list is false, otherwise true); in this case we are trading a lesser consistency (likely only to be appreciated by someone who's been thinking for a long time about contexts) for a greater one. =head1 IMPACTS L would require a different interpretation, namely that the result would be the list formed by applying C<&&> or C<||> to each successive pair of elements in C<@b> and C<@c>. This author likes the idea of certain component-wise operators, and appreciates the importance of consistency, but just can't see a component-wise interpretation of the logical operators being either useful or intuitive. =head1 REFERENCES L L, "Replace C with a generic C function" L, "Apply operators component-wise in a list context"
RFC 4 (v2) type inference
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
type inference
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 1 Aug 2000
Last Modified: 27 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 4
=head1 ABSTRACT
Types should be inferred whenever possible
=head1 CHANGES
Removed static type declarations. That should be another RFC.
=head1 DESCRIPTION
For large systems, and often for small ones, type checking is
extremely valuable for optimization and error detection. It is
particularly useful when trying to make global changes without
introducing major errors by forgetting to update code. I propose that
we create a type hierarchy, such as
any
list
list(T)
hash
hash(T1 -> T2)
scalar
reference
object of class T
ref(T)
nonref
number
integer
void
(This is just a sketch; there are many ways of skinning this cat.)
Types will be inferred based on constants and operators. The inference
process would assign a type or set of possible types to every node in
the parse tree. Variables would not have a single type (unless
explicitly constrained by a declaration); 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. The effects of line 4 depend on the implementation. Possible
results include C<< hash(nonref -> scalar) >> and the union type C<<
hash(nonref -> ref(nonref)) union hash(nonref -> nonref) >>. Line 5's
effect depends on whether C's type is known. If not, then I<$x>
will have type C after line 5.
Note that so far, all existing programs will always typecheck
successfully, so no burden has been placed on the programmer who does
not want types. Also note that the linear, 1-pass process above is a
dramatic oversimplification of a realistic type inference algorithm.
=head1 MIGRATION
None required. The output of p52p6 may be run through the inferencer,
but not even native Perl6 code will be required to make it through the
type inferencer without errors.
=head1 IMPLEMENTATION
Still being thought out. I'm hoping to use Ole Agesen's CPA (Cartesian
Product Algorithm) to deal with functional polymorphism, and some
variant of Plevyak and Chien's iterative algorithm to deal with the
harder problem of data polymorphism.
=head2 ISSUES
There are several problematic constructs for type inferencing.
=over 4
=item eval""
Eval"" by default forces the type inferencer to assume the worst for
all subroutine, all global variables, and all lexical variables
captured by a closure. Only very local inference will remain. This
could be controlled by new pragmas, for example a non-overridable
attribute for subroutines (so that its slot in the symbol table will
remain constant), or a pragma to assume that eval"" is read-only with
respect to the symbol table and all variables.
=item symbolic dereferencing
C<< $x->f() >> is a tricky case because $x may be either a reference
or a package name, and determining which C is being called
requires value inference on C<$x>. A pragma disallowing non-constant
symbolic dereferencing with the arrow operator would help
(C<< Package->f() >> is not problematic).
=item AUTOLOAD
Really just an example of the problems of symbol table manipulation
with respect to type inference. AUTOLOAD means that any function whose
name is not known at compile time (or I not be known, as in
C<< $x->$f() >>), must conservatively be assumed to be autoloaded and
execute an eval"" that discards almost all type information.
=item modularity (caching type information)
The efficiency of powerful type inferencing algorithms isn't all that
good, and my intuition says that Perl6 is going to need all the power
it can get. Much efficiency can be gained by, for example, maintaining
type information for a module along with its bytecode. (This type
information is more than just the outcome of type inference. It needs
to include templates describing how types propagate through each
subroutine of the module, since modules will generally allow much more
polymorphism than will actually be used in a particular program.)
=back
=head1 REFERENCES
Ole Agesen. Concrete Type Inference : Delivering Object-Oriented
Applications. PhD thesis, Department of Computer Science of Stanford
University, Published by Sun Microsystem Laboratories (SMLI TR-96-52),
1996.
It's a long thesis, but it's by far the most clear description of type
inferencing that I've found. He uses almost no formulas, and instead
describes things in terms of graphs and pictures. He has a much
shorter paper that summarizes his contributions that I haven't read
yet.
John Plevyak, Andrew A. Chien. Iterative Flow Analysis.
Re: RFC 76 (v1) Builtin: reduce
Damian Conway wrote: > >> Well, RFC 23 doesn't mention ^0, and has several examples starting >> at ^1. And it draws the analogy between ^1, ^2, etc and $1, $2, >> etc. I didn't make it up. > > My apologies. The examples you refer to are incorrect. They were added by > a helper, but the responsibility is mine -- for not checking them > thoroughly enough. > "Array and placeholder indices both start at *zero*!" Sorry for being late, but "why?!" It makes more sense in a vacuum, but given $1, $2, etc, I'd *much* more expect them to start with ^1, ^2, and so on. It's much more consistent. Unless we move the program name out of $0 and redo regexp's... [1] -Nate [1] Suggest this and I will kill you. :-)
Re: On the case for exception-based error handling.
At 10:20 AM 8/27/00 -0400, Bennett Todd wrote:
>I'd usually rather just say
>
> my $fh = open $filename;
>
>and be done with it, but then I'd always "use Fatal qw(:all);". But
>if I'd done such a "use Fatal", and then wanted to catch one, I sure
>hope I wouldn't have such a rabid try/catch bru-ha-ha inflicted on
>me; couldn't I just say
>
> my $fh = eval { open $filename } or whatever ...;
>
>die/eval works really sweetly; I haven't figured out why people
>want to replace eval { BLOCK } with try/catch. If you want more
>structured data in the exception, make $! an arbitrary complex
>object that stringifies to the text message.
We're proposing exactly that. RFC 88 refers to $@ as that variable; RFC
151 proposes merging $@ into $!. And eval BLOCK should work exactly the
same way in Perl 6 as it does now, so you will indeed be able to do what
you propose. (This is my position and RFC 88's position, but there are
disagreements.)
(Nearly) everrrybuddy heppy :-)
--
Peter Scott
Pacific Systems Design Technologies
Re: On the case for exception-based error handling.
2000-08-22-15:13:23 Peter Scott:
> I too would rather say
>
> my $fh = open $filename or die "Couldn't copy source: $!"
>
> than
>
> my $fh; try { $fh = open $filename } catch { die "Couldn't copy
> source: ", $@->syserr }
I'd usually rather just say
my $fh = open $filename;
and be done with it, but then I'd always "use Fatal qw(:all);". But
if I'd done such a "use Fatal", and then wanted to catch one, I sure
hope I wouldn't have such a rabid try/catch bru-ha-ha inflicted on
me; couldn't I just say
my $fh = eval { open $filename } or whatever ...;
die/eval works really sweetly; I haven't figured out why people
want to replace eval { BLOCK } with try/catch. If you want more
structured data in the exception, make $! an arbitrary complex
object that stringifies to the text message.
> Module authors should also be able to take advantage of Fatal.pm.
> "use Fatal" should set something that can be checked by any
> programmer (heck, that doesn't even have to be restricted to
> module authors; the creator of an insanely large program might do
> it). The programmer can use this to decide whether to throw an
> exception or return. [Bennett, this impacts RFC 70 in IMHO a good
> way; you may consider expanding its scope to be not just binding
> on the core, but advisory for everything else. Perhaps suggest an
> interface whereby user code can see what the setting is.]
I beat you to it. While RFC 70 was intended to just request that it
be possible to finish Fatal.pm so it works as intended and desired,
it does mention:
If [the finishing-up of Fatal.pm, after fixing the busted core]
were a success, then the requested category could also be posted
into a testable variable, allowing module authors who wished to
to automatically support this functionality as well.
:-)
-Bennett
PGP signature
Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@>
> : That numerical part could then form the basis of the extended exception > : mechanism. No, the programmer shouldn't memorize the error numbers: > : there should be predefined constants, like > : > : ERROR::filenotfound > : > : which are numeric, and which could then be used for the catch switch. > : Well, maybe drop the "ERROR::" part for brevity -- but not for clarity. > > I think I agree with the folks that say errors should be caught by > type, not by number. Just as a for instance, you ought to able to > write a simple handler that catches any ERRNO-style error. Yup. Enumerating errors/warnings is awkward because it says you know beforehand all your possible errors/warnings. It is very static and non-extensible--having to recompile your Perl if you add/delete/change errors/warnings isn't exactly dynamic. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: READ THIS: Re: My Wish
Bart Lateur wrote: > Next, you'll say that every idea must be actually submitted as an RFC > before being worthy of discussion. Have to say, I agree with Bart on this. While being in the RFC format was distracting, far better that he dumped them straight to the list before submitting them as real RFC's, for exactly the reasons Skud mentioned. -- John Porter We're building the house of the future together.
Re: READ THIS: Re: My Wish
On Sat, 26 Aug 2000 19:04:48 +1000, [EMAIL PROTECTED] wrote: >Righto. I'll coach Sumesh through how to post an RFC properly, and how >to check whether something's in Perl yet or not. > >DO NOT fill -language with discussions of these pseudo-RFCs. Please. >I'm begging you. I don't get it. There are plenty of wild ideas thrown into this list, pre-RFC's if you like. There usually is some discussion on this idea before it actually is submitted as an RFC, or simply forgotten. IMO this should apply to Suresh Kumar .R's ideas as well. The fact that he poored them into the RFC format is irrelevant. Next, you'll say that every idea must be actually submitted as an RFC before being worthy of discussion. -- Bart.
Re: RFC 45 (v1) || should propagate result context to bo
On 5 Aug 2000 21:40:43 -, Perl6 RFC Librarian wrote: >It would be nice to be able to say > > @a = @b || @c > >instead of having to resort to > > @a = @b ? @b : @c Would it? It looks like a small win, unless @b is actually a list instead of just an array. Currently, || is a scalar operator. It makes sense that way. Oh, there are proposals to make @a = @b + @c; do the calculation on an element by element basis. If that is accepted, I think this should apply to || as well. -- Bart.
