Re: new sigil

2005-10-25 Thread Luke Palmer
On 10/24/05, TSa [EMAIL PROTECTED] wrote: Does this capturing of the type into ¢T also involve runtime code template expansion? That is, if sametype(Int,Int) didn't exist it would be compiled on the fly for a call sametype(3,2)? I think that's up to the implementation. From the language

$_ defaulting for mutating ops

2005-10-25 Thread Juerd
I think it'd be great if +=, ~=, +=, ++, etc, could all assume $_ on their LHS when there is no obvious operand. This clashes with prefix:=, but that's nothing a space cannot fix. Same for lvalue subs called x or xx (or X or XX). my $subject = foo foo foo; given ($subject) {

Re: Perl 6 fears

2005-10-25 Thread Michele Dondi
On Mon, 24 Oct 2005, H.Merijn Brand wrote: FEAR: Perl6 will not be able to fix the stigma of just a scripting language or line noise perl5 has never been just a scripting language But sadly enough it is often _perceived_ as such. And also like line noise, as the person you're answering to

txt vs OO [was: Re: Proposal to make class method non-inheritable]

2005-10-25 Thread Michele Dondi
On Fri, 14 Oct 2005, Stevan Little wrote: I think Perl 6's OO system has the potential to be to OO programming what Perl 5, etc was to text processing. This, I believe, is in large part due to Sorry for replying so late. Thought it seems appropriate to post this in this time of Perl 6 fears

Re: $_ defaulting for mutating ops

2005-10-25 Thread Rob Kinyon
On 10/25/05, Juerd [EMAIL PROTECTED] wrote: I think it'd be great if +=, ~=, +=, ++, etc, could all assume $_ on their LHS when there is no obvious operand. This clashes with prefix:=, but that's nothing a space cannot fix. Same for lvalue subs called x or xx (or X or XX). my $subject =

Re: Perl 6 fears

2005-10-25 Thread Juerd
Joshua Gatcomb skribis 2005-10-25 8:30 (-0400): IIRC, Andy has taken up the Perl6 PR hat. I think Juerd should like be working with Andy on this one. The rebuttals to these fears needs to be well thought out and convincing because from my personal experience they are prevalent. I'll work

Re: $_ defaulting for mutating ops

2005-10-25 Thread Juerd
Rob Kinyon skribis 2005-10-25 8:37 (-0400): Did you post this specifically to anti-address the fear that P6 will be more line-noise-ish than P5? :-p No. Leaving out $_ is one of the important features in *reducing* line noise. We're all very used to seeing it, but to most people it is just two

Re: $_ defaulting for mutating ops

2005-10-25 Thread Michele Dondi
On Tue, 25 Oct 2005, Rob Kinyon wrote: On 10/25/05, Juerd [EMAIL PROTECTED] wrote: I think it'd be great if +=, ~=, +=, ++, etc, could all assume $_ on their LHS when there is no obvious operand. [snip] Especially bare ++ would be useful, I think. Did you post this specifically to

Re: txt vs OO [was: Re: Proposal to make class method non-inheritable]

2005-10-25 Thread Stevan Little
On Oct 25, 2005, at 6:31 AM, Michele Dondi wrote: On Fri, 14 Oct 2005, Stevan Little wrote: I think Perl 6's OO system has the potential to be to OO programming what Perl 5, etc was to text processing. This, I believe, is in large part due to Sorry for replying so late. Thought it seems

Pronouns [Re: $_ defaulting for mutating ops]

2005-10-25 Thread Michele Dondi
On Tue, 25 Oct 2005, Juerd wrote: Reducing line noise isn't my goal, though. I feel that the implicit defaulting to $_ makes Perl a more natural and elegant language, and would like this principle being extended to these operators. Indeed, both the implicit defaulting to $_ AND the

Re: Pronouns [Re: $_ defaulting for mutating ops]

2005-10-25 Thread Juerd
Michele Dondi skribis 2005-10-25 17:05 (+0200): Now, one that I've sometimes desired is a two level $_, i.e. a variable, say, $__ referring to the _second next_ enclosing lexical scope. I am aware that in this vein one may ask a third analogue and so on, but let's face it: $_ already covers

Re: Pronouns [Re: $_ defaulting for mutating ops]

2005-10-25 Thread Michele Dondi
On Tue, 25 Oct 2005, Juerd wrote: Michele Dondi skribis 2005-10-25 17:05 (+0200): Now, one that I've sometimes desired is a two level $_, i.e. a variable, say, $__ referring to the _second next_ enclosing lexical scope. I am aware that in this vein one may ask a third analogue and so on, but

Re: Pronouns [Re: $_ defaulting for mutating ops]

2005-10-25 Thread Mark Reed
On 2005-10-25 11:17 AM, Michele Dondi [EMAIL PROTECTED] wrote: I find $__ confusing, and prefer $OUTER::_, which already exists. Hmmm... maybe you're right that $__ is too huffmanized (and hence confusing) but $OUTER::_ is somewhat too few... What's confusing about $__ is that it looks too

Re: txt vs OO [was: Re: Proposal to make class method non-inheritable]

2005-10-25 Thread Michele Dondi
On Tue, 25 Oct 2005, Stevan Little wrote: Well, the point is that it is interesting to note that text processing is an _application area_, whereas OO programming is a programming language paradigm. Allow me to clarify. Perl 5 (and below) are known by outsiders (non-perl users) as being a

Re: Pronouns [Re: $_ defaulting for mutating ops]

2005-10-25 Thread Juerd
Michele Dondi skribis 2005-10-25 17:17 (+0200): Hmmm... maybe you're right that $__ is too huffmanized (and hence confusing) but $OUTER::_ is somewhat too few... for (1..9) - $n { # ought to be more than enough eval qq[ macro prefix:\$_$n { \${ OUTER:: x $n }_ }

Re: Pronouns [Re: $_ defaulting for mutating ops]

2005-10-25 Thread Michele Dondi
On Tue, 25 Oct 2005, Juerd wrote: for (1..9) - $n { # ought to be more than enough eval qq[ macro prefix:\$_$n { \${ OUTER:: x $n }_ } ]; } And then you can use $_1 .. $_9. I think $_1 is much clearer than $__, but I think neither is needed in the standard

Re: $_ defaulting for mutating ops

2005-10-25 Thread Sebastian
I think it'd be great if +=, ~=, +=, ++, etc, could all assume $_ on their LHS when there is no obvious operand. It'd be nice to have these, but is it something that can wait? I wouldn't mind if more effort was spent on other pieces if this can be easily done in the future - sebastian

Re: $_ defaulting for mutating ops

2005-10-25 Thread Juerd
Sebastian skribis 2005-10-25 9:17 (-0700): I think it'd be great if +=, ~=, +=, ++, etc, could all assume $_ on their LHS when there is no obvious operand. It'd be nice to have these, but is it something that can wait? I wouldn't mind if more effort was spent on other pieces if this can be

Re: new sigil

2005-10-25 Thread Larry Wall
On Sat, Oct 22, 2005 at 06:00:38AM -0400, Damian Conway wrote: : Autrijus wrote: : : Indeed. Somehow I think this makes some sense: : : sub Bool eqv (|T $x, |T $y) { ... } : : Except that it prevents anyone from ever writing: : : multi sub circumfix:| | (Num $x) { return abs $x }

Re: Avoid the Yen Sign [Was: Re: new sigil]

2005-10-25 Thread Larry Wall
On Sun, Oct 23, 2005 at 10:55:34PM +0900, Dan Kogai wrote: : To make the matter worse, there are not just one yen sign in : Unicode. Take a look at this. : : ¥ U+00A5 YEN SIGN : ¥ U+FFE5 FULLWIDTH YEN SIGN : : Tough they look and groks the same to human, computers handle them : differently.

Re: Avoid the Yen Sign [Was: Re: new sigil]

2005-10-25 Thread Larry Wall
: On 10/23/05, Autrijus Tang [EMAIL PROTECTED] wrote: : In addition to your handy table, the and french quotes, which are used : quite heavily in Perl 6 for both bracketing and hyper operators, also have : full width equivalents: : : 300A;LEFT DOUBLE ANGLE BRACKET;Ps;0;ON;Y;OPENING

Re: Perl 6 fears

2005-10-25 Thread Luke Palmer
On 10/24/05, H.Merijn Brand [EMAIL PROTECTED] wrote: On Mon, 24 Oct 2005 11:49:51 -0400, Joshua Gatcomb [EMAIL PROTECTED] wrote: FEAR: Perl6 internals will be just as inaccessable as p5 paradox. Many people don't find perl5 inaccessible at all Who? Do you know anybody who hacks the regex

Re: new sigil

2005-10-25 Thread Rob Kinyon
Basically, ¢T is a close analog of t, which is the variableish form for sub t. When used in a declaration, both of them introduce a bare name as an alias into whatever scope the declaration is inserting symbols, albeit with different syntactic slots. So just as my t := { ... }

Re: Perl 6 fears

2005-10-25 Thread Rob Kinyon
On 10/25/05, Luke Palmer [EMAIL PROTECTED] wrote: On 10/24/05, H.Merijn Brand [EMAIL PROTECTED] wrote: On Mon, 24 Oct 2005 11:49:51 -0400, Joshua Gatcomb [EMAIL PROTECTED] wrote: FEAR: Perl6 internals will be just as inaccessable as p5 paradox. Many people don't find perl5 inaccessible

Re: Perl 6 fears

2005-10-25 Thread Nicholas Clark
On Tue, Oct 25, 2005 at 11:57:10AM -0600, Luke Palmer wrote: On 10/24/05, H.Merijn Brand [EMAIL PROTECTED] wrote: On Mon, 24 Oct 2005 11:49:51 -0400, Joshua Gatcomb [EMAIL PROTECTED] wrote: FEAR: Perl6 internals will be just as inaccessable as p5 paradox. Many people don't find perl5

Re: new sigil

2005-10-25 Thread Luke Palmer
On 10/25/05, Larry Wall [EMAIL PROTECTED] wrote: We're probably converging on a general rule that two or more declarations of the same variable in the same scope refer to the same entity: my $x = 1; # outer $x; { $x = 2; # bound to OUTER::$x

Re: new sigil

2005-10-25 Thread Larry Wall
On Tue, Oct 25, 2005 at 01:57:52PM -0400, Rob Kinyon wrote: : I'm assuming that when you allow : : my ¢T := sometype(); : : you're also allowing : : my class T := sometype(); Yes, that's the idea. : So, what happens when stupid me names a class class through : symbol-table craziness?

Re: new sigil

2005-10-25 Thread Jonathan Scott Duff
On Tue, Oct 25, 2005 at 12:18:41PM -0600, Luke Palmer wrote: I like that symmetry between foo and ¢foo. So to get the behavior that an outer type variable applies to an inner sub, could I do this: # a complicated identity function :-) sub foo (¢T $x -- ¢T) { my sub bar (T

Re: new sigil

2005-10-25 Thread Benjamin Smith
On Tue, Oct 25, 2005 at 02:02:58PM -0500, Jonathan Scott Duff wrote: On Tue, Oct 25, 2005 at 12:18:41PM -0600, Luke Palmer wrote: snip examples from luqui of type variables being used multiple times with and without sigils I don't think so. In the first example all the T (or ¢T) are the same

Re: Pronouns [Re: $_ defaulting for mutating ops]

2005-10-25 Thread Larry Wall
On Tue, Oct 25, 2005 at 05:26:32PM +0200, Juerd wrote: : Michele Dondi skribis 2005-10-25 17:17 (+0200): : Hmmm... maybe you're right that $__ is too huffmanized (and hence : confusing) but $OUTER::_ is somewhat too few... : : for (1..9) - $n { # ought to be more than enough :

Re: S04 default { } bug?

2005-10-25 Thread Larry Wall
On Mon, Oct 24, 2005 at 07:39:23AM +0300, Ilmari Vacklin wrote: : Hi, : : S04 says thus: : : The default case: : : default {...} : : is exactly equivalent to : : when true {...} : : However, that parses to: : : if $_ ~~ bool::true { ...; leave } : : Which is not

Re: Ways to add behavior

2005-10-25 Thread Larry Wall
On Mon, Oct 24, 2005 at 06:33:20AM -0700, Ashley Winters wrote: : # behavior through prototype -- guessing realistic syntax : Base.meta.add_method( : do_it = method ($arg) { : say doing $arg!; : }); : : : # or, just add it to a single instance : $x.meta.add_method( : do_it =

Re: Zip more than two arrays?

2005-10-25 Thread Larry Wall
On Fri, Oct 21, 2005 at 04:04:25PM -0600, Luke Palmer wrote: : However, if I get my wish of having zip return tuples, then it can be : left-associative. But since it interleaves instead, making it left- : or right-associative gives strange, incorrect results. I expect zip ought to bundle up into

Re: Ways to add behavior

2005-10-25 Thread Stevan Little
Larry, On Oct 25, 2005, at 4:37 PM, Larry Wall wrote: On Mon, Oct 24, 2005 at 06:33:20AM -0700, Ashley Winters wrote: : # behavior through prototype -- guessing realistic syntax : Base.meta.add_method( : do_it = method ($arg) { : say doing $arg!; : }); : : : # or, just add it to

Re: new sigil

2005-10-25 Thread Larry Wall
On Thu, Oct 20, 2005 at 11:18:14AM -0600, Eric wrote: : Actualy i think ^ might be my favorite so far. : : sub sametype (^T $x, ^T $y) {...} I thought that, too, until I realized it wouldn't work as an rvalue: ^T.count# 1's complement of number of T instances On top of which, if it did

Re: new sigil

2005-10-25 Thread Larry Wall
On Thu, Oct 20, 2005 at 09:59:49AM -0600, Luke Palmer wrote: : How about this: : : sub foo(c|T $x) { : my sub util (c|T $in) {...} : util($x) : } : : Is that c|T in util() a new, free type variable, or am I asserting : that the type of util()'s argument must be the same

Re: new sigil

2005-10-25 Thread Larry Wall
On Tue, Oct 25, 2005 at 11:44:35PM +0200, Juerd wrote: : Larry Wall skribis 2005-10-25 14:35 (-0700): : On Thu, Oct 20, 2005 at 11:18:14AM -0600, Eric wrote: : : Actualy i think ^ might be my favorite so far. : : sub sametype (^T $x, ^T $y) {...} : I thought that, too, until I realized it

Re: new sigil

2005-10-25 Thread Juerd
Larry Wall skribis 2005-10-25 15:51 (-0700): ^T would still have to be a placeholder variable. Which it is, in a way. Still, I don't think ^ as a sigil needs to mean the same thing as ^ as a twigil. Visually similar pairs are also not related: ?foo$?foo *foo$*foo

RE: Avoid the Yen Sign [Was: Re: new sigil]

2005-10-25 Thread Jan Dubois
On Tue, 25 Oct 2005, Larry Wall wrote: As for the ¥ pitfall, so far we've intentionally been careful to use it only where an operator is expected, whereas \ is legal only where a term is expected. So at least for Perl code, we can translate legacy ¥ to different codepoints. (Whether the

Re: Avoid the Yen Sign [Was: Re: new sigil]

2005-10-25 Thread Juerd
Jan Dubois skribis 2005-10-25 12:33 (-0700): Just something to keep in mind in case you are tempted to use the Won sign as a sigil or operator in the future. I don't know what stitch() will do, but this will have to be its infix operator :) zip ¥ Y stitch Won w Juerd --

Perl 6 Summary for 2005-10-10 through 2005-10-24

2005-10-25 Thread Matt Fowles
=head1 Perl 6 Summary for 2005-10-10 through 2005-10-18 All~ Welcome to another Perl 6 Summary. Sadly, this week's summary is not brought to you by cookies as I already finished them. Sadder still, it is also brought to you a week late. On the plus side, Mike Doughty's Haughty Melodic is

Re: Perl 6 Summary for 2005-10-10 through 2005-10-24

2005-10-25 Thread Jonathan Worthington
Matt Fowles [EMAIL PROTECTED] wrote: =head3 Obsolete Win32 Exports Michael Walter found and removed some obsolete Win32 Exports. Jonathan Worthington applied the patch. Weren't we planning on auto generating these? The Plan is to mark functions that are to be exported with something that

Re: $_ defaulting for mutating ops

2005-10-25 Thread Larry Wall
On Tue, Oct 25, 2005 at 02:51:35PM +0200, Juerd wrote: : For comparison, here is the same code snippet again. First with, and : then without explicit $_. : : With: : : given ($subject) - $_ { : $_ ~~ s/foo/bar/; : $_++; : $_ x= 2; : $_ ~= !; : } : :

Re: new sigil

2005-10-25 Thread Larry Wall
On Wed, Oct 26, 2005 at 01:17:10AM +0200, Juerd wrote: : Larry Wall skribis 2005-10-25 15:51 (-0700): : ^T would still have to be a placeholder variable. : : Which it is, in a way. Though we don't currently allow placeholders in ordinary sigs, or even in conjunction with ordinary sigs. :

Re: new sigil

2005-10-25 Thread Eric
On 10/25/05, Larry Wall [EMAIL PROTECTED] wrote: On Wed, Oct 26, 2005 at 01:17:10AM +0200, Juerd wrote: : Larry Wall skribis 2005-10-25 15:51 (-0700): : ^T would still have to be a placeholder variable. : : Which it is, in a way. Though we don't currently allow placeholders in ordinary

Re: new sigil

2005-10-25 Thread Luke Palmer
On 10/25/05, Eric [EMAIL PROTECTED] wrote: I would just like to mention that 'class' is confusing because you don't realy mean class there. The whole conversation is about types so why not have it be 'type'? If you read the introduction to theory.pod[1], you'll find that we are actually