Re: A thought for later -- POD tables

... -- Peter Scott

Re: Perl 6 Summary for 2004-10-01 through 2004-10-17

ke of genius. This conjured up an image of Larry whacking someone with a coelacanth... -- Peter Scott http://www.perldebugged.com/ *** NEW *** http://www.perlmedic.com/

Re: Must pseudo-hashes die?

d accept the other features it provides. I'd like to see this in Perl 6. I detest the pseudo-hash implementation (the part that's exposed to the user, I mean). -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com

Re: Exegesis2 and the "is" keyword

, yet this usage might suggest to many people that they can be changed at run time. If you see what I mean. I'm sure I could get used to it, I'm just speaking to learnability. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com

Slice refs

and I haven't grokked that from the exegeses yet. That's it. We now return you to the Clinton discussion ("it depends what the meaning of 'is' is...") -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com

Re: Slice refs

At 01:31 PM 5/21/2001 +1000, Damian Conway wrote: >> Um, this is a tiny little diversion here prompted by something that >> came up on perl-beginners, of all places... it's not possible in >> perl 5 to make a reference to an array or hash slice without doing >> some copying. >>

Re: Properties and stricture

. Of those, only subroutine refs and automatic method generation look like must-haves for major projects, which are willing to surrender some of the cute stuff in return for stability. Quite how Foo prevents Bar from causing shenanigans if Bar was used first, I don't know; might not be possible until runtime. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com

Re: Properties and stricture

At 02:39 PM 6/5/2001 -0700, Daniel S. Wilkerson wrote: >Thank you, that's what I thought it might be. This can be done at compile >time with a two-stage >compilation. The first one writes the code that the second >compiles. Then the checking can be >done during the second stage. Not when the

Re: Multi-dimensional arrays and relational db data

At 05:58 PM 6/10/2001 -0400, Sam Tregar wrote: >SQL via DBI. It's got a terrible learning curve but it's still around for >a reason. You learn all about SQL's strengths if you start trying to >replace it with arrays and hashes. Go forth and learn! He's right. I do a lot of DBI stuff with Orac

Re: Multi-dimensional arrays and relational db data

At 06:06 PM 6/10/2001 -0500, Me wrote: >Dataset from multiple 'joined' tables > > (A pair of joined tables can be visualized as two > spreadsheet like grids that intersect at right angles > with the intersection point being the joined column. > The vertical slice picks out rows whe

Re: Multi-dimensional arrays and relational db data

ill don't think there's anything to be gained here. As far as I can tell, you're saying, "I want it to be easier to express relational database operations." Me too. I just don't think they get any easier than they already are. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com

Re: Multiple classifications of an object

s" relationship, >but that doesn't feel much better. Its just another >way of programming round a weakness in the object >models of most mainstream languages > >Can anyone see any problems with making C and >C work with lists? C is not effected. We >might want some magi

Re: Per-object inheritance in core a red herring?

did, it might be really slow. > > Somebody should write an implementation first, and then tackle efficiency. > >This is a joke, right? I'm on Candid Camera. I think people are just surprised that you didn't call it Red::Herring. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com

Re: Barewords and subscripts

yes, because then we could treat >*all* instances of {...} as a block returning either a closure, a value >for subscripting, or an anonymous hash, rather than having to decide at >tokeniser time. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com

Re: Barewords and subscripts

At 05:43 PM 1/26/02 +, Simon Cozens wrote: >On Sat, Jan 26, 2002 at 09:28:18AM -0800, Peter Scott wrote: > > >%foo{"bar"} > >It's bare, and it's a word. Maybe you want to come up with another term to describe it then... but it isn't a &

Re: Barewords and subscripts

bout how Perl 6 should be easier to parse, and this issue is the poster child for the "Only perl can parse Perl" camp. Does the price of easier parseability have to be "oatmeal mixed with fingernail clippings"? -- Peter Scott Pacific Systems Design Technologies

Re: rethinking printf

#x27;s a constant, but not if you're doing something like printf "#.3f " x @nums, @nums; and @nums is empty. You could always scan the format for a %-specifier which was valid under the old rules and warn that they seem to be using retro syntax. # bespeaks a number-type of thi

Re: Ex4 smart match question

t do @left =~ @right %left =~ %right do? One can imagine useful default interpretations that are not commutative. -- Peter Scott Pacific Systems Design Technologies

Re: Loop controls

and undef or empty list for loops that didn't execute at all). Which means that some loops could execute and still be false. Is this hopelessly retrograde thinking? Are the hordes of programmers yet-to-be that will be weaned exclusively on Perl 6 look scornfully on me for such opin

Re: Loop controls

ting into the language something which will get very little use, except that a few people will no doubt enjoy it and insist they can't live without it? I'm starting to wonder whether some features should be optional... use extended qw(loop_syntax); -- Peter Scott Pacific Systems Design Technologies

Re: eval {} or carp "blah: $@"

At 02:33 PM 5/2/02 -0600, Jim Cromie wrote: >eval {} or carp "$@ blah"; > >it seems to work, and it reads nicer (to my eye) than > >eval {}; if ($@) {} % perl -le 'eval { print "No exceptions here"; 0 } or warn "$@ blah"' No exceptions her

Re: Perl 6 Summary

l_2001.html Or if you like: http://www.yetanother.org/damian/Perl5+i/coroutines.html -- Peter Scott Pacific Systems Design Technologies

Re: Continuations for fun and profit

closures, we >can do this from wherever we like in the program. So if you could serialize a continuation, you could freeze your program state to disk and restore it later? Cool, makes for easy checkpoint/restarts. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/

Re: [perl6/specs] 58fe2d: [S12] spec setting and getting values of attribute...

iolated the separation of thingummy (my terminology isn't so good here, I trust you know what I mean). I don't know how you solve this but please think about this use case. Of course not every object can or should be serialized but elective object persistence is pretty important.

Re: The trouble with awesome

rest were sysadmins). Now the landscape looks very different. -- Peter Scott

<    1   2   3