Re: Parrot 0.7.1 "Manu Aloha" released

Patrick R. Michaud wrote: I sent the appropriate patch to the webmaster, but it hasn't been applied yet (and I lack a commit bit for the parrotcode.org site). Once that's applied, the url should be fixed. Thanks, applied. I also updated parrot.org. Allison

Parrot 0.4.13 "Clifton" Released

On behalf of the Parrot team, I'm proud to announce Parrot 0.4.13 "Clifton." Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.4.13 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. Parro

Perl 6 & Parrot Essentials as project documentation

I just signed an agreement with O'Reilly that assigns the full copyright in the book "Perl 6 and Parrot Essentials" to The Perl Foundation. The text is out-of-date, but can be updated much more rapidly than it can be rewritten from scratch. I'll check the Parrot parts into:

new Parrot project manager

We're splitting off the Parrot project manager role from the Perl 6 project manager role, to make better use of the time and energy of available volunteers. Will "Coke" Coleda has graciously agreed to take on the PM responsibilities for Parrot, and Jesse Vincent will continue as PM for Perl 6.

namespaces, a single colon to separate HLL prefix?

Quick question, is there a syntax specified in Perl 6 for referring to namespaces from other languages? I'm reviewing the namespaces PDD and want to update this snippet: -- IMPLEMENTATION EXAMPLES: Suppose a Perl program were to import some Tcl module with an import pattern of ``c*'' -- som

Re: [svn:perl6-synopsis] r9197 - doc/trunk/design/syn

Smylers wrote: Allison Randal writes: I keep expecting 'sigspace' to have something to do signatures. So do I. How about :litspace for 'literal space'? Except they aren't exactly literal, because they only indicate where _some_ space has to be, not that it has t

Re: [svn:perl6-synopsis] r9197 - doc/trunk/design/syn

[EMAIL PROTECTED] wrote: Log: Changed :words/:w to :sigspace/:s and invented ss/// and ms// (or maybe mm//). I keep expecting 'sigspace' to have something to do signatures. Larry++ on :s. :) Allison

Re: A rule by any other name...

Oh, and since we're calling them "regexes", I suggest calling them "regular expressions" too, since both "regex(p)" and "regular expression" have taken on the popular meaning of "pattern matching". If we're going to be anti-pedantic, let's be consistently anti-pedantic. :) Allison

Re: A rule by any other name...

Patrick R. Michaud wrote: Whitespace in regexes and rules is metasyntactic, in that it is not matched literally. Effectively what the :w (or :words or :skip) option does it to change the metasyntactic meaning of any whitespace found in the regex. Or, another way of thinking of it -- as S05

Re: A rule by any other name...

Jonathan Scott Duff wrote: On Wed, May 10, 2006 at 05:58:57PM -0700, Allison Randal wrote: rule: - Has :ratchet and :skip turned on by default - May only be used inside a grammar Should that be - Must be declared as part of a grammar or role ??? It is: - The 'rule' keyword m

Re: A rule by any other name...

Patrick R. Michaud wrote: On Thu, May 11, 2006 at 08:57:53PM +0800, Audrey Tang wrote: Patrick R. Michaud wrote: - is a single character of obligatory whitespace Hmm, it's literal ' ' (that is, \x20), not "whitespace" in general, right? For "obligatory whitespace" we have \s. Oops, you're

Re: A rule by any other name...

Damian Conway wrote: skip: - We keep :words as shorthand for :skip(//) - And :skip is shorthand for :skip(//) ...where defaults to , but is distinct from it (i.e. it can be redefined independently). It also has the benefit that developers redefining can call as one of the alternates i

Re: A rule by any other name...

To summarize a phone call today, the more intelligent defaults we add to differently named rule keywords the more comfortable I am with having different names. So, here's what we have so far (posted both as an FYI and to confirm that we have the coherent solution I think we have): rule: - Has

Re: A rule by any other name...

On Wed, 10 May 2006, Damian Conway wrote: > Allison wrote: > > I've never met anyone who *voluntarily* added > the 'p'. ;-) You've spent too much time in the U.S. ;) > > and the fact that everyone knows 'regex(p)' > > means "regular expression" no matter how may times we say it doesn't. > > Su

