Re: Synopses on the smoke server are a bit out-of-date
Hi, Agent Zhang wrote: On 9/28/06, Agent Zhang [EMAIL PROTECTED] wrote: lanny noticed yesterday that the Synopses on the smoke server were different from the ones on feather. Because I am maintaining the feather ones, I know the synopses there are being resync'd every hour as expected. Now the synopses on the smoke server is ~50 rev behind but the timestamp looks good. What's wrong with it? could you please point to an example smoke? See for example http://xrl.us/rzp7, http://xrl.us/rzp8, http://xrl.us/rzp9, smokes several days old. The timestamps indicates a refresh run a few hours ago, and the syn rev is r12533. According to svn log -v http://svn.perl.org/perl6/doc/trunk/design/syn | head r12533 is indeed the current revision. (Many thanks to malon++!) --Ingo
Re: synopses on smoke server
Hi, Christopher D. Malon wrote: Agentz++ writes, in a Pugs blog comment: if someone can offer regular smoke results (i.e. the tests.yml generated by `make smoke'), we can render the Synopses on feather with smoke results as well The obvious way to get this to happen, for all runtimes, is to integrate the synopsis-with-smoke production with the existing smoke server infrastructure. I've started hacking this in, but have some concerns. A few are mainly directed to iblech++. 1. Multi-versioning the tests: The inlined tests need to match the revision at which the smoke was produced. Is it okay to have the smoke server check out the relevant revision of the pugs/t directory each time a smoke of a new revision is submitted, or is that too expensive? Currently, the smokeserver does not run smartlinks.pl etc., but redirects to tests.pugscode.org via .htaccess: Redirect /iblech/stuff/pugs-smokes/t http://tests.pugscode.org/t Redirect /iblech/stuff/pugs-smokes/ext http://tests.pugscode.org/ext (tests.pugscode.org used to be an alias to something under http://feather.perl6.nl/.) This way the smokeserver doesn't need to do anything except storing the .html of smokes; especially it doesn't have to be updated WRT new synopses/tests/smartlinks.pl. Accordingly, ... 3. What is the full path to smartlinks.pl on the smoke server? ...there is none. 5. Will a commit that changes smokeserv-server.pl be picked up by the smoke server right away? No; currently, you'll have to ping me (best by mail). (Note that testing the smokeserver locally shouldn't be hard, as it doesn't require setting up a proper database etc. Copying smokeserv-serv.pl somewhere under cgi-bin/ and adjusting the paths should suffice.) I might down the whole smoke system with my commit. Anyone willing to debug with me when I do? I am, of course. :) --Ingo
Re: synopses on smoke server
Hi, Christopher D. Malon wrote: Currently, the smokeserver does not run smartlinks.pl etc., but redirects to tests.pugscode.org via .htaccess: Redirect /iblech/stuff/pugs-smokes/t http://tests.pugscode.org/t Redirect /iblech/stuff/pugs-smokes/ext http://tests.pugscode.org/ext The multi-versioning of the t/ directory seems critical, because the tests in the YAML smokes are identified by line number, and the correspondence will be wrong if the test has changed. Therefore I'm afraid that a redirect to a single version of t/ won't suffice. ah! I didn't realize that. If the load of an SVN checkout (just of t/) upon smoke submit is too much, maybe we should migrate to a different server. Running svn a few times a day is really not an issue :) --Ingo
Re: binding arguments
Hi,
Juerd wrote:
Ingo Blechschmidt skribis 2005-12-25 17:37 (+0100):
I disagree about binding only being a language thing:
I fail to see how your example code illustrates your disagreement.
return 42
if (my $short := $long_parameter_name) == $specialcase;
I inferred that you think/thought that binding should/can't be used in
expressions:
Juerd wrote:
That works very well, because binding as an expression makes no sense
anyway, it being a language thing.
Thus I wanted to demonstrate that binding as an expression does make
sense (to me at least).
Sorry if I misinterpreted your post.
push @foo, (my $head := pop @grtz);
A bit better style, but I'd still recommend against it.
Consider:
my @sites = abc.org def.org ghi.org ;
loop {
push @sites, (my $site := shift @sites);
check_for_updates($sites);
sleep ...;
}
You're doing something in an expression that has no effect on what
happens in the expression itself.
Right; but I don't consider this as bad style or as problematic.
Consider a perhaps more usual example:
# Perl 5
while(...) {
process($tasks[$i++]);
# The ++ does not have an effect on the expression itself,
# writing process($tasks[$i]) wouldn't make any difference.
if(...) { $i-- } # redo the last task
if(...) { $i = 0 } # redo all tasks
if(...) { $i++ } # skip next task
}
--Ingo
Re: for loop list of lists: flattening arguments to pointy sub
Hi,
Andrew Savige wrote:
In Pugs, you can process a simple list of lists like this:
my @lol = ( [ '1a', '1b' ], [ '2a', '2b' ], [ '3a', '3b' ] );
for @lol - $t { say 1st='$t[0]' 2nd='$t[1]' }
Yet the $t[0] and $t[1] look untidy to me, so I'd prefer to specify
that the for closure block takes two parameters, something like:
for - $x, $y { say 1st='$x' 2nd='$y' }
But I have no clue what to put in place of above.
for @lol - [$x,$y] { say 1st='$x' 2nd='$y' }
(Assuming that the syntax for unpacking array parameters wasn't changed
when I weren't looking.)
You can read more about this in S06, Unpacking array parameters [1].
--Ingo
[1]
http://dev.perl.org/perl6/doc/design/syn/S06.html#Unpacking_array_parameters
Re: binding arguments
Hi,
Juerd wrote:
The next thing I thought was: hey, argument *passing* is actually
*binding* to variables in the sub, so why not use the := operator?
That works very well, because binding as an expression makes no sense
anyway, it being a language thing. And luckily, named arguments are
also a language thing, so that works out:
I disagree about binding only being a language thing:
# Happened to me in Perl 5 today
sub foo ($long_parameter_name) {
return 42
if (my $short := $long_parameter_name) == $specialcase;
...usual processing with $short...
}
push @foo, (my $head := pop @grtz);
(my $alias := $long_name).grtz();
# etc.
(Unless of course, you consider this to be obfuscation.)
--Ingo
Binding of list slice elements
Hi, my ($a, $b, $c) = a b c; my $also_a := ($a,$b,$c)[0]; $also_a eq a; # correct? $also_a = A; # does not die? $a eq A; # true? my $also_b = b; ($a,$b,$c)[1] := $also_b; $b eq b; # true? $b = B;# does not die? $also_b eq B; # true? Note that if my assumptions are correct, the following expressions must be true as well (also see [1]), unless there's some additional magic. ($a,$b,$c)[0] =:= $a; ($a,$b,$c)[1] =:= $b; ($a,$b,$c)[2] =:= $c; Thus: ($a,$b,$c)[1] = 42; # same as $b = 42 And: (0,1,2)[1] = 42; # dies (cannot modify constant) (0,1,2)[1] := 42; # dies (cannot rebind constant) my @foo = a b c; my @bar = d e f; (@foo,@bar)[2] =:= @foo[2]; # true (@foo,@bar)[3] =:= @bar[0]; # true (@foo,@bar)[2] = 42; # same as @foo[2] = 42 (@foo,@bar)[3] = 42; # same as @bar[0] = 42 (@foo,@bar)[2] := 42; # same as @foo[2] := 42 (@foo,@bar)[3] := 42; # same as @bar[0] := 42 (These questions were motivated by Flavio's work in progress [2] (A draft on the runtime view of how Lazy things (like Arrays) work).) --Ingo [1] http://www.nntp.perl.org/group/perl.perl6.language/22924 [2] http://svn.openfoundry.org/pugs/docs/notes/laziness.txt
Re: Multidimensional argument list binding (*@;foo)
Hi,
Luke Palmer wrote:
On 11/20/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
sub foo (*@;AoA) { @;AoA }
my @array1 = a b c;
my @array2 = d e f;
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
Hm. How is (*@;AoA) different from (Array [EMAIL PROTECTED]) then? (Assuming
that
foo(@a; @b) desugars to foo([EMAIL PROTECTED], [EMAIL PROTECTED]).)
--Ingo
Re: statement_controlfoo() (was Re: lvalue reverse and array views)
Hi,
Rob Kinyon wrote:
On 11/20/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
Yep. Also note that for is not a special magical construct in Perl
6, it's a simple subroutine (statement_control:for, with the
signature ([EMAIL PROTECTED], Code *code)). (Of course, it'll usually be
optimized.)
Example:
{
my sub statement_control:for ([EMAIL PROTECTED], Code *code) {
map code, reverse @array;
}
for a b c - $item { say $item }
# c\nb\na\n
}
# for restored, as the modified for went out of scope:
for a b c - $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?
statement_control:if,
statement_control:unless,
statement_control:for,
statement_control:while,
statement_control:until, and
statement_control:loop
come to my mind.
??!! is proably defined as
sub ternary:?? !! ($cond, $then is lazy, $else is lazy) {
if $cond { $then } else { $else }
}
(Assuming that ternary is the correct grammatical category and is
lazy DWIMs.)
Of course, the compiler is free to optimize these things if it can prove
that runtime's statement_control:if is the same as the internal
optimized statement_control:if.
--Ingo
Re: till (the flipflop operator, formerly ..)
Hi,
Larry Wall wrote:
On Sun, Nov 20, 2005 at 08:51:03PM +0100, Ingo Blechschmidt wrote:
: 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.
Ah, it's a macro. This clarifies things.
: 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:
[...]
Thanks very much, this code is very clear. :)
: 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:till(LHS, RHS);
Probably not. Calling macros as functions is a bit of a problem.
Yep. (I assumed infix:till would be an ordinary subroutine.)
: But how would infix:till maintain the state then, as no explicit
: ID is passed to it? Does infix:till 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.
Agreed. The desugar you provides feels far more sane.
: 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 ^..^.
Ok.
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().
Makes sense.
--Ingo
Re: Multidimensional argument list binding (*@;foo)
Hi,
Luke Palmer wrote:
On 11/21/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
Hm. How is (*@;AoA) different from (Array [EMAIL PROTECTED]) then? (Assuming
that
foo(@a; @b) desugars to foo([EMAIL PROTECTED], [EMAIL PROTECTED]).)
Well, it's not at all, under that assumption. But that assumption is
wrong.
Aha! FYI, I got that interpretation from r6628 of S09 [1]:
The following two constructs are structurally indistinguishable:
(0..10; 1,2,4; 3)
([0..10], [1,2,3,4], [3])
I think foo(@a; @b) doesn't have a sugar-free form (that is to
say, it is the sugar-free form). Among things that desugar to it:
@a == foo() == @b
foo(@a) == @b
@a == @b == foo() # maybe; don't remember
To illustrate:
sub foo ([EMAIL PROTECTED]) {
say [EMAIL PROTECTED];
}
sub bar (*@;a) {
say +@;a;
}
foo(1,2,3; 4,5,6); # 6
bar(1,2,3; 4,5,6); # 2
That is, the regular [EMAIL PROTECTED] has concat semantics. However, I'd
like to
argue that it should have die semantics, for obvious reasons.
Just to clarify -- only ; with *@;a should have die semantics, ,
with *@;a should continue to work, right? (If so, I agree.)
Could you provide some more examples with ;, please? In particular, what
are the results of the following expressions?
(42; 23)
(@a; @b)
(@a; @b)[0]
(@a; @b)[0][0]
((42;23); (17;19))
((@a;@b); (@c;@d))
*(42; 23)
*(@a; @b)
( (42; 23), 19)
(*(42; 23), 19)
[42; 23]
[EMAIL PROTECTED]; @b]
Thanks very much,
--Ingo
[1] http://svn.perl.org/perl6/doc/trunk/design/syn/S09.pod
/The semicolon operator
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}
fooPugs;# 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 = a b c d;
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
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 = a b c 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 = a b c, 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:for, with the signature
([EMAIL PROTECTED], Code *code)). (Of course, it'll usually be optimized.)
Example:
{
my sub statement_control:for ([EMAIL PROTECTED], Code *code) {
map code, reverse @array;
}
for a b c - $item { say $item }
# c\nb\na\n
}
# for restored, as the modified for went out of scope:
for a b c - $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
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:till(LHS, RHS);
But how would infix:till maintain the state then, as no explicit ID
is passed to it? Does infix:till 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
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, Czip() 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 = a b c;
my @array2 = d e f;
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
Re: ='s container and binding semantics
Hi,
Larry Wall wrote:
On Sun, Nov 06, 2005 at 03:10:40PM +0100, Ingo Blechschmidt wrote:
[ = should not automatically bind its .value to the RHS ]
I think binding directly to .key or .value is different from what =
does. So after
$pair = $key = $value;
setting $value doesn't change $value, but after
$pair.value := $value
it does.
Yep, of course.
We could have an = equivalent that does binding rather than
copying:
[ :=, :, ::, etc. ]
Personally, I think that these operators are not needed. In my PIL to
JavaScript compiler, I used the equivalent of =: exactly two times,
and I did not mind declaring infix:«=:» myself, as it's such a short
and very readable declaration:
my sub infix:«=:» ($key, $value is rw) {
my $pair = ($key = $value);
$pair.value := $value;
$pair;
}
our pairs are containers, not values. Maybe \(key = $value) is
how you turn = into ::, since in the case of an arglist you have
to be able to bind to the original $value.
Makes sense. :)
--Ingo
='s container and binding semantics
Hi, my ($key, $value) = key val; my $pair = ($key = $value); $pair.key = new; # Should this fail (cannot modify a constant)? # Should this update $pair.key, but leave $key untouched? # Should this update $pair.key, implicitly updating $key as well? $pair.value = new; # Should this fail (cannot modify a constant)? # Should this update $pair.value, but leave $value untouched? # Should this update $pair.value, implicitly updating $value # as well? If setting $pair.value changes $value, should rebinding $pair.value cause the binding to get destroyed: $pair.value := $some_other_var; $pair.value = new; # $value unchanged, $some_other_var set to new If setting $pair.value does not change $value, should binding $pair.value to $value do what I mean: $pair.value := $value; $pair.value = new; # $value changed --Ingo
Re: Sane (less insane) pair semantics
Hi,
TSa wrote:
Ingo Blechschmidt wrote:
Exactly. I'd like to add that, under the proposal, you always know
what things are passed how, only by looking for a *.
foo $var;# always positionally, even if $var isa Pair
foo *$pair; # always named
But where is the name? Is it 'pair'? Like in
foo :pair($pair);
No.
or dynamically through
foo $pair.key = $pair.value;
Yep.
assuming that precedence of = is tighter than foo's.
I think it is.
As I lengthyly ranted elsewhere in this thread the splat should just
defer the
structural callability check until runtime. Well, and since everybody
seems to be happy with .$pair denoting a call through a hardref stored
in $pair, I don't understand why :$pair is not (yet) denoting a hard
pairref. Both forms beeing interpreted in the context of the term to
Um, sorry, I don't understand... The only syntax I know of where a $
follows a . is calling method references:
my $meth = method (Foo $self: ...) {...};
$foo.$meth(...);
(But this syntax doesn't have, obviously, anything to do with
magical/non-magical pairs.)
If full uncertainty isn't your thing, you might instruct the type
system to make sure that $pair at least doesn't fail you on pairhood
my Pair $pair;
Yep.
foo $pair; # syntactically an item, thus a positional call
foo *$pair; # guarranteed pair after splatting
foo [EMAIL PROTECTED]; # always positionally
This makes perfect sense to me if you mean that the positionals
that foo requests are satisfied in the order provided by @array
without exceptions for pairs, not to mention subtypes of pairs
or things that do the Pair role etc.
Yep, it's very important that Pairs are not exceptions.
foo *%hash; # always named (hash keys taken as parameter names)
So that shall fail at compile time if foo has *anonymous* positionals?
Assuming that anonymous positionals exist, yes, I think so.
Previously, you wasn't able to know whether you passed something
positionally or by name:
sub bar ($x) { grtz $x }
bar 42; # 42 passed to grtz positionally
bar a = 42; # either the pair (a = 42) passed to grtz
# positionally or the number 42 passed by name
Under the new proposal, grtz $x always passes $x positionally. You
don't need grtz's signature, nor do you need to know $x's type (is
$x a Pair?).
Yep. But you could attempt to dispatch .key on $x in grtz:
sub grtz ($item)
{
say $x.key;
}
and get a printout of 'Undef of Key' or so and 'a' respectively.
HiHi, or a 'method not understood' exception if .key is not applicable
to 42 ;)
Yep, of course. Pairs are, when not splatted with *, normal instances of
normal classes. (And when pairs are splatted, they are no longer pairs,
but syntactical constructs. (This might of course be implemented using
some class in the compiler, but this is an implementation detail.))
Stuart Cook wrote:
And look, if you really wanted to, you could define your own
splat-style operator that works exactly as you describe. But I don't
think it should be the default.
I think that is difficult *without* parser support because
a purely prefix thingy doesn't get the coderef the flattened
array goes to.
Right, also prefix:* can be faked as a normal subroutine (the PIL to
JavaScript compiler does this currently [1]), it has to be some kind of
grammatical rule or perhaps a macro if we want it to be implemented
properly.
Right. Under the proposal, you can -- *if you want to* -- use pairs
stuffed in arrays as named arguments:
foo *hash(@array_of_pairs);
# @array_of_pairs's pairs used as named args
This hash function there is hardly the same as the one from S06, that
takes every other pair from @array_of_pairs, converts *the pair*
to a key---which might preserve the key actually---and combines it
with the next entry from the array as value?
Hm. I thought the hash() sub would be a bit more DWIMmy, so it can be
used for desugaring:
my %hash = (a = 1, b,2, c); # desugared to
my %hash = hash(a = 1, b,2, c); # which means
my %hash = (a = 1, b = 2, c = undef);
# thus:
sub hash ([EMAIL PROTECTED]) returns Hash {
my %hash;
while shift @things - $thing {
given $thing {
when Pair { %hash{$thing.key} = $thing.value }
default {
my $value = shift @things;
%hash{$thing} = $value;
}
}
}
%hash;
}
But, looking at S06, the reference implementation of S06 isn't that
DWIMmy. Dunno whether this is simply a oversight in S06 or whether it
has been purposefully left out.
@AoP = (a = 'a', b = 'b', c = 'c', d = 'd');
%hash = hash @AoP;
# = (AoP[0] = AoP[1], AoP[2] = AoP[3]);
# = ( a = 'b' , c = 'd' );
+%hash == 2; # true?
With my hash, +%hash would be 4.
But if we made
Re: Sane (less insane) pair semantics
Hi,
Stuart Cook wrote:
On 11/10/05, Austin Hastings [EMAIL PROTECTED] wrote:
A rule that says
splatting
a list coerces all pairs into named args works just fine. The
corresponding rule, accessing the parameters to your sub as a list
(not using *%args) coerces all named args to pairs. Presto!
Reversible, etc.
2)
What if the list contains pairs, but you want to pass them as
positionals? What if it might contain pairs, but you're not sure?
What if you introduce a new named parameter (or change a parameter
name), and what you thought was a positional pair now becomes a named
arg?
Your suggestion would involve re-introducing some of the 'magic' that
real experience suggests we should be trying desperately to get away
from.
Exactly. I'd like to add that, under the proposal, you always know what
things are passed how, only by looking for a *.
foo $var;# always positionally, even if $var isa Pair
foo *$pair; # always named
foo [EMAIL PROTECTED]; # always positionally
foo *%hash; # always named (hash keys taken as parameter names)
Previously, you wasn't able to know whether you passed something
positionally or by name:
sub bar ($x) { grtz $x }
bar 42; # 42 passed to grtz positionally
bar a = 42; # either the pair (a = 42) passed to grtz
# positionally or the number 42 passed by name
Under the new proposal, grtz $x always passes $x positionally. You
don't need grtz's signature, nor do you need to know $x's type (is $x
a Pair?). Compare this with the old semantics:
grtz $x;
# $x is not a Pair? == $x passed positionally
# else ==
# grtz expects a Pair as its first positional parameter?
# == $x passed positionally
# else ==
# grtz's signature lists a parameter named $x.key?
#== $x.value passed by name
# else
# == $x passed positionally
And look, if you really wanted to, you could define your own
splat-style operator that works exactly as you describe. But I don't
think it should be the default.
Right. Under the proposal, you can -- *if you want to* -- use pairs
stuffed in arrays as named arguments:
foo *hash(@array_of_pairs);
# @array_of_pairs's pairs used as named args
foo [EMAIL PROTECTED];
# @array_of_pairs's pairs used positionally
But if we made [EMAIL PROTECTED] mean that...
* [EMAIL PROTECTED]'s pairs are always taken as named arguments,
there wouldn't be a simple way to pass pairs positionally.
* [EMAIL PROTECTED]'s pairs are always taken as pairs,
there wouldn't be a simple way to use the pairs as named arguments.
* [EMAIL PROTECTED]'s pairs are taken as pairs or named arguments,
depending on the called subroutine (does it accept named params?
Do some parameters specifically want a Pair? etc.), we'd introduce
non-local non-determinism to a quite important part of the language.
--Ingo
Re: Sane (less insane) pair semantics
Hi,
Austin Hastings wrote:
How about perl should DWIM? In this case, I'm with Juerd: splat
should pretend that my array is a series of args.
Yep.
So if I say:
foo [EMAIL PROTECTED];
or if I say:
foo([EMAIL PROTECTED]);
I still mean the same thing: shuck the array and get those args out
here, even the pairs.
Right, you name it: you get *pairs* out of the array, not named
parameters. Under the proposal, a Pair object doesn't have any special
magic -- it's simply
class Pair { has $.key; has $.value is rw }
Thus:
my @array = (42, hi, (a = 23));
foo [EMAIL PROTECTED]; # same as
foo 42, hi, (a = 23); # three positional params (Int, Str, Pair)
It's worth pointing out that perl does know the list of declared named
args, though that may not be enough. If the pair.key matches an
expected arg, then splat should collapse it for sure. If it doesn't
match...I dunno.
But that's exactly the problem. You shouldn't have to worry about any
special magic when dealing with [EMAIL PROTECTED] Consider:
sub foo ($a, $b, $c, ?$d) {...}
my @array = (1, 2, (key = value));
foo [EMAIL PROTECTED]; # fine, no problem, $c will receive (key = value)
my @array = (1, 2, (d = value));
foo [EMAIL PROTECTED]; # oops! $a = 1, $d = value
# Required argument 'c' not given!
Is there a list() operator for converting hashes into lists of pairs?
my @array_of_pairs = %hash; # short for
my @array_of_pairs = list %hash;
--Ingo
Re: Sane (less insane) pair semantics
Hi, Mark Reed wrote: On 2005-10-10 13:36, Ingo Blechschmidt [EMAIL PROTECTED] wrote: Under the proposal, a Pair object doesn't have any special magic Right. So under this proposal, the key = value syntax is overloaded: in some contexts it creates a Pair object, and in others it assigns a value to a named parameter, and parentheses are the disambiguating mechanism to get the former behavior in the latter context. Meanwhile, a reference to a Pair object occurring in an argument list does not interact with the named-parameter mechanism at all. Exactly. At least, not by default. It would be desirable to have a way to flatten a hash/list of Pairs/whatever in such a way that it *does* map key names to named parameters. Yep: foo *%hash; # keys of %hash taken as named parameters foo *hash(@array_of_pairs); # @array_of_pairs's pairs taken as named parameters --Ingo
Re: Sane (less insane) pair semantics
Hi, Dave Whipp wrote: Austin Hastings wrote: How about perl should DWIM? In this case, I'm with Juerd: splat should pretend that my array is a series of args. So if I say: foo [EMAIL PROTECTED]; or if I say: foo([EMAIL PROTECTED]); I still mean the same thing: shuck the array and get those args out here, even the pairs. The trouble is, an array doesn't contain enough information: Compare: foo( (a=1), b=2 ); With @args = ( (a=1), b=2 ); foo( [EMAIL PROTECTED] ); my @args = ( (a = 1), b = 2 ); # is sugar for my @args = ( (a = 1), (b = 2) ); # We can't stuff named arguments into an array, only pairs. # Named arguments are neither objects nor some other data type, # they're purely syntactical. If we have an arglist ctor, then we could have @args = arglist( (a=1), b=2 ); foo( [EMAIL PROTECTED]); say @args.perl ## ( ## (a=1) but is_positional, ## (b=2) but is_named, ## ) but without such a constructor, it would be difficult to DWIM correctly. Yep, see Luke's tuple proposal [1]: my $tuple = ( (a = 1), b = 2 ); foo *$tuple; # same as foo( (a = 1), b = 2 ); # one positional argument (a Pair) and # the named parameter b --Ingo [1] http://svn.openfoundry.org/pugs/docs/notes/theory.pod /Tuples
Re: Sane (less insane) pair semantics
Hi, Juerd wrote: Ingo Blechschmidt skribis 2005-10-10 19:36 (+0200): my @array = (42, hi, (a = 23)); It is worth pointing out that the inner parens here are merely for grouping: this information is lost afterwards, hence this: foo [EMAIL PROTECTED]; # same as shouldn't be foo 42, hi, (a = 23); # three positional params (Int, Str, Pair) but instead foo 42, hi, a = 23 # two positional args, one named. OR pairs need to remember whether they were originally in parens. This is very doable, but whether we want or need it is very arguable. Luckily, this is not needed, see my response to Dave [1]: Because named arguments are purely syntactic (i.e., they are not objects or some other kind of data type), you can't stuff them into an array (or a scalar, for that matter). # (assuming = binds thighter than =) my $scalar = a = 1; # sugar for my $scalar = (a = 1); my @array = (42, a = 1); # sugar for my @array = (42, (a = 1)); Named arguments can -- under the proposal -- only ever exist in calls. --Ingo [1] http://www.nntp.perl.org/group/perl.perl6.language/23438
Re: Sane (less insane) pair semantics
Hi, Juerd wrote: Ingo Blechschmidt skribis 2005-10-10 19:59 (+0200): my @args = ( (a = 1), b = 2 ); # is sugar for my @args = ( (a = 1), (b = 2) ); Please, no. Please let the pair constructor be =, not (=). There is really no need for this operator to consist of both infix and circumfix parts. Please leave the parens for grouping (and in calls: breaking recognition). Err, of course! The parens around b = 2 should make clear that b = 2 is not a named argument, but a pair. Outside of calls, the parens are only for grouping: my @args = (b = 2);# same as my @args = ((b = 2)); # same as my @args = b = 2; --Ingo
Re: Sane (less insane) pair semantics
Hi,
Juerd wrote:
Ingo Blechschmidt skribis 2005-10-10 20:08 (+0200):
Named arguments can -- under the proposal -- only ever exist in
calls.
Which leaves us with no basic datastructure that can hold both
positional and named arguments. This is a problem because in a call,
they can be combined.
Very true. This is why we need Luke's Tuple proposal [1]. Basically:
my $tuple = (a = 1, (b = 2)):{ ...block... }; # $tuple.isa(Tuple)
# Tuples are ordinary objects -- they can be stored
# in scalars, arrays, etc.
# But splatting tuples unfolds their magic:
foo(*$tuple); # same as
foo(a = 1, (b = 2)):{ ...block...};
# named arg a, positional pair (b = 2),
# adverbial block { ...block... }
# (Yep, under the current proposal, tuple construction conflicts
# with list/array construction. FWIW, I'd be fine with
# using Tuple.new(...) as the tuple constructor.)
--Ingo
[1] http://svn.openfoundry.org/pugs/docs/notes/theory.pod
Sane (less insane) pair semantics
Hi,
while fixing bugs for the imminent Pugs 6.2.10 release, we ran into
several issues with magical pairs (pairs which unexpectedly participate
in named binding) again. Based on Luke's Demagicalizing pairs thread
[1], #perl6 refined the exact semantics [2].
The proposed changes are:
* (key = $value) (with the parens) is always a positionally passed
Pair object. key = $value (without the parens) is a named
parameter:
sub foo ($a) {...}
foo(a = 42);# named parameter a, $a will be 42
foo(:a(42)); # same
foo((a = 42)); # positional parameter (a pair),
# $a will be the Pair (a = 42)
foo((:a(42))); # same
* Passing a variable containing a Pair is always passed positionally:
my $pair = (a = 42); # or :a(42)
foo($pair); # positional parameter, $a will be the Pair (a = 42)
* Unary * makes a normal pair variable participate in named binding:
foo(*$pair); # named parameter a, $a will be 42
* Same for hashes:
my %hash = (a = 1, b = 2, c = 3);
foo(%hash); # positional parameter, $a will be \%hash
foo(*%hash); # three named parameters
Opinions?
--Ingo
[1] http://article.gmane.org/gmane.comp.lang.perl.perl6.language/4778/
[2]
http://colabti.de/irclogger/irclogger_log/perl6?date=2005-10-09,Sunsel=528#l830
Re: Sane (less insane) pair semantics
Hi,
Uri Guttman wrote:
IB == Ingo Blechschmidt [EMAIL PROTECTED] writes:
IB * (key = $value) (with the parens) is always a positionally
passed
IB Pair object. key = $value (without the parens) is a named
IB parameter:
IB sub foo ($a) {...}
IB * Unary * makes a normal pair variable participate in named
binding:
IB foo(*$pair); # named parameter a, $a will be 42
IB * Same for hashes:
IB my %hash = (a = 1, b = 2, c = 3);
IB foo(%hash); # positional parameter, $a will be \%hash
IB foo(*%hash); # three named parameters
IB Opinions?
works for me.
Great! :)
but what about lists and arrays?
my @z = ( 'a', 1 ) ;
foo( @z ) # $a = [ 'a', 1 ] ??
Yep.
my @z = ( a = 1 ) ;
foo( @z ) # $a = pair( a = 1 ) or does that need * too?
No. Even foo([EMAIL PROTECTED]) would cause $a to be the Pair (a = 1).
If you really wanted to have an array of pairs participate in named
binding, you'd have to write:
foo(*hash(@z)); # (which is short for)
my %hash = @z; foo(*%hash);
same questions for lists (this shows a nested sub call)
sub bar { return ( a = 1 ) }
foo( bar() ) # i would expect $a == ( a = 1 ) since there is
# no *
Yep.
foo( *bar() ) # i would expect $a == 1
Yep.
--Ingo
Re: use fatal err fail
Hi,
TSa wrote:
Yuval Kogman wrote:
On Wed, Sep 28, 2005 at 11:46:37 -0500, Adam D. Lopresto wrote:
thinking for a while. In short, I propose that use fatal be on by
default, and that err be turned into syntactic sugar for a very
small try/CATCH block.
I like it a lot. It gives the advantages of both the flexible, more
robust try/catch, and the (locally) concise, clear error return.
I don't like it at all. I fear, that we mix two orthogonal concepts
just because it is convenient.
I agree with you, TSa. I'd like to add that we don't have to do without
convenience in the majority of cases:
use fatal;
for @files {
my $fh = try { open $_ } err next;
load_config_from($fh);
}
* try {...} is, like Perl 5's eval {...}, *not* statement-level.
This means you can easily wrap it around an expression.
Particularly you can write
my $fh = try { open $_ } err next; # instead of
my $fh;
try {
$fh = open $_;
CATCH { next }
};
* Yes, try {...} err ... does not check the exception type, but
the proposed ... err ... doesn't either.
* try { foo() } err next will next even if foo() did not throw
an exception, but returned undef. But I don't think that's a problem
in most cases. One can always do:
try { foo(); 1 }
FWIW, I also agree with Darren that use fatal should be on by default.
--Ingo
Stringification, numification, and booleanification of pairs
Hi, quick questions: my $pair = (a = 42); say ~$pair; # a\t42? a\t42\n? a 42? say +$pair; # 0 (pairs aren't numbers)? # 42? # 0 (a is not a number)? # 0 (~$pair can't be used as a number)? say ?$pair; # true (because 42 is true)? # true (because pairs are always true)? FWIW, I'd opt for ~$pair to be a\t42, +$pair to be +(~$pair) [1], and ?$pair to be always true. --Ingo [1] The numification of match objects used to *not* be the numification of their stringification, causing confusion, see http://tinyurl.com/asocc.
Re: \(...)?
Hi,
(sorry for the long delay.)
Juerd juerd at convolution.nl writes:
Ingo Blechschmidt skribis 2005-09-19 14:21 (+):
\(1,2,3);# Reference to a list promoted to an array (!)
\(((1,2,3)));# same
Except that it has to be a reference to a reference, because (1,2)
(in scalar context) already evaluates to a reference, because it can't
be a pure array.
See my definition of prefix:\ below. Parentheses used for grouping
do not change the context.
Could you think of a formal specification of \ the way you want it,
that doesn't exist of only examples? What context does it give its
RHS?
multi prefix:\ (Item $item) {...}
multi prefix:\ (@array) {...}
multi prefix:\ (%hash) {...}
# (The necessary magic needed for dealing with the proposed
# [EMAIL PROTECTED], which would be equivalent to map { \$_ } @array,
# is not included here.)
So:
\$obj;# $obj in item context
[EMAIL PROTECTED]; # @array in Array context (so @array doesn't auto-ref
# to a reference to itself, which would cause the problem
# you mentioned (that [EMAIL PROTECTED] would evaluate to a ref
# pointing to a ref))
\%hash; # analogous
What do you want , in that comma to do?
sub infix:, ([EMAIL PROTECTED] is rw) { @things }
# The is rw should refer to the parameters, i.e.
# infix:, returns aliases:
# ($a, $b)[0] = $c;# same as $a = $c
# ($a, $b)[0] =:= $a; # true
So the comma operator supplies list context to its arguments (because
of the slurpy @things) and returns an array. It can't return a list,
because, as you've said, lists aren't real data types.
Because the comma operator supplies list context, (@a, @b) flattens
@a and @b, so it's like @a.concat(@b).
(Of course, there is still the comma operator which separates arguments.
This operator is not the infix:, we talk about, e.g.:
foo(1,2,3); # infix:, *not* called
foo (1,2,3); # same as
foo( (1,2,3) ); # infix:, called
(BTW, is the argument-separator comma operator accessible by a
subroutine, like most other operators are? (I think not.)))
Are parens in any way special when used with \?
No:
\($obj); # same as
\$obj;
\((($obj))); # same as
\$obj;
\($a, $b);# same as
do {
my @temp = ($a, $b);
[EMAIL PROTECTED];
}
\((($a, $b))); # is really
prefix:\$a, $b;# is really
prefix:\( ($a, $b) ); # is really
# (Inner parentheses needed to prevent the comma to be treated
# as the other comma operator which separates arguments.)
prefix:\(infix:,($a, $b)); # same as
do {
my @temp = ($a, $b);
[EMAIL PROTECTED];
}
What is the precedence of \?
The comma operator should bind tighter than \:
\$a, $b# same as
(\$a), $b
BTW, list ::= infix:,:
($a,);# could be considered ugly
list $a; # same effect, but could be considered not ugly
I hope this mail makes sense :)
--Ingo
Re: \(...)?
Hi, Matt Fowles wrote: On 9/21/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote: foo(1,2,3); # infix:, *not* called foo (1,2,3); # same as foo( (1,2,3) ); # infix:, called Do you mean this to read? foo(1,2,3); # infix:, *not* called foo .(1,2,3);# infix:, *not* called foo (1,2,3); # infix:, called foo( (1,2,3) ); # infix:, called Right. Should have added an extra \n. --Ingo
Re: \(...)?
Hi,
Juerd wrote:
Ingo Blechschmidt skribis 2005-09-21 17:24 (+0200):
multi prefix:\ (Item $item) {...}
multi prefix:\ (@array) {...}
multi prefix:\ (%hash) {...}
I keep forgetting. What's the rule for determining that the (Item
$item) is used, rather than (@array), when one uses \$aref? It'd be
bad if $aref dereferenced first :)
IIRC the rules aren't really there yet (but there're various proposals).
But, as you say, the rules will have to make sure that [EMAIL PROTECTED] calls
the
prefix:\ with the signature of (@array).
Is Item really a type?
I think so, see http://use.perl.org/~autrijus/journal/25337,
http://use.perl.org/~autrijus/journal/25365, and some
http://svn.openfoundry.org/pugs/examples/:
Any is now really Any (includes Junction);
the role hierarchy looks like this:
Any
/ \
ItemJunction
# (The necessary magic needed for dealing with the proposed
# [EMAIL PROTECTED], which would be equivalent to map { \$_ } @array,
# is not included here.)
Also, the magic for handling multiple arguments is missing.
This magic isn't needed, as there is no way to pass multiple arguments
to prefix:\ (except by explicitly calling prefix:\, of course):
\(1,2,3); # is really
\infix:,(1,2,3); # thus prefix:\ gets a single array,
# not three arguments.
What's the syntax for accepting a variable number of arguments, each
of which can be anything, regardless of context? How do you find out
what you got (array or scalar)?
I'm not 100% sure what you mean by regardless of context in this, err,
context, but I'll try anyway:
# Naive approach (doesn't work)
sub foo ([EMAIL PROTECTED]) {...}
foo @array_containing_only_one_element;
foo @array_containing_only_one_element[0];
# XXX -- foo can't tell the difference between these two
# invocations.
# Better approach
multi bar (@array) {...}
multi bar ([EMAIL PROTECTED]) {...}
bar @array_containing_only_one_element; # first variant called
bar @array_containing_only_one_element[0]; # second variant called
# But I don't think it's possible to make
bar @foo, @baz;
# cause @args to be bound to ([EMAIL PROTECTED], [EMAIL PROTECTED]), as
slurpy parameters
# automatically flatten @?ARGUMENTS (unspecced variable).
# I started a thread about this a while ago, but can't find a link
# to it...
Does it even make sense to implement \ in Perl? Does it make sense to
try and figure out a Perl signature for it?
It definitely makes sense to figure out an appropriate signature, as
a signature can help us to better understand what context \ supplies
to its parameters, how many arguments it accepts, etc.
It may or not may make sense to actually implement prefix:\ in Perl,
depending on the compiler, the backend, and the runtime.
Because the comma operator supplies list context, (@a, @b) flattens
@a and @b, so it's like @a.concat(@b).
Ah, comma supplies list context regardless of the context the comma is
in? Is this current, or part of your proposal? I thought comma would
propagate context.
Well, (@a, @b) always evaluated to @a.concat(@b), so I guess the
comma operator supplies list context even in the current spec:
my @c = (@a, @b); # same as @c = @a.concat(@b)
my $c = (@a, @b); # flattens @a and @b as well (but, of course,
# $c contains a reference after the assignment.)
infix:, definitely supplies list context in my proposal, as
infix:, has a signature of ([EMAIL PROTECTED]), and slurpy parameters supply
list context. (See, figuring out infix:,'s signature does make
sense :))
This clarifies much. Thanks.
:)
--Ingo
Re: \(...)?
Hi,
TSa Thomas.Sandlass at orthogon.com writes:
Ingo Blechschmidt wrote:
[EMAIL PROTECTED];# Ref to array
\(@array); # List of refs to @array's elements, i.e. same as
map { \$_ } @array;
# Weird (violating the parens are only for grouping rule), but
# consistent with Perl 5.
Correct?
I opt for 'no'. () should just group and \@array is a sillily
written arrayref. If you want @array to flatten lazily for enreferencing
this should be \([EMAIL PROTECTED]) which works without parens as well:
[EMAIL PROTECTED]
---and is one char shorter than \(@array). And of course there is eager
flattening enreferencing: [EMAIL PROTECTED]
I like this very much! :)
BTW, I like the ubiquitous interpretation of prefix * as infinite arity
marker at call sites as above and in sig definitions.
I agree completely :).
I'd like to violate the parens are only for grouping rule only if
absolutely necessary, and make more use of prefix *.
So...:
[EMAIL PROTECTED]; # Reference to array, of course
\(@array); # same
\(((@array))); # same
\(1,2,3);# Reference to a list promoted to an array (!)
\(((1,2,3)));# same
[EMAIL PROTECTED];# List of references to @array's elements
\*(((@array))); # same
\*(1,2,3); # List of references to @array's elements
\*(((1,2,3))); # same
Opinions?
--Ingo
Re: \(...)?
Hi,
Larry Wall wrote:
The only questions in my mind are whether Perl 5's \($a,$b) is
what people expect (it's arguably counterintuitive to newbies),
and whether there's some other construct that would more naturally
construct a list of references. It's not just \« though, since it
has to *parse* as a list of lvalues. Maybe a siglet can degenerate to
that, but there are problems with that approach too. Unless someone
can come up with a better proposal, \($a,$b) is the default winner
on the basis of prior Perl 5 art.
So...:
[EMAIL PROTECTED];# Ref to array
\(@array); # List of refs to @array's elements, i.e. same as
map { \$_ } @array;
# Weird (violating the parens are only for grouping rule), but
# consistent with Perl 5.
Correct?
--Ingo
--
Linux, the choice of a GNU | Row, row, row your bits, gently down the
generation on a dual AMD | stream...
Athlon!|
Re: \(...)?
Hi,
Juerd juerd at convolution.nl writes:
Ingo Blechschmidt skribis 2005-09-06 21:24 (+0200):
\(@array,) is [ @array ], NOT map { \$_ } @array
I'm not sure of the []s, remember postcirumfix:[ ] creates *new*
containers:
That was the point.
[EMAIL PROTECTED] = $bar;
(@array,)[0] = $bar;
AFAIK, these are the same thing, because the left side of [0] is in
Array context, which is a scalar context, in which comma creates a new
anonymous array ref.
To prevent misconceptions: You think that both
[EMAIL PROTECTED] = $bar; # and
(@array,)[0] = $bar;
change @array[0] to $bar, right?
If so, I have to disagree. Consider:
(my $arrayref = [1,2,3])[1] = 42;
If postcircumfix:[ ] did *not* create new containers, this
statement would fail (Can't modify constant item 2) instead of
setting $arrayref[1] to 42.
Similarily,
(my $arrayref = [$foo])[0] = 42;
would not set $arrayref[0] to 42 and leave $foo untouched, but
would set $foo to 42. I don't think this is correct.
To clarify my view with code: I think postcirumfix:[ ] could
be implemented like this:
sub *postcircumfix:[ ] ([EMAIL PROTECTED]) {
# Explicitly copy @elems:
my @array = @elems;
return [EMAIL PROTECTED];
}
And, presuming that I've understood you correctly, then you
would implement postcirumfix:[ ] like this:
sub *postcircumfix:[ ] ([EMAIL PROTECTED]) {
# Do *not* copy @elems here
return [EMAIL PROTECTED];
}
(But note that I may be completely wrong, of course.)
--Ingo
Re: \(...)?
Hi,
Juerd wrote:
Ingo Blechschmidt skribis 2005-09-09 11:59 (+):
\(@array,) is [ @array ], NOT map { \$_ } @array
I'm not sure of the []s, remember postcirumfix:[ ] creates
*new* containers:
That was the point.
[EMAIL PROTECTED] = $bar;
(@array,)[0] = $bar;
AFAIK, these are the same thing, because the left side of [0] is in
Array context, which is a scalar context, in which comma creates a
new anonymous array ref.
To prevent misconceptions: You think that both
[EMAIL PROTECTED] = $bar; # and
(@array,)[0] = $bar;
change @array[0] to $bar, right?
No, neither does.
[EMAIL PROTECTED] = $bar fills a new array with the elements of @array, and
[then
overwrites the first. The array is then discarded.
Agreed.
(@array,)[0] = $bar does the same, IIRC, because the LHS of .[0] is
object and thus scalar context, possibly specifically Array context,
and the comma operator then behaves as if it has [] around it: it
creates an anonymous array. Again, it's just the elements of @array
that are used.
Ah! I think I got your point now! :)
I agree that the comma operator creates an anonymous array, but I do not
agree that it behaves as if it has [] around it.
Creating an anonymous array does not require creating new containers --
if I've understood things correctly, then the comma operator creates
arrayrefs (in appropriate contexts), but does *not* create new
containers. By contrast, the [] operator always creates arrayrefs
holding new containers.
(The comma operator *may not* create new container containers, because
($foo, $bar)[1] = $baz;
should change $bar to $baz (you reminded me of this property of
infix:, in
http://www.nntp.perl.org/group/perl.perl6.language/22924).)
Now, (@array)[0] = $bar does assign to @array[0].
Of course, as in this case neither the comma operator nor the []
operator is used, the () are only used for grouping.
I think the comma operator in scalar context should not create arrays,
because that is wildly confusing for most people, and a dangerous trap
even for those who do grok it. We already have [] for creating
anonymous arrays, and here a second WTDI isn't buying us anything.
I'd probably agree *if* cirumfix:[ ] and infix:, really did the
same thing (creating arrays containing new containers), but, IIUC,
infix:, does not create new containers while postcirumfix:[ ]
does.
(my $arrayref = [1,2,3])[1] = 42;
[1, 42, 3]. With () for grouping, not lists, and [] working on
references as well as the original, you're assigning to $arrayref[1],
not the nonexistent second element of the nonexistent list.
I agree.
sub *postcircumfix:[ ] ([EMAIL PROTECTED]) {
Do postfix list operators exist in Perl 6? AFAIK, the only thing that
can create a list is list context, and I'm very unsure how anything
that can handle both a list and an item can be postfix.
D'oh, I meant circumfix:[ ], not postcircumfix:[ ].
circumfix:[ ] is the operator used in [1,2,3], postcirumfix:[ ] is
the operator used in @array[$index].
--Ingo
Accessing a list literal by key?
Hi, # Should this work? say (a = 1, b = 2)b; # 2 or error? # Similarily: my @array = (a = 1, b = 2); say @arrayb; my $arrayref = [ a = 1, b = 2 ]; say $arrayrefb; FWIW, I think accessing arrays and arrayrefs by key should probably not work, but I'm unsure on (...)b. (%hash[$numerical_index] is, of course, bogus, as hashes aren't ordered by default.) --Ingo -- Linux, the choice of a GNU | Row, row, row your bits, gently down generation on a dual AMD | the stream... Athlon!|
Re: \(...)?
Hi,
Juerd wrote:
Ingo Blechschmidt skribis 2005-09-09 15:12 (+0200):
I agree that the comma operator creates an anonymous array, but I do
not agree that it behaves as if it has [] around it.
Creating an anonymous array does not require creating new containers
--
So comma in scalar context creates an array of aliases?
Exactly! :)
(Presuming that I understood things correctly, of course.)
That would be a welcome difference.
I like that behaviour, too. :)
should change $bar to $baz (you reminded me of this property of
infix:, in
Infix? Infix operators are binary, comma is not.
I took the name from Pugs's PIL. The signature of infix:, is ([EMAIL
PROTECTED]),
so it isn't strictly binary, of course.
I think the name infix:, is based on the names of the chained
comparators:
1 2 3; # is really
infix:{}(1, 2, 3);
(This is, as far as I know, not specced. Take it as an report on Pugs's
internals.)
--Ingo
--
Linux, the choice of a GNU | Row, row, row your bits, gently down
generation on a dual AMD | stream...
Athlon!|
Re: \(...)?
Hi, Larry Wall wrote: On Fri, Sep 09, 2005 at 04:40:11PM +0200, Juerd wrote: : Ingo Blechschmidt skribis 2005-09-09 15:12 (+0200): : I agree that the comma operator creates an anonymous array, but I : do not agree that it behaves as if it has [] around it. : : Creating an anonymous array does not require creating new : containers -- : : So comma in scalar context creates an array of aliases? That would : be a welcome difference. It might at that. Though doubtless there is a downside I'm not seeing yet... ($foo, $bar) = ($grtz, $baka); say $foo, $bar; # newbieHm, $foo and $bar are changed to $grtz respectively # $baka... So assigning to a list really assigns to the # elements of the list! So the comma operator constructs # a list of aliases, neat! # Now let's see whether the following works as well: ($foo, $bar)[0] = $grtz; # Ok, no error message. say $foo; # ...but why was $foo not changed? # I thought the comma operator constructs a list of # aliases...?/newbie Also note that the comma operator creating a list of aliases does *not* affect regular [...] or assignment to an array: (1,2,3)[1]++; # Can't modify constant item 2 my @a = (1,2,3); # @a's STORE method recognized that the RHS # is an aggregate, so it created new containers. @a[1]++; # No error say @a[1];# 3 [1,2,3][1]++; # No error, circumfix:[ ] assigned to an # array internally, so new containers were # created. --Ingo -- Linux, the choice of a GNU | Row, row, row your bits, gently down generation on a dual AMD | the stream... Athlon!|
\(...)?
Hi,
# Perl 5
my @array_of_references = \($foo, $bar, $baz);
print [EMAIL PROTECTED];# prints 3
print ${ $array_of_references[1] }; # prints $bar
# Perl 6
my @array = \($foo, $bar, $baz);
say [EMAIL PROTECTED];
# 3 (like Perl 5)?
# Or 1, making \(...) similar to [...]?
If \(...) still constructs a list of references, are the following
assumptions correct?
\(@array); # same as
[EMAIL PROTECTED];
# (As () is only used for grouping in this case.)
# Correct?
\(@array,); # same as
map { \$_ } @array;
# (As postcircumfix:{'\\(', ')'} is called here.)
# Correct?
--Ingo
--
Linux, the choice of a GNU | Row, row, row your bits, gently down
generation on a dual AMD | the stream...
Athlon!|
Re: \(...)?
Hi,
Juerd wrote:
Ingo Blechschmidt skribis 2005-09-06 19:46 (+0200):
If \(...) still constructs a list of references, are the following
assumptions correct?
IIRC, the RHS of \ is in scalar context, and the comma in scalar
context (the parens are just for precedence), creates an arrayref.
Which is interesting (and imho, a bad idea), because:
\(@array); # same as
\(@array) and [EMAIL PROTECTED] are the same thing
Agreed.
\(@array,); # same as
\(@array,) is [ @array ], NOT map { \$_ } @array
I'm not sure of the []s, remember postcirumfix:[ ] creates *new*
containers:
[EMAIL PROTECTED] = $bar;
# @array[0] unchanged
Compare this to:
(@array,)[0] = $bar;
# @array[0] changed to $bar
So, I think, if we ditch Perl 5's special \(...),
\(@array,); # should be the same as
\do { (@array,) };
This has the consequence that
(\(@array,))[0] = $bar;
changes @array[0].
--Ingo
--
Linux, the choice of a GNU | Mr. Cole's Axiom: The sum of the
generation on a dual AMD | intelligence on the planet is a constant;
Athlon!| the population is growing.
our constant pi, my constant pi?
Hi, quick questions: constant pi = 3; # works # Is pi package- or lexically-scoped? our constant pi = 3; # legal? my constant pi = 3; # legal? This is consistent with sub foo, our sub foo, and my sub foo, which are all allowed. --Ingo -- Linux, the choice of a GNU | Row, row, row your bits, gently down the generation on a dual AMD | stream... Athlon!|
multisub.arity?
Hi,
multi foo ($a) {...}
multi foo ($a, $b) {...}
say foo.arity;
# die? warn and return 0? warn and return undef? return 1|2?
--Ingo
--
Linux, the choice of a GNU | There are no answers, only
generation on a dual AMD | cross-references.
Athlon!|
undef but 1..2?
Hi,
Larry Wall wrote:
On Fri, Sep 02, 2005 at 05:56:39PM +0200, Ingo Blechschmidt wrote:
: multi foo ($a) {...}
: multi foo ($a, $b) {...}
:
: say foo.arity;
: # die? warn and return 0? warn and return undef? return 1|2?
How 'bout undef but 1..2? :-)
Interesting, but now you have to elaborate a bit. :)
I've thought there're two forms of the but operator:
my $foo = Foo.new but {
.bar($baz);
.grtz = baka;
};
$obj but SomeRole;
# leaves $obj untouched and returns $obj with the SomeRole role
# incorporated, i.e. .does(SomeRole) is true then
0 but true; # is really
0 but bool::true # works, as bool::true is a role
0 but 42; # error: Can't use 42 as a role
Ok. But what about undef but 1..2? 1..2 isn't a role, right? So how can
infix:but work with it?
--Ingo, who has probably misunderstood your :-) :)
--
Linux, the choice of a GNU | The future is here. It's just not widely
generation on a dual AMD | distributed yet. -- William Gibson
Athlon!|
for $arrayref {...}
Hi,
my $arrayref = a b c;
for @$arrayref {...};# loop body executed three times, of course
for ($arrayref,) {...}; # loop body executed only one time
for ($arrayref) {...}; # loop body executed one or three times?
for $arrayref {...}; # loop body executed one or three times?
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
@array = $scalar
Hi, @array = $scalar;# really means @array = ($scalar,); # same as @array = (); @array[0] = $scalar; # Correct? @array = $arrayref; # really means @array = ($arrayref,); # same as @array = (); @array[0] = $arrayref; # thus say [EMAIL PROTECTED]; # always 1 # Correct? --Ingo
Re: Binding of array elements
Ingo Blechschmidt wrote: Then we wondered what should happen to array elements which are bound to other variables if some things happen to the array. (Of course, the same thoughts apply to hashes as well). Two more questions: * @array[$out_of_bounds_index] := $var; # Fatal error (Can't rebind non-existant container)? # Or autovivify @array[$out_of_bounds_index]? * @foo[$idx] := $var; my @bar = @foo; $var= $new_var; # @foo[$idx] and $var are now $new_var, but @bar is unchanged, right? --Ingo -- Linux, the choice of a GNU | We are Pentium of Borg. Division is futile. generation on a dual AMD | You will be approximated. Athlon!|
Does list construction create new containers?
Hi, * my @array = a b c d; @array[1] = new; # Array elements are, of course, new (rw) containers. * my @array = ($foo, $bar); @array[0] =:= $foo; # False -- array element are new containers. @array[0] = $baz; # $foo unchanged I think these semantics are pretty clear. But what about lists? ($foo, $bar)[0] =:= $foo; # False (i.e. no difference to arrays) or true? --Ingo -- Linux, the choice of a GNU | How to become immortal: Read this signature generation on a dual AMD | tomorrow and follow its advice. Athlon!| —-Holger Uhr
Using lists containing arrays as lvalues
Hi, (sorry for me going into implementation details, but, as it's really a language design question, I refrained from sending this to p6c.) While trying to make the following work in PIL2JS... my ($head, @tail) = foo(); it occured to me that this is bogus, or at least hard to implement. Without help from the grammar/macros, this translates to the following in PIL: my ($head, @tail); infix:,($head, @tail) = foo(); infix:, is the sub which create lists, e.g. (1,2,3) is really infix:,(1,2,3). Therefore, infix:, has a signature of ([EMAIL PROTECTED]), but this (of course) causes @tail to be flattened before it reaches infix:,, causing the statement not to DWIM. (This corresponds to (@foo, @bar) in Perl-space, which does not evaluate to a list with two elements, but to a list containing @[EMAIL PROTECTED] elements (think @foo.append(@bar))). I see two possible solutions: 1) Make it work -- we'll use macros, help from the grammar, or some other technique to make it work. 2) We ask people to use the more clear my ($head, [EMAIL PROTECTED]) := foo(); I.e. we use binding's property that the LHS is a subroutine signature. (Note that I do not talk about the LHS being a list of scalars (e.g. ($a, $b, $c) = foo()), this post only speaks about using lists containing @arrays as lvalues). If we generally recommend this solution especially to newbies, it has got the additional property that my ($foo, $bar) := foo(); will fail if foo returns more than two things (instead of silently discarding any additional arguments, i.e. assuming my ($foo, $bar, [EMAIL PROTECTED]) := foo(); Opinions? -- Linux, the choice of a GNU | Row, row, row your bits, gently down the generation on a dual AMD | stream... Athlon!|
Re: Does list construction create new containers?
Hi,
Yuval Kogman wrote:
On Sat, Aug 27, 2005 at 17:38:26 +0200, Ingo Blechschmidt wrote:
($foo, $bar)[0] =:= $foo;
# False (i.e. no difference to arrays) or true?
I think this is true, because you can say:
($foo, $bar) = (1, 2);
And more curiously:
for ($foo, $bar) { $_ = Value }; # implcit is rw
for ($foo, $bar) - $bah { $bah = Value }; # not is rw... is
# it a different elem? or the same elem with behavior changed
# for this scope?
I'd say (and this is how it's implemented in PIL2JS currently [1]) it's
the same element, but wrapped in a proxy which dies on STORE requests.
I.e.:
for ($foo, $bar) - $bah { $bah = Value } # is really
for ($foo, $bar) - $bah is rw {
(new Proxy:
FETCH = { $bah },
STORE = { die Can't modify readonly... },
) = Value;
}
If flattenning becomes involved, then it gets harder to decide:
($foo, @array)[2] =:= @array[1]; # i don't know about this
($foo, [EMAIL PROTECTED])[2] =:= @array[1]; # i think this is definately false
Hm, I'd say both are true. Consider:
my $var;
sub foo ([EMAIL PROTECTED]) { @args[0] =:= $var };
foo($var, $other, $stuff);
# Should definitely be true, I think.
--Ingo
[1] FYI, here's the relevant snippet of PIL2JS's subroutine signature
handling code ([2], lines 263-265):
unless($self-{tpParam}{isWritable}) {
push @js, $jsname = new PIL2JS.Box.ReadOnly($jsname);;
}
[2] http://svn.openfoundry.org/pugs/perl5/PIL2JS/lib/PIL/Params.pm
--
Linux, the choice of a GNU | The computer revolution is over. The
generation on a dual AMD | computers won. -- Eduard Bloch
Athlon!|
Re: Binding of array elements
Hi, Yuval Kogman wrote: On Sat, Aug 27, 2005 at 14:29:29 +0200, Ingo Blechschmidt wrote: * @foo[$idx] := $var; my @bar = @foo; $var= $new_var; # @foo[$idx] and $var are now $new_var, but @bar is unchanged, # right? Yes, I agree. But we do need a way in the middle. Right now we have: @bar := @foo; # array container aliased, so all nested containers are shared @bar = @foo; # array structure duplicated, elem containers duplicated but no way to say all the elements are the same, but the structure isn't. Maybe this works, but I don't think so since assignment isn't an operator, but a syntactic construct (i think): @bar := @foo; I like this very much! :) Additionally, if we allow hyperizing = and :=, we could get rid of the special lists-as-lvalues magic: # If you had previously written ($foo, $bar) = ($grtz, $baka); # you'd now write ($foo, $bar) »=« ($grtz, $baka); (But, FWIW, I kind of like the special lists-as-lvalues magic.) --Ingo -- Linux, the choice of a GNU | In Nature there are neither rewards nor generation on a dual AMD | punishments, there are consequences. Athlon!| -- R.G. Ingersoll
Re: Using lists containing arrays as lvalues
Hi, Yuval Kogman wrote: On Sat, Aug 27, 2005 at 19:16:55 +0200, Ingo Blechschmidt wrote: my ($head, [EMAIL PROTECTED]) := foo(); if foo returns a list of scalars =2 this is like parameter unpacking: my ($head, [EMAIL PROTECTED]) = *foo(); [...] Right, but I wanted to drive at the difficulty of making this work, sorry if I was unclear. ($head, [EMAIL PROTECTED]) := foo(); # (Note: := here, not =) This is not a problem, because :='s LHS is a subroutine signature, which means the necessary magic is already there. But there is a problem with the ordinary assignment form: ($head, @tail) = foo(); If the LHS is an ordinary list (i.e., if we don't use help from the grammar/macros), then the @tail would get flattened before it reached the assignment operator. This is turn would cause the statement not to DWIM: my ($head, @tail) = foo(); # is really my ($head, @tail); ($head, @tail) = foo(); # is really (as @tail is empty) ($head, ())= foo(); # is really ($head)= foo(); # is really $head = foo(); # !!! for this I think we need an easier solution... Perhaps flattenning foo instead of adding a slurp, or making yadda yadda in lvalue throw it's arguments away silently: my ($foo, $bar, ...) := foo(); I like that! :) --Ingo -- Linux, the choice of a GNU | self-reference, n. - See self-reference generation on a dual AMD | Athlon!|
Re: Perl 6 code - a possible compile, link, run cycle
Hi,
Yuval Kogman wrote:
On Thu, Aug 25, 2005 at 11:16:56 -, David Formosa (aka ? the
Platypus) wrote:
On Wed, 24 Aug 2005 16:13:03 +0300, Yuval Kogman
[EMAIL PROTECTED] wrote:
perl6 creates a new instance of the perl compiler (presumably an
object). The compiler will only compile the actual file 'foo.pl',
and disregard any 'require', 'use', or 'eval' statements.
use has the potentional to change the way the compiler
parses the code. So use needs to be regarded.
Hmm... Good point.
I don't know how this is dealt with WRT to the every module is
compiled with it's own compiler approach perl 6 is supposed to
have.
The indermediate form of a compiled .pm has to have a section containing
information about the symbols exported by the module, similar to
today's pilGlob section Pugs gives you if you use -CPIL, -CPerl5, or
-CJSON:
$ pugs -CPerl5 -we 'sub foo {...}' | \
perl -MYAML -we 'print Dump(eval )'
--- !perl/PIL::Environment
pilGlob:
[...]
- !perl/PSub
pSubBody: PNil
pSubLValue: 0
pSubName: 'main::foo'
pSubParams: [...]
pSubType: SubRoutine
pilMain: !perl/PStmts
pStmt: PNoop
pStmts: PNil
This section will contain all information needed:
* User-defined operators
* Other symbols exported by is export
* Exported macros
Note that *none* of these things influence the compilation of other .pls
and .pms unless they're exported. I.e.:
# Foo.pm
module Foo {
sub infix:+ ($a, $b) { 42 }
say 1 + 1; # 42
}
# Exported symbols: ::Foo
# test.pl
use Foo;
say 1 + 1; # 2
# Bar.pm
module Foo {
sub infix:+ ($a, $b) is export(:DEFAULT) { 42 }
say 1 + 1; # 42
}
# Exported symbols: ::Foo, infix:+
# test.pl
use Bar;
say 1 + 1; # 42
--Ingo
--
Linux, the choice of a GNU | We are Pentium of Borg. Division is futile.
generation on a dual AMD | You will be approximated.
Athlon!|
Re: Perl 6 code - a possible compile, link, run cycle
Hi, Yuval Kogman wrote: On Thu, Aug 25, 2005 at 15:42:28 +0200, Ingo Blechschmidt wrote: This section will contain all information needed: * User-defined operators * Other symbols exported by is export * Exported macros Okay, this raises a distinction: Compile time exports Runtime exports Well, all exports happen at compile-time, but you're right, some exports (regular subs) will probably not be used before runtime. If I compile foo.pl, which uses SomeModule, and SomeModule exports stuff at compile time, and foo.pl's object code is saved, what happens when SomeModule is upgraded? Right. If you upgrade your glibc to an ABI-incompatible version, things will probably break. But, as you say, we can... try to link the runtime symbols anyway, the user expects it to work try to recompile foo.pl if it's source code is available when compiling foo.pl, prelink SomeModule's runtime symbols into it, to ensure that no other version of SomeModule can affect foo.pl's emitted code. This can be a recursive or non recursive process. --Ingo -- Linux, the choice of a GNU | Mr. Cole's Axiom: The sum of the generation on a dual AMD | intelligence on the planet is a constant; Athlon!| the population is growing.
Binding of array elements
Hi,
with PIL-Run (Perl 6 to Perl 5 compiler) progressing rapidly, the topic
binding came up on #perl6.
Binding is a simple symbol table manipulation, right?
No, consider @array[$idx] := $var or more generally
$sub(@args) := $var.
Then we wondered what should happen to array elements which are bound to
other variables if some things happen to the array. (Of course, the
same thoughts apply to hashes as well).
Consider an element @array[$idx] being bound to a variable $var, i.e.
@array[$idx] := $var;
After the binding, what happens if you do...
* @array[$idx] = $new_value;
# $var is now $new_value
* @array.delete($idx);
# $var unchanged, but assigning to $var doesn't modify @array any
# longer; similarily, changing @array[$idx] doesn't modify $var now.
* @array = ();
# $var unchanged, but assigning to $var doesn't modify @array any
# longer; similarily, changing @array[$idx] doesn't modify $var now.
* @array := @other_array;
# $var unchanged, but assigning to $var doesn't modify @array any
# longer; similarily, changing @array[$idx] doesn't modify $var now.
* sub foo (@arr) { @arr[$idx] = $new_value }
foo @array;
# $var and @array[$idx] are now $new_value
* sub bar (Array $arr) { $arr[$idx] = $new_value }
foo @array;
# $var and @array[$idx] are now $new_value
* sub grtz ([EMAIL PROTECTED] is rw) { @args[$idx] = $new_value }
grtz @array;
# $var and @array[$idx] are now $new_value
* sub baka ([EMAIL PROTECTED]) { push @args, $some_value }
baka @array;
# $var, @array[$idx] and @array unchanged
Sane?
* What happens if @array gets spliced?
More precisely, does splice call .delete before changing an array
element? I.e. does splice call...
@array.delete($some_index); @array[$some_index] = $some_value;
# or
@array[$some_index] = $some_value;
* What happens if the array becomes tied (or was already)?
--Ingo
--
Linux, the choice of a GNU | The computer revolution is over. The
generation on a dual AMD | computers won. -- Eduard Bloch
Athlon!|
Calling positionals by name in presence of a slurpy hash
Hi,
(asking because a test testing for the converse was just checked in to
the Pugs repository [1])
sub foo ($n, *%rest) {...}
foo 13;
# $n receives 13, of course, %rest is ()
foo 13, foo = bar;
# $n receives 13 again, %rest is (foo = bar)
foo n = 13;
# $n receives 13, %rest is (), right?
foo n = 13, foo = bar;
# $n receives 13, %rest is (foo = bar), right?
--Ingo
[1] http://svn.openfoundry.org/pugs/t/subroutines/slurpy_param.t
--
Linux, the choice of a GNU | Row, row, row your bits, gently down the
generation on a dual AMD | stream...
Athlon!|
Re: ~ and + vs. generic eq
Hi,
Yuval Kogman wrote:
I think this is more consistent, and just as useful:
10 == 10; # dispatches to num
10 == 10; # dispatched to Num, by means of coercion (== has some
affinity to it for backwards compatibility) 10 == 10; # dispatches
to Str, due to better match 10.0 == 10; # unlike perl 5 this is
false 10.0 +== 10; # but this is true
10 ~== 10; # like eq
sorry, I've some problems with this proposal:
== has always meant numeric equality in Perl and I'd like it to stay
that way.
More importantly, the distinction between +== and ~== is far too subtle,
I think -- the two long =s kind of hide the +~?. You have to look more
carefully to see the distinction between +== and ~==; == vs. eq is much
more apparent, IMHO.
Oh and +== isn't as good huffmanized as == is.
The matchic MMD generator in the prelude, that makes the complex
set of rules found in s04 should simply apply to any infix operator
(and should be applied in the prelude to ~~, as well as ==), so that
~~ and == on collections are defined with the same aggregate
semantics, but MMD ~~ or == applies to the nested elements in the
same shape:
sub extend_comparators (op) {
[...]
I think I like that idea, although I have to admit that I might have not
understood it fully.
I wonder whether it's possible to use an adverbial modifier to specify
the comparator:
say @foo ~~ @bar; # is really
say @foo ~~ @bar :comparator{ $^a ~~ $^b };
say @foo ~~ @bar :comparator{ $^a eq $^b };
say @foo ~~ @bar :comparator{ $^a == $^b };
--Ingo
--
Linux, the choice of a GNU | The future is here. It's just not widely
generation on a dual AMD | distributed yet. -- William Gibson
Athlon!|
use language_with_different_indentifier_syntax:...
Hi, on #perl6, we were wondering how to use() modules from foreign languages which have an incompatible identifier syntax. E.g.: use perl5:Foo::Bar; # fine, no problem # Load JavaScript modules from JSAN use jsan:Test.Simple; # should we simply accept the dot, or... use jsan:Test::Simple; # ask users to write this? --Ingo
Re: Symbolic dereferentiation of magical variables
Hi,
Larry Wall wrote:
On Sat, Aug 20, 2005 at 10:33:03PM +, Ingo Blechschmidt wrote:
: S02 says:
: our $a; say $::(a); # works
:
: my $a; say $::(a); # dies, you should use:
: my $a; say $::(MY::a); # works
That looks like somebody's relic of Perl 5 thinking. Personally,
I don't see why the second one should die. I was kind of hoping
that symbolic lookups would include lexicals in Perl 6, unlike in
Perl 5. Then you use MY or OUR to force it one way or the other.
I like that very much! :)
: How can I use symbolic dereferentiation to get $?SELF, $?CLASS,
: ::?CLASS, %MY::, etc.?
:
: say $::('$?SELF');# does this work?
Probably not, since the ::() notation doesn't want sigils in the key,
and you have to say
$?::('SELF')
to have any hope of it working. On the other hand
%MY::$?SELF
might get you the symbol out of the symbol table hash,
ok.
unless $?SELF is too macro-y for that. $? variables aren't required
to have a dynamically lookupable meaning at run time, since their
native dynamic context is the compiler, not the run-time.
Makes perfect sense.
: say $::('MY::$?SELF');# or this?
No, we don't currently allow sigils after ::.
I took that straight from S02 :):
All symbolic references are done with this notation:
$foo = Foo;
$foobar = Foo::Bar;
$::($foo) # package-scoped $Foo
$::(MY::$foo) # lexically-scoped $Foo
$::(*::$foo) # global $Foo
$::($foobar)# $Foo::Bar
$::($foobar)::baz # $Foo::Bar::baz
$::($foo)::Bar::baz # $Foo::Bar::baz
$::($foobar)baz # ILLEGAL at compile time (no operator baz)
and such.) I think I like the option lowering the sigil to the key.
Maybe the outer sigil is meaningless in that case, and it's just
OUTER::OUTER::$_
But if we say that any package/type name can tagmemically function
as a hash if you use like one, then the last :: can go too:
OUTER::OUTER$_
OUTER::OUTER{'$_'}
I like those, especially as we've said that the sigils are part of the
variable name.
Though we're getting close to confusing this notation with
%OUTER::OUTER::{'$_'}
which looks similar, but (if we take the Perl 5 meaning) doesn't
do :: splitting on the key. In other words, this would also get
to OUTER::OUTER$_:
OUTER{'$OUTER::_'}
because it's accessing through the package as a hash and does further
:: breakdown. But this wouldn't work:
%OUTER::{'$OUTER::_'}
because it's accessing through the actual symbol table hash, which
doesn't have any such symbol as one of its keys.
That's an awfully subtle distinction, though. I think OUTER::OUTER's
symbol table hash needs a better name than %OUTER::OUTER. Maybe it's
named OUTER::OUTER%OUR or OUTER::OUTER::%MY or some such.
Makes sense.
Which makes me think that Perl 5's %FOO::{'name'} symbol table
notation is really bogus, because %OUTER:: doesn't really refer to a
single symbol table in Perl 6, but the starting place for a symbol
search that may span several symbol tables.
If we go with these changes, this functionality (starting place for a
search) would be available by using
Foo::Bar$symbol_to_lookup; # right?
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
Re: Can a scalar be lazy ?
Hi,
Yiyi Hu wrote:
my( $s, $t ); $s = value t is $t; $t = xyz; print $s;
in perl 5, it will give a warning, and won't do right thing.
we have to use other way or eval '$s' before print to get a correct
answer.
So I wonder, If we can make $scalar lazy also. As array now is lazy by
default.
there're at least three different ways which do want you want:
# Using a closure
my $s = { value t is $t };
# And then
say $s();# Note the ()
# Using Proxy
my $s := new Proxy: FETCH = { value t is $t };
# And then
say $s; # Note no ()
# With nothingmuch's lazy proposal (implemented in Pugs)
my $s := lazy { value t is $t };
say $s; # Again, no () needed
BTW, does Proxy fill in an appropriate default if one misses STORE? I.e.
new Proxy: FETCH = { foo }; # same as
new Proxy:
FETCH = { foo },
STORE = {
die No STORE block...;
};
--Ingo
--
Linux, the choice of a GNU | The next statement is not true.
generation on a dual AMD | The previous statement is true.
Athlon!|
Re: Serializing code
Hi,
Yuval Kogman nothingmuch at woobling.org writes:
On Sat, Aug 20, 2005 at 22:27:56 +, Ingo Blechschmidt wrote:
Not code, but the return value of code.emit
Hm, Str? Or possibly a subtype of Str, allowing:
I would guess an AST, that is, any object, that implements
stringification.
the AST could just be the same PIL reblessed with some new
serialization magic, but I guess for most languages you want to make
a real AST to AST conversion, and only then serialize.
Even better :)
But we should note that some backends don't generate meaningful
ASTs, simply because they don't convert PIL - target language
AST - target language, but PIL - target language directly. I.e.
my $ast = $code.emit(..., :languageFoo);
say keys $ast; # FooCode
say $astFooCode; # ...
my $ast = { 3 + 4 }.emit(..., :languagePIL);
say $ast.pBody.pStmt.pExpr.pLV.pArgs[1].pLit.pVal; # 4
Ah. Normal globals can probably be freezed more or less exactly
like normal lexical variables, I don't see a big problem there.
The question is - should globals be frozen? Or should they
optimistically refer to values on the other side?
I think that
sub hello {
$*DOM.document.write(pHello World!/p);
}
should capture $*DOM in the same sense that a closure matches them,
and the global scope is implicitly the uber-parent lexical scope
type thingy.
Then, once we've unified, we can steal something from C and friends:
$*DOM is external;
sub hello {...} # $*DOM is not serialized, but will be resolved
# by the runtime on the other side
Anybody got ideas on how control is needed, and how it should be
specified?
Hm, I think the $*DOM thing could be solved quite elegantly:
There could be a module JavaScript::Browser or so, which would
export $*DOM. I.e.:
#!/usr/bin/pugs
$*DOM.document.write(...);
# Compile-time error: $*DOM not declared
#!/usr/bin/pugs -BParrot
use JavaScript::Browser $*DOM;
$*DOM.document.write(...);
# error: $*DOM does only work when running in a browser
#!/usr/bin/pugs -CJS
use JavaScript::Browser $*DOM;
$*DOM.document.write(...);
# fine now
This exported $*DOM object could then be a (proxy) object with
appropriate magic -- i.e. die when the current runtime is not
a browser and relay all calls to the respective native JavaScript
objects otherwise.
I think something like $*DOM is exported is too generic,
not sure...
The code itself isn't much a problem, much more problematic
are access to outer lexical variables:
my $a = ...;
my $b = { ...$a... };
$b();
Right... It is my assumption that actually serializing this is
trivial. The real question is whether we want to serialize, and
what parts we would like to serialize when we do.
Hm, probably we should serialize all variables which are not
specifically marked as objects which should not be freezed (e.g.
$*DOM).
--Ingo
--
Linux, the choice of a GNU | There are no answers, only
generation on a dual AMD | cross-references.
Athlon!|
Re: *%overflow
Hi,
Luke Palmer wrote:
sub foo (+$a, *%overflow) {
say %overflow{};
}
foo(:a(1), :b(2)); # b2
foo(:a(1), :overflow{ b = 2 }); # b2
I'd think so, too.
foo(:a(1), :overflow{ b = 2 }, :c(3)); # ???
Error: Too many arguments passed to foo?
Presuming that multiple *%slurpy_hashes are allowed, I'd say that...
sub bar (+$a, *%overflow, *%real_overflow) {
say [%overflow{}] [%real_overflow{}];
}
bar(:a(1), :overflow{ b = 2 }); # [b2] []
bar(:a(1), :overflow{ b = 2 }, :c(3)); # [b2] [c3]
But it seems to be cleaner to disallow multiply *%slurpies and just go
with the error.
--Ingo
--
Linux, the choice of a GNU | The future is here. It's just not widely
generation on a dual AMD | distributed yet. -- William Gibson
Athlon!|
Re: Serializing code
Hi,
Yuval Kogman nothingmuch at woobling.org writes:
On Thu, Aug 18, 2005 at 12:24:40 +, Ingo Blechschmidt wrote:
Yuval Kogman nothingmuch at woobling.org writes:
So now that the skeptics can see why this is important, on the
design side I'd like to ask for ideas on how the code serialization
looks...
sub { $?DOM.document.write(phello world!/p) }.emit(
:runtime($browser_autodetect_object),
# this can be guessed by asking the $runtime object:
# :languagejavascript,
);
This is superficially nice,
Indeed!
but here's what's missing:
[...]
- what exactly is a code object?
- a wrapper for some PIL code
- that can be executed by the runtime
Code objects may as well be executed at compile-time
(think macros, use and BEGIN blocks), but...:
But it's still the runtime that runs them
Compilation has a runtime that runs the compiler, and compile-time
code. The output may be handed down to another runtime that actually
runs.
Oh, right, of course. I misread that.
Well, you call code.emit above, so it's probably a Code
object, even though it calls subs and methods from the
Perl6::Internals namespace (or somesuch).
Not code, but the return value of code.emit
Hm, Str? Or possibly a subtype of Str, allowing:
$template.param(globaljs)= $emitted.global_section;
$template.param(js_of_a_div) = $emitted.main_section;
Of course, these additional methods wouldn't be available for
all backends.
- handling of data
- types of:
- globals?
I've probably misunderstood you, but can't globals, like all
other variables, have any type you want them to have?
Not types in the kind of value type... Read it as:
handling of data... what types of data... global variables are
types of data
Ah. Normal globals can probably be freezed more or less exactly
like normal lexical variables, I don't see a big problem there.
WRT pads: Luckily, pads are constant, i.e. you can't inject
a new lexical variable at runtime (%MY::new_var = ...).
The backend does have to take care of read accesses, of course
(think $CALLER::, $::(...), %MY::, %OUR::, etc.).
FYI, this is how PIL2JS handles this currently:
my $foo; # is really
my $foo; %MY::foo := $foo;
sub foo {...}; # is really
sub foo {
my %MY:: = ();
push @*CURRENT_SUBPADS, %MY::;
LEAVE { pop @*CURRENT_SUBPADS };
...;
}
- closures?
A subclass of Code, e.g. Bare.
How are they stored?
The code itself isn't much a problem, much more problematic
are access to outer lexical variables:
my $a = ...;
my $b = { ...$a... };
$b();
A backend can then either use the native closure support of the
runtime it targets (if existing) or it has to lambda lift, i.e.
my $b = { ...$a... }; # is really
my $b = - $a { ...$a... };
$b(); # is really
$b($a);
I'd like to have a pragma to switch between these policies.
I doubt a pragma is enough - we need full introspection and fine
grained control for this, both in the lexical and the dynamic
scopes.
Even better! :)
--Ingo
--
Linux, the choice of a GNU | The computer revolution is over. The
generation on a dual AMD | computers won. -- Eduard Bloch
Athlon!|
Symbolic dereferentiation of magical variables
Hi,
S02 says:
our $a; say $::(a); # works
my $a; say $::(a); # dies, you should use:
my $a; say $::(MY::a); # works
How can I use symbolic dereferentiation to get $?SELF, $?CLASS,
::?CLASS, %MY::, etc.?
say $::('$?SELF');# does this work?
say $::('MY::$?SELF');# or this?
Also, is $::! valid syntax? (Or am I required to write this as
$::(!)?)
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
Re: Serializing code
Hi,
Yuval Kogman nothingmuch at woobling.org writes:
So now that the skeptics can see why this is important, on the
design side I'd like to ask for ideas on how the code serialization
looks...
sub { $?DOM.document.write(phello world!/p) }.emit(
:runtime($browser_autodetect_object),
# this can be guessed by asking the $runtime object:
# :languagejavascript,
);
This is superficially nice,
Indeed!
but here's what's missing:
[...]
- what exactly is a code object?
- a wrapper for some PIL code
- that can be executed by the runtime
Code objects may as well be executed at compile-time
(think macros, use and BEGIN blocks), but...:
sub foo { $?DOM.document.write(...) }
BEGIN { foo() }; # error, there's no $?DOM object
# at compile-time!
- what exactly is code.emit
- also an object?
Well, you call code.emit above, so it's probably a Code
object, even though it calls subs and methods from the
Perl6::Internals namespace (or somesuch).
- handling of data
- types of:
- globals?
I've probably misunderstood you, but can't globals, like all
other variables, have any type you want them to have?
- closures?
A subclass of Code, e.g. Bare.
- two examples of data sharing policies:
- the border between the webapp and the browser is
smudged by serialization and proxy objects
- the border between the webapp and the browser is
clear
and distinct, and calls between the two are done by
explicitly invoking one runtime from the other
I'd like to have a pragma to switch between these policies.
--Ingo
Re: scopes of $?SELF and $?CLASS
Hi,
Stevan Little wrote:
So, onto my question, I am wondering what are the valid scopes for
$?SELF and $?CLASS.
Are these (magical) globals who only have bound values in certain
contexts? If that is so, what value do they have outside of a valid
context? undef? or is attempting to accessing the value a runtime
exception?
hm, I've thought of these as follows:
class Foo {...}# is really
class Foo {
my $?CLASS := Foo;
...;
}
method bar($self:) {...} # is really
method bar($self:) {
my $?SELF := $self;
...;
}
The obvious one is that they are both valid within a method. I asumme
that $?SELF is bound to the invocant, and $?CLASS is bound to the
class the method was defined within. It seems to me that this also
mean that in a class method, that $?SELF == $?CLASS?
I think so, too.
Also (IIRC) we discussed $?CLASS being valid inside a class Foo { ...
} block at the hackathon. Would mean that something like this should
be possible.
class FooLoggerProxy is Foo {
has Logger $.logger;
for ($?CLASS.meta.superclasses()) - $super {
for ($super.meta.getmethods()) - $method {
$?CLASS.meta.add_method($method.label = method {
$?SELF.logger.log($method.label ~ has been
called); return $method.do([EMAIL PROTECTED])
});
}
}
}
I'd opt for yes.
I am not sure if there are any other valid contexts other than inside
a method or a class composition block. At least none that I can think
of.
role, submethod?
--Ingo
--
Linux, the choice of a GNU | Mathematicians practice absolute freedom.
generation on a dual AMD | -- Henry Adams
Athlon!|
Ambiguity of parsing numbers with underscores/methods
Hi, 1_234; # surely 1234 1e23; # surely 1 * 10**23 1._5; # call of method _5 on 1? 1._foo; # call of method _foo on 1? 1.e5; # 1.0 * 10**5? 1.efoo; # call of method efoo on 1? 1.e_foo;# call of method e_foo on 1? 0xFF.dead; # call of method dead on 0xFF? --Ingo -- Linux, the choice of a GNU | Elliptic paraboloids for sale. generation on a dual AMD | Athlon!|
Re: BEGIN {...} and IO
Hi,
Nicholas Clark wrote:
On Tue, Jun 14, 2005 at 07:56:32PM +0200, Ingo Blechschmidt wrote:
Maybe we should just hardcode the filehandles-leaking-into-runtime
case in the compiler? And, if the compiler can't detect the problem
at compile-time, just throw a runtime exception?
my $fh = BEGIN { open some_file };
=$fh; # Can't readline() on unopened filehandle leaked
# from compile-time into runtime, try to...
Aren't filehandles just part of a more general case of the compiler
serialising something out to the bytecode on disk that can't actually
be serialised? So the attempt at serialisation of a file handle,
directory handle, database handle, shared memory handle or any other
external resource should fail? (Unless that resource class has a
viable serialise/deserialise system)
yep. So my question is: How can I tell the Perl 6 compiler how it can
serialize my special object? How can I ask it to not serialize my
special object?
BTW, is it even necessary to support user-defined serializing
behaviours? (After all, an Item can only be an Int, Num, Str, Ref, Bit,
Pair, Junc, Type, Code, Undef, and Object in PIL2 [1].)
--Ingo
[1] http://svn.openfoundry.org/pugs/src/PIL/Val.hs
--
Linux, the choice of a GNU | Row, row, row your bits, gently down the
generation on a dual AMD | stream...
Athlon!|
Various questions on .ref and .meta
Hi, ~Str;# class? Str? ~::Str; # class? Str? ~Str.meta; # class? (fill in please)? ~::Str.meta; # class? (fill in please)? +Str; +::Str; +Str.meta; +::Str.meta; # all errors? ?Str; ?::Str; ?Str.meta; ?::Str.meta; # all true? Str =:= ::Str; # true? some string.ref =:= Str; # true? Str.ref; # (fill in please) ::Str.ref; # (fill in please) Str.meta.ref;# (fill in please) ::Str.meta.ref; # (fill in please) Str.ref.ref; # (fill in please) ::Str.ref.ref; # (fill in please) --Ingo -- Linux, the choice of a GNU | The future is here. It's just not widely generation on a dual AMD | distributed yet. -- William Gibson Athlon!|
Reassigning .ref and .meta? Rebinding class objects?
Hi, my $str = Hello; $str.ref = Int; # allowed? $str.meta = some_sub.meta; # allowed? my $str = Hello; Str ::= Int; # allowed? ::Str ::= ::Int;# or is this allowed? say $str; # still Hello? Or is it an Int now? my $new_str = Hi; say $new_str; # is this an Int now? Str ::= simple string; # not allowed? ::Str ::= simple string; # not allowed? --Ingo -- Linux, the choice of a GNU | Row, row, row your bits, gently down the generation on a dual AMD | stream... Athlon!|
Re: Interpolation of arrays
Hi,
[EMAIL PROTECTED] wrote:
While trying to use say for debugging, I ran across an oddity. While
I can:
say [EMAIL PROTECTED];
and
say @some_array;
this doesn't work:
say @some_array;
Pugs is correct here, you need to use [] or {} to interpolate
aggregates:
say $scalar @array[] %hash{};
Even stranger:
class SomeClass {
has $.scalar_attr;
has @.array_attr;
method trial () {
say $.scalar_attr @.array_attr;
}
}
Calling trial yields the correct value of the scalar, but the literal
'@.array_attr' instead of its value. Oddly, substituting $.array_attr
yields the value with no complaint that there is no such scalar.
Ah, that's probably because under the current runcore, all $.vars are
merely keys for a hash, and the sigil seems to get stripped away.
(Under the new PIL runcore, Stevan's metamodel will be/is integrated,
i.e. we'll have real OO, and accessing
$.attributes_which_do_not_exist will fail at compile-time.)
Am I missing something, or should I submit a test?
Yes, please do so! :)
If the later, what folder should I put it in?
t/oo/attributes/, probably.
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
$pair[0]?
Hi, my $pair = (a = 1); say $pair[0]; # a? say $pair[1]; # 1? I've found this in the Pugs testsuite -- is it legal? --Ingo -- Linux, the choice of a GNU | Black holes result when God divides the generation on a dual AMD | universe by zero. Athlon!|
undef.chars?
Hi, (found in the Pugs testsuite.) my $undef = undef; say $undef.chars? # 0? undef? die? say chars $undef; # 0? undef? die? I'd opt for undef.chars to be an error (no such method) and chars undef to return 0 (with a warning printed to STDERR^W$*ERR). Opinions? --Ingo -- Linux, the choice of a GNU | When cryptography is outlawed, bayl bhgynjf generation on a dual AMD | jvyy unir cevinpl! Athlon!|
Re: $pair[0]?
Hi,
Andrew Shitov wrote:
say $pair[0]; # a?
It looks like $pair is an arrayref while 'say ref $pair' tells 'Pair'.
right, this is why I asked, IMHO it's bogus.
And may I ask a relating question:
my $pair = ('name' = 'age');
say $pair{'name'}; # prints 'age'
say $pair['name']; # why prints 'name'? == question
say $pair['age']; # prints 'name'
That's probably because both name and age get numified to 0 which in
turn means (in current Pugs) .key.
--Ingo
--
Linux, the choice of a GNU | There are no answers, only
generation on a dual AMD | cross-references.
Athlon!|
Re: $pair[0]?
Hi,
Luke Palmer wrote:
On 8/4/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
my $pair = (a = 1);
say $pair[0]; # a?
say $pair[1]; # 1?
I've found this in the Pugs testsuite -- is it legal?
Nope. That's:
say $pair.key;
say $pair.value;
Also:
say $paira; # 1
say $pair{anything else}; # undef
But we don't implicitly cast references like that.
thanks for clarification, that's what I've thought, too :)
--Ingo
--
Linux, the choice of a GNU | The next statement is not true.
generation on a dual AMD | The previous statement is true.
Athlon!|
[S29] Mutating map and grep
Hi,
according to S29 [1], neither map nor grep allow mutation:
multi sub Perl6::Array::map (@values, Code $expression) returns Lazy
multi sub Perl6::List::map (Code $expression : [EMAIL PROTECTED]) returns
Lazy
multi sub Perl6::Array::grep (@values : Code *test ) returns Lazy
multi sub Perl6::Array::grep (@values, MatchTest $test ) returns Lazy
multi sub Perl6::List::grep (MatchTest $test : [EMAIL PROTECTED]) returns
Lazy
OTOH, Perl 5 did allow it:
my @array = (0, 1, 2, 3);
my @result = map { $_++; 42 } @array;
print @result; # 42424242
print @array;# 1234
Is this a bug in S29 or will this be feature removed from Perl 6
and you'll have to say (for example)
use listops :mutating;
my @result = map { $_++; 42 } @array; # works now
What about reduce? (FWIW, I'd like it to allow mutation.)
What about sort? (FWIW, I'd like it to not allow mutation,
as allowing mutations would probably prevent many
optimizations.)
Opinions?
--Ingo
[1] http://svn.openfoundry.org/pugs/docs/AES/S29draft.pod
--
Linux, the choice of a GNU | The future is here. It's just not widely
generation on a dual AMD | distributed yet. -- William Gibson
Athlon!|
Re: zip with ()
Hi, Andrew Shitov wrote: I tried zip under pugs. my @odd = (1, 3, 5, 7); my @even = (2, 4, 6, 8); my @bothA = zip @odd, @even; print @bothA; This code prints 12345678 as expected. After parenthesis were used to group zip arguments, results changes to 13572468. Is it right? Whitespace is significant: say zip @odd, @even;# zip gets two arguments, result is # 12345678. say zip(@odd, @even); # zip gets two arguments, result is # 12345678. say zip (@odd, @even); # zip gets only one argument, the flattened # list (@odd, @even), containing the # elements (1,3,5,7,2,4,6,8). Then zip # tries to zip this one list, resulting in # 13572468. --Ingo -- Linux, the choice of a GNU | To understand recursion, you must first generation on a dual AMD | understand recursion. Athlon!|
Re: [S29] Mutating map and grep
Hi,
TSa (Thomas Sandlaß) wrote:
Ingo Blechschmidt wrote:
Is this a bug in S29 or will this be feature removed from Perl 6
and you'll have to say (for example)
use listops :mutating;
my @result = map { $_++; 42 } @array; # works now
Why not just
my @result = map - $_ is rw { $_++; 42 } @array; # works now
right, but IIRC if you omit the signature and the -, you're implicitly
declaring ($_ is rw):
for @array { $_++ } # works
for @array - $_ { $_++ } # error, $_ not rw
for @array - $_ is rw { $_++ } # works
for @array - $a { $a++ } # error, $a not rw
for @array - $a is rw { $a++ } # works
Pugs seems to confirm this:
my $coderef = { $_++ };
my $var = 3;
$coderef($var), # no error
say $var; # 4
If I'm wrong, and $_ is ro by default, then I like your solution very
much, as it makes my intention very clear (look! I'll probably modify
$_ soon!). :)
--Ingo
--
Linux, the choice of a GNU | Knowledge is that which remains when what
generation on a dual AMD | is learned is forgotten. - Mr. King
Athlon!|
Re: zip with ()
Hi, TSa (Thomas Sandlaß Thomas.Sandlass at orthogon.com writes: Ingo Blechschmidt wrote: say zip (@odd, @even); # zip gets only one argument, the flattened # list ( @odd, @even), containing the Why flattened? Shouldn't that be *(@odd, @even)? IIUC: say zip *(@odd, @even); # zip gets called with the parameters 1, 3, 5, 7, 2, 4, 6, 8. say zip (@odd, @even); # zip gets called with one argument, (1, 3, 5, 7, 2, 4, 6, 8). say zip ([EMAIL PROTECTED], [EMAIL PROTECTED]); # zip gets called with one argument, ([1, 3, 5, 7], [2, 4, 6, 8]). In general, (@foo, @bar) returns a new list with the element joined, i.e. @foo.concat(@bar). If you want to create a list with two sublists, you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTECTED], [EMAIL PROTECTED]). But of course, I could be totally wrong. :) # elements (1,3,5,7,2,4,6,8). Then zip Why not ([1,3,5,7],[2,4,6,8]) list of two array refs? Because you'd have to explicitly take reference to them: say zip ([EMAIL PROTECTED], [EMAIL PROTECTED]). (Can somebody confirm my thoughts?) --Ingo
Stringification of pairs
Hi, quick question: my $pair = (a = 1); say ~$pair; I assume that outputs a\t1, because of the pairs can pretend to be one-element hashes-rule. Correct? --Ingo -- Linux, the choice of a GNU | We are Pentium of Borg. Division is futile. generation on a dual AMD | You will be approximated. Athlon!|
Re: $arrayref.ref?
Hi, Larry Wall wrote: On Sat, Jul 30, 2005 at 02:14:52PM +0200, Ingo Blechschmidt wrote: : http://use.perl.org/~autrijus/journal/25337: : deref is now 0-level; $x = 3; $y = \$x; $y++. # now an exception : : my $arrayref = [1,2,3]; [...] : say $arrayref.isa(Ref); # true or false? False, though tied($arrayref).isa(Ref) is probably true. hm? I've probably misunderstood something, but I don't see any tied variables in the snippet above -- so why should we use tied() to get at the non-autodereffing ref of an autodereffing ref? I thought tieing is a way to intercept further assignments -- i.e. $some_tied_variable = ...; will call user-defined code. But this is not the case when dealing with simple references, right? my $arrayref = [1,2,3]; # $arrayref contains an autodereffing Ref of Array now. $arrayref = 42; # $arrayref contains a simple Num now. # The [1,2,3], which was previously stored in $arrayref, # does not notice the new assignment. Thus I propose we use tied() only to get at the underlying real contents of a tied variable, and use get_non_autodereffing_ref_out_of_autodereffing_ref() (with a shorter name, of course), to convert an autodereffing ref to a non-autodereffing ref. my $arrayref = [1,2,3]; $arrayref.isa(Ref); # false tied($arrayref); # error/undef get_non_autodereffing_ref_out_of_autodereffing_ref($arrayref).isa(Ref); # true Opinions? --Ingo -- Linux, the choice of a GNU | To understand recursion, you must first generation on a dual AMD | understand recursion. Athlon!|
$arrayref.ref?
Hi, http://use.perl.org/~autrijus/journal/25337: deref is now 0-level; $x = 3; $y = \$x; $y++. # now an exception my $arrayref = [1,2,3]; say $arrayref.ref;# Ref or Array? say $arrayref.isa(Ref); # true or false? say $arrayref.isa(Array); # false or true? say +$arrayref; # 3 or error? say $arrayref + 1;# 4 or error? --Ingo -- Linux, the choice of a GNU | Black holes result when God divides the generation on a dual AMD | universe by zero. Athlon!|
Binding scalars to aggregates
Hi, my @array = a b c; my $arrayref := @array; push $arrayref, c; say [EMAIL PROTECTED]; # a b c d, no problem $arrayref = [d e f]; say [EMAIL PROTECTED]; # d e f, still no problem $arrayref = 42;# !!! 42 is not a Ref of Array Should the last line be treated as $arrayref = (42,); which, as the LHS is in scalar context, would auto-referize to $arrayref = [42]; which would work? Or should that be an error? (FWIW, I favour option 2.) --Ingo -- Linux, the choice of a GNU | Row, row, row your bits, gently down the generation on a dual AMD | stream... Athlon!|
Binding hashes to arrays?
Hi, is binding hashes to arrays (or arrays to hashes) legal? If not, please ignore the following questions :) my @array = a b c d; my %hash := @array; say %hasha; # b push @array, e f; say %hashe; # f? %hashX = Y; say [EMAIL PROTECTED]; # ??? # X Y (or X = Y?) appended to the end of @array? It seems to me supporting this is hard to get right... --Ingo -- Linux, the choice of a GNU | Mr. Cole's Axiom: The sum of the generation on a dual AMD | intelligence on the planet is a constant; Athlon!| the population is growing.
Re: Binding scalars to aggregates
Hi, Larry Wall wrote: On Sat, Jul 30, 2005 at 02:33:15PM +0200, Ingo Blechschmidt wrote: : my @array = a b c; : my $arrayref := @array; [...] : $arrayref = 42;# !!! 42 is not a Ref of Array : : Should the last line be treated as : $arrayref = (42,); : which, as the LHS is in scalar context, would auto-referize to : $arrayref = [42]; : which would work? : : Or should that be an error? : : (FWIW, I favour option 2.) Why shouldn't it do option 3, which is to work like in Perl 5? It should only be an error if $arrayref is declared with a type inconsistent with 42. Assignment goes to the container, not the current contents of that container. hm, I thought binding would make $arrayref and @array point to the same container? I.e.: my $a = 42; my $b; # $a -- Container1 -- 42 # $b -- Container2 -- undef $b := $a; # $a -- Container1 -- 42 # $b -- Container1 -- 42 (note: Container*1*) $a = 23; # $a -- Container1 -- 23 # $b -- Container1 -- 23 # But plain assignment does, of course, not change containers: my $c; # $c -- Container3 -- undef $c = $a; # $c -- Container3 -- 23 $a = 19; # $a -- Container1 -- 19 # $b -- Container1 -- 19 # $c -- Container3 -- 23 I.e. assignment goes to the container, but doesn't change it, and binding changes the container. --Ingo -- Linux, the choice of a GNU | Elliptic paraboloids for sale. generation on a dual AMD | Athlon!|
Re: Binding scalars to aggregates
Hi,
Larry Wall wrote:
Except that you've rebound the container. Hmm, maybe the original
binding is an error.
what about:
sub foo (Array $arrayref) {...}
my @array = a b c d;
foo @array;
The binding used by the parameter binding code does not use the
standard := operator then, right? (As it'd have to $arrayref :=
@array.)
--Ingo
--
Linux, the choice of a GNU | We are Pentium of Borg. Division is futile.
generation on a dual AMD | You will be approximated.
Athlon!|
Slurpy is rw arrays ([EMAIL PROTECTED] is rw)
Hi,
are the following assumptions correct?
sub foo ([EMAIL PROTECTED]) { push @args, 42 }
sub bar ([EMAIL PROTECTED] is rw) { push @args, 42 }
foo @some_array; # dies (Can't modify constant array...)
bar @some_array;
# works, but does not change @some_array, as the * causes bar to
# receive a *new* array (which happens to contain @some_array's
# elements), right?
# @args is only an array constructed by the parameter binding code;
# @args =:= @some_array is false (consider bar(@some_array, 42)).
bar 1,2,3; # works too
Or is @args always readonly and the declaration ([EMAIL PROTECTED] is rw) is an
error?
--Ingo
--
Linux, the choice of a GNU | Perfection is reached, not when there is no
generation on a dual AMD | longer anything to add, but when there is
Athlon!| no longer anything to take away.
Re: Messing with the type heirarchy
Hi,
Luke Palmer wrote:
http://repetae.net/john/recent/out/supertyping.html
This was a passing proposal to allow supertype declarations in
Haskell. I'm referencing it here because it's something that I've had
in the back of my mind for a while for Perl 6. I'm glad somebody else
has thought of it.
[...]
role Complex
does Object
contains Num
{...}
I've probably misunderstood you, but...:
role Complex does Object {...}
Num does Complex;
# That should work and DWYM, right?
--Ingo
--
Linux, the choice of a GNU | Wissen ist Wissen, wo man es findet.
generation on a dual AMD |
Athlon!|
Do slurpy parameters auto-flatten arrays?
Hi,
are the following assumptions correct?
sub foo ([EMAIL PROTECTED]) { @args[0] }
say ~foo(a, b, c); # a
my @array = a b c d;
say ~foo(@array);# a b c d (or a?)
say ~foo(@array, z); # a b c d (or a?)
say ~foo([EMAIL PROTECTED]); # a
say ~foo(*(@array, z));# a
sub bar ([EMAIL PROTECTED]) { [EMAIL PROTECTED] }
say bar(1,2,3); # 3
say bar(@array); # 1 (or 4?)
say bar(@array, z);# 2 (or 5?)
say bar([EMAIL PROTECTED]);# 4
--Ingo
--
Linux, the choice of a GNU | There are no answers, only
generation on a dual AMD | cross-references.
Athlon!|
Hash creation with duplicate keys
Hi,
# Perl 5
my %hash = (a = 1, b = 2, a = 3);
warn $hash{a}; # 3
But I vaguely remember having seen...:
# Perl 6
my %hash = (a = 1, b = 2, a = 3);
say %hasha;# 1
Can somebody confirm this?
--Ingo
--
Linux, the choice of a GNU | Mathematicians practice absolute freedom.
generation on a dual AMD | -- Henry Adams
Athlon!|
User-defined behaviour of hashes in list context
Hi,
according to Damian [1]...:
my %hash = (a = 1, b = 2);
my @array = %hash;
say @array[0].isa(Pair); # true
How can I override this behaviour?
class MyHash is Hash {
# Please fill in here
}
my %hash is MyHash = (a = 1, b = 2);
my @array = %hash; # should call my own routine
--Ingo
[1]
http://groups.google.de/group/perl.perl6.language/msg/dc552000b7c6191e
--
Linux, the choice of a GNU | Row, row, row your bits, gently down the
generation on a dual AMD | stream...
Athlon!|
How do subroutines check types?
Hi,
class Foo {...}
Foo.new.isa(Foo); # true
Foo.isa(Foo); # true (see [1])
Foo.does(Class);# true
sub blarb (Foo $foo, $arg) {
...; # Do something with instance $foo
}
blarb Foo.new(...), ...;
# No problem
blarb Foo, ...;
# Problem, as blarb expects an *instance* of Foo,
# not the class Foo.
How do I have to annotate the type specification in the
declaration of the subroutine to not include the class Foo, but
only allow instances of Foo?
Or is the default way to check the types of arguments
something like the following, in which case my first question
doesn't arise?
if $param ~~ $expected_type and not $param ~~ Class {
# ok
} else {
die Type error: ...;
}
(But this feels special-casey...)
(And, just curious -- how can I override the default checking
routine?)
--Ingo
[1] http://www.nntp.perl.org/group/perl.perl6.language/0
--
Linux, the choice of a GNU | Row, row, row your bits, gently down the
generation on a dual AMD | stream...
Athlon!|
Re: creating threas in BEGIN
Hi,
Luke Palmer wrote:
On 7/14/05, Nicholas Clark [EMAIL PROTECTED] wrote:
This is more a note to collective 'self' question than one I expect
the answer to right now. (The answer I expect right now is a glib it
will)
How will the perl6 compiler cope with people creating threads inside
BEGIN blocks?
A glib it won't.
Unless someone can come up with a reason you would want to do that.
class SomeCryptMod {
my %tables_which_are_expensive_to_create =
precalc_tables();# called at BEGIN time
sub precalc_tables () {
# Use threads to speed up calculation:
for 0..1 - $i {
# Or whatever the thread API is.
Thread.create:{ precalc_table_for $i };
}
Thread.wait_for_all_threads;
}
...;
}
If you compile that module then, the compiler will only have to
calculate %tables_which_are_expensive_to_create once (as the results
are serialized in the .pbc), and the code could use threads to speed up
calculation.
(But I'm fine with outlawing it, or making it a new feature in Perl
6.x.y, or whatever :))
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
Re: User-defined infix subs/methods?
Hi,
Michele Dondi wrote:
Good, I'd forgotten about that. Which means that it's even harder
for someone to compile a module in a strange dialect, since they'd
essentially have to write their own version of use that forces
recompilation (reuse, if you will). And the harder we make it to
write reuse, the better.
IIUC this will introduce a certain degree of asymmetry though, in that
in some sense p6 will be extremely generous in giving users the
ability to use whatever dialect/syntax modification they like in their
programs but just at the same time it will try to make it hard for
them to do so when refactoring code into suitable modules. Ain't it
so?
no, if I understood Larry correctly, you can of course write a nice
grammar-modifying module, but other modules you use() still use
Perl 6's standard grammar. E.g.:
use Grammar::Ruby;
# Ruby syntax from here on:
proc { |a| puts a + 1 }.call 3# 4
use SomeOtherModule
# SomeOtherModule.pm will be parsed using the standard grammar,
# *not* Grammar::Ruby.
If you wanted the compiler to parse SomeOtherModule.pm using Ruby's
grammar, you'd have to write:
use Grammar::Ruby;
reuse SomeOtherModule
--Ingo
--
Linux, the choice of a GNU | Row, row, row your bits, gently down the
generation on a dual AMD | stream...
Athlon!|
What do use and require evaluate to?
Hi,
what do use and require evaluate to?
S06 suggests it's probably some kind of Module object:
The result of a use statement is a (compile-time) object that also has
an .assuming method, allowing the user to bind parameters in all the
module's subroutines/methods/etc. simultaneously:
(use IO::Logging).assuming(logfile = .log)
We could make (use Foo) evaluate to the class object Foo,
allowing:
my $foo = (use Foo).new(...);
Alternatively, we could go the Perl 5 way and return the
last thing evaluated in Foo.pm (which might be a Module
object, assuming that module Foo {...} evaluates to Foo).
What do successive uses of use and require evaluate to?
Perl 5 is inconsistent:
$ cat Foo.pm
package Foo; 42;
$ perl -we 'warn require Foo; warn require Foo'
42 at -e line 1.
1 at -e line 1.
I'd like Perl 6's use and require to return the same thing.
In Perl 5, %INC maps the partial path names of the modules
loaded to their absolute ones. What should the keys and values
of %*INC be in Perl 6?
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
Quick OO .isa question
Hi,
class Foo {}
class Bar is Foo {}
Bar.new.isa(Object);# true
Bar.new.isa(Class); # false
Bar.new.isa(Foo); # true
Bar.new.isa(Bar); # true
# These are clear, I think.
Bar.isa(Object);# true
Bar.isa(Class); # true
Bar.isa(Foo); # ? (my guess: false)
Bar.isa(Bar); # ? (my guess: false)
--Ingo
--
Linux, the choice of a GNU | We are Pentium of Borg. Division is futile.
generation on a dual AMD | You will be approximated.
Athlon!|
How do I... create a value type?
Hi,
my $x = 42;
my $y = $x;
$y++;
say $x; # Still 42, of course
class Foo {
has $.data;
method incr () { $.data++ }
# Please fill in appropriate magic here
}
my Foo $x .= new(:data(42));
my Foo $y = $x;
$y.incr();
say $x.data;# Should still be 42
say $x =:= $y; # Should be false
--Ingo
--
Linux, the choice of a GNU | The computer revolution is over.
generation on a dual AMD | The computers won.
Athlon!| -- Eduard Bloch
Re: Quick OO .isa question
Hi,
Stevan Little wrote:
On Jul 11, 2005, at 9:16 AM, Ingo Blechschmidt wrote:
Bar.isa(Object);# true
Bar.isa(Class); # true
Bar.isa(Foo); # ? (my guess: false)
Bar.isa(Bar); # ? (my guess: false)
I am not sure about this. I think that .isa as a class method should
behave much as it does for an instance method. If we start supporting
things like Bar.isa(Class) then we start exposing the soft underbelly
of the meta-model to the outside world. Which IMO might not be a good
idea.
ah, you mean there could be problems, when, for example, Bar is not
actually a Class, but a PersistentClass or something, and one tries to
check whether a given $obj is a class by using .isa? I.e.:
my $obj = get_a_class_or_something_else();
if $obj.isa(Class) {...}# XXX
IIRC, Larry once said that Class is actually a role, so then both the
builtin standard class object and PersistentClass .does(Class), so this
shouldn't be a problem, because one should use .does anyway (or ~~).
So, to fix the above snippet:
my $obj = get_a_class_or_something_else();
if $obj.does(Class) {...} # or
if $obj ~~ Class{...}
--Ingo
--
Linux, the choice of a GNU | There are no answers, only
generation on a dual AMD | cross-references.
Athlon!|
Re: Quick OO .isa question
Hi,
Stevan Little wrote:
Actually I was thinking that MyClass.isa(...) would work much as it
did in Perl 5 (like an instance). But that access to the underlying
MyClass class instance would not be as simple. Something like
::MyClass would provide access to the Class instance.
class Foo {}
Foo.isa(Object) # true
Foo.isa(Foo)# true
Foo.isa(Class) # false
::Foo.isa(Object) # true
::Foo.isa(Class) # true
::Foo.isa(Foo)# false
However, this is not speced anywhere, so I am just really making stuff
up out of my head :)
I've always thought Foo and ::Foo were synonyms (except maybe in
signatures, but that's another thread). I.e.:
Foo =:= ::Foo =:= ::(Foo); # true
And all of these are (except if you do metamodel hackery) Class objects,
i.e. the following all work and are semantically identical:
my $foo = Foo .new;
my $foo = ::Foo.new;
my $foo = ::(Foo).new;
Am I wrong?
--Ingo
--
Linux, the choice of a GNU | Black holes result when God divides the
generation on a dual AMD | universe by zero.
Athlon!|
Re: Quick OO .isa question
Hi, Larry Wall wrote: On Mon, Jul 11, 2005 at 09:46:30AM -0400, Stevan Little wrote: : On Jul 11, 2005, at 9:16 AM, Ingo Blechschmidt wrote: : Bar.isa(Object);# true : Bar.isa(Class); # true : Bar.isa(Foo); # ? (my guess: false) : Bar.isa(Bar); # ? (my guess: false) : : I am not sure about this. I think that .isa as a class method should : behave much as it does for an instance method. Right, or you can't easily decide whether Bar isa Foo in the abstract. You need to able to reason about the relationships of user-defined classes in the absence of instances. ah, of course, that makes sense. So anyway, that gives us something like: Bar.isa(Foo); # true Bar.isa(Bar); # true Bar.isa(Class) # false presuming Class is only a role Bar.does(Class) # true Bar.does(CLASS) # false Bar.meta.isa(Foo); # false Bar.meta.isa(Bar); # false Bar.meta.does(Class) # false Bar.meta.isa(CLASS) # false presuming CLASS is only a role Bar.meta.does(CLASS) # true These make perfect sense, too. And there's a clear distinction between Bar and Bar.meta, so I'm absolutely fine with that :) --Ingo -- Linux, the choice of a GNU | When cryptography is outlawed, bayl bhgynjf generation on a dual AMD | jvyy unir cevinpl! Athlon!|
