Re: RFC 34 (v1) Angle brackets should not be used for fi

Someone wrote: > > How about "Deprecate use of file globbing with angle brackets. Emit a > > warning when this behaviour is used." I want to RFC this, but I feel like starting a new language with deprecated behaviours is a Bad Move. The whole damn point is so we can get away from all the deprec

Re: RFC 34 (v1) Angle brackets should not be used for fi

[EMAIL PROTECTED] wrote: > On Fri, Aug 04, 2000 at 10:13:59PM -, Perl6 RFC Librarian wrote: > >=head1 IMPLEMENTATION > > > >Remove the file-globbing behavior of the angle brackets. > > How about "Deprecate use of file globbing with angle brackets. Emit a > warning when this behaviour is used

Re: RFC 34 (v1) Angle brackets should not be used for fi

On Fri, Aug 04, 2000 at 10:13:59PM -, Perl6 RFC Librarian wrote: >=head1 IMPLEMENTATION > >Remove the file-globbing behavior of the angle brackets. How about "Deprecate use of file globbing with angle brackets. Emit a warning when this behaviour is used." K. -- Kirrily Robert -- <[EMAIL

Re: RFC 10 (v2) Filehandles should use C<*> as a type pr

On Fri, Aug 04, 2000 at 03:04:08PM -0700, Nathan Wiger wrote: >I think this is a good candidate for recording why we decided not to do >something. > >Did we even reach consensus on how to do this? Put a Status: header in >VERSION? > >For recording purposes, maybe once the Status: line is added we

Re: RFC 22 (v1) Builtin switch statement

On Fri, Aug 04, 2000 at 05:16:15PM -0400, John Porter wrote: >Glenn Linderman wrote: >> >> This is not to detract from the ideas of higher order functions or curried >> whatever, but I >> don't think those are or should be necessary to a powerful switch statement. > >I vote thus: to have RFC 22 r

sublist request: perl6-language-io

WORKING GROUP: perl6-language-io CHAIR: Nathan Wiger <[EMAIL PROTECTED]> MISSION:Draft and discuss I/O related RFCs, including (but not limited to) RFCs 14 and 30. DEADLINE: 3 weeks, extensible on request (end August 26) DESCRIPTION:Submit I/O related RF

Re: RFC 22 (v1) Builtin switch statement

Ken Fox wrote: > Then write the switch as: > > switch ( __ ) { > case $v == 1: { ... } > case $v == 2: { ... } > case $v == @foo { ... } > } > > It might take you a little while to get your head around the __ > symbol. I'm not sure it's useful to think of it as a variable; > poiso

sublist request: perl6-language-unlink

WORKING GROUP: perl6-language-unlink CHAIR: Nathan Wiger <[EMAIL PROTECTED]> MISSION:Discuss and redraft RFC 29. Draft and discuss an opposing RFC *or* rename RFC 29 to "ways of dealing with unlink()" and discuss various viewpoints. DEADLINE:

sublist request: perl6-langauge-flow

WORKING GROUP: perl6-language- flow CHAIR: uri guttman <[EMAIL PROTECTED]> MISSION: Draft, discuss, and revise RFCs relating to flow control in Perl 6, eg switch/case, looping, etc. Suggest/request other flowcontrol-related lists if appropriate DEADLIN

Re: RFC 27 (v1) Coroutines for Perl

> "s" == skud <[EMAIL PROTECTED]> writes: s> There is currently no such thing as a sub-sublist. perl6-language-flow s> would not independently spawn perl6-language-flow-switch etc. Instead, s> the chair of -flow could contact me and suggest a new sublist such as s> perl6-language-sw

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

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

Re: RFC 27 (v1) Coroutines for Perl

On Fri, Aug 04, 2000 at 02:34:07PM -0400, Uri Guttman wrote: > >that is a major reason why i want to move all of those rfc's under the >flow one so we can properly address that low level design and language >changes to support them all. i should have my draft rfc done later >tonight and will post

Re: RFC 22 (v1) Builtin switch statement

Glenn Linderman wrote: > For instance, > > if ( $v == @foo ) > > is clearly testing the size of foo against the value of $v. But > > switch ( $v ) { > case 1: { ... } > case 2: { ... } > case @foo { ... } > } > > does not! Then write the switch as: switch ( __ ) { ca

ConwayPerl (was Re: RFC 22 (v1) Builtin switch statement)

Damian Conway said: > switch ( $x < __ ) { > > case 0 { print "negative" } > case 1 { print "unity" } > case any(2..9) { print "small" } > case @list { print "in range" } > } > Now _that's_ the coolest thing I've seen since, well, umm, this morning, when I read the original RFC. Damian, a lot of

RFC 37 (v1) Positional Return Lists Considered Harmf

This and other RFCs are available on the web at http://tmtowtdi.perl.org/rfc/ =head1 TITLE Positional Return Lists Considered Harmful =head1 VERSION Maintainer: Jarkko Hietaniemi <[EMAIL PROTECTED]> Date: 04 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 37 =head1 ABS

Re: RFC 22 (v1) Builtin switch statement

> None of these perform more than one operation per pair of types. By doing the > factoring, you are constraining the type and specific value of the left hand > expression in your matching operation, limiting the set of operations that can > be performed quite severely. > >[

Re: RFC 23 (v1) Higher order functions

Ken Fox wrote: > And neither did you... ;) The last line should be: > > : $_[0] < 2 + $_[1] * atan($pi/$_[2]) or die $_[3] > > That's why curried functions should automatically re-curry themselves > instead of depending upon lazy programmers. ;) > But of course I only included thi

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

On Fri, 04 Aug 2000, Bart Lateur wrote: > I think it's a bad idea. I would rather do it as the C64 did: use a very > short function name as an alternative to "print". > > P "This gets printed!", "\n", "Yeah!\n"; > Unfortunately (for you), you can't use '?' because it would be > ambiguous

Re: RFC 24 (v1) Semi-finite (lazy) lists

> > This RFC proposes that the right operand of a C<..> operator > > may be omitted in a list context, producing a lazily evaluated > > semi-finite list. It is further proposed that operations on > > such lists also be carried out lazily. > > > Why only the right operand? What's

Re: RFC 23 (v1) Higher order functions

> Unless I'm missing something here, you're not filling in the args correctly. > I think you mean: > > $check = sub (;) { > @_==0 ? __ < 2 + __ * atan($pi/__) or die __ > : @_==1 ? $_[0] < 2 + __ * atan($pi/__) or die __ > : @_==2 ? $_[0] < 2

Re: RFC 23 (v1) Higher order functions

Thanks for the useful insights and pointers, Ken. Top stuff (as usual :-) I particularly liked the currying context and notions of explicitly marking curries. Obviously I'll need to de-jetlag a little more and run my brain over it again. However, implicit currying is so damn handy that I suspect

Re: RFC 22 (v1) Builtin switch statement

Damian Conway wrote: >> This switch statement RFC seems to be built on the premise that the >> reason to have a switch statement is to remove a common parameter >> from the following limited form conditional expressions. > > Yes. As I point out in the paper, that's the *nature* of a s

Re: RFC 25 (v1) Multiway comparisons

Jonathan Scott Duff wrote: > On Fri, Aug 04, 2000 at 10:52:24PM -0400, Ken Fox wrote: > > Why would we ever use source filters when we're going to have a > > beautiful extend-syntax macro system. > > Because source filters *are* that macro system. Why would we invent > yet another language withi

Re: RFC 23 (v1) Higher order functions

Jeremy Howard wrote: > Unless I'm missing something here, you're not filling in the args correctly. > I think you mean: > > $check = sub (;) { > @_==0 ? __ < 2 + __ * atan($pi/__) or die __ > : @_==1 ? $_[0] < 2 + __ * atan($pi/__) or die __ > : @_==2 ? $_[0] < 2

Re: RFC 25 (v1) Multiway comparisons

On Fri, Aug 04, 2000 at 10:52:24PM -0400, Ken Fox wrote: > Why would we ever use source filters when we're going to have a > beautiful extend-syntax macro system. Because source filters *are* that macro system. Why would we invent yet another language within a language when we can use a language

Re: RFC 28 (v1) Perl should stay Perl.

Perl6 RFC Librarian wrote: > not because language design is a fun thing to do of an evening. Huh? You mean I'm supposed to pretend to not enjoy myself? I keep all my hair shirts at work, thanks. > If that's the case, nobody wins if we bend the Perl language out of all > recognition, because it w

Re: RFC 24 (v1) Semi-finite (lazy) lists

> This RFC proposes that the right operand of a C<..> operator > may be omitted in a list context, producing a lazily evaluated > semi-finite list. It is further proposed that operations on > such lists also be carried out lazily. > Why only the right operand? What's wrong with @a[..1]? Of cours

Re: RFC 23 (v1) Higher order functions

> $check = sub (;) { > @_==0 ? __ < 2 + __ * atan($pi/__) or die __ > : @_==1 ? $_[0] < 2 + __ * atan($pi/__) or die __ > : @_==2 ? $_[0] < 2 + $_[1] * atan($pi/__) or die __ > : @_==3 ? $_[0] < 2 + $_[1] * atan($pi/$_[1]) or die __ > : $_

Re: RFC 25 (v1) Multiway comparisons

Jonathan Scott Duff wrote: > If implemented via source filters, $x < $y < $z would get translated > to $x < $y && $y < $z, which, of course, short circuits. No need for > "$y (but true)" (Although, we already have "0 but true" until someone > submits an RFC to remove it ;-) Why would we ever u

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

At 09:38 PM 8/4/00 -0400, Ken Fox wrote: >Dan Sugalski wrote: > >$foo = 12; > >$bar = something(); > >$bar = $foo; > > > > could work out to: > > > >$foo = $bar = 12; > >something(); > >If $foo is a lexical variable and it hasn't been aliased then >you might be able to do that

Re: RFC 23 (v1) Higher order functions

[Could we get the librarian to cc: the RFC owner and hide replies from the announcement list?] Perl6 RFC Librarian wrote: > That is, the expression: > > $check = __ < 2 + __ * atan($pi/__) or die __; > > is equivalent to: > > $check = sub (;) { > $_[0] < 2

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

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: : : =head2 Disadvantages : : Literally none have been broached on the various C mailing lists. Potential disadvantage, depending on implementation: The loss of distinctiveness. Right now, when one sees a $ variable, they notice its specialness an

Re: Proposed sublist: flowcontrol

> "CF" == Chaim Frenkel <[EMAIL PROTECTED]> writes: > "UG" == Uri Guttman <[EMAIL PROTECTED]> writes: UG> dispatch - discuss support of the multiple ways to control UG> dispatching of perl ops (event loops, threads, UG> co-routines, etc.) UG> the dispatch list should eventually

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

Dan Sugalski wrote: >$foo = 12; >$bar = something(); >$bar = $foo; > > could work out to: > >$foo = $bar = 12; >something(); If $foo is a lexical variable and it hasn't been aliased then you might be able to do that optimization. The following is just as good and safer: $fo

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

Glenn Linderman wrote: > Now what good meanings could we attribute to $myself and $I > ? Right. Remember, if it looks like Perl (and with the addition of $ME, it will), then it probably is Perl. :) J. David

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

Andy Wardley wrote: > What about '$me'? It ties in nicely with 'my' (although perhaps for the > wrong reasons), it's half as much typing as 'self' or 'this' and we get > to annoy both sets of religious zealots at once. :-)= Yes! I love it!

Re: RFC 29 (v1) unlink() should be left alone

On Fri, 4 Aug 2000, Damien Neil wrote: > My opinion on the unlink()/remove() debate: Ignoring our history is > foolish. Why suddenly transform every Perl program that uses unlink(), > which has been valid for over a decade, into one using an outmoded and > deprecated construct? unlink() is, in

Re: RFC 29 (v1) unlink() should be left alone

Gosh, just unlink() leave it as it is. --tom

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

John Porter wrote: > Glenn Linderman wrote: > > > > What good are comments if you can't find them when you need them? > > There's not thinging to stop you from writing > > qc/*** MAGIC HERE */; Oh so true, but there's nothing that makes me want to do that eith

Re: RFC 29 (v1) unlink() should be left alone

> On Fri, 4 Aug 2000 16:33:41 -0700, Damien Neil wrote (in part): Damien> On Fri, Aug 04, 2000 at 04:39:24PM -0400, Spider Boardman Damien> wrote: >> The C (POSIX.1) remove() function is NOT just unlink() in >> drag. Damien> Not everywhere, at least: Damien> REMOVE(3) FreeBSD Library Functi

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

Karl Glazebrook wrote: > OK I will raise to the bait > > I think it's a bit unfair to say that PDL people have failed to 'bite', > there was quite a bit of discussion on our list after your post. Also > some concern about how much of perl6 is vapourware. > I do apologise, Karl. It turns out that I

Re: PDL-P: indexing

Joshua N Pritikin wrote: > <...> > Also, you can specify a non-default step size: > > @pdl(1:9:2, 1:9:2); # (1,1) (3,1) (5,1) (7,1) (9,1) (1,3) (3,3) ... > > Although I'm not sure how frequently custom step sizes are used in PDL > code... > More generally, we need to be able to specify: - Sli

Re: RFC 29 (v1) unlink() should be left alone

On Fri, Aug 04, 2000 at 04:39:24PM -0400, Spider Boardman wrote: > The C (POSIX.1) remove() function is NOT just unlink() in drag. Not everywhere, at least: >REMOVE(3) FreeBSD Library Functions Manual REMOVE(3) ... > The remove() function is an alias for the unlink(

Re: Avoid memory copy and redundant loops in reduce/fold

Ken Fox wrote: > > $a = sum(@b*@c+@d) > > I'm not strong in math, but I do remember a bit about row and column > vectors. Isn't @b*@c ambiguous? Shouldn't it normally be interpreted > as a dot product, i.e. treat all vectors the same? > It depends on what perl6-language comes up with. Probably

Re: RFC 29 (v1) unlink() should be left alone

Myers, Dirk <[EMAIL PROTECTED]> writes: > If a remove() is added, it should (IMHO) seek-and-destroy. This is impossible on a Unix file system. -- Russ Allbery ([EMAIL PROTECTED])

RFC 34 (v1) Angle brackets should not be used for fi

This and other RFCs are available on the web at http://tmtowtdi.perl.org/rfc/ =head1 TITLE Angle brackets should not be used for file globbing. =head1 VERSION Maintainer: Jon Ericson <[EMAIL PROTECTED]> Date: 4 August 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 34 =hea

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

>Andy Wardley wrote: >> What about '$me'? It ties in nicely with 'my' (although perhaps for the >> wrong reasons), it's half as much typing as 'self' or 'this' and we get >> to annoy both sets of religious zealots at once. :-)= >Yes, absolutely. Now what good meanings could we attribute to $

Re: RFC 10 (v2) Filehandles should use C<*> as a type pr

I think this is a good candidate for recording why we decided not to do something. Did we even reach consensus on how to do this? Put a Status: header in VERSION? For recording purposes, maybe once the Status: line is added we should add an additional section. Maybe STATUS, JUSTIFICATION, POSTMO

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

Steve Simmons <[EMAIL PROTECTED]> writes: > 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 ar

RFC 33 (v1) Eliminate bareword filehandles.

This and other RFCs are available on the web at http://tmtowtdi.perl.org/rfc/ =head1 TITLE Eliminate bareword filehandles. =head1 VERSION Maintainer: Peter Scott <[EMAIL PROTECTED]> Date: 4 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 33 =head1 ABSTRA

RFC 10 (v2) Filehandles should use C<*> as a type pr

This and other RFCs are available on the web at http://tmtowtdi.perl.org/rfc/ =head1 TITLE Filehandles should use C<*> as a type prefix if typeglobs are eliminated. =head1 VERSION Maintainer: Peter Scott <[EMAIL PROTECTED]> Date: 4 Aug 2000 Version: 2 Mailing List: [EMAIL

Re: RFC 22 (v1) Builtin switch statement

> This switch statement RFC seems to be built on the premise that the > reason to have a switch statement is to remove a common parameter > from the following limited form conditional expressions. Yes. As I point out in the paper, that's the *nature* of a switch statement. To distribute

Re: RFC 22 (v1) Builtin switch statement

Glenn Linderman wrote: > > This is not to detract from the ideas of higher order functions or curried > whatever, but I > don't think those are or should be necessary to a powerful switch statement. I vote thus: to have RFC 22 rejected (29 rules?!), and RFC 23 accepted, with appropriate ramifica

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

You would need two (or more) perl executables. The downloaded CPAN (or other source) scripts/modules that don't follow the conventions would either have to be ported to the local environment. Or they would need their own executable that doesn't follow the standard. One or more groups will suffer

Re: RFC 22 (v1) Builtin switch statement

This switch statement RFC seems to be built on the premise that the reason to have a switch statement is to remove a common parameter from the following limited form conditional expressions. For that reason, two new keywords are required: switch: to define the common parameter, and case: to int

Re: RFC 30 (v1) STDIN, STDOUT, and STDERR should be rena

> STDIN, STDOUT, and STDERR should follow suit and be renamed > $STDIN, $STDOUT, and $STDERR. $TDIN, $TDOUT, $TDERR -- John Porter

Re: RFC 24 (v1) Semi-finite (lazy) lists

lazy as an operator or attribute was discussed (a year ago?) on p5p. This would be needed to allow user subs to operate exactly like built-ins. sub foo : lazy { ... } or &foo lazy @foo, &bar(), ... (Hmm, Actually, putting a code ref/closure on the stack, then the @_ iterator

RFC 30 (v1) STDIN, STDOUT, and STDERR should be rena

This and other RFCs are available on the web at http://tmtowtdi.perl.org/rfc/ =head1 TITLE STDIN, STDOUT, and STDERR should be renamed =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 04 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 30 =head1 ABSTRAC

RFC: "Empty But True" Special String Value (was Re: RFC 25)

-- John Porter

Re: RFC 25 (v1) Multiway comparisons

> > > This RFC proposes that multiway comparisons such as: > > > > > > if ( 0 <= $x < 10 ) { print "digit" } > > > > > > should do what the user means. > > I think this should mean what it means in Icon, namely, that > $x < $y evaluates to false if $x >= $y, and e

Re: RFC 25 (v1) Multiway comparisons

On Fri, Aug 04, 2000 at 04:48:24PM -0400, John Porter wrote: > I think this should mean what it means in Icon, namely, that > $x < $y evaluates to false if $x >= $y, and evaluates to > "$y (but true)" if $x < $y. This allows the operators to be > nested, i.e. $x < $y < $z would be ( $x < $y )

Re: RFC 25 (v1) Multiway comparisons

> > This RFC proposes that multiway comparisons such as: > > > > if ( 0 <= $x < 10 ) { > > print "digit" > > } > > > > should do what the user means. I think this should mean what it means in Icon, namely, that $x < $y evaluates to false if $x >= $y, and evaluates

Re: Different points of view, a little perspective.

We're here to work on perl6. Let's stay focused. -- John Porter

Re: RFC 25 (v1) Multiway comparisons

> I suspect it already has a different meaning, based on operator > precedence rules, left to right evaluation, etc., but I strongly > doubt there is much use of it in that manner, and would encourage > this redefinition to be used instead. It's currently an error (even if you redefin

Re: RFC 25 (v1) Multiway comparisons

Great idea! (Don't accuse me of apathetic lurking!) I suspect it already has a different meaning, based on operator precedence rules, left to right evaluation, etc., but I strongly doubt there is much use of it in that manner, and would encourage this redefinition to be used instead. Perl6 RFC

Re: RFC 29 (v1) unlink() should be left alone

The C (POSIX.1) remove() function is NOT just unlink() in drag. It's something like this (in perl): sub remove ($) { if ( !-l $_[0] && -d _ ) { rmdir $_[0]; } else { unlink $_[0]; } } In other words, it's rmdir() if its argument is

Re: RFC 22 (v1) Builtin switch statement

> Does "goto odds" mean start evaluating all cases after the > "odds:" label? Meaning that the below is equivalent to the above? > I think this is what the original poster was asking; if not, I'd > like to ask it! That's exactly what it means. > > switch ($val) { >

Re: RFC 22 (v1) Builtin switch statement

Damian Conway wrote: >> Could a way be found to control the flow so that the next case (not always >> the one next in the order of the statment) could be executed? For example >> you have cases 1-10. You want all odd cases to also execute case 9 and the >> even cases to also execu

Re: RFC 18 (v1) Immediate subroutines

At 04:08 PM 8/4/00 -0400, Chaim Frenkel wrote: >I've never used it, but PL/I' preprocessor and ASMG's preprocessor , >If I recall correctly, both worked this way. The text of the arguments >and the actual input stream were available for manipulation. The >return value (or emitted strings) were use

Re: Problems with perl6-rfc address??

Ignore this, I'm an idiot. I thought perl6-rfc was totally automated. Sorry. -Nate Nathan Wiger wrote: > > Sorry for the broadcast, but anyone else having problems with perl6-rfc? > I sent two separate RFC's in from separate mail servers but haven't seen > anything happen with them. It's been a

Re: Proposed sublist: flowcontrol

> "UG" == Uri Guttman <[EMAIL PROTECTED]> writes: UG> dispatch- discuss support of the multiple ways to control UG> dispatching of perl ops (event loops, threads, UG> co-routines, etc.) UG> the dispatch list should eventually split off lists that focus on the

Re: PDL-P: indexing

On Fri, Aug 04, 2000 at 10:02:05AM -1000, [EMAIL PROTECTED] wrote: > On Fri, 4 Aug 2000, Tuomas Lukka wrote: > > On 4 Aug 2000, Ariel Scolnicov wrote: > > Well, first of all, > > > > 10:100, 30:200 > > > > is not the same: in Perl it comes out as > > > > 10..100, 30..200 > > > > 1

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

> > Well, first of all, > > > > 10:100, 30:200 > > > > is not the same: in Perl it comes out as > > > > 10..100, 30..200 > > > > 10, 11, ... , 100, 30, 31, .., 200 > > > > Additionally, generically it would not necessarily have to be a range of > integers. The range could be spe

Problems with perl6-rfc address??

Sorry for the broadcast, but anyone else having problems with perl6-rfc? I sent two separate RFC's in from separate mail servers but haven't seen anything happen with them. It's been a good hour, too. Thanks, Nate

Re: RFC 18 (v1) Immediate subroutines

I've never used it, but PL/I' preprocessor and ASMG's preprocessor , If I recall correctly, both worked this way. The text of the arguments and the actual input stream were available for manipulation. The return value (or emitted strings) were used as input to the parser. This would be quite clos

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

On Fri, 4 Aug 2000, Tuomas Lukka wrote: > On 4 Aug 2000, Ariel Scolnicov wrote: > > Well, first of all, > > 10:100, 30:200 > > is not the same: in Perl it comes out as > > 10..100, 30..200 > > 10, 11, ... , 100, 30, 31, .., 200 > Additionally, generically it would not ne

Re: Language RFC Summary 4th August 2000

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

RE: RFC 29 (v1) unlink() should be left alone

> 5. Other operating systems/ file systems have, or could have > hypothetically, the same operation. I.e. just because NTFS > doesn't have multiple links now (or does it?) doesn't mean > it won't in the future. NTFS does support hard links right out of the box, although the firs

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

On 4 Aug 2000, Ariel Scolnicov wrote: > Karl Glazebrook <[EMAIL PROTECTED]> writes: > > > OK I will raise to the bait > > > > I think it's a bit unfair to say that PDL people have failed to 'bite', > > there was quite a bit of discussion on our list after your post. Also > > some concern about

RE: RFC 22 (v1) Builtin switch statement

Not a bad solution, at least for the example I put forth. I like the ability to have the specific as well as the general in the case statement ('2' and '__%2 != 0'). Thanks. > Could a way be found to control the flow so that the next case (not always > the one next in the order of the stat

RE: RFC 29 (v1) unlink() should be left alone

Ariel Scolnicov: > It so happens that remove() is standard C (library) for removing a > file. It therefore makes sense to use *that* name, if any change is > made. IMHO, it's poorly named (though using remove() at least has the virtue of not conflicting with/overloading the existing "delete").

Different points of view, a little perspective.

Snippet from O'Reilly's upcoming fictional novel, the first in a new series written for its loyal audience of CS professionals: "Young Perl had definitely reached that 'awkward stage' in life -- not quite a fully-accepted adult, but definitely not a child anymore. Her parents, /they/ loved her, sh

Re: RFC 28 (v1) Perl should stay Perl.

At 02:17 PM 8/4/00 -0500, Jonathan Scott Duff wrote: >I'm with Chaim on this one. One of the things I *love* about perl is >that it doesn't constrain me to a particular paradigm and moreover it >almost naturally supports other paradigms (like functional >programming). I'm always touting this as

Re: RFC 22 (v1) Builtin switch statement

On Sat, Aug 05, 2000 at 05:09:28AM +1000, Damian Conway wrote: > Not necessary. > > switch ($val) { > case 3 { print "three"; goto odds } > case 4 { print "three"; goto evens } And "goto" could be spelt "next" too? That would make sense to me,

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

Also on the issue of loop unrolling and efficient looping. PDL has what we call 'threading'. This allows a C-level function to specify the dimensionality of the arguments it accepts. For example a function addtoline() which hyptheticaly adds a constant to a row vector might have a 'signature'

Re: Language RFC Summary 4th August 2000

> What I'm planning to RFC is a simple format() built-in (probably > in a pragma) very similar to the form() subroutine described in: http://www.csse.monash.edu.au/~damian/TPC/2000/Autoformat/paper.html Damian

Re: RFC 28 (v1) Perl should stay Perl.

> > "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > > PRL> =item Functional Programming > > PRL> Just because Perl has a C operator, this doesn't make it a > PRL> functional programming language. Perl has always been squarely > PRL> procedural, and so things like C and C and other

RE: RFC 22 (v1) Builtin switch statement

> Could a way be found to control the flow so that the next case (not always > the one next in the order of the statment) could be executed? For example > you have cases 1-10. You want all odd cases to also execute case 9 and the > even cases to also execute case 10. So in case 3 you w

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

Karl Glazebrook <[EMAIL PROTECTED]> writes: > OK I will raise to the bait > > I think it's a bit unfair to say that PDL people have failed to 'bite', > there was quite a bit of discussion on our list after your post. Also > some concern about how much of perl6 is vapourware. > > I am game to ta

Re: Language RFC Summary 4th August 2000

> >> It definitely is, since formats do things that can't be done in modules. > > > >Such as??? > > Well, the easy binding of variables for later use. When one declares a > format, variables in it are saved for later use without needing refs. > Formats are sort of like

Re: Language RFC Summary 4th August 2000

At 04:00 AM 8/5/00 +1000, Damian Conway wrote: >> It definitely is, since formats do things that can't be done in modules. > >Such as??? Well, the easy binding of variables for later use. When one declares a format, variables in it are saved for later use without needing refs. Formats are s

Re: RFC 24 (v1) Semi-finite (lazy) lists

Thus it was written in the epistle of Damian Conway, > > I have an RFC coming on that :-) I think Skud asked the wrong questiong :-). Would you please submit a comprehensive of the topics on which you are not about to produce an RFC. That will allow others to focus their work. Thank you very

Re: RFC 29 (v1) unlink() should be left alone

Nathan Wiger <[EMAIL PROTECTED]> writes: > > I say this as a Unix weenie, albeit a Unix *user* rather than a Unix > > *programmer*. I'm quite used to navigating the Unix filesystem but, > > having never braved Unix systems programming, had no conceptual link > > between deleting/"rm"ing files, a

RE: RFC 22 (v1) Builtin switch statement

Could a way be found to control the flow so that the next case (not always the one next in the order of the statment) could be executed? For example you have cases 1-10. You want all odd cases to also execute case 9 and the even cases to also execute case 10. So in case 3 you would say something l

Re: RFC 28 (v1) Perl should stay Perl.

I'm not quite buying into this. There are some things that are just easier with this style of thinking. Its a higher level construct. Akin to telling your interior decorator that you'd like the furniture to match the wallpaper. You've left out all the details but the decorator can easily see wha

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

OK I will raise to the bait I think it's a bit unfair to say that PDL people have failed to 'bite', there was quite a bit of discussion on our list after your post. Also some concern about how much of perl6 is vapourware. I am game to take part in discussions. It has always been apparent to m

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

On Fri, Aug 04, 2000 at 11:37:30AM -0700, Peter Scott wrote: > It would not be "you need to rebuild your perl", but "the administrator of > this site does not allow unstrict programming by default." The original poster said "a compile-time option to be decided by the administrator of each site".

Re: RFC 24 (v1) Semi-finite (lazy) lists

> From [EMAIL PROTECTED] Sat Aug 5 04:36:31 2000 > Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) >by indy05.csse.monash.edu.au (8.8.8/8.8.8) with ESMTP id EAA20410 >for <[EMAIL PROTECTED]>; Sat, 5 Aug 2000 04:36:31 +1000 (EST) > Received:

Re: Proposed sublist: flowcontrol

> > i think damian's influence on perl6 > > is our real triple top secret weapon. > > This realization has hit me on the head really hard. > My prediction is that Perl6 will have to be dual-credited. I doubt it: Lucifer doesn't get a by-line on the Bible. There's only one Larry.

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

Andy Wardley wrote: > What about '$me'? It ties in nicely with 'my' (although perhaps for the > wrong reasons), it's half as much typing as 'self' or 'this' and we get > to annoy both sets of religious zealots at once. :-)= Yes, absolutely. Now what good meanings could we attribute to $mysel

  1   2   3   >