RFC 259 (v1) Builtins : Make use of hashref context for garrulous builtins

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Builtins : Make use of hashref context for garrulous builtins =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 19 September 2000 Mailing List: [EMAIL PROTECTED] Number: 259 Versi

RFC 258 (v1) Distinguish packed binary data from printable strings

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Distinguish packed binary data from printable strings =head1 VERSION Maintainer: Tim Conrow <[EMAIL PROTECTED]> Date: 18 Sept 2000 Mailing List: [EMAIL PROTECTED] Number: 258 Version: 1 Status:

Pre-withdrawal notice for RFC184

I'm planning to withdraw RFC184 ("Perl should support an interactive mode"), due to lack of interest. There was little discussion of it, and the consensus seemed to be that C is "good enough" for most purposes, and C for all others. While I do not agree, it does mean there is no call for this R

Re: RFC 213 (v1) rindex and index should return undef on failure

Chaim Frenkel wrote: > > "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes: > > GL> There is a difference between "undefined" and "unknown". > > GL> Perl undefined is a different concept--that of an uninitialized > GL> variable. This is proven from its earliest versions where the > GL> valu

state of the language WG

Morning all, This email forms my latest semi-official report on the state of the Perl 6 Language WG, and also begs the forbearance of the Perl 6 community as I go through a slightly difficult time personally. I've been fairly quiet on -language and -meta because everything seems to be moving alo

Re: RFC 213 (v1) rindex and index should return undef on failure

> "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes: GL> There is a difference between "undefined" and "unknown". GL> Perl undefined is a different concept--that of an uninitialized GL> variable. This is proven from its earliest versions where the GL> value is coerced to 0 or '' (specific

Re: pack/unpack is damn unperlish. Explain them as Perl.

> "ST" == Sam Tregar <[EMAIL PROTECTED]> writes: ST> I think you're talking about unpack() here, which I've only used once. I ST> think unpack() is usually replaceable by substr() or regexes. Contrast ST> that with pack() for which no equivalent replacement is possible, as far ST> as I know

Re: RFC 230 (v2) Replace C built-in with pragmatically-induced C function

> > The function itself would be called C and would be > > imported with a C pragma. > > Much better, but I don't think you mean "pragma", and in fact I'm pretty > sure you know that, but you still need to s/pragma/module/g. I think the > title should be changed to something lik

Re: RFC 230 (v2) Replace C built-in with pragmatically-induced C function

> The function itself would be called C and would be > imported with a C pragma. Much better, but I don't think you mean "pragma", and in fact I'm pretty sure you know that, but you still need to s/pragma/module/g. I think the title should be changed to something like Replace C and C built-i

RFC255: Fix iteration of nested hashes

> This RFC proposes that the internal cursor iterated by the C function > be attached to the instance of C (i.e. its op-tree node), In the past, this has been a mistake, because it breaks the identity of closures. For example, with your proposal, the following code, which works now, will no lo

Re: 'eval' odd thought

Bart Lateur: > If your P5->P6 translator is slow, i.e. written > in Perl, this would imply a pretty big performace hit. It is better for translated programs to do the right thing slowly than to do the wrong thing as quickly as possible. > What would help is a debugging mode that prints out the

RFC 257 (v1) UNIVERSAL::import()

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE UNIVERSAL::import() =head1 VERSION Maintainer: Michael G Schwern <[EMAIL PROTECTED]> Date: 18 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 257 Version: 1 Status: Developing =head1 ABSTRACT

RFC 255 (v1) Fix iteration of nested hashes

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Fix iteration of nested hashes =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 18 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 255 Version: 1 Status: Developing =head1 A

RFC 230 (v2) Replace C built-in with pragmatically-induced C function

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Replace C built-in with pragmatically-induced C function =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 15 Sep 2000 Last Modified: 18 Sep 2000 Mailing List: [EMAIL PROTECTED] N

RFC 195 (v3) Retire chop().

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Retire chop(). =head1 VERSION Maintainer: Nathan Torkington <[EMAIL PROTECTED]> Date: 5 Sep 2000 Last Modified: 18 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 195 Version: 3 Status: Froze

RFC 84 (v2) Replace => (stringifying comma) with => (pair constructor)

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Replace => (stringifying comma) with => (pair constructor) =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 10 Aug 2000 Last Modified: 18 Sep 2000 Mailing List: [EMAIL PROTECTED]

