Re: till (the flipflop operator, formerly ..)
On Sun, Nov 20, 2005 at 08:51:03PM +0100, Ingo Blechschmidt wrote:
: Hi,
:
: according to the new S03, till is the new name for the flipflop
: operator.
Presuming we can make it work out as an infix macro.
: Do the flipflop operators of subroutines maintain own
: per-invocation-of-the-sub states? I.e.:
:
: sub foo (&x) { x() till 0 }
:
: foo { 0 }; # evaluates to a false value, of course
:
: foo { 1 }; # evaluates to a true value, of course
: foo { 0 };
: # still true?
: # (Argumentation: The flipflop is in the "true" state,
: # so the LHS is not evaluated.)
: # Or is it false?
: # (Argumentation: The flipflop operator of the previous
: # invocation is not the flipflop operator of the current
: # invocation, so the return value is false.)
It's still true. Ignoring the "E0" issue, the desugar of "A till B"
is something like:
do {
state $flipflop = 0;
my $retval;
if $flipflop or A {
$retval = ++$flipflop;
if B { $flipflop = 0 }
}
else {
$retval = 0;
}
$retval;
}
or more succinctly,
do {
state $flipflop = 0;
$flipflop or A
?? (++$flipflop, not B || ($flipflop = 0))[0]
!! 0;
}
The rewrite of x() till 0 looks like:
do {
state $flipflop = 0;
my $retval;
if $flipflop or x() {
$retval = ++$flipflop;
if 0 { $flipflop = 0 }
}
else {
$retval = 0;
}
$retval;
}
or
do {
state $flipflop = 0;
$flipflop or x()
?? (++$flipflop, not 0 || ($flipflop = 0))[0]
!! 0;
}
(Note that P5's ... syntax has other semantics which I'm not sure how
to combine with the "till" proposal. But the ... semantics are kind
of bogus anyway--it basically doesn't test for falsification till
the next time through, so if you're searching for the beginning and
ending lines with patterns, the two lines can't be the same line.
Maybe that's the "tilll" operator. :-)
: Also, all operators can be called using the subroutine form (which is a
: very good thing), e.g.:
:
: say infix:<->(42, 19); # 23
:
: Is this true for till as well?
:
: say infix:(LHS, RHS);
Probably not. Calling macros as functions is a bit of a problem.
: But how would &infix: maintain the state then, as no explicit ID
: is passed to it? Does &infix: access an internal %states hash,
: using $CALLER::POSITION as keys?
That feels like a hack to me. I'd rather find a way of poking a real
state variable into the caller's scope if we have to support that.
: Perl 5's flipflop operator appends "E0" to the final sequence number in
: a range, allowing searches for /E/. My guess is that this is superseded
: by "$sequence_number but this_is_the_endpoint_of_the_range" (you get
: the idea). Correct?
I was just thinking that you'd use till^ if you wanted to exclude the
endpoint. And ^till to exclude the beginning, and ^till^ to exclude
both, just as with ..^, ^.., and ^..^.
In fact, that's really my main motivation for wanting it to be infix.
Otherwise it might as well be an ordinary flipflip() macro, or fromto().
Oh, we also haven't really dealt with the implicit comparison to
the current line number, but that's perhaps something we don't really
need to support any more.
Larry
statement_control() (was Re: lvalue reverse and array views)
On 11/20/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
[snip]
> Yep. Also note that "for" is not a special magical construct in Perl 6,
> it's a simple subroutine (&statement_control:, with the signature
> ([EMAIL PROTECTED], Code *&code)). (Of course, it'll usually be optimized.)
>
> Example:
>
> {
> my sub statement_control: ([EMAIL PROTECTED], Code *&code) {
> map &code, reverse @array;
> }
>
> for -> $item { say $item }
> # "c\nb\na\n"
> }
>
> # for restored, as the modified for went out of scope:
> for -> $item { say $item }
> # "a\nb\nc\n"
Is there a list of the statement control items that are implemented as
such vs. implemented in another way?
Thanks,
Rob
Re: lvalue reverse and array views
On 11/20/05, Daniel Brockman <[EMAIL PROTECTED]> wrote: > Reversing an array, changing it, and then rereversing it --- > I think that kind of pattern is common. I would think that reversing a string, modifying it, then reversing it back is more common. Does modifying the reversal of a string modify the original? Rob
Re: Multidimensional argument list binding (*@;foo)
On 11/20/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> sub foo (*@;AoA) { @;AoA }
>
> my @array1 = ;
> my @array2 = ;
>
> my @AoA = foo @array1, @array2;
> say [EMAIL PROTECTED]; # 2?
1
> say [EMAIL PROTECTED]; # a b c?
a b c d e f
However,
my @AoA = foo(@array1; @array2);
# all of Ingo's predictions are now correct
> foo 1, 2;
> # dies (neither 1 nor 2 are arrays)?
Nope. The return value would be [[1,2]].
> foo $arrayref1, $arrayref2;
> # dies (neither $arrayref1 nor $arrayref2 are arrays)?
Returns [[$arrayref1, $arrayref2]] (a three-dimensional array).
> foo();
> # works, +foo() is 0?
Hmm. Hard to say whether that would be [] or [[]].
Luke
Multidimensional argument list binding (*@;foo)
Hi,
quoting r6624 of S06 [1]:
> Some functions take multiple Lists that they wish not to be flattened
> into one list. For instance, C wants to iterate several lists
> in parallel, while array and hash subscripts want to process
> multidimensional slices. The set of underlying argument list (List)
> objects may be bound to a single array parameter declared with a C<;>
> twigil:
>
> sub foo (*@;slices) { ... }
sub foo (*@;AoA) { @;AoA }
my @array1 = ;
my @array2 = ;
my @AoA = foo @array1, @array2;
say [EMAIL PROTECTED]; # 2?
say [EMAIL PROTECTED]; # a b c?
say [EMAIL PROTECTED]; # d e f?
# Correct?
foo 1, 2;
# dies (neither 1 nor 2 are arrays)?
foo $arrayref1, $arrayref2;
# dies (neither $arrayref1 nor $arrayref2 are arrays)?
foo();
# works, +foo() is 0?
Also, is specifying other, non-slurpy arguments prior to a slurpy
@;multidim_arglist legal? E.g.:
sub bar ($normal_var, @;AoA) {...}
bar 42, @array1, @array2;
# $normal_var is 42,
# @AoAis ([EMAIL PROTECTED], [EMAIL PROTECTED])
# Correct?
The existence of a @array variable does not imply the existence of a
@;array variable, right?
--Ingo
[1] http://svn.perl.org/perl6/doc/trunk/design/syn/S06.pod
till (the flipflop operator, formerly ..)
Hi,
according to the new S03, till is the new name for the flipflop
operator.
Do the flipflop operators of subroutines maintain own
per-invocation-of-the-sub states? I.e.:
sub foo (&x) { x() till 0 }
foo { 0 }; # evaluates to a false value, of course
foo { 1 }; # evaluates to a true value, of course
foo { 0 };
# still true?
# (Argumentation: The flipflop is in the "true" state,
# so the LHS is not evaluated.)
# Or is it false?
# (Argumentation: The flipflop operator of the previous
# invocation is not the flipflop operator of the current
# invocation, so the return value is false.)
Also, all operators can be called using the subroutine form (which is a
very good thing), e.g.:
say infix:<->(42, 19); # 23
Is this true for till as well?
say infix:(LHS, RHS);
But how would &infix: maintain the state then, as no explicit ID
is passed to it? Does &infix: access an internal %states hash,
using $CALLER::POSITION as keys?
Perl 5's flipflop operator appends "E0" to the final sequence number in
a range, allowing searches for /E/. My guess is that this is superseded
by "$sequence_number but this_is_the_endpoint_of_the_range" (you get
the idea). Correct?
--Ingo
Re: Hyphens vs. Underscores
On Thu, Nov 17, 2005 at 04:05:30AM +0100, Daniel Brockman wrote: > That is, hyphen and underscore are synonymous in identifiers, > but an initial hyphen is not taken to be part of the identifier. > Why not make this feature generic and define equivalence classes for equivalent characters in an identifier? This would introduce a very interesting mathematical feature to Perl6. Something else comes here to my mind: Wildcard identifiers: foo*bar (12, "foo"); (maybe with a different syntax, i'm not sure yet). >From the matching functions/subroutines/whatever the one with a matching signature could be called. A warning or some exception should be thrown if multiple signatures match. Maybe these features could also be implemented via a syntax hook in the parser maybe: use wildcard_identifiers; or use equivalence_identifiers; There are no other languages i know where this is possible, but i would find it quite useful, and i know others that would like a feature like this. Wildcard identifiers would play in hand with the module versioning maybe too. Selecting _any_ version of a module, but i haven't paid much attention to the syntax/semantic of that. greetings, Robin Redeker -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker
Re: \x{123a 123b 123c}
On Sat, Nov 19, 2005 at 06:32:17PM -0800, Larry Wall wrote:
> On Sun, Nov 20, 2005 at 01:26:21AM +0100, Juerd wrote:
> : Ruud H.G. van Tol skribis 2005-11-20 1:19 (+0100):
> : > Maybe
> : > "\x{123a 123b 123c}"
> : > is a nice alternative of
> : > "\x{123a} \x{123b} \x{123c}".
>
> We already have, from A5, \x[0a;0d], so you can supposedly say
> "\x[123a;123b;123c]"
Hmm, I hadn't caught that particular syntax in A05. AFAIK it's not
in S05, so I should probably add it, or whatever syntax we end up
adopting.
(BTW, we haven't announced it on p6l yet, but there's a new version of
S05 available.)
> [...]
> But I see that the semicolon is rather cluttery, mainly because it's
> too tall. I'm not sure going all the way to space is good, but we
> might have
> "\x[123a,123b,123c]"
> just to get a little visual space along with the separator.
Just to verify, with this syntax would we expect
\x[123a,123b,123c]+
to be the same as
[\x123a \x123b \x123c]+
and not "\x123a \x123b \x123c+" ?
> It occurs to me that we didn't spec whether character classes ignore
> whitespace. They probably should, just so you can chunk things:
>
> / <[ a..z A..Z 0..9 _ ]> /
>
> Then the question arises about whether <[ \ ]> is an escaped space
> or a backslash, or illegal
I vote that it's an escaped space. A backslash is nearly always \\
(or should be imho).
> But if we make it match a backslash
> or illegal, then the minimal space matcher becomes \x20, I think,
> unless you graduate to \s. On the other hand, if we make it match
> a space, people aren't going to read that way unless they're pretty
> sophisticated...
There's also , unless someone redefines the subrule.
And in the general case that's a slightly more expensive mechanism
to get a space (it involves at least a subrule lookup). Perhaps
we could also create a visible meta sequence for it, in the same
way that we have visible metas for \e, \f, \r, \t. But I have
no idea what letter we might use there.
I don't think I like this, but perhaps C<< <> >> becomes
and C<< < > >> becomes <' '>? Seems like not enough visual distinction
there...
Pm
Re: lvalue reverse and array views
Hi,
Juerd wrote:
> Ingo Blechschmidt skribis 2005-11-20 16:44 (+0100):
>> Where is the difference (for the user) between a subroutine which
>> returns an appropriate proxy object and an array?
>
> The big difference between pure arrays and referenced arrays, for the
> user, is that pure arrays flatten in list context, while referenced
> arrays do not. Especially with for, this is very relevant.
I'd formulate this as "that @-arrays, i.e. variables whose sigil is @,
flatten in list context, while $-arrayrefs do not".
> I don't know if it is possible for an object to flatten in list
> context, but I would be surprised if it turned out to be.
For sure it is! Recall that "my @array = " creates an object.
> Scalars should NEVER flatten in list context.
Yep. Again, I'd formulate this as "variables whose sigil is $ should
NEVER flatten in list context".
> This includes all references
Yep.
> and thus objects.
I disagree -- @array and %hash, created by plain old assignment ("my
@array = ", "my %hash = (...)"), are objects.
>> I think it'd even optimize many cases:
>> for @foo ¥ @bar {...}
>
> All for-optimizations are in the for, in Perl 5. It would be nice to
> have these in the actual functions and operators in Perl 6. Then
> for-reverse is not a special case anymore, and the optimization is
> indeed optimizing other cases too.
Yep. Also note that "for" is not a special magical construct in Perl 6,
it's a simple subroutine (&statement_control:, with the signature
([EMAIL PROTECTED], Code *&code)). (Of course, it'll usually be optimized.)
Example:
{
my sub statement_control: ([EMAIL PROTECTED], Code *&code) {
map &code, reverse @array;
}
for -> $item { say $item }
# "c\nb\na\n"
}
# for restored, as the modified for went out of scope:
for -> $item { say $item }
# "a\nb\nc\n"
>> (BTW, IIUC, per r6622 of S06.pod [1] &zip returns an array of
>> arrayrefs now:
>> for zip('a'...; 0...; @foo) -> [$a, $i, $x] { ...}
>
> Hm, that's sufficiently ugly. Is this really needed?
>
> I quite like how
>
> for @foos Y @bars -> $foo, $bar { ... }
>
> looks, and don't quite like
>
> for @foos Y @bars -> [ $foo, $bar ] { ... }
>
> as much.
I agree completely.
>> (Or does for no longer automatically take as much elements from the
>> input array as needed?
>
> I like the arity-sensitivity solution better, I think.
Me too.
--Ingo
Re: lvalue reverse and array views
Ingo Blechschmidt skribis 2005-11-20 16:44 (+0100):
> Where is the difference (for the user) between a subroutine which
> returns an appropriate proxy object and an array?
An object is a scalar, an array is an array. Perl has unreferenced
arrays --I like to call them "pure" arrays--, and references to arrays.
A sub can, as far as I know, return a pure array, if the sub is an
lvalue sub. The array that is returned can be tied to be a reversed view
of the original array.
The big difference between pure arrays and referenced arrays, for the
user, is that pure arrays flatten in list context, while referenced
arrays do not. Especially with for, this is very relevant.
I don't know if it is possible for an object to flatten in list context,
but I would be surprised if it turned out to be. Scalars should NEVER
flatten in list context. This includes all references and thus objects.
> I think it'd even optimize many cases:
> for @foo ¥ @bar {...}
All for-optimizations are in the for, in Perl 5. It would be nice to
have these in the actual functions and operators in Perl 6. Then
for-reverse is not a special case anymore, and the optimization is
indeed optimizing other cases too.
> (BTW, IIUC, per r6622 of S06.pod [1] &zip returns an array of arrayrefs
> now:
> for zip('a'...; 0...; @foo) -> [$a, $i, $x] { ...}
Hm, that's sufficiently ugly. Is this really needed?
I quite like how
for @foos Y @bars -> $foo, $bar { ... }
looks, and don't quite like
for @foos Y @bars -> [ $foo, $bar ] { ... }
as much.
> (Or does for no longer automatically take as much elements from the
> input array as needed?
I like the arity-sensitivity solution better, I think.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: lvalue reverse and array views
Hi,
Juerd wrote:
> Will Perl 6 support mutable for-reverse?
I'd like it! :)
> Some possible answers that I could think of:
>
> (a) Yes, but as a special case
> (b) Yes, because reverse returns lvalue aliases
> (c) No
>
> But there's another one, that I didn't immediately think of:
>
> (d) Yes, because reverse @foo always behaves like an array (rather
> than a function that *returns* a list), just with a different view:
> the elements are in the wrong order.
Where is the difference (for the user) between a subroutine which
returns an appropriate proxy object and an array?
# Perl 5
sub foo {...}
foo[42]; # really foo([42])
# Perl 6
sub foo {...}
foo[42]; # really (foo())[42]
foo{"Pugs"}; # really (foo()){"Pugs"}
foo;# really (foo()){"Pugs"}
> This option d is interesting, and would probably be nice to have,
> because it would also allow this (contrived and useless) kind of
> thing:
>
> push reverse(@foo), $bar;
>
> And while that isn't very interesting, I think something like
>
> my @bar := reverse @foo;
>
> would be very useful.
Yep :)
(Also note that if we make &reverse return an appropriate proxy object
so this example works, for reverse @array {...} will automatically be
optimized.)
> The same thing would be interesting for zip:
>
> my @xyzzy := @foo Y @bar;
>
> Assuming this results in an even number of elements in @xyzzy, pushing
> a single element onto @xyzzy could result in an element added to @foo
> every odd, and to @bar every even time.
>
> Would something like that be possible? Wanted?
I'd like that as well. (Generally, I'd like to see many lvalue subs and
methods in default Perl 6.)
> Not too costly?
I think it'd even optimize many cases:
for @foo ¥ @bar {...}
# Generating a new array containing @foo ¥ @bar is, thanks to
# zip's laziness, unnecessary.
(BTW, IIUC, per r6622 of S06.pod [1] &zip returns an array of arrayrefs
now:
for zip('a'...; 0...; @foo) -> [$a, $i, $x] { ...}
(Or does for no longer automatically take as much elements from the
input array as needed? I.e. does
my @array = ;
for @array -> $a, $b { say "$a $b" }
no longer output "a b\nc d\n", but die?))
--Ingo
[1] http://svn.perl.org/perl6/doc/trunk/design/syn/S06.pod
--Ingo
Re: lvalue reverse and array views
Daniel Brockman skribis 2005-11-20 6:58 (+0100): > Well, wouldn't pushing an element onto @xyzzy be more like > pushing the car to @foo and the cdr to @bar, or throwing an > exception if the new element is not a Pair? Zipping has nothing to do with pairs, though! Consider, for example: @foo Y @bar Y @baz > (What is Perl's pair terminology, by the way?) A Pair has a key and a value. To retrieve the key, use the .key method, to retrieve the value, use the .value method, to retrieve a list of both, use the .kv method. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
