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 t
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 ord
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.
: Still
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;
: $_ ~= "!";
: }
:
: Wit
"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
=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 qui
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 w
Juerd
--
h
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 J
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
+f
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 w
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 wouldn't work as an rvalue:
> ^T.count # 1's complement of nu
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 ty
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
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
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
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
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
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
: e
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:
> I don't think so. In the first example all the T (or ¢T) are the same
> type after the first ¢T (where the type is bound). In the second one
> you'd get two separ
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 b
On Tue, Oct 25, 2005 at 05:24:52PM +0200, Michele Dondi wrote:
: Also, Perl6 OO capabilities are already above the top of my head.
Sure, they're above my head too. Which should be obvious by now... :-)
: But maybe that's just me. Whatever, I guess that the {casual,average}
: programmer may be
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?
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 OU
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
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 p
> 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 := { ... }
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 th
: 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;OP
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.
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 $
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 c
> 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
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
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 }_"
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 bein
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 lo
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
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 c
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 availabilit
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 ap
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 anti-a
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
tw
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
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).
>
> m
On 10/24/05, H.Merijn Brand <[EMAIL PROTECTED]> wrote:
> My only current fear is that I won't live long enough to be able to use
> and
> understand the full richness of what perl6 is going to offer me.
>
> (Oh, and that perl6 will never be able to upgrade my scripts that use
> 'format', but I'm aw
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"
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 answer
On Mon, 24 Oct 2005 11:49:51 -0400, Joshua Gatcomb <[EMAIL PROTECTED]>
wrote:
> On 10/24/05, Juerd <[EMAIL PROTECTED]> wrote:
> >
> > > >Feel free to add your own, or fears you heard about!
>
>
> FEAR: Perl6 internals will be just as inaccessable as p5
paradox. Many people don't find perl5 inac
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) {
49 matches
Mail list logo