RFC 70 (v4) Allow exception-based error-reporting.

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Allow exception-based error-reporting. =head1 VERSION Maintainer: Bennett Todd <[EMAIL PROTECTED]> Date: 8 Aug 2000 Last Modified: 18 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 70 Version:

RFC 55 (v2) Compilation: Remove requirement for final true value in require-d and do-ed files

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Compilation: Remove requirement for final true value in require-d and do-ed files =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 7 Aug 2000 Last Modified: 18 Sep 2000 Mailing Lis

RFC 54 (v2) Operators: Polymorphic comparisons

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Operators: Polymorphic comparisons =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 7 Aug 2000 Last Modified: 18 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 54 Version: 2

RFC 42 (v3) Request For New Pragma: Shell

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Request For New Pragma: Shell =head1 VERSION Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]> Date: 5 Aug 2000 Last Modified: 18 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 42 Version: 3

RFC 25 (v2) Operators: Multiway comparisons

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Operators: Multiway comparisons =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 4 Aug 2000 Last Modified: 18 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 25 Version: 2 S

RFC 24 (v2) Data types: Semi-finite (lazy) lists

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Data types: Semi-finite (lazy) lists =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 4 Aug 2000 Last Modified: 18 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 24 Version:

RFC 22 (v2) Control flow: Builtin switch statement

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Control flow: Builtin switch statement =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 4 Aug 2000 Last Modified: 18 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 22 Version

Re: Beefier prototypes (was Re: Multiple for loop variables)

Tom asked how we'd deal with variadic subroutines without sacrificing compile-time information (i.e. parameter lists). Below I've indicated how RFC 128 would handle the cases he lists. To recap: RFC 128 proposes that parameters may be given a C<:repeat> attribute to make them variadic within a

Re: RFC 230 (v1) Replace C built-in with pragmatically-induced C function

> >I propose that the existing C mechanism be removed from Perl 6 > >and be replaced with a pragma-induced add-in function, based on > >the semantics of C, as described in > >the following sections. > > Can you please explain what's the difference between a module and a > pr

Re: RFC 230 (v1) Replace C built-in with pragmatically-induced C function

On 15 Sep 2000 19:18:18 -, Perl6 RFC Librarian quoted Damian Conway: >I propose that the existing C mechanism be removed from Perl 6 >and be replaced with a pragma-induced add-in function, based on >the semantics of C, as described in >the following sections. Can you please explain what's t

Re: pack/unpack is damn unperlish. Explain them as Perl.

On Mon, 18 Sep 2000, Michael G Schwern wrote: > On Mon, Sep 18, 2000 at 12:32:08PM -0400, Sam Tregar wrote: > > If I grok'd the bastards, I'd write the explaination myself. If you grok'd the bastards I bet you'd realize how useless such an explanation would be. The chief reason for using pack/

Re: RFC 252 (v1) Interpolation of subroutines

On Mon, Sep 18, 2000 at 11:37:50AM -0700, Glenn Linderman wrote: > > Parens are also mandatory if > > arguments are to be passed. > > And I guess the balancing of the parens would solve many of the > problems of argument parsing for the function, which is a concern to > me. Within actual double

Re: RFC 213 (v1) rindex and index should return undef on failure

At this point, I think the whole thread on functions throwing exceptions should either be: (a) turned into an RFC or (b) abandoned. This discussion is going around and around like a piece of toilet paper in a weakly-flushing toilet. Nat

Re: RFC 230 (v1) Replace C built-in with pragmatically-induced C function

> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> This would work: DC> footer => sub { "$From - $To" } DC> except there's no way of setting the $From and $To variables as DC> each page is formatted. I don't think C by itself is the DC> right solution for this problem, unless I add

Re: RFC 213 (v1) rindex and index should return undef on failure

John Porter wrote: > Glenn Linderman wrote: > > > > The idea of a _normal_ situation being considered exceptional is raised when the > > code written inappropriately handles some of the normal return values. > > You would throw exceptions at the problem of bad coding practice. Not the goal. The

Re: RFC 252 (v1) Interpolation of subroutines

Perl6 RFC Librarian wrote: > The & is mandatory. Which makes me happy with this proposal > Parens are also mandatory if > arguments are to be passed. And I guess the balancing of the parens would solve many of the problems of argument parsing for the function, which is a concern to me. Within

Re: pack/unpack is damn unperlish. Explain them as Perl.

