Re: RFC 54 (v1) Operators: Polymorphic comparisons

On Tue, 08 Aug 2000 23:43:26 -0400, Ken Fox wrote: >(assuming min() is polymorphic): > > min($a, $b) eq $a > >Ugly, but minimal changes to the language. We could adopt a syntax similar to sort(): $lowest = min($x, $y, $z); # default: numerical (?) $first = min { $a cmp $b } (

Re: access to pod/doc text by code

On Tue, 08 Aug 2000 20:49:38 -0400, Matthew Persico wrote: >pod2usage is the call I THINK you are refering to. Who cares if it is >slow? YA extension to perldoc? -- Bart.

Re: RFC 65 (v1) Add change bar functionality to pod

> =head1 DESCRIPTION > > Making what's changed in documentation stand out's quite useful, > something I'm coming to appreciate more and more as the RFCs are > flying back and forth. The standard way to do this is to mark the > changed sections with one or more vertical bars on the left margin. >

Re: RFC 23 (v2) Higher order functions

> =head1 TITLE > > Higher order functions Sounds good. We should add this to the language. Oh boy, the tricks we can play with this... Hildo

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

> > =head1 TITLE > > All Perl core functions should return objects > Yuck. Why not use the proposed want() and return hash-refs or slices, when appropriate. Hildo

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

Peter Scott <[EMAIL PROTECTED]> writes: > At 09:28 AM 8/8/00 +0100, Piers Cawley wrote: > >Peter Scott <[EMAIL PROTECTED]> writes: > > > > > At 12:07 AM 8/8/00 +0200, Bart Lateur wrote: > > > >On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote: > > > > > > > > >I meant that BEGIN, END, and INI

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

Damian Conway sent the following bits through the ether: > If you take this, I won't be able to port the forthcoming Klingon.pm > module to Perl 6!!! D'oh! ;-) Leon -- Leon Brocard.http://www.astray.com/ yapc::Europe - September 22-24 London - http://yapc.org/Europe

Re: access to pod/doc text by code

Uri Guttman <[EMAIL PROTECTED]> writes: > some people have mentioned help strings as special parts of a sub > declaration like gnu lisp has. this could be more support for that type > of thing. but i don't want it to be too strange. Hmm... sub foo ($$;@) :lvalue "Documentation string h

Re: RFC 23 (v2) Higher order functions

Peter Scott <[EMAIL PROTECTED]> writes: > >=head1 TITLE > > > >Higher order functions > > Well, this should keep the Obfuscated Perl Contest going for at least > another decade :-) Whilst still being deeply useful in non obfuscatory contexts too. -- Piers

Re: Error handling

> > > > Timeouts, shouldn't be reliant on UNIX. (Although I dont think they should > > be in the language eigther. A system is easily developed using threads. > > something which I hope to develop when perl6 is ready...) > > > > I don't understand this paragraph. As it stands, if you want to hav

Re: println() ... printbr()

> I actually saw this in the newsgroups and thought it was a neat idea. What > about >println $textvar; > instead of >print "$textvar\n"; > Ever so much easier to read and write, prints the arg and appends \n. ]- I thought 'bout this too, but I think it is not general enought..Why ? we sh

Fw: println() ... printbr()

- Original Message - From: "Peter Bevan" <[EMAIL PROTECTED]> To: "raptor" <[EMAIL PROTECTED]> Sent: Wednesday, August 09, 2000 11:05 AM Subject: Re: println() ... printbr() > > > > I actually saw this in the newsgroups and thought it was a neat idea. > What > > > about > > >println

Re: println() ... printbr()

* Peter Bevan ([EMAIL PROTECTED]) [09 Aug 2000 20:08]: > To: "raptor" <[EMAIL PROTECTED]> [...] > > print @array; > > > > must work like this : > > foraeach (@array) { print "$_\n"}; > > foraeach (@array) { print "$_"}; > > > > not like at the moment : > > foraeach (@array) { print $_}; > This I

Re: RFC 65 (v1) Add change bar functionality to pod

On Wed, 09 Aug 2000, Hildo Biersma wrote: > > =head1 DESCRIPTION > > > > Making what's changed in documentation stand out's quite useful, > > something I'm coming to appreciate more and more as the RFCs are > > flying back and forth. The standard way to do this is to mark the > > changed sections

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