A rule by any other name...

On Apr 20, 2006, at 1:32 PM, Damian Conway wrote: KeywordImplicit adverbsBehaviour regex (none) Ignores whitespace, backtracks token :ratchetIgnores whitespace, no backtracking rule :ratchet :words Skips whitespace, no back

Re: A proposition for streamlining Perl 6 development

On Feb 7, 2006, at 19:21, Stevan Little wrote: Perl 6 will get implemented. Oh, of that I have no doubt. Never did, and neither does Yuval (if I may speak for him while he is asleep :). But all that we are trying to do here is shake out some cobwebs, a little spring cleaning if you will. Ex

Re: A proposition for streamlining Perl 6 development

On Feb 7, 2006, at 15:31, Stevan Little wrote: Now I am not as involved in Parrot as I am in Pugs so I might be way off base here, but from my point of view Parrot still has a long way to go before it runs Perl 6 code. Part of that is because the bridge between PIR/PMCs and Perl 6 just does not

Re: A proposition for streamlining Perl 6 development

On Feb 7, 2006, at 13:28, Yuval Kogman wrote: Apologies if this is insulting to anyone, but personally I think that Perl 6 (pugs, parrot, everything) is losing too much momentum lately. I think we need to seriously rethink some of the implementation plan. I understand your frustration. I even

Reviewers for "Perl 6 Essentials", 2nd. ed.

It's that time of year again, and we're looking for reviewers for the 2nd edition of "Perl 6 Essentials". The review will start mid-March and last about a week. Drop me a message if you're interested. We may have to narrow down the list of volunteers a bit. 15 sets of comments is about the maximum

Re: [perl] RE: s/// in string context should return the string

Simon wrote: > > How should we go about bringing A3 up to match current reality? It is, after > all, over two years old now. We talked about this today. Our current thought is to retroactively write the Synopses and keep those up-to-date (with notes in the outdated parts of the A's and E's pointi

Re: Anonymous Subroutine Names

Smylers wrote: > I had been assuming that Perl 6 would continue the tradition that > anonymous subroutines don't have names. > > 'Synopsis 6' contains this line: > > On an anonymous subroutine, any return type can only go after the > name: > > Which "name" would that be? > > The example giv

Re: Pre-defined properties/traits/etc.

Simon wrote: > > > Oh well, it was only two letters. There wasn't anything about > > > approximate matching in A5, was there? > > This was a [MZ]u[nr]ich joke, I think. * Allison trundles off to caffeinate her brain.

Re: Pre-defined properties/traits/etc.

On Sun, Mar 02, 2003 at 12:02:42AM +0100, Paul Johnson wrote: > On Sat, Mar 01, 2003 at 02:58:04PM -0600, Allison Randal wrote: > > > [0] STL = St. Louis - June 2002, ETH = ETH campus in Munich - Sept. > > ETH is in Zurich. The Mini::Conference there was immediately followed

Re: Pre-defined properties/traits/etc.

Simon Cozens wrote: > > Well, here's a start. Here are the ones I've found in the Exegeses and > Apocalypses. Things like 'is copy' and 'is given' (and probably a > great many others) have only been mentioned on the list, and I'm not > grepping through all the list mail. :) C is gone now anyway.

Re: Arrays, lists, referencing

Luke wrote: > If you want to modify a parameter in place, you declare with C. > If you want to pass by-value, there might be a property for that, but > I think this was recommended: > > sub foo($bar_) { > my $bar = $bar_; # Copy, not bind > # ... with $bar > } In th

Re: newline as statement terminator

Nicholas Clark wrote: > There's nothing wrong with stealing, er "borrowing" the good bits of > reptiles though, is there?. I didn't think that perl was fussy about where > it gets its inspiration from. It isn't and never will be. We're openly friendly to all languages. But Perl is also quite diff

Re: newline as statement terminator

Miko O'Sullivan wrote: > > NOTE TO ALLISON RANDAL: in your face-to-face meetings next week, please > make sure that "Larry Wall" isn't really Guido van Rossum with a fake > mustache. Righto. No reptiles, only jewels and birds. And possibly the occasional snark. ;) Allison

Re: Language Discussion Summaries

Miko O'Sullivan wrote: > > Therefore, I propose that members of the language list provide summaries > of the discussions in the group. Each summary describes a proposed idea > feature of the language, then summarizes the list's feelings on the idea. > Different opinions will be presented. The su

Re: Sabbatical from the list

Damian wrote: > This is just to let everybody know that I will be unsubscribing from > p6-lang for the foreseeable future, effective immediately. > > I deeply regret that I simply no longer have the time to cope with the > volume of messages being generated here. Unfortunately, the exigencies of

Re: Unifying invocant and topic naming syntax

Me wrote: > > c) the ability to break lexical scope > > Well, I could argue that c) already exists > in the form of passing parameters in parens. > > Of course, that doesn't feel like "breaking" > anything. Formal parameters are lexically scoped. Lexical scope: references to the established ent