Michael G Schwern writes: > You can do it! While it seems "food" and "supermarket" are critical > to the understanding of a shopping-cart, they're really just > incedental. I'm saying the same thing about un/pack! > > If I grok'd the bastards, I'd write the explaination myself. Please take thi

Re: pack/unpack is damn unperlish. Explain them as Perl.

On Mon, Sep 18, 2000 at 12:32:08PM -0400, Sam Tregar wrote: > "Describe to me how you use a supermarket shopping-cart in terms of a > hardware store. Don't mention any words for food. Just talk about nuts > and bolts." "When shopping for tools, a shopping-cart is the thing you carry your tools

Re: pack/unpack is damn unperlish. Explain them as Perl.

On Mon, Sep 18, 2000 at 12:31:34PM -0400, Casey R. Tweten wrote: > I think pack/unpack are perlish enough. Especially if we believe that > printf/sprintf are perlish. Interpolation is perlish. printf and sprintf are not. And for similar reasons as pack/unpack. "%e a floating-point number, in

Re: RFC 213 (v1) rindex and index should return undef on failure

Glenn Linderman wrote: > > There is a difference between "undefined" and "unknown". Can you explain this difference, briefly? If not, could you give me something off-list? Thanks, John Porter

Re: RFC 213 (v1) rindex and index should return undef on failure

Glenn Linderman wrote: > > The idea of a _normal_ situation being considered exceptional is raised when the > code written inappropriately handles some of the normal return values. You would throw exceptions at the problem of bad coding practice. I think it's better to correct the bad coding p

Re: RFC 253 (v1) UNIVERSAL::require()

Michael G Schwern wrote: > > It all works. Mokay... > DTRT? Data Terminal Ready, Tim? Document Filing and Retrieval Tedium? Do The Right Thing, of course. -- John Porter

Re: RFC 253 (v1) UNIVERSAL::require()

On Mon, Sep 18, 2000 at 11:20:15AM -0400, John Porter wrote: > Seems to me that it would need to be written as > > $module->UNIVERSAL::require; > > How do you propose to avoid that? What is a class but a package? And what is the name of a class but a package name? And since there's no c

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

On 15 Sep 2000, at 11:25, Steve Fink wrote: > Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'? While 'foo\\' ne 'foo\' :-) (specifically, the former is not a syntax error :-) Cheers, Philip

Re: RFC 213 (v1) rindex and index should return undef on failure

Chaim Frenkel wrote: > What about a hypothetical, use tristate. This would give undef some > extra special powers. There is a difference between "undefined" and "unknown". SQL NULL, and the resultant tristate operators used in SQL, specifically is based on NULL representing the "unknown" value.

Re: RFC 213 (v1) rindex and index should return undef on failure

Chaim Frenkel wrote: > > "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes: > > >> Neither is EOF on a file, or working with an empty list. Adding all these > >> exceptions for non-exceptional and quite common scenerios is bothersome. > > I don't know where this idea of a _normal_ situation

Re: RFC 223 (v1) Objects: C pragma

On Mon, Sep 18, 2000 at 10:16:46AM -0400, John Porter wrote: > Hildo Biersma wrote: > > IMHO, mixing procedural and OO interfaces to the same module is a bad > > idea. Promoting it in the language is not wise. > > O.k., but that's not the same as disallowing it. Perl is not a B&D > language. I

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

>But Tom, that preserves all the white space both before and after the '!'! >Michael's goal is to eliminate the leading white space, although he didn >'!' bit. So I'm not sure how you'd have written that if you'd have done >specification. Yeah, ok. I still think # Your stuff that you w

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

Tom Christiansen wrote: > I am certainly in strong favor of a simple and visually distinctive > solution, and find that the leading bit helps a lot. But I would probably > have written that as: > > die < !The old lie > ! Dulce et decorum est > ! Pro patria mori. > P

Re: pack/unpack is damn unperlish. Explain them as Perl.

Today around 12:32pm, Sam Tregar hammered out this masterpiece: : On Mon, 18 Sep 2000, Michael G Schwern wrote: : : > Perhaps someone could attempt to write an explaination of pack and : > unpack in completely Perl terms. No bits, no ints, no nybbles, no : > IEEE floating point arithmetic, no p

Re: pack/unpack is damn unperlish. Explain them as Perl.

On Mon, 18 Sep 2000, Michael G Schwern wrote: > Perhaps someone could attempt to write an explaination of pack and > unpack in completely Perl terms. No bits, no ints, no nybbles, no > IEEE floating point arithmetic, no prior knowledge of C necessary. > Those are not Perl. Scalars, arrays, hash

Re: Accessing a variable's attributes (was Re: RFC 241 (v1) ...)

Simon Cozens wrote: > > (The deadline for collecting ideas passed two weeks ago. Why is this all > still going on?) Because there are still many worthy ideas which have not surfaced yet. Which is the higher priority? -- John Porter We're building the house of the future together.

Re: RFC 253 (v1) UNIVERSAL::require()

Nathan Wiger wrote: > > Huh? All classes inherit from UNIVERSAL implicitly. Yes, but at that point in the execution, $module is not a class. > It's the same reason you can write: > >$module->can('dance'); Once upon a time this was not possible. I guess it has changed. -- John Porter

RE: $a in @b (RFC 199)

From: Tom Christiansen [mailto:[EMAIL PROTECTED]] > From: Garrett Goebel > > There seems to be some general consensus that some people > > would like to be able to short-circuit functions like > > grep. Do you see no need for the code > > block equivalent of C/C/C? > > What, you mean like > >

Re: RFC 253 (v1) UNIVERSAL::require()

John Porter wrote: > > > As a solution, a UNIVERSAL:::require() method can be added with the following > > syntax: > > > > $module = "Some::Module"; > > $module->require; > > Seems to me that it would need to be written as > > $module->UNIVERSAL::require; > > How do you propose

Re: pack/unpack is damn unperlish. Explain them as Perl.

Michael G Schwern wrote: > > Perhaps someone could attempt to write an explaination of pack and > unpack in completely Perl terms. No bits, no ints, no nybbles, Uh huh... Are you prepared to write an explanation of Perl arrays without making any mention of Perl scalars? -- John Porter

Re: RFC 253 (v1) UNIVERSAL::require()

> As a solution, a UNIVERSAL:::require() method can be added with the following > syntax: > > $module = "Some::Module"; > $module->require; Seems to me that it would need to be written as $module->UNIVERSAL::require; How do you propose to avoid that? > What should happen if

Re: RFC 252 (v1) Interpolation of subroutines