On Tue, Aug 08, 2000 at 10:47:10PM -0700, Russ Allbery wrote: > John Tobey <[EMAIL PROTECTED]> writes: > > On Wed, Aug 09, 2000 at 02:22:22AM +0200, Bart Lateur wrote: > > >> date() would be more general, and replace both. You can pass it a time > >> zone, ANY time zone, and it will tell you what

Re: println() ... printbr()

On Wed, 9 Aug 2000 12:42:18 +0100, raptor wrote: >There shall be easier way in Perl6 for doing this ... I too get really tired >of these "\n" and 's at the end >ALSO ... > >print @array; I assume that's "printbr" >must work like this : >foreach (@array) { print "$_"}; sub printbr {

chomp & unchomp

Here is the argument- Perl has (had?) chomp(). It removes \n at the end of a line. That's something we often need to do. We ALSO often need to ADD \n to the end of a line. This usually looks something like: print "$kitty\n"; Hence my println() suggestion. Maybe instead it should be: unc

Re: RFC 48 (v2) Objects should have builtin stringifying

Michael Fowler wrote: > > I think a stringified reference is worth seeing, moreso than a simple undef, > for debugging purposes if nothing else. I personally would like to have the stringification of refs be a symmetric operation, i.e. such a string should dwim in a ref context: $r = bl

Re: RFC 58 (v1) C changes.

Bart Lateur wrote: > > chomp() is basically just a "postprocess data coming from a file" > command. That is way too simplistic. I for one think the current behavior of chomp() is ideal for its simplicity. while(<>) { /foo/ and next; # why bother chomping?

Re: RFC 58 (v1) C changes.

Dan Sugalski wrote: > > unless you think we should require arrays to be passed by reference. > > It's an op. Arrays can be passed in any way we want. But as I already pointed out, we don't want to pass just arrays, we need to be able to pass any LIST. -- John Porter

Re: RFC 58 (v1) C changes.

On Wed, 9 Aug 2000 09:23:02 -0400, John Porter wrote: >That is way too simplistic. I for one think the current behavior >of chomp() is ideal for its simplicity. > > while(<>) { > /foo/ and next; # why bother chomping? > if ( /bar/ ) { > pr

Re: RFC 58 (v1) C changes.

On Tue, Aug 08, 2000 at 08:53:30PM -0400, Dan Sugalski wrote: > On Tue, 8 Aug 2000, Michael Mathews wrote: > > > Dan Sugalski said: > > > > > * Do we even want to allow after-the-fact chomps, or do it > > automagically > > > >at read time? > > > "Yes" is rather ambiguous. > > > > To clarify: "Ye

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

On Wed, 9 Aug 2000 08:59:41 +0100, Leon Brocard wrote: >D'oh! ;-) Ah, yes. Chris Nandor's module D'oh couldn't possibly be called with this appropriate name any more. OTOH, try this: $hash{a'b} = 1; print key

Re: RFC 65 (v1) Add change bar functionality to pod

At 08:56 AM 8/9/00 +0100, Hildo Biersma wrote: > > =head1 DESCRIPTION > > > > Making what's changed in documentation stand out's quite useful, > > something I'm coming to appreciate more and more as the RFCs are > > flying back and forth. The standard way to do this is to mark the > > changed sect

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

At 11:05 PM 8/8/00 -0700, Nathan Wiger wrote: >I agree with what Ken said completely: > > > Hey! That sounds like an implementation topic... ;) (The internals > > should be able to handle this if the language wants it, right?) > >Let's get the ideas going. The internals might have some honest conc

Re: Things to remove

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: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

Ken Fox wrote: > > Both of those expressions are the infinite list (-infinity..-1). I have > no idea how to write that properly 'cause I'm not a math guy. These > things aren't streams (infinite queues) -- they're infinite stacks. I'm > not sure they have a name in computer science. O.k., here's

Re: RFC 58 (v1) C changes.

At 09:24 AM 8/9/00 -0400, John Porter wrote: >Dan Sugalski wrote: > > > unless you think we should require arrays to be passed by reference. > > > > It's an op. Arrays can be passed in any way we want. > >But as I already pointed out, we don't want to pass just arrays, >we need to be able to pass

Re: RFC 48 (v2) Objects should have builtin stringifying

At 09:13 AM 8/9/00 -0400, John Porter wrote: >Michael Fowler wrote: > > > > I think a stringified reference is worth seeing, moreso than a simple > undef, > > for debugging purposes if nothing else. > >I personally would like to have the stringification of refs be a >symmetric operation, That le

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

Thus it was written in the epistle of John Porter, > Ken Fox wrote: > > > > Both of those expressions are the infinite list (-infinity..-1). I have > > no idea how to write that properly 'cause I'm not a math guy. These > > things aren't streams (infinite queues) -- they're infinite stacks. I'm >

Re: RFC 58 (v1) C changes.

Bart Lateur wrote: > > It's not "simple". It's confusing. Not at all! At least, not to me. If you find it unsimple and confusing, then I guess I'll have to chalk it up to the heterogeneity of the Perl community. > Very often I do stuff like you > describe, and then it turns out that there a

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

Ted Ashton wrote: > John Porter: > > > > What would be the output of the following program: > > > > $\ = "\n"; > > $i = 0; > > for ( .. -1 ) { > > $i++; > > last if $i > 2; > > print > > } > > > > If the answer is (as I suspect), "This never

Re: RFC 48 (v2) Objects should have builtin stringifying

John Porter wrote: > > Michael Fowler wrote: > > > > I think a stringified reference is worth seeing, moreso than a simple undef, > > for debugging purposes if nothing else. > > I personally would like to have the stringification of refs be a > symmetric operation, i.e. such a string should dwim

Re: Things to remove

The discussion of a new name for perl6 is amusing but irrelevant. It's not like this list doesn't get enough traffic already. Thanks for ceasing and desisting. Nat

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

John Porter replied to what > Ted Ashton wrote: > > John Porter: > > > > > > What would be the output of the following program: > > > > > > $\ = "\n"; > > > $i = 0; > > > for ( .. -1 ) { > > > $i++; > > > last if $i > 2; > > > print > > > } > > > > > > If

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

> > All Perl core functions should return objects > > > > Yuck. Why not use the proposed want() and return hash-refs or slices, > when appropriate. No reason you couldn't do that too. This just affects scalar contexts. -Nate

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

> It means a lot more code to write (and debug) for the things that > return these objects, and that means parts of perl will be > slower, take longer to write, and take up more space. Point taken. I don't think internals should be ignored altogether, just that they shouldn't be the driving force

Re: RFC 48 (v2) Objects should have builtin stringifying

Hildo Biersma wrote: > > Bit dangerous there - the string-to-ref operator is left out for a > purpose. > - Would you really want the ref-counting system / the GC system to > scan strings? > - Would like like the effects of pointer arithmetic that > the ref-tostring, edit-string, string-to-

Re: RFC 58 (v1) C changes.

On Wed, 9 Aug 2000 10:24:28 -0400, John Porter wrote: >Bart Lateur wrote: >> >> It's not "simple". It's confusing. > >Not at all! At least, not to me. If you find it unsimple and confusing, >then I guess I'll have to chalk it up to the heterogeneity of the Perl >community. >> Very often I do

RFC 79 (v1) Code which is both executable and POD.

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Code which is both executable and POD. =head1 VERSION Maintainer: John Porter <[EMAIL PROTECTED]> Date: 9 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 79 =head1 ABSTRACT Allow som

Re: RFC 58 (v1) C changes.

Bart Lateur wrote: > > There's no need for that macho "I can lick this" attitude. Being > consistent, everywhere, is clearly simpler. Being explicit about when you want your lines chomped is more consistent, IMHO, than always getting it whether you want it or not. [irrelevant timings of perl5 c

Re: RFC 58 (v1) C changes.

John Porter writes: > Being explicit about when you want your lines chomped is more > consistent, IMHO, than always getting it whether you want it or not. I'm getting the feeling that this discussion should either end or become an RFC. Soon. Nat

RE: RFC 58 (v1) C changes.

The Perl 6 Librarian writes >=head1 DESCRIPTION > >This RFC contains two proposed changes. First, as it is common to want to >removed newlines upon reading a file, > > while (chomp()) { >. . . > } > >should become the equivalent of > > while () { >chomp; >. . . > } > >where th

Re: RFC 48 (v2) Objects should have builtin stringifying

> I think a stringified reference is worth seeing, moreso than a simple undef, > for debugging purposes if nothing else. Debugging is great, but I don't think this is the way to do it. The reason is some objects might have a STRING method while others don't, so you'll only get partial access to s

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

At 07:55 AM 8/9/00 -0700, Nathan Wiger wrote: > > It means a lot more code to write (and debug) for the things that > > return these objects, and that means parts of perl will be > > slower, take longer to write, and take up more space. > >Point taken. I don't think internals should be ignored alt

Re: RFC 79 (v1) Code which is both executable and POD.

From: "Perl6 RFC Librarian" > This allows actual running code to be inserted directly into the documentation > for that code. This (if I understand your aim here) points out The Difference between comments and POD, and underlines why POD is not a good way to comment code. Comments can always be

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

Tangentialy, can I suggest that a nicer synthax might be -Inf..-1 / 1..Inf, etc. Assuming that we end up supporting full IEEE floats, this becomes the "obvious" synthax, and I find C<(-Inf..Inf)> to be far more clear then C<(..)>. We've got plenty of puncuation already, thank you very much. Als

Re: vector and matrix calculations in core? (was: Re: Ramblings on "base class" for SV etc.)

Bart et al: In keeping with Larry's design philosophy that the language should "not just sit there -do something!" I agree that there should be a number of vector/matrix manipulations available, performed in a psuedo-scalar context (not in a loop). Just to name a few: arithmetic ops +-*/ ceil

Re: RFC 58 (v1) C changes.

> "UG" == Uri Guttman <[EMAIL PROTECTED]> writes: UG> and the globals can be used by the magic <> which was asked by jonathan UG> scott. when you use <> you rarely IMO use many other handles. typically UG> <> is used in filter programs. Personal counter example. Many times, I take multiple i

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

Bart Lateur writes: : On Wed, 9 Aug 2000 08:59:41 +0100, Leon Brocard wrote: : : >D'oh! ;-) : : Ah, yes. Chris Nandor's module D'oh couldn't possibly be called with : this appropriate name any more. : : : : : OTOH, try this: :

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

John Tobey <[EMAIL PROTECTED]> writes: > On Tue, Aug 08, 2000 at 10:47:10PM -0700, Russ Allbery wrote: >> It's far worse than non-portable; it's completely insufficient. The >> POSIX TZ syntax cannot represent many real time zones. You need the >> Olson-style naming scheme which refers to entri

RE: RFC 67 (v1) Deep Copying, aka, cloning around.

From: Peter Scott [mailto:[EMAIL PROTECTED]] > > >I would like deep copying to include copying CODE. It would > >be useful for implementing object methods... > > Why would it be necessary to deep copy a CODE reference? It might not be necessary. I'm still learning how to write kosher Perl... el

Re: vector and matrix calculations in core? (was: Re: Ramblings on "base class" for SV etc.)

At 04:06 PM 8/9/00 +, Ed Mills wrote: >In keeping with Larry's design philosophy that the language should "not >just sit there -do something!" I agree that there should be a number of >vector/matrix manipulations available, performed in a psuedo-scalar >context (not in a loop). That would

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

> I do agree that the internals shouldn't drive the language (otherwise a > crack team of Ninja would've already taken care of that Conway guy... :), > but neither can they be completely ignored. Agreed. Which reminds me, we should call off those Ninja... :-) > Honestly, I'd rather you put toge

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

> I think this is a bit heavy-weight for core. Agreed. General-purpose timezone support is scheduled for a swift and painless death in the next version of RFC 48. Only the local timezone and GMT will be included in the RFC, same as now. I wish it could happen, but too many people have brought up

Re: Things to remove

[EMAIL PROTECTED] writes: :> Most of the requests for deletion seem to begin with, "This isn't :> used..." :> :> To which, "*I* use it." is a very valid argument. : : Agreed. The real problem with ?...? is that it complicates the hell out : of the parser. So long as the special

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

Tangentialy, can I suggest that a nicer synthax might be -Inf..-1 / 1..Inf, etc. This assumes that the float synthax will be extended to include "NaN" and "Inf" as valid floating-point literals. (This does take away from non-reserved namespace.) Has this been proposed yet? Assuming that we en

Re: RFC 58 (v1) C changes.

Dan Sugalski <[EMAIL PROTECTED]> writes: > So? It's an op. Lists can be passed any way we want. :) In what respect would that be different from a function? (cf. RFC 26). -- Johan

Re: access to pod/doc text by code

Uri Guttman <[EMAIL PROTECTED]> writes: > MP> pod2usage is the call I THINK you are refering to. Who cares if it is > MP> slow? I'll bet that if you are writting to the screen or a file, THAT's > MP> the slow part, not traipsing through the file parsing for POD. It might > MP> make an int

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

I don't think it will be a half million objects. Let's take stat (and all the other long list returns). The underlying implementation object could be a packed structure psuedohash. (Think DSECT.) Then the only op would be the packed structure pseudohash lookup. Which would be done at compile tim

Re: access to pod/doc text by code

> "JV" == Johan Vromans <[EMAIL PROTECTED]> writes: JV> Uri Guttman <[EMAIL PROTECTED]> writes: >> i think reading the file may have issues like finding it. or doc strings >> for each sub vs. parsing that out of the whole pod. i just bothers me to >> have to read that file for stuff

Re: RFC 58 (v1) C changes.

At 07:19 PM 8/9/00 +0200, Johan Vromans wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > > > So? It's an op. Lists can be passed any way we want. :) > >In what respect would that be different from a function? >(cf. RFC 26). Ops are lower level. (I'm not talking about, say, the localtime op, but

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

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

Re: RFC 76 (v1) Builtin: reduce

Please consider the possiblity of tristate logic (RFC TBD.) ala, SQL. Assuming a "use tristate", undef + number = undef This might require that the reduce function be able to ignore undefs. Either always under the tristate pragma. Or on a case by case basis. Also you haven't specified if the ar

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

At 01:33 PM 8/9/00 -0400, Chaim Frenkel wrote: >I don't think it will be a half million objects. The problem I have with this RFC is that it is too broad a brush. Since different core functions would need to return different objects (there would be some common ones, but otherwise it would be p

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

At 10:44 AM 8/9/00 -0700, Larry Wall wrote: >[EMAIL PROTECTED] writes: >: 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

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

At 01:33 PM 8/9/00 -0400, Chaim Frenkel wrote: >I don't think it will be a half million objects. > >Let's take stat (and all the other long list returns). The underlying >implementation object could be a packed structure psuedohash. (Think >DSECT.) Then the only op would be the packed structure p

Re: RFC 79 (v1) Code which is both executable and POD.

Michael Mathews wrote: > > This ... underlines why POD is not a good way to comment code. > ... > This RFC would seem to address the issue quite neatly. So, are you saying that if this RFC is implemented, POD would be an good way to comment code? -- John Porter

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

Dan Sugalski writes: > stat makes some sense. (local|gm)time makes some sense. The socket > functions make some sense. The message and shared memory functions make > some sense. Basically most of the 'advanced' functions make some sense. > That's the problem--they all make some sense, which is

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

Dan Sugalski writes: : Does that mean, then, that when module A does a "$C::bar = 1" it affects a : different package namespace than module B doing a "$C::bar = 2"? Presumably. : And does it also extend to things like this: : : package A; : use C 1.2; : package B; : use C 1.4;

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

On Wed, Aug 09, 2000 at 12:09:42PM -0600, Nathan Torkington wrote: > Dan Sugalski writes: > > stat makes some sense. (local|gm)time makes some sense. The socket > > functions make some sense. The message and shared memory functions make > > some sense. Basically most of the 'advanced' functions

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

At 12:09 PM 8/9/00 -0600, Nathan Torkington wrote: >stat, sockets, messaging, and the rest of the advanced stuff should >probably go to modules. Yes, plus the get* functions. Do we need an RFC on this? -- Peter Scott Pacific Systems Design Technologies

Re: RFC: Higher resolution time values

Dan Sugalski <[EMAIL PROTECTED]> writes: >> >>As an engineer I would really like to know when you are going to >>run out of precision in double - that is forty something bits of mantissa. >>That is more precision than you have in the real world. > >It's not precision, it's resolution. What do you

Overloading && ||

Damian Conway <[EMAIL PROTECTED]> writes: >Operator overloading is scheduled to be revamped. While I remember - it would be good if overload mechansim could be extended to cover && and || as well as & and | with the class deciding if short-circuit happens. -- Nick Ing-Simmons

Re: RFC 79 (v1) Code which is both executable and POD.

John Porter writes: : Michael Mathews wrote: : > : > This ... underlines why POD is not a good way to comment code. : > ... : > This RFC would seem to address the issue quite neatly. : : So, are you saying that if this RFC is implemented, POD would be : an good way to comment code? It already i

Re: RFC 79 (v1) Code which is both executable and POD.

John Porter asked: > Michael Mathews wrote: > > This ... underlines why POD is not a good way to comment code. ... > > This RFC would seem to address the issue quite neatly. > So, are you saying that if this RFC is implemented, POD would be > a good way to comment code? I do consider this a poten

Re: Overloading && ||

> Damian Conway <[EMAIL PROTECTED]> writes: > >Operator overloading is scheduled to be revamped. > > While I remember - it would be good if overload mechansim > could be extended to cover && and || as well as & and | > with the class deciding if short-circuit happens. Oh, defi

Re: Overloading && ||

At 06:23 PM 8/9/00 +, Nick Ing-Simmons wrote: >Damian Conway <[EMAIL PROTECTED]> writes: > >Operator overloading is scheduled to be revamped. > >While I remember - it would be good if overload mechansim >could be extended to cover && and || Yes. >as well as & and | >with the class deciding i

Re: RFC 79 (v1) Code which is both executable and POD.

On Wed, 9 Aug 2000, Michael Mathews wrote: > To be fair, neither of these are examples of using a comment function for > "comments" though, but rather using a comment function to disable sections > of code and I suppose that makes as much sense as using POD to disable code. This is another insta

Re: Ramblings on "base class" for SV etc.

Dan Sugalski <[EMAIL PROTECTED]> writes: > >Well, compactness for one. With a scalar on one side it's less odd (it was >a bad example). When funkier, though: > > @foo = @bar * @baz; > >the expansion becomes less obvious It is "obviously" a cross-product ;-) With perl's $s and @s we can actual

Re: RFC 76 (v1) Builtin: reduce

> Please consider the possiblity of tristate logic (RFC TBD.) ala, SQL. > > Assuming a "use tristate", undef + number = undef > > This might require that the reduce function be able to ignore undefs. > Either always under the tristate pragma. Or on a case by case basis. I'm no

Re: RFC 79 (v1) Code which is both executable and POD.

Michael Mathews wrote: > > I do consider this a potential alternative to the MLC RFC ... I don't. This RFC deals strictly with POD. If a good in-line comment solution is also implemented, so much the better; but orthogonal to this. > but to my mind it > addresses the opposite problem: how to

Re: RFC 79 (v1) Code which is both executable and POD.

Andy Dougherty wrote: > > This is another instance where a macro preprocessor might be useful. > ... > Just hoping that looking at it from another skewed viewpoint may inspire > someone, Fine; but I hope people only see RFC 79 as an extension to POD, because that's all it really is. It does not

Re: Overloading && ||

> No. I don't want to see && or || and not know whether it short-circuits > without looking in the class interface. My brain is conditioned through > years of C and Perl to expect that they always short-circuit. This is too > venerable a semantic to change. Please. What if I want t

Re: RFC: Higher resolution time values

At 06:16 PM 8/9/00 +, Nick Ing-Simmons wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > >> > >>As an engineer I would really like to know when you are going to > >>run out of precision in double - that is forty something bits of mantissa. > >>That is more precision than you have in the real

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

At 11:11 AM 8/9/00 -0700, Larry Wall wrote: >Dan Sugalski writes: >: Does that mean, then, that when module A does a "$C::bar = 1" it affects a >: different package namespace than module B doing a "$C::bar = 2"? > >Presumably. H. That brings up some issues of ambiguity, then. If you use C in

Re: Overloading && ||

At 04:58 AM 8/10/00 +1000, Damian Conway wrote: >> No. I don't want to see && or || and not know whether it short-circuits >> without looking in the class interface. My brain is conditioned through >> years of C and Perl to expect that they always short-circuit. This > is too > >

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

At 12:09 PM 8/9/00 -0600, Nathan Torkington wrote: >I want the core to stay useful but not complex. If localtime returned >a hashref in scalar context, that'd be enough for me: > > $now = localtime; > print $now->{MONTH}; > print $now->{YEAR}; # already has 1900 added onto it :-)

Re: RFC 79 (v1) Code which is both executable and POD.

Larry Wall wrote: > : So, are you saying that if this RFC is implemented, POD would be > : an good way to comment code? > > It already is, as far as I'm concerned. I do too. RFC 79 presumes that POD continues in its state of grace. > Seems like all we're discussing now is how much those indep

Re: Overloading && ||

At 12:04 PM 8/9/00 -0700, Peter Scott wrote: >At 04:58 AM 8/10/00 +1000, Damian Conway wrote: >>> No. I don't want to see && or || and not know whether it >> short-circuits >>> without looking in the class interface. My brain is conditioned >> through >>> years of C and Perl to exp

Re: RFC 79 (v1) Code which is both executable and POD.

> "JP" == John Porter <[EMAIL PROTECTED]> writes: JP> =for pod perl JP> # this line goes to both the default pod processor AND the perl parser. but how will perl access that text? what perl var get the text in that =for block? the proposal for a special here doc notation is possible

Re: Overloading && ||

> >What if I want to overload && and || so that they help built an expression > >tree, rather than immediately evaluating? > > Is it worth the damage it will cause to fragile brains like mine? "Pain is the weakness leaving your body!" ;-) > I have often wondered whether a langua