Re: Unifying invocant and topic naming syntax

Austin wrote: > > > The idea of $= as CALLER::_ is good, though. > > > > Though C is a nasty sequence. > > Final // only required for "another default": > //= $= // 5 # Default to $CALLER::_, or 5 Aye, it's just a worst case scenario. C and C<= $=> are still line-noisy. It's a trade-off betw

Re: Unifying invocant and topic naming syntax

On Tue, Nov 19, 2002 at 01:24:30PM -0800, Austin Hastings wrote: > So what's wrong with: > > sub foo($param is topic //= $= // 5)# Shorter form with $= > sub foo($param is topic //= $CALLER::_ // 5) > > It doesn't really seem like we can make it much shorter. Yes, we could > convert //= into

Re: Unifying invocant and topic naming syntax

Austin wrote: > > For methods, will that be the invocant or the first other parameter? > > $string.toLanguage("french") > > Topic is $string, or "french" ? It is the invocant. Allison

Re: Unifying invocant and topic naming syntax

Larry wrote: > I'm trying to remember why it was that we didn't always make the first > argument of any sub the topic by default. I think it had to do with > the assumption that a bare block should not work with a copy of $_ from > the outside. I dug through the archives. We were considering al

Re: Unifying invocant and topic naming syntax

To summarize, we're discussing 3 features: a) the ability to set the topic with a block (sub, method, etc) b) the ability to set a default value for a parameter c) the ability to break lexical scope 1) for $_ only 2) for any variable Each of these features already have syntax that allows

Perl 6 documentation project mailing list

Ask was fast: > Subscribe by sending mail to [EMAIL PROTECTED] > NNTP access and archives at nntp.perl.org will be available a few > hours after the first posting to the list. Let the games begin... Allison

Re: perl6-lang Project Management

[responding to several of the most recent posts] Let's table discussion of the details for a few days until we get the perl6-documentation list set up. Then we can dig into planning out the scope and goals of the project, and what roles various people might take. Allison

Re: perl6-lang Project Management

Dan Sugalski wrote: > Simon Cozens wrote: > > >Here is my suggested solution to the problem. > And, though, snipped, a fine solution it is, with two caveats: There's potential here. If we arrange it so Larry can stay focused and the total productivity of the project increases, we'll have a good t

Re: perl6-lang Project Management

Nicholas Clark wrote: > > Not good. 5 patches means that 4 people wasted effort trying to help. > I don't have a solution to this problem (sorry). But I think it's an > important problem to solve. Wasted effort is a problem. I don't know that a perfect solution exists. Parrot's solution of making

Re: perl6-lang Project Management

On Wed, Nov 06, 2002 at 10:54:23AM -0800, Michael Lazzaro wrote: > > -- The "latest news" on the Perl6 section of dev.perl.org was updated > July 7th, introducing Piers, and other than linking to Piers' summaries > contains no information pertinent to Perl6 -- only Parrot. Sounds like a place y

Re: perl6-lang Project Management

On Wed, Nov 06, 2002 at 06:58:52PM +, Simon Cozens wrote: > [EMAIL PROTECTED] (Michael Lazzaro) writes: > > Big, Big HOLE in the middle. _Who_ is fleshing out the mindless, > > trivial details that Larry posts to this list, and _who_ is > > creating/updating the documentation to reflect those

Re: perl6-lang Project Management

Since you're interested in the management of the Perl 6 project, I'll let you in on some of it. Let's start with a step back into a bit of history: We started off with an intense RFC process. This produced many good ideas, not-so-good ideas, and ideas with potential but desperately needing polish.

Re: Unifying invocant and topic naming syntax

On Tue, Nov 05, 2002 at 05:13:45AM -0600, Me wrote: > > relatively few subroutines need access > > to the upscope topic. > > Well, this is a central issue. What are > the real percentages going to be here? > Just how often will one type the likes > of > > -> is given($foo is topic) { ... } >

Re: Unifying invocant and topic naming syntax

On Sun, Nov 03, 2002 at 11:17:32PM -0600, Me wrote: > > I started with a simple thought: > > is given($foo) > > seems to jar with > > given $foo { ... } > > One pulls in the topic from outside and > calls it $foo, the other does the reverse -- > it pulls in $foo from the outside and ma

Re: Question about "for" loop

On Fri, Nov 01, 2002 at 02:40:08AM +0200, [EMAIL PROTECTED] wrote: > > for @a -> $x, $y { ... $x is topic ... } > > for @a ; @b -> > $x, $y ; $z { ... WHAT is topic ? ... } > > what is topic in multi stream loop ? Always the first, so $x in both. Unless you specify otherwise:

Re: Private contracts?

On Tue, Oct 08, 2002 at 04:32:40PM -0400, Trey Harris wrote: > In a message dated Tue, 8 Oct 2002, Allison Randal writes: > > Hmmm... I can see how it might be handy if C would just > > grab the highest numbered "Acme::N..." module on the system. > > A

Re: Private contracts?

On Mon, Oct 07, 2002 at 05:56:19PM -0700, chromatic wrote: > On Sat, 05 Oct 2002 15:51:04 -0700, Allison Randal wrote: > > > > > class A would have: > > > > use Acme::N-1_0; # or whatever the format of the name is > > > > while the updated class

Re: Private contracts?

On Sat, Oct 05, 2002 at 02:50:11PM -0400, Trey Harris wrote: > > Ah, but the usual case is this: > > You download from CPAN class A that depends on version 1.0 of class N. > You then download class B that also depends on version 1.0 of class N. > You create an application that uses both classes

Re: Private contracts?

On Fri, Oct 04, 2002 at 12:03:44AM -0400, Trey Harris wrote: > In a message dated Thu, 3 Oct 2002, John Williams writes: > > > On Thu, 3 Oct 2002, Trey Harris wrote: > > > > > Incidentally, has there been any headway made on how you DO access > > > multiple classes with the same name, since Larry

Re: Private contracts?

On Thu, Oct 03, 2002 at 05:14:22PM -0400, Michael G Schwern wrote: > On Thu, Oct 03, 2002 at 03:45:33PM -0500, Allison Randal wrote: > > On Thu, Oct 03, 2002 at 03:00:21PM -0400, Michael G Schwern wrote: > > > On Thu, Oct 03, 2002 at 02:46:38PM -0400, Michael G Schwern wrote:

Re: Private contracts?