Tom Christiansen wrote: > > And what if it's a built-in? What if it's not quite a built-in, > but an import? What if you don't *know* whether it's a built-in? I would hope that the distinction (at the syntactic level) goes away. (Except for the small set of exceptional built-ins, which clearly

Re: Accessing a variable's attributes (was Re: RFC 241 (v1) ...)

At 04:04 PM 9/18/00 +0100, Simon Cozens wrote: >On Mon, Sep 18, 2000 at 10:51:52AM -0400, John Porter wrote: > > I would think that if it could be done at all, > > it would only be in extension (formerly XS) code. > >Why? I don't want to go to C just to add a flag to a variable. That smacks of >ma

Re: $a in @b (RFC 199)

>From: Tom Christiansen [mailto:[EMAIL PROTECTED]] >> From: Jarkko Hietaniemi >> >> >I find this urge to push exceptions everywhere quite sad. >> >> Rather. >> >> Languages that have forgotten or dismissed error returns, turning >> instead to exceptions for everything in an effort to make the c

RE: $a in @b (RFC 199)

From: Tom Christiansen [mailto:[EMAIL PROTECTED]] > From: Jarkko Hietaniemi > > >I find this urge to push exceptions everywhere quite sad. > > Rather. > > Languages that have forgotten or dismissed error returns, turning > instead to exceptions for everything in an effort to make the code > "sa

Re: Accessing a variable's attributes (was Re: RFC 241 (v1) ...)

On Mon, Sep 18, 2000 at 10:51:52AM -0400, John Porter wrote: > Are all the possible attributes going to be predefined, or can the > user define new ones? The user should be able to do anything they damn well like. This is, allegedly, Perl, which means it's about making it easy to do what the pro

Re: RFC 244 (v1) Method calls should not suffer from the action on a distance

>> foo->bar($baz, $coon) >> should be made synonymous with >> foo->bar $baz, $coon >> >> I can see no ambiguity in this call, but it not always works with Perl5. Arrow invocation does not a listop make. Only indirect object invocation style does that. print STDOUT $foo, $bar, $glarch;

Re: RFC 244 (v1) Method calls should not suffer from the action on a distance

Nathan Wiger wrote: > > This RFC proposes to remove indirect object syntax > > Please show me how to write: > >print STDERR @stuff; > > without it, while keeping it a method of the STDERR filehandle, and > without requiring ->. Hopefully STDERR as a "filehandle" is going away. Assuming it

Re: RFC 244 (v1) Method calls should not suffer from the action on a distance

> 'foo'->bar($baz) > > looks visually clattered, but C> looks as if it expresses > its meaning. The default choice is done so that if you need other > choice, your code does not look artificial. Hear, hear! > foo->bar($baz, $coon) > > should be made synonymous with > > foo

Accessing a variable's attributes (was Re: RFC 241 (v1) ...)

Peter Scott wrote: > > How about an attribute for hashes: > > my %foo : fixed; Has anyone talked about the ability to access the attributes attached to a variable? Are all the possible attributes going to be predefined, or can the user define new ones? I would think that if it coul

Re: Beefier prototypes (was Re: Multiple for loop variables)

[This somewhat elderly draft was found lying about an edit buffer, but I do not believe it was ever sent yet.] >Now, the possibility to either pass individual scalars to a sub, or an >array, (or several arrays, or a mixture of arrays and scalars) and Perl >treating them as equivalent, t

Re: Backtracing contexts with self($n) (was Re: RFC 223 (v1) Objects: C pragma)

Hildo Biersma wrote: > > Look, there's a reason we have objects - they encapsulate state. If a > module supports objects and procedural calls, in the latter case it will > either need a handle to the state (objects by anoither name), or will > store the state internally. If the module stores th

Re: RFC 223 (v1) Objects: C pragma

Hildo Biersma wrote: > > > I think such modules are a bad idea, because their functionality is > > > typically restricted. > > An example of this is the CGI module. You consider CGI.pm an example of a module with restricted functionality? > IMHO, mixing procedural and OO interfaces to the same

Re: RFC 252 (v1) Interpolation of subroutines

On Mon, 18 Sep 2000 01:22:31 -0600, Tom Christiansen <[EMAIL PROTECTED]> wrote: > Surely the next request will be to make anything that works outside > of quotes work inside of them, completely erasing the useful visual > distinction. Why should operators, after all, be any different > from funct

Re: RFC 223 (v1) Objects: C pragma

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Objects: C pragma > > =head1 VERSION > > Maintainer: Damian Conway <[EMAIL PROTECTED]> > Date: 14 September 2000 > Mailing List: [EMAIL PRO

Re: RFC 230 (v1) Replace C built-in with pragmatically-inducedC function

> >print format $fmt, @stuff; > > Early brain-dump. This should be it. That's what I've done for the second version (on its way soon). Damian

Re: RFC 230 (v1) Replace C built-in with pragmatically-inducedC function

On Fri, 15 Sep 2000 20:13:34 -0700, Nathan Wiger <[EMAIL PROTECTED]> wrote: > > I loathe the indirect object syntax. > > Well that makes one of us! ;-) > > > Easy. Put them in a subroutine: > > > > sub format1 { format $template1, @data }; > > sub format2 { print STDERR format $

Re: RFC 252 (v1) Interpolation of subroutines

On Mon, Sep 18, 2000 at 01:16:43AM -0600, Tom Christiansen wrote: > Huh? And what if it's a built-in? What if it's not quite a built-in, > but an import? What if you don't *know* whether it's a built-in? Easy enough, built-ins shouldn't be special (I'm speaking in general, not just when interp

Re: RFC 252 (v1) Interpolation of subroutines

Surely the next request will be to make anything that works outside of quotes work inside of them, completely erasing the useful visual distinction. Why should operators, after all, be any different from functions? print "I have Fooey->fright($n) frobbles.\n"; print "I have &snaggle($n)

Re: RFC 252 (v1) Interpolation of subroutines

>Subroutines calls should interpolate in double-quoted strings and similar >contexts. >print "Sunset today is at &sunset($date)"; >interpolates to: >print 'Sunset today is at '.sunset($date); Huh? And what if it's a built-in? What if it's not quite a built-in, but an import? What if

Re: RFC 253 (v1) UNIVERSAL::require()

On Sun, Sep 17, 2000 at 11:22:36PM -0700, Nathan Wiger wrote: > We should probably consider a UNIVERSAL::import too, perhaps to either > take over Exporter's or at least make sure things work right. In > particular I'm thinking in the context of a couple RFC's: > >RFC 74 (v3): Proposal to ren