Re: Overloading && ||

> Of course, by the time Damian's done, perl won't actually *do* > anything--you'll need to fire off another window and do a "kill > -HEYYOUGETMOVING 23442" to actually make something happen... Actually, the plan is exactly the opposite. By the time I'm finished everything will be done

Re: RFC 54 (v1) Operators: Polymorphic comparisons

At 05:12 PM 8/7/00 -0400, Chaim Frenkel wrote: > > "DC" == Damian Conway <[EMAIL PROTECTED]> writes: > > >> I currently fail to switch to 'eq' many times when I should, but the > >> failure mode is obvious. Her the failure mode will be really strange. > >DC> I would claim that the failure mode

Re: Overloading && ||

At 05:23 AM 8/10/00 +1000, Damian Conway wrote: >> Of course, by the time Damian's done, perl won't actually *do* >> anything--you'll need to fire off another window and do a "kill >> -HEYYOUGETMOVING 23442" to actually make something happen... > >Actually, the plan is exactly the oppo

Re: DRAFT RFC: Enhanced Pack/Unpack

At 10:53 PM 8/7/00 +0200, Bart Lateur wrote: >Right. Why you people don't call it "Intel" vs. "Motorola", like the >rest of the civilised world, I don't know. ;-) See the TIFF spec, for >example. > >Er, in case you were in any doubt: Motorola (from the 68k processors) is >BigEndian, Intel (x86)

Re: DRAFT RFC: Enhanced Pack/Unpack

At 07:26 PM 8/7/00 +0100, Tom Hughes wrote: > From /usr/include/endian.h on my linux box: > >#define __LITTLE_ENDIAN 1234 >#define __BIG_ENDIAN4321 >#define __PDP_ENDIAN3412 > >Basically PDP or middle endian is low byte first within each word >but high word first in the overall longword.

Re: chomp & unchomp

On Wed, 09 Aug 2000, Ed Mills wrote: > Here is the argument- > > Perl has (had?) chomp(). It removes \n at the end of a line. That's > something we often need to do. We ALSO often need to ADD \n to the end of a > line. This usually looks something like: > > print "$kitty\n"; Chomp removes o

Re: RFC 79 (v1) Code which is both executable and POD.

Uri Guttman wrote: > > but how will perl access that text? what perl var get the text in that > =for block? Well, the proposal was more about getting perl code into doco than getting doco into perl. > the proposal for a special here doc notation is possible but > that can be hard for pod to p

Re: chomp & unchomp

Bryan C. Warnock wrote: > > Chomp removes one or more line separators from the end. It does? You're using a different version of Perl than I am. -- John Porter

  1   2   >