Larry Wall writes:
>
> Despite the severe overloading problems, it's really gonna be hard
> to do much better than
>
> $topic ? (.a + .b + .c)
> my dog $spot ?= .new;
> @array?.[.min .. .max]
>
> And I do think people would rebel at using Latin-1 for that one.
> I get enoug
On Tue, Mar 16, 2004 at 08:40:50PM +0200, arcadi shehter wrote:
: How about <- which is not overloaded by boolean connotations
: and is sort of ? turned by 90 degrees .
Don't think so. It's too ambiguous with current meanings.
: $topic<- (.a + .b + .c)
That asks if $topic is numerically l
On Mon, Mar 15, 2004 at 08:36:23PM -0500, Joe Gottman wrote:
:
: - Original Message -
: From: "Deborah Pickett" <[EMAIL PROTECTED]>
: To: "Perl 6 Language" <[EMAIL PROTECTED]>
: Sent: Sunday, March 14, 2004 10:44 PM
: Subject: Re: Mutating methods
:
- Original Message -
From: "Deborah Pickett" <[EMAIL PROTECTED]>
To: "Perl 6 Language" <[EMAIL PROTECTED]>
Sent: Sunday, March 14, 2004 10:44 PM
Subject: Re: Mutating methods
> On Sat, 13 Mar 2004 05.30, John Siracusa wrote:
> > The only cas
On Fri, Mar 12, 2004 at 05:32:33AM -0500, Austin Hastings wrote:
: Boo, hiss.
:
: Two things:
:
: 1- I'd rather use "inplace" than self.
What is this "place" thing? I want the object to do something to itself
reflexively, which may or may not involve places...
: 2- I'd rather it be AFTER, than
On Fri, Mar 12, 2004 at 03:47:57AM -0500, Austin Hastings wrote:
: > -Original Message-
: > From: Larry Wall [mailto:[EMAIL PROTECTED]
: > On Thu, Mar 11, 2004 at 11:38:11AM +, Andy Wardley wrote:
: > : Larry Wall wrote:
: > : > multi sub *scramble (String $s) returns String {...}
:
On Sat, Mar 13, 2004 at 12:03:35AM +0200, arcadi shehter wrote:
: some time in the past there was a talk about ... ?? ... :: ... operator being
: a combination of two binary : ?? and :: . But I dont know the ruling.
: If one factorize trinary ??:: to two binary operators,
: ?? could act a po
On Mon, Mar 15, 2004 at 12:10:40PM -0700, John Williams wrote:
: Or the slightly less attractive (IMHO) syntax invented recently:
:
: $x +=« ($a, $b, $c, $d);
The latest guess is that we're not using lopsided ones for binary ops, but
only for unary ops.
Larry
> This brings me to another "idea" I have.. although I have a feeling you guys
> have already thought of it.
>
> Instead of ...
> $x = $a + $b + $c + $d;
> How about ...
> $x = +«$a $b $c $d»
The closest way to what you have written is this:
$x = 0;
$x »+=« ($a, $b, $c, $d);
Or t
Deborah Pickett writes:
> Someone Damian-shaped will probably come in and point out how to prettify that
> using "given", but it still wouldn't be as short as last week's
>
> $coderef.("argument").{hashelem}.self:sort();
But that still has problems. What's the important thing in this
"sentence"
On Sat, 13 Mar 2004 05.30, John Siracusa wrote:
> The only case that seems even
> remotely onerous is this one:
>
> my My::Big::Class::Name $obj = My::Big::Class::Name.new();
> vs.
> my My::Big::Class::Name $obj .= new()
There's also the related issue of in-place operations on some
di
Date: Fri, 12 Mar 2004 12:01:10 -0800 Larry Wall wrote:
>It's really a pity that question mark is already so overloaded with
>boolean connotations, because
>
>$dog? .bark
>
>would really be the best postfix operator in ASCII for this.
>People would probably end up writing
>
>my Dog $spot ?
Please bare with me, I do follow this list, but sporadically.
What it all boils down to, obviously, is that we, as lazy programmers, want
to have to type less, but still leave the code make sense when read. So to
me, that should automatically throw out stuff such as C<$x = ( $foo § .a +
.b + .c )
"Oh, it's got lots of Japanese in it, I'd better read it..." :)
[EMAIL PROTECTED] (Larry Wall) writes:
> Some will argue that since English doesn't have a grammatical
> postfix topicalizer like Japanese, we should stick with something
> like more English-like:
>
> $x = (.a + .b + .c given $f
Larry Wall wrote:
Now, if we had a unary = that assigned to the current topic, we could do
it with the existing topicalizer as
given my Dog $dog { = .new }
But I'm not recommending that approach, because I dislike unary =, and
because I don't want every declaration to have to say "given".
On Fri, Mar 12, 2004 at 09:19:46AM -0800, Dave Whipp wrote:
: Why are we mixing the concepts of assignment and topicalization --
: especially in a way that doesn't generalize. Why can't we invent a
: "topicalization" operator, analogous to the old binding operator, that
: simply sets its LHS as th
On 3/12/04 12:43 PM, Larry Wall wrote:
> Some good questions only have bad answers. This might be one of them.
I have been watching this thread with increasing unease, asking myself
exactly what the potential benefit is of this proposed feature and syntax.
I'm all for saving some typing, but yees
On Fri, Mar 12, 2004 at 12:29:36PM +1100, Deborah Pickett wrote:
: That triggered a thought about unary operators. What about:
:
: $a !=;# i.e., $a = ! $a;
Well, an argument could be made that the corresponding syntax is really:
!= $a;
But you have to read the
A = B ==> A
On Fri, Mar 12, 2004 at 03:47:22AM -0500, Austin Hastings wrote:
> > -Original Message-
> > From: Larry Wall [mailto:[EMAIL PROTECTED]
> >
> > Now in the specific case of . and .= we don't exactly have a normal
> > binary operator, because the right side is not an expression.
>
> $tis.=«
"Larry Wall" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Unfortunately we can't just use topicalization to say
>
> my Cat $tom = .new()
>
> because most people won't expect simple assignment to break their
> current topic.
>
> So another option is to replace = with somethin
Austin Hastings writes:
>
>
> > -Original Message-
> > From: Larry Wall [mailto:[EMAIL PROTECTED]
> > On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote:
> > : So, will "mutatingness" be a context we'll be able to inquire on
> > : in the implementation of a called routine?
>
> -Original Message-
> From: Damian Conway [mailto:[EMAIL PROTECTED]
>
> Larry wrote:
>
> > On the other hand, I suspect most people will end up declaring it
> >
> > int method
> > self:rotate (int $a is rw) {...}
> >
> > in any event, and reserve the =rotate for .=rotate, which c
On Fri, 12 Mar 2004 10.51, Damian Conway wrote:
> There are also cases where something like:
>
> $a ||= $b;
>
> or:
>
> $a += $b;
>
> changes the type of value in $a. Should we flag those too? Currently we do
> warn on the second one if $a can't be cleanly coerced to numeric. Would
> th
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> On Thu, Mar 11, 2004 at 11:38:11AM +, Andy Wardley wrote:
> : Larry Wall wrote:
> : > multi sub *scramble (String $s) returns String {...}
> : [...]
> : > Or you can just call it directly as a function:
> : > sc
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote:
> : So, will "mutatingness" be a context we'll be able to inquire on
> : in the implementation of a called routine?
>
> Probably not, but it's vaguely possi
Larry wrote:
On the other hand, I suspect most people will end up declaring it
int method
self:rotate (int $a is rw) {...}
in any event, and reserve the =rotate for .=rotate, which can never put
the = on the left margin, even if we let ourselves have whitespace
before POD directives. S
Larry Wall wrote:
On Thu, Mar 11, 2004 at 01:18:52PM -0800, chromatic wrote:
: On Thu, 2004-03-11 at 13:04, Larry Wall wrote:
:
: > Well, okay, not a boolean. More like a troolean.
:
: Unless it's a falselean.
It's more truelean than falselean by a 2/3rds majority. And it's
much more if you in
On Thu, Mar 11, 2004 at 01:18:52PM -0800, chromatic wrote:
: On Thu, 2004-03-11 at 13:04, Larry Wall wrote:
:
: > Well, okay, not a boolean. More like a troolean.
:
: Unless it's a falselean.
It's more truelean than falselean by a 2/3rds majority. And it's
much more if you include 2, -2, 3, -3
On Thu, 2004-03-11 at 13:04, Larry Wall wrote:
> Well, okay, not a boolean. More like a troolean.
Unless it's a falselean.
-- c
On 3/11/04 4:04 PM, Larry Wall wrote:
> On Thu, Mar 11, 2004 at 12:43:22PM -0800, Larry Wall wrote:
> : Which is precisely the problem with something like
> :
> : $a cmp= $b
> :
> : insofar as $a is being treated as a string at one moment and as a boolean
> : at the next.
>
> Well, okay, not
On Thu, Mar 11, 2004 at 12:43:22PM -0800, Larry Wall wrote:
: Which is precisely the problem with something like
:
: $a cmp= $b
:
: insofar as $a is being treated as a string at one moment and as a boolean
: at the next.
Well, okay, not a boolean. More like a troolean.
Larry
On Thu, Mar 11, 2004 at 02:05:55PM -0600, Jonathan Scott Duff wrote:
: On Thu, Mar 11, 2004 at 11:11:54AM -0800, Larry Wall wrote:
: > On the final hand, if people fall in love with both self:sort and =sort, we
: > could have =sort be a shorthand for self:sort where it's unambiguous.
:
: Wouldn't
On Thu, Mar 11, 2004 at 11:11:54AM -0800, Larry Wall wrote:
> On the final hand, if people fall in love with both self:sort and =sort, we
> could have =sort be a shorthand for self:sort where it's unambiguous.
Wouldn't =sort potentially muck with POD?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECT
On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote:
: So, will "mutatingness" be a context we'll be able to inquire on
: in the implementation of a called routine?
Probably not, but it's vaguely possible you could somehow get a
reference to what is being assigned to, if available, and
On Thu, Mar 11, 2004 at 11:38:11AM +, Andy Wardley wrote:
: Larry Wall wrote:
: > multi sub *scramble (String $s) returns String {...}
: [...]
: > Or you can just call it directly as a function:
: > scramble("hello")
:
: Can you also call scramble as a class method?
:
: class String
Larry --
So, will "mutatingness" be a context we'll be able to inquire on
in the implementation of a called routine? Or, could we provide
a specialized distinct implementation for mutating that would get
called if .=X() is used? If we are performing some operation on
large data, and we know the en
> "AW" == Andy Wardley <[EMAIL PROTECTED]> writes:
AW> What about ? is as a ternary operator:
AW> @foo?bar:baz;
IIRC, that was changed to ?? :: because larry wanted the single ? for
more important uses. also doubling the ? made it more like &&, || which
are related logical ops.
and ?
Larry Wall wrote:
> Yet another approach is to *replace* dot with something that mutates:
>
> @array!sort
> @array?sort
>
> Either of those would work syntactically in that case, since neither !
> nor ? is expected as a binary operator.
What about ? is as a ternary operator:
@foo?ba
Larry Wall wrote:
> multi sub *scramble (String $s) returns String {...}
[...]
> Or you can just call it directly as a function:
> scramble("hello")
Can you also call scramble as a class method?
class String is extended {
method scramble { ..etc... }
}
String.scramble("hello")
On Thu, Mar 11, 2004 at 01:09:59AM -0500, Austin Hastings wrote:
:
:
: > -Original Message-
: > From: Damian Conway [mailto:[EMAIL PROTECTED]
: > Sent: Wednesday, 10 March, 2004 09:48 PM
: > To: [EMAIL PROTECTED]
: > Subject: Re: Mutating methods
: >
: >
: >
> -Original Message-
> From: Damian Conway [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 10 March, 2004 09:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Mutating methods
>
>
> Brent "Dax" Royal-Gordon wrote:
>
> >> / $foo:=(abc) $ba
On Wed, Mar 10, 2004 at 10:46:05PM -0500, matt wrote:
: I was thinking along the lines of...
:
: String $foo = "hello";
: $foo.scramble!
That would be $foo.=scramble in the current scheme of things.
: print "$foo\n";
: $foo = "hello"
: print $foo.scramble ~ "\n";
: print $foo;
:
: OUTPUT (or cl
I was thinking along the lines of...
String $foo = "hello";
$foo.scramble!
print "$foo\n";
$foo = "hello"
print $foo.scramble ~ "\n";
print $foo;
OUTPUT (or close):
elhlo
hloel
hello
Also, along these same things.. is there a way to apply a method to all
variables/objects of a certain type (e.g.
Brent "Dax" Royal-Gordon wrote:
/ $foo:=(abc) $bar:=(def) /
Am I misreading, or are you suggesting that $foo may contain 'abc' after
running this example, even if the match wasn't successful?
No. I re-checked with Larry this morning and he confirmed that all bindings in
rules only "stick" if
Damian Conway wrote:
/ $foo:=(abc) $bar:=(def) /
Am I misreading, or are you suggesting that $foo may contain 'abc' after
running this example, even if the match wasn't successful?
--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has always been at war with Easta
Luke Palmer wrote:
I understand the association with C<$?foo>. But most of the time, when
I'm writing a grammar, I'm catching these rules in order to stick them
in the parse tree, not to do tests on them later on in the rule. The
very essence of rules is hypotheticality, where nothing is permane
Larry Wall writes:
> On Wed, Mar 10, 2004 at 12:42:00PM -0700, Luke Palmer wrote:
> : I can think of a couple that I like better:
> :
> : <^foo>
> : <*foo>
> :
> : <^foo> is my favorite at the moment (even though <*foo> is more
> : visually pleasing), because it looks like it's transferri
On Wed, Mar 10, 2004 at 12:42:00PM -0700, Luke Palmer wrote:
: > (Also, these days you have to say to collect the results into $0.)
:
: Hooray! That was something I had been worried about.
:
: But C doesn't seem to fit visually. What's "questionable" about
: that?
It's questionable insofar as
Luke Palmer wrote:
Hooray! That was something I had been worried about.
But C doesn't seem to fit visually. What's "questionable" about
that?
Nothing questionable, but
everything hypothetical:
captures to the
$?foo hypothetical variable
Damian
Larry Wall writes:
> On Wed, Mar 10, 2004 at 11:19:52AM -0800, Brent Dax Royal-Gordon wrote:
> : Luke Palmer wrote:
> : >The reason we couldn't just decalre it with C is because its
> : >right hand side is not a usual expression.
> :
> : Isn't that what macros are for?
> :
> : macro infix:.=
On Wed, Mar 10, 2004 at 11:19:52AM -0800, Brent Dax Royal-Gordon wrote:
: Luke Palmer wrote:
: >The reason we couldn't just decalre it with C is because its
: >right hand side is not a usual expression.
:
: Isn't that what macros are for?
:
: macro infix:.= ($lhs, $rhs) is parsed(//) {
Metho
On Wed, Mar 10, 2004 at 05:39:33PM +0100, Juerd wrote:
: Perlists,
:
: In Perl 5, lc, lcfirst, quotemeta, uc and ucfirst don't mutate.
: chomp and chop do mutate.
:
: I imagine these will all be methods in Perl 6:
:
: $foo.lc
: $foo.quotemeta
: $foo.chomp
:
: I'd like a mutating ver
Luke Palmer wrote:
The reason we couldn't just decalre it with C is because its
right hand side is not a usual expression.
Isn't that what macros are for?
macro infix:.= ($lhs, $rhs) is parsed(//) {
return Perl::assignment_expression.new(
lhs => $lhs,
rhs => Per
Juerd writes:
> Perlists,
>
> In Perl 5, lc, lcfirst, quotemeta, uc and ucfirst don't mutate.
> chomp and chop do mutate.
>
> I imagine these will all be methods in Perl 6:
>
> $foo.lc
> $foo.quotemeta
> $foo.chomp
>
> I'd like a mutating version of lc, and a non-mutating version of
54 matches
Mail list logo