On Thu, Oct 03, 2002 at 03:00:21PM -0400, Michael G Schwern wrote: > On Thu, Oct 03, 2002 at 02:46:38PM -0400, Michael G Schwern wrote: > > class ATV is Car, interface { > > Hmmm. That should probably be > > class ATV isa Car is interface { That's: class ATV is Car is interf

Re: Private contracts?

On Thu, Oct 03, 2002 at 02:46:38PM -0400, Michael G Schwern wrote: > > attr _tilt is private; BTW, that's: attr $.tilt; Attributes are private by default. Allison

Re: A Perl 6 class question

On Sat, Aug 10, 2002 at 07:30:19PM -0400, Chris Dutton wrote: > > The only problem I could see, and I wanted to wait for at least one > other opinion before mentioning this, is rewriting the above as: > > my $foo_class $foo_obj = $foo_class.new; I'm not exactly sure what you're trying to do wi

Re: A Perl 6 class question

On Fri, Aug 09, 2002 at 03:09:29PM -0400, Chris Dutton wrote: > > This one actually came to me just the other night. Would it be possible > in Perl 6 to create "anonymous classes"? Something like: > > my $foo_class = class { > method new { > # yada yada yada > } > }

Re: Ruby iterators

On Tue, Jul 02, 2002 at 07:32:00PM -0600, Luke Palmer wrote: > On Tue, 2 Jul 2002, Michael G Schwern wrote: > > > * Yes, Perl 6 will have named arguments to subroutines. > > > > What I can remember from the Perl 6 BoF is it will look something like this: > > > > sub foo ($this, $that) { > >

Re: Some regex syntax foibles

On Tue, Jul 02, 2002 at 03:59:57PM -0500, Allison Randal wrote: > > The parens in #3, C<< <( code )> >>, make sense if you think of s/3/2/ Allison

Re: Some regex syntax foibles

On Mon, Jul 01, 2002 at 02:52:06PM -0500, Me wrote: > Current p6 rx syntax aiui regarding embedded code: > > / > #1 do (may include an explicit fail): > { code } > > #2 do with implicit 'or fail' > <( code )> > > #3 interp lit: > $( { code } ) > > #4 interp as r

Re: A5: a few simple questions

On Thu, Jun 06, 2002 at 08:21:25PM +0100, Piers Cawley wrote: > Allison Randal <[EMAIL PROTECTED]> writes: > > > No, because rules are basically methods, just like grammars are > > basically classes. You would only need a semi-colon if you were defining > >

Re: A5: a few simple questions

On Thu, Jun 06, 2002 at 10:38:39AM -0400, John Siracusa wrote: > On 6/6/02 2:43 AM, Damian Conway wrote: > > rule wordlist { (\w+) [ , (\w+) ]* } > > No semicolon at the end of that line? I've already forgotten the "new > rules" for that type of thing... :) No, because rules are basically met

Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)

On Fri, May 17, 2002 at 05:40:30PM -0600, Luke Palmer wrote: > Back to from where this arose, however, I think LAST (and BETWEEN, if > it will exist) should probably be PRE blocks. This is the only way it > could be consistently possible to implement. It wouldn't make any > sense to have it a PRE

Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)

On Tue, May 07, 2002 at 03:15:48PM +0100, Graham Barr wrote: > > LAST Executes on implicit loop exit or call to last() > Loop variables may be unknown Not exactly "unknown". It's just that, in a few cases, their values may have changed by the time the LAST block is executed. > And I th

Re: Loop controls

On Mon, May 06, 2002 at 10:53:11AM +1000, Damian Conway wrote: > Allison asked: > > > Hmmm... would C not have the same problem as C? It also > > "can't decide whether to execute until it knows whether the loop is > > going to iterate again". > > Yes, it does. Then I agree with Miko, it's not

Re: Loop controls

On Fri, May 03, 2002 at 11:13:45AM -0700, David Whipp wrote: > Damian Conway wrote: > > BUGS > > Unlikely, since it doesn't actually do anything. However, > > bug reports and other feedback are most welcome. > > Bug: > > don't { die } unless .error; > > doesn't DWIM (though the curre

Re: Loop controls

On Wed, May 01, 2002 at 05:08:14PM -0400, Miko O'Sullivan wrote: > Damian said: > > The C block can't decide whether to execute until > > it knows whether the loop is going to iterate again. And it can't > > know *that* until it has evaluated the condition again. At which > > point, the $filename

Re: // in Perl 5.8?

On Wed, May 01, 2002 at 01:04:10PM -0700, Brent Dax wrote: > > *bites back sarcastic comment about the pace of Perl 6's development* *fails to squelch reply about the survival rate of prematurely birthed babies* Some things just take time.

Re: Loop controls

On Wed, May 01, 2002 at 02:47:56PM -0400, Aaron Sherman wrote: > On Wed, 2002-05-01 at 12:22, Allison Randal wrote: > > > You also avoid totally annoying Pythonists who occasionally use (and > > might be converted to) Perl. :) > > ... > > Perl is fundamentally

Re: Loop controls

On Wed, May 01, 2002 at 12:53:39PM -0400, Melvin Smith wrote: > At 11:44 AM 5/1/2002 -0500, Allison Randal wrote: > > > >Um... I know it's scary, but I can actually imagine using this (or > >something like this) in development. I'll occasionally work on a sect

Re: Loop controls

On Wed, May 01, 2002 at 04:22:29PM +1000, Damian Conway wrote: > > NAME > Acme::Don't - The opposite of `do' > > DESCRIPTION ... > > Note that the code in the `don't' block must be syntactically valid > Perl. This is an important feature: you get the accelerated performance >

Re: Loop controls

On Wed, May 01, 2002 at 09:03:42AM -0500, Jonathan Scott Duff wrote: > > Hmm. I wonder why the python community (apparently) have no problems > with elses on loops: > > 7.2 The while statement > > The while statement is used for repeated execution as long as an > expression

Re: Loop controls

On Tue, Apr 30, 2002 at 12:53:32PM +1000, Damian Conway wrote: > Allison wrote: > > > The answer is the same, in any case: "When the condition in the > > C has a false value, when the list/array in the C is empty, > > or when the condition (2nd expression) in the C is met on the first >

Re: Loop controls

On Mon, Apr 29, 2002 at 04:25:26PM -0700, Peter Scott wrote: > At 01:55 PM 4/29/02 -0500, Allison Randal wrote: > > > >There will have to be a section of the training material devoted to > >"When is a loop false?" (I like that perspective, it nicely unifies the >

Re: Loop controls

On Mon, Apr 29, 2002 at 04:14:01PM -0400, Aaron Sherman wrote: > > Well then, I guess we should dump "elsif" from if too. After all, it > could all be done with nested blocks of if/else But C is different. You use it all the time. The frequency with which you'd need a loop that leads into a

Re: Loop controls

On Mon, Apr 29, 2002 at 03:30:40PM -0400, Aaron Sherman wrote: > > Ok, once more for those in the cheap seats (no offense, it's just a lot > of people seemed to have ignored the thread until now and jumped in > without the context), this is how we got here: > > 1. Larry says loops will have "ELS

Re: Loop controls

On Mon, Apr 29, 2002 at 10:26:26AM -0400, Aaron Sherman wrote: > On Fri, 2002-04-26 at 19:30, Miko O'Sullivan wrote: > > > 1) Do we have a reality check on why this syntax is needed? > > It's because the alternative is: > > Perl5: > $did = 0; > for($i=0;$i<$max;$i++) { >

Re: Loop controls

On Mon, Apr 29, 2002 at 10:10:01AM -0400, Aaron Sherman wrote: > On Fri, 2002-04-26 at 19:06, Allison Randal wrote: > > Absolutely what I thought. "elsif" would be for "thing else if" where > "elsfor" would be "thing else for-loop". Since you

Going meta to tagmemic rhetoric (was Re: Loop controls)

On Sat, Apr 27, 2002 at 12:50:49PM +0200, Paul Johnson wrote: > > Here's another possibility. People trust Larry to get it right and > don't feel the need to weigh in with opinions. I trust Larry. That's actually why I feel free to play the devil's advocate. I trust him to toss the dross and

Re: Loop controls

On Sat, Apr 27, 2002 at 10:53:09PM +1000, Damian Conway wrote: > Allison wrote: > > > And the discussion of scope led to (what I think is) an interesting > > tidbit on NAMED blocks... > > Which I presume was that the proposed usage: > > while $result.get_next() -> $next { > # do som

Re: Loop controls

Hmmm... some discussion generated on this subject, but fairly light. I take that as an indicator that an C on loops is a fairly popular idea. The other possibilities are that b) people don't want any form of "else" on loops and aren't saying so or c) people simply don't care, but silence and apath

Re: Loop controls

On Fri, Apr 26, 2002 at 11:14:36PM -0600, Luke Palmer wrote: > On Fri, 26 Apr 2002, Allison Randal wrote: > > > Besides, I would expect an C to actually be a loop of it's own, > > on the principle of "elsif = else + if" so "elsfor = else + for". >

Re: Loop controls

On Fri, Apr 26, 2002 at 05:24:13PM -0400, Aaron Sherman wrote: > On Fri, 2002-04-26 at 14:11, Allison Randal wrote: > > The "else" of a loop construct isn't really the same as the "else" of an > > C. You can't use an C for one thing. > > W

Re: Loop controls

On Fri, Apr 26, 2002 at 08:49:23AM +1000, Damian Conway wrote: > Trey Harris wrote: > > > So: > > > > for $results.get_next() { > > FIRST { print "Results:"; } > > NEXT { print ""; } > > } else { > > print "No results."; > > } > > > > Do I have that right? > > Yes. Presuming Larry decide

Re: Unary dot

On Tue, Apr 16, 2002 at 09:29:21AM -0400, Miko O'Sullivan wrote: > > "Wouldn't Know a Tagmemic if it Bit Him on the Parse" Ooh, can I steal that as a title? (Though I'll s/Tagmemic/Tagmeme/.) I like it! :) Allison

Re: Unary dot

On Mon, Apr 15, 2002 at 11:03:15PM -0400, John Siracusa wrote: > On 4/15/02 10:24 PM, Larry Wall wrote: > > The main point of doing this isn't really the migration from Perl 5, > > but a basic underlying philosophy of linguistics known as tagmemics. > ("tagmemics"? ;) Yay, tagmemics! :) Shall

Re: How to default? (was Unary dot)

On Sat, Apr 13, 2002 at 08:53:41AM -0700, Glenn Linderman wrote: > > Off hand, it seems like defaulting to "is dynamic_topic" would make > more of those common useful $_-dependent subroutines work without > change, but I guess if the perl 5 to 6 translator can detect use of $_ > before definition

Re: How to default? (was Unary dot)

On Fri, Apr 12, 2002 at 05:34:13PM -0700, Glenn Linderman wrote: > Allison Randal wrote: > > > In a message dated Fri, 12 Apr 2002, Glenn Linderman writes: > > > > $_ becomes lexical > > > Sound logic. And it almost did go that way. But subs that access the &g

Re: How to default? (was Unary dot)

Okay, first thing to keep in mind, this hasn't been finally-finalized yet. Alot was hashed out in the process of proofing E4, but there will be more to come. On Fri, Apr 12, 2002 at 07:39:17PM -0400, Trey Harris wrote: > In a message dated Fri, 12 Apr 2002, Glenn Linderman writes: > > $_ becomes

Re: How to default? (was Unary dot)

On Fri, Apr 12, 2002 at 02:44:38AM -0400, Trey Harris wrote: > I think I've missed something, even after poring over the archives for > some hours looking for the answer. How does one write defaulting > subroutines a la builtins like print() and chomp()? Assume the code: > > for <> { > pr

Re: Unary dot

On Thu, Apr 11, 2002 at 12:01:58PM +1000, Damian Conway wrote: > Allison Randal wrote: > > > H... this being the case, is there any reason we should ever need to > > name the invocant explicitly? > > Yes. To make it read-writable. Curses! Foiled again! :) >

Re: Unary dot

On Thu, Apr 11, 2002 at 08:04:56AM +1000, Damian Conway wrote: > > Reflecting on this, it seems that it would be useful if methods > implicitly did their default topicalization-of-invocant like so: > > -> $self > > rather than just: > > -> $_ > > That is, that as well as aliasing

Re: Unary dot

On Thu, Apr 11, 2002 at 08:04:56AM +1000, Damian Conway wrote: > Allison wrote: > > > >$self.foo() => $self->foo() # and can be .foo() when $self is $_ > >.foo() => $_->foo() # but might be altered by a pragma > >foo() => foo() > > > And welcome back to where we started! ;-) Exact

Re: Unary dot

> > "David Whipp" <[EMAIL PROTECTED]> writes: > > > > > Thus, the perl5 transalations would be: > > > > > > foo() => $self->foo() > > > .foo() => $_->foo() > > > &foo() => foo() > > > ... Alternative: $self.foo() => $self->foo() # and can be .foo() when $self is $_ .foo() => $_->f

Re: Unary dot

On Wed, Apr 10, 2002 at 09:23:23PM +0100, Piers Cawley wrote: > "David Whipp" <[EMAIL PROTECTED]> writes: > > > Thus, the perl5 transalations would be: > > > > foo() => $self->foo() > > .foo() => $_->foo() > > &foo() => foo() > > ... > > For reasons that I can't quite put my finger on at

Re: Unary dot

On Wed, Apr 10, 2002 at 03:49:44PM -0400, Mark J. Reed wrote: > On Wed, Apr 10, 2002 at 02:42:58PM -0500, Allison Randal wrote: > > > I like the following, assumed to be within method m1: > > > > > > ..m2(); # call m2 the same way m1 was called, instance or c

Re: Unary dot

On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote: > On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote: > > > ::m2; # calls global subroutine main::m2 > > > main::m2; # calls global subroutine main::m2 > > > > This is looking more and more horrible Glenn. > I think we need t

Re: Unary dot

On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote: > Allison Randal wrote: > > > > Direction 2 moves into the more exciting but scarier realm of alternate > > defaults. > > It could, but how about an alternative? Ah-ha, yet a third Direction! >

Re: Unary dot

On Tue, Apr 09, 2002 at 09:56:02PM +0100, Piers Cawley wrote: > Larry Wall <[EMAIL PROTECTED]> writes: > > > We're talking about how to make .foo mean self.foo regardless of the > > current topic. > > Are we? I was looking for a way to unambgiously access the current > object in such a way that

Re: Topicalizers: Why does when's EXPR pay attention to topicaliz er r egardless of associated variable?

On Wed, Mar 20, 2002 at 09:59:35AM -0800, Larry Wall wrote: > > I should update y'all to my current thinking, which is that $_ is > always identical to the current topic, even if the topic is aliased to > some other variable. To get at an outer topic, you'd have to use the > same mechanism we'll

Re: Topicalizers: Why does when's EXPR pay attention to topicaliz er r egardless of associated variable?

On Thu, Feb 28, 2002 at 03:17:19PM -0600, Garrett Goebel wrote: > I do worry that as Perl grows richer, so does the need for underlying > consistency and simplicity. You're not alone in that. > I guess it is all about seeking the correct balance. And that is > something Larry and the Perl commu

Re: Topicalizers as user-defined extensions

On Thu, Feb 28, 2002 at 03:28:29PM -0800, Austin Hastings wrote: > > --- Garrett Goebel <[EMAIL PROTECTED]> wrote: > > > > Hmm... Out of curiosity what kind of user-extensible topicalizer > > aware constructs would you make? > > Remember Larry's comment that the -> operator is a kind of "parame

Re: proposal: when-blocks, and binding $_

On Thu, Feb 28, 2002 at 04:12:12PM -0800, Austin Hastings wrote: > > Nobody has the least bit of trouble understanding that WITHIN the for > loop, the "default value" just changed from whatever it was outside. Well, C is a topicalizer, and always has been, even before we had a name for it, so th

  1   2   >