Re: Perl6Storm: Intent to RFC #0101

> if ( all { $_->($file) } \&writable, \&directory ) { ... Is that the PDL C? With the superpositional C it would be: if ( all(\&writable, \&directory)->($file) ) { ... :-) Hm. Maybe C, C, etc. could return objects that equate to a filename *only* if the original predicate is t

Re: RFC 290 (v1) Remove -X

> > > I'd even go so far as to say that the current -X syntax should be > > > _extended_, to allow for multiple tests at once, maybe by way of a > > > leading caret (mnemonic "all"): > > > > > > -^rwx; # $_ is readable, writable and executable > > > > > > ($s

RE: RFC 264 (v1) Provide a standard module to simplify the creation of source filters

Paul wrote: > > Given this level of complexity, it's perhaps not surprising that source > > code filtering is not commonly used. > > Whilst I don't have any problems with you module, I think you are > overstating the complexity of the existing situation. This should be all > t

Re: Exposing regexp engine & compiled regexp's

> 1. I think it should be possible to have ``incomplete matches''. > > Regexp's are interpreted by a NFA, that is a state machine. > I think it would be nice if, when I try to match a regexp against > a string, and the string ends before the regexp matches, it >

Re: Exposing regexp engine & compiled regexp's

Branden wrote: > I read your RFC 93. It mentions using a sub to read from the > string. I just think it uses the sub in two conflicting ways, one > for requesting more data from the stream and other for telling > there was a match. It's really using the sub as a interface to whatever

Re: Exposing regexp engine & compiled regexp's

> I once brutalized Henry Spencer's engine into telling me when I was > on my way to a match. This was for a UI: I wanted to be able to say > that the input should only match this RE, and if they typed something > that broke the match, I could beep and disallow the character. >

Re: Exposing regexp engine & compiled regexp's

> The only thing I remark is that I believe all of Perl should be the > most exposed possible, so that unseen levels of introspection > can be achieved. In that philosophy I wrote my idea about > exposing the engine's guts. I'm well-known as a non-delving-into-the-guts type of guy. I

Re: Exposing regexp engine & compiled regexp's

> As Rick pointed out, there's no problem with overloading =~ for an > object, in the same way it's done with `eq', and one object's > function could return either an object or a closure (a sub > reference), so that a module could even hide the details of whether > it's using the ob

Re: About RFC 271: pre/post handlers

Branden wrote: > I was reading RFC 271 and thinking about this pre/post handler > thing. Why instead of having 2 subs, one for pre and other for post > condition, and having to deal with things as strange as $_[-1], why > don't we have only one handler that calls the real sub? Becaus

RE: About RFC 271: pre/post handlers

> > the RFC has a glaring mistake: derived pre-conditions are > > supposed to be tested *before*, not after inherited ones!) > > Okay... good... nix. You'd want/need pre's called in derived-first order > anyways to hide the messy implementation details of base classes. Yup. It wa

Re: About RFC 271: pre/post handlers

Branden writes: > > And -- more compellingly -- because the inheritance semantics of > > pre and post handlers are distinctly different. See: > > Well, with those inheritance semantics, I believe the example > > : pre read_file { > : flock $_[0], LOCK_EX; > : }

Re: Why shouldn't sleep(0.5) DWIM?

> >Or, should we just implement usleep() and (for lack of a better name) > > snooze() is a better name ;-) nap() is even better (shorter that sleep() :-) Damian

Re: Really auto autoloaded modules

> Speaking of contract names, is Damien about? No, but when you summon the AntiChrist, I sometimes appear instead. ;-) Damian

Re: Really auto autoloaded modules

> >However, it also seems that this is getting *really* complicated really > >quickly. > > I'd agree. I was picturing the file the parser used reading something like: > >socket|Socket|1.0|gt I think this is the way to go. I'd suggest that the syntax be easier for humans (

Re: Really auto autoloaded modules

> Where should this info be maintained? In a module in @INC (sort of like > CPAN/MyConfig.pm)? Or in a special file that's only written to via a > module install? Or in a block atop each module that's yanked out via > MakeMaker? Or??? The parser needs to have it in a standard system

Re: Really auto autoloaded modules

> I would assume that 'use' would be done before 'autouse', so any 'use > lib' statements would already be taken into account? I'm probably > missing something super-obvious, so please point it out if so. No. C before C was my assumption too. > Yeah, a little too tedious. For the

Re: assign to magic name-of-function variable instead of "return"

> Really? Are lexicals in the sub visible in the post handler? No. Only the original arguments and the return value. > (Of course I realize *F does not illustrate this...) Exactly. ;-) Actually, I do agree that Perl 6 ought to provide a universal "destructor" mechanism on *any* block

Re: assign to magic name-of-function variable instead of "return"

> I see this all the time. What would fit the bill is to have something > like a C block for subs; they get called during the same > phase as destructors of objects going out of scope. > > sub readit { > open F, "< $f" ... > scalar() > } > c

Re: assign to magic name-of-function variable instead of "return"

return ( $stuff, $morestuff, $whatever ) always close F; I *really* like that keyword. Though I'd prefer to see it as a block suffix: sub { ... return $yadda_yadda; } always { close F } Then you could add it to loops as well, in co

Re: Larry's Apocalypse 1

> Of course all of this has been discussed. (See > http://archive.develooper.com/perl6-language-io%40perl.org/, > especially RFCs 100 and 14.) And is already available in a nearby parallel dimension: http://www.yetanother.org/damian/Perl5+i/open.html ;-) Damian

Re: Flexible parsing (was Tying & Overloading)

> I think we have to be careful here. We should ask people to name site > policy files after their site, and not use a generic name like > "site_policy", since we'd be likely to end up with 20 different > "standard" site_policy files wandering around the net. So something > like

Re: a modest proposal Re: s/./~/g

> : Hey, that would make "_ _ __" legal Perl code. Abigail, Abigail! > > Now we just need to make "... ___ ..." mean something exceptional. Just download the Bleach.pm module from the CPAN. It includes Morse.pm. Damian ---cut---cut---cut---cut---

Re: Flexible parsing (was Tying & Overloading)

> > You Americans and your non-ISO penchant for putting the specific before > > the general. Surely that should be: > > > > use Policy::O::Reilly; > > I knew someone would argue that, but I didn't think it would > be someone as illustrious as Damian. Illustrious???

Re: Please make "last" work in "grep"

> > Because you might have a wantarray situation that expects no values? > > > > () = whateveryouwant(); > > I am sure that situation is handled by the 'want' RFC. Yep. The most recent version is at: http://www.yetanother.org/damian/Perl5+i/want.html > I have not re

Re: Please make "last" work in "grep"

> >Hopefully the "something similar", I hope in Perl 6 we will able to > >bury the "0 but true" workaround to the backyard on a moonless night :-) > > Especially since you don't need it. "0E0" and "0.", to name just two, > work just as well. ;-) http://yetanother.org/damian/Perl

Re: Apoc2 - Context and variables

> I'm interested in what happens with interactions: > >$a = @b; > > Does this: > >1. Get the length (doesn't seem to make sense now) No. length(@b) or @b.length() for that. >2. Pull a reference to @b (like Perl5's "$a = \@b") Yep. Scalar context eval of a

Re: Apoc2 - concerns

> > I'm wondering what this will do? > >$thingy = $STDIN; > > This seems to have two possibilities: > >1. Make a copy of $STDIN > > This one. I see a filehandle in *boolean* context meaning "read to $_", > just like the current "while ()" magic we all know and occasio

Re: Apoc2 - concerns

> Doubtless Damian could come up with a way to view them as hashes... Well, of course. An iterator is neither pure state nor pure behaviour. It's an inextricable commingling of the two. In other words: an object. So they are *most naturally* viewed as hashes: package Iterator;

Re: Perl, the new generation

> Damian's converted a program from the Cookbook to perl6 to show how > the language might look. It's not vastly different from the perl5 > version. It certainly still looks like the same language. Yep. BTW this is the first in a series of articles paralleling Larry's Apocalypses. Ever

Re: p6 casting as shortcut for lengthier p5 syntax

> What about array and hash accesses starting with scalar-indicators? > I guess it is easy to misread A2 to mean that not only will > >scalar(@trucks[5]) > > return the sixth truck, but > >$trucks[5] > > will no longer work. Just so everyone is clear: i

Re: what I meant about hungarian notation

> When all the smoke clears, it will be relatively simple to declare an > ordered hash probably on the order of adding a single word to its > declaration. Yep. In fact, it's now relatively simple in Perl 5. You just grab the Attribute::Handlers and Tie::SortHash modules and add a sing

Re: Apoc2 - concerns

> Perhaps it's because the people who are capable of writing such a > module, are the ones who don't need it. But, not everyone is a conway. Immortality at last...I appear to have become a common noun. ;-) Damian

Re: what I meant about hungarian notation

I'm not buying into the argument...just providing data: > What is the meaning of the following four expressions in Perl6? > > @bar[$foo]; # A Access element int($foo) of array @bar > %bar{$foo}; # B Access entry "$foo" of hash %bar > @bar{$foo}; # C

Re: Damian Conway's Exegesis 2

John Siracusa wrote: > Okay, this part has me confused. And rightly so: it was a screw-up. I lost track of whether I was keeping the property on the value or on the node reference and ended up doing both. Interestingly, the code would still have *worked* since the (originally unset) proper

Re: Damian Conway's Exegesis 2

Bryan C. Warnock sniped: > >> Okay, this part has me confused. > > > > And rightly so: it was a screw-up. I lost track of whether I was keeping > > the property on the value or on the node reference and ended up doing > > both. > > What? You didn't test it before you po

Re: Damian Conway's Exegesis 2

Simon observed: > On Tue, May 15, 2001 at 03:30:07PM -0700, Dave Storrs wrote: > > - A while ago, someone suggested that the word 'has' be an alias > > for 'is', so that when you roll your own properties, you could write > > more-grammatically-correct statements such as "my $var has

Re: 'is' and action at a distance

Ed wrote: > Any ideas on how to handle this with the 'is' keyword? I was > reading the slashdot comments to Exegesis II, and this seemed to be > the one issue that had merit. A couple of the posters bemoaned the > fact that they were debugging PL/I about 25 years ago, and had code

Re: 'is' and action at a distance

Ed asked: > > print %{(+$fh).prop};# All the value's properties > > > > um.. I'm not the greatest fan of this syntax.. what's the '+' for? As I explained at the end of the "re: properties" message, it's to evaluate $fh, so we get the hash of properties belonging the value in

Re: 'is' and action at a distance

Ed said: > No, because you can say: >print "$fh"; > and find out exactly what is going on. > > In the case with > undef $fh; > $fh is true. > > if ($fh) { print "HERE!!!\n"; } > > print "$fh"; > > you get nada, right? Right. > So... why t

Re: 'is' and action at a distance

Schwern wrote: > Let me see if I understand this... > > $Foo is true; > > # Meanwhile, in another part of the city... > > $Foo = 0; > print "My spider sense is tingling" if $Foo; > > Does that print or not? Not. The run-time property is set on the *value* i

re: properties

Thanks to everyone who has been contributing to the discussion on properties, and especially to those who have emailed me off-list about the issue. Unfortunately, I'm currently not able to respond individually to further messages on this topic. My latest Conway Channel diary entry at

Re: Separate "as" keyword? (Re: 'is' and action at a distance)

Bart wrote: > >While I understand how "0 but true" is a cute hack that is destined to > >be replaced by a truth property, I fail to realize how it's useful to > >have a value that's true no matter what value you assign to it later. > > I thought the "truth" property was attached t

Re: 'is' and action at a distance

Piers wrote: > > >> Can 'undef' valued thingys have properties > > > > > > Yes. > > > > > >> and functions? > > > > > > No. > > > > > > > Why not? > > You can always set a property on a function reference. But it seems a > little weird that

Re: 'is' and action at a distance

Graham wrote: > On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote: > > > print keys $foo.prop; # prints "NumberHeard" > > > print values $foo.prop; # prints "loneliestever" > > This is an example of one of my concerns about namespace overlap > wit

Re: Slice refs

Peter Scott 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. > Hey, this is *Perl*! Of course i

Re: properties

Graham wrote: > > >my $a is true = 0; # variable property > > >my $a = 0 is true; # variable property > > >my ($a) = 0 is true;# value property > > > > Wow. Totally ETOOCONFUSING. > > That has been exactly my thou

Re: Slice refs

Peter wrote: > >$ref = > > sub{my%k;@k{@{+pop}}=\(@_);splice@_,$_,!$k{$_}for reverse > > 0..@_;\@_}->(@A,\@I); > > Oh, well, if I'd known it was *that* succinct... > > But... that *does* involve copying; the original poster was talking > about huge arrays where copyin

Re: properties

Dave Storrs wrote: > Second: I'm afraid that even after all this discussion and puzzling over > this table for a bit, I'm still a bit baffled by this stuff. Perhaps I'm > just slow, but let's assume for the sake of argument that I'm not the only > one still scratching his head. C

Re: properties

Scott wrote: > Would you also advocate separate declarative syntax for variable > properties and value properties? That's where I think much confusion > will be. That's covered in my new proposal too. Damian

Re: properties

Scott Duff wrote: > > $bar is Open; > > $bar is Open("from 5pm"); > > $bar{soom} is Open("from 5pm"); > > "bar" is Open("from 5pm"); > > 1 is Open("from 5pm"); > > > > Note that in the first three of the above cases, it's the I > vari

Re: properties

> > Err. There are only two things: compile-time variable properties and > > run-time value properties. Attributes are a Perl 5 construct that we're > > renaming because the name conflicts with the OO term for object data. > > So, > > $a is true > > and > > $

re: properties

MJD just pointed out a minor thinko in the explanatory Perl6 code I posted: sub gorkulator { ... return $result is true if defined $result; return undef is Because($borked); } # and later... if ($res = gorkulator) {

Re: 1 until defined(getvalue()); return it;

David wrote: >defined $thing and return $thing Why not use the existing mechanism? Namely: return $_ for grep{defined} $thing; which also scales rather nicely: return $_ for grep{defined} $thing, $otherthing, $somethingelse; As for the original problem of: 1

Re: $foo.Foun (was Re: Properties and stricture)

> Question 1: > > Afaict, even with use strict at its most strict, perl 6 > can't (in practice) complain, at compile time, if > > $foo.Foun > > refers to an undeclared Foun. It could certainly warn you, but it can't object fatally since there's always the p

Re: $foo.Foun (was Re: Properties and stricture)

> Consider the code: > > my $foo = 1 is Found; > &bar($foo); > > sub bar { my $baz = shift; if ($baz.Found) { ...} } > > Does the value of $baz have the Found property? Yes. > If so, does the compiler know that? No. Because it only has the property at

Re: $foo.Foun (was Re: Properties and stricture)

> So, is it right to say that one can't use stricture to avoid > use of mistyped user defined value attached properties? > (Perhaps with the exception of references to a value > property in the same lexical scope as assignments of > that value?) > > And, if this is so, then i

Re: Coupla Questions

> So, to match $foo's colour against $bar, I'd say > > $bar =~ /$foo.colour/; No, you need the sub call parens as well: $bar =~ /$foo.colour()/; > Great, but how do I match $foo followed by any character followed by the > literal "colour"? $bar =~ /

Re: Coupla Questions

> >> So, to match $foo's colour against $bar, I'd say > >> > >> $bar =~ /$foo.colour/; > > > > No, you need the sub call parens as well: > > > > $bar =~ /$foo.colour()/; > > Hm, I thought Larry said you would need to use $() to interpolate

Re: Coupla Questions

> But with the above you still have abiguity, for example what does this do > > $bar =~ /$foo.colour($xyz)/; "Looks like a method call with parens, so *is* a method call with parens." > I may be remembering about interpolation into strings as "$file.ext" is > going t

Re: Coupla Questions

> > But it's not as *convenient* as "unadorned" interpolation. > > Sometimes convenient has to give way Here we differ. I think the frequency of the /$var.ident(whatever)/ pattern is likely to be low enough that method interpolation is a better use for the syntax. > > Exp

Re: Coupla Questions

> Should properties interpolate in regular expressions? (and/or strings) Do you mean property look-ups via the pseudo-method syntax? In that case, yes they should > I don't suppose they should, because we don't expect subroutines to. > (if $foo =~ /bar($baz,$quux)/;? Urgh, maybe we ne

Re: Coupla Questions

> > $ref.{a}can be $ref{a} > > which can also be > > $ref.a > > can it not? Err..no. $ref.{a}/$ref{a} is an access on a hash element through the hashref in $ref. $ref.a is a call to the method a() of the object referred to by

Re: Coupla Questions

Graham asked: > IIRC there was some suggestion of a class being able to declare > elements to be accessable as methods in this was. > > So if $ref is of a known type and 'a' was declared in that way, > the parser would take $ref.a and turn it into $ref.{a} This is intended. I'm n

RE: suggested properties of operator results

Dave Whipp asks: > Does it do short-circuit evaluation, too? I would certainly expect it to, yes. Damian

Re: Coupla Questions

> What I was asking, in a roundabout way, was if > $foo.bar.baz > makes sense; your answer suggests that it does. In which case, we can > teach the parser that a property query is just like a method call is > just like a hash or array element (with optional dereference if you're

Re: suggested properties of operator results

Larry and I recently discussed chaining inequality operators. He's in favour of it, but not of complex semantics involving properties and implicit state (as I originally proposed in the RFC) I think we will see n-ary comparisons allowed in Perl 6: if ($x < $y <$z < $foo) {... but as sp

Re: Coupla Questions

Simon asked: > Are properties subscriptable? (Can the value of a property be a > reference that can be dereferenced?) Property values can be any scalar value, including array, hash, and code refs. > Can properties have properties? No, but their scalar values can. Damian

Re: Coupla Questions

Graham wrote: > Now I may be wrong here, but I thought I remembered something about > > .foo being the same as $_.foo It's certainly a possibility. > In which case you could do > >for (%database.$accountnumber) { > >.interestearned += $interestrat

Re: Multiple classifications of an object

> >What's wrong with multiple inheritance? > > Nothing, but he wants MI on a per-object basis, rather than a per-class > basis, presumably to avoid having to create a zillion classes who's sole > purpose in life is to have an @ISA array. > > Sounds sensible, and worth send

Re: Multiple classifications of an object

> > The downside is of course that I need to make a small stub for every > > single function I want to delegate. > > Well, that's relatively simple to automate... > > Wasn't Damian working on something like this? I looked at his > delegation stuff in perl5+i, but it didn't

Re: Generalizing value properties to become postits

> Simplifying somewhat (ok, a heck of a lot), an rvalued: > > $foo is bar > > or > > $foo : bar > > is syntactic sugar for: > > bar($foo) > > with some extra magic for handling a properties hash > associated with $foo's value, in particul

Re: Generalizing value property setting to become postits

> > Me: > [$foo is bar] can change the value of $foo. > > > Damian: > Yes. For example: > my $foo is persistent; > > Could you explain this further please? The programmer has specified a property named 'persistent'. The programmer has marked the

Re: (proto)typing, return types, polymorphism, ... ?

Chris Hostetter asked: > Quandary #1: How "deep" of type specifications should / will perl6 allow? > For example, could something like this work? > my ARRAY(int(0..9)) $ref # $ref can only store an array ref > # ...and that array can only hold ints

Re: nice2haveit

> Two things i think is good to have it : > > 1. ALIAS keyword. > - first reason is 'cause many people don't know that this is possible.. at > least any newscommer and it will help not to forgot that it exist :"). > - Code become more readable. > - can be Overloaded >

Re: properties, revisited

> Damian, > You mentioned in E2 that the chomped property relies on the insep > property of the filehandle (formerly $/). Can I extrapolate that >$. >$, >$\ >$| > will also be properties on filehandles? (How about >$" > for arrays?) It's not

Re: properties, revisited

> More questions regarding the new 'given when' construct. More answers (modulo Larry :-) > 1) Is a 'when' clause required? Is it: > > [ LABEL: ] given ( expr_1 ) { >when expr_2 : block >[ when expr_3 : block ...] >expr_n [;] >

Re: properties, revisited

Dan suggested: > The syntax for variable and value properties are going to be different, I > think, I just can't remember what it's going to be. (I think the colon's > involved, but isn't it always?) I think you're now channelling my de specula, not Larry's de jure. :-) In A2, Larry

RE: properties, revisited

> # >my $foo is const = 0 is true; > # > > # > $foo has the property const, while the value 0 in $foo has > # > the property true. > # > # So, if I do > # > # my $foo is constant = new Counter(0); > # $foo->increment # OK > > I think so. Yep. Except the prop

Re: properties, revisited

> There are a number of properties "built into" Perl 6. Nearly all of these > properties don't make sense across the board - eg, a scalar won't have a > dimension, a hash won't prompt, etc. > > So given the two different sets that you must consider (variable versus > value, and

Re: Expunge implicit @_ passing

> When foo() is called as &foo with no parens and no arguments, it > inherits @_ from it's caller. > I can't think of any reason why this feature is useful anymore, and it > can be a really confusing behavior, so what say we kill it in Perl 6? It's alreday scheduled for termination.

Re: Will subroutine signatures apply to methods in Perl6

Garrett asked: > Any word from on high whether subroutine signatures will apply to > methods in Perl6? Well, I hardly qualify as "on high" ("on *a* high" perhaps?) but I can definitely say this: They will and they won't. ;-) At compile-time, signatures can only be honoured if the com

Re: Temp properties

John asked: > Can properties be temp()orarily masked? For example: > > foreach my $array (@arrays) > { > temp $array.sep = ', '; # assuming this is a real property > print "$array\n"; # prints "item1, item2, item3, ..." > } I would expect so,

Re: Will subroutine signatures apply to methods in Perl6

Uri writes: > DC> One might also envisage a C pragma to require > DC> that all lexicals be typed. > > do you mean lexical params in a sub signature? or all lexicals in the > current scope which contains the pragma? any(@above). Some people will want one; some, the other. We

Re: CLOS multiple dispatch

> > I sure miss multi-dispatch. http://dev.perl.org/rfc/256.html Damian

Re: CLOS multiple dispatch

Schwern explained: > # Following RFC 256 > sub name (Foo $self) : multi { > return $self->{name}; > } > > sub name (Foo $self, STRING $name) : multi { > $self->{name} = $name; > return $self->{name}; > } > > which is q

Re: CLOS multiple dispatch

> Even if the dispatcher is the heart of multimethods, perhaps it > would be nice if it were convenient to replace the dispatcher > in whole or part. I'm sure if we asked Dan nicely, he'd consider hanging the dispatcher on a lexically-scoped hook to make that possible ;-) Damian

RE: CLOS multiple dispatch

> > It doesn't. The multimethod consists of those variants that are currently > > loaded. > > > How do you define the currently loaded? Accessible in the program's symbol table and registered with the multimethod dispatcher. > >> 2) If there is mismatch on more than one

Re: CLOS multiple dispatch

Dan observed: > I hadn't considered having it as a global thing, just because I can see > class Foo wanting multimethods, and class Bar being fine with 'normal' > class hierarchy walking, and class Baz deciding it wants the automatic > redispatch form of method calling. > > We

RE: CLOS multiple dispatch

Hong wrote: > > Note that the handler that is selected depends on the *combination* of > > the types of the two arguments. And that the dispatcher understands > > the argument/parameter inheritance relationships and selects the most > > specific handler for each combination. For examp

Re: Multiple-dispatch on functions

> Thinking about what Zhang was saying about multiple-dispatch not being > inherently OO. I think he's sort of right. Multiple-dispatch need > not be confined to method lookups. True, but that doesn't make it non-OO ;-) > foo(); > foo($bar); > foo($baz); >

Re: Multiple-dispatch on functions

Ken wrote: > The way to approach this problem is to profile > Class::MultiMethods and figure out (a) where the hot spots > are and (b) what core support would help eliminate those > hot spots. But please don't do that until I release the next update of C::MM, which will use a new dis

Re: LangSpec: Statements and Blocks [first,last]

iVAN wrote: > As we read in Damian Conway- Perl6-notes, there will be "...may be..." (Remember, I'm only the shambling henchman ;-) > a var-iterator that can be used to see how many times the cycle has > been "traversed" i.e. > &g

Re: Prototypes

> But since the current prototyping system... has a highly positive > pressure gradient compared to the surrounding air, Well...I think it's more a problem of "I do no' thin' dat word means wha' you thin' it means". People want prototypes to be parameter type specifiers, when they're actua

Re: Prototypes

> > Are prototypes going to be checked at runtime now? > > For methods, at least. Dunno about subs, that's Larry's call. I > could make a good language case for and against it. It adds > overhead on sub calls, which is a bad thing generally. I would strongly like to see a guarante

Re: What's up with %MY?

> I haven't seen details in an Apocalypse, but Damian's > Perl 6 overview has a bit about it. The Apocalypse > specifically mentions *compile-time* scope management, > but Damian is, uh, Damian. (DWIMery obviously. ;) Hmm. It would seem *very* odd to allow every symbol table *ex

Re: LangSpec: Statements and Blocks

Some feedback. > Syntax Overview > > Keywords > continue, do, else, elsif, for, foreach, given, goto, grep, if, last, > map, next, redo, sort, sub, unless, until, when, while C and C (C is not nearly so certain.) > Conditional Statement Modifiers > > 6. [ L

Re: What's up with %MY?

Dan revealed: > > How am I expected to produce fresh wonders if you won't let me > > warp the (new) laws of the Perl universe to my needs? > That's easy--you slip the pumpking or internals designer a 10-spot. > Amazing what it'll do... :) And how do you think I got five of my module

Re: What's up with %MY?

Dave Mitchell asked: > If there is to be a %MY, how does its semantics pan out? That's %MY::. The colons are part of the name. > for example, what (if anything) do the following do: > > sub Foo::import { > my %m = caller(1).{MY}; # or whatever > %m{'$x'} = 1;

RE: What's up with %MY?

Dan wrote: > At 12:50 PM 9/4/2001 -0500, Garrett Goebel wrote: > > > >So deleting it > >would remove it from the scratchpad of &incr. But I would guess that > >future calls to &incr would have to autovify $x in the scratchpad and > >start incrementing it from 0. I.e., ignorin

Re: Prototypes

Bryan wrote: > > > Er, scratch this. Blows up if the sub isn't prototyped. A much > > > *better* way is to make the prototype of any sub a property > > > (trait) of that sub. We can always query for a property. > > > > This is possible now: > > $foo = sub ($) { print "hello wor

  1   2   3   4   5   6   7   8   9   10   >