Re: Accepted abbreviations
arefarray reference boolboolean const constant elemelement err error fh filehandle funcfunction hrefhash reference int integer interp interpreter i iterator? kv key/value num number obj object op operator, operation r read(able) ref reference regex regular expression expr expression rw read/write ro read-only str string sub subroutine w write(able) in input out output io input/output mem memory os operating system anon anonymous interestingly, among references there are aref and href, but scalar and subroutine references are not presented. Vadim
Re: for all(@foo) {...}
> No, S03 is probably just wrong there. Junctions are scalar values, and
> don't flatten in list context. Maybe we need something like:
>
> for =all(@foo) {...}
>
> to iterate the junction.
for all(1,2,3).values { say $_; }
reads nicely and works in pugs.
Also, flattening may get messy with nested junctions.
> for any(1,2,3) {...}
>
> then it would have done the "next", because 1 < 2.
Confused myself there. Thanks.
> =none(1,2,3) should return a list of all the things that aren't 1, 2,
> or 3 in random order. Maybe a lazy implementation will be beneficial
> at that point. :-)
none() outside of boolean context is lazily evaluated by my brain.
My eyes glaze over and I think about something else.
Brad
--
When one is not capable of true intelligence, it is good to consult with
someone of good sense. -- Hagakure http://bereft.net/hagakure/
Re: for all(@foo) {...}
On Sat, Apr 23, 2005 at 10:29:20PM -0700, Larry Wall wrote:
: On Sun, Apr 24, 2005 at 03:02:16PM +1000, Brad Bowman wrote:
: : Hi,
: :
: : I'm trying to understand the following section in S03:
: :
: : S03/"Junctive operators"
: :
: : Junctions are specifically unordered. So if you say
: : for all(@foo) {...}
: : it indicates to the compiler that there is no coupling between loop
: : iterations and they can be run in any order or even in parallel.
: :
: : Is this a "for" on a one element list, which happens to
: : be a junction, or does the all() flatten?
:
: No, S03 is probably just wrong there. Junctions are scalar values, and
: don't flatten in list context. Maybe we need something like:
:
: for =all(@foo) {...}
:
: to iterate the junction.
For the purposes of S03 it would have been better to use an example
without list context like:
-> $x {...}(all(@foo))
or maybe
all(@foo).each:{...}
I think that "given" specifically does not autothread it's block, so
given any(1,2,3) {...}
matches each case against any(1,2,3). That is, there is an MMD variant
of "given" that accepts a Junction, which disables autothreading.
Or maybe S03 really just wants to say that
if all(@foo).each:{...} {...}
is allowed to stop evaluating cases in "random" order when it gets
the first false value back from .each, while
if any(@foo).each:{...} {...}
is allowed to stop as soon as it gets a true value.
Larry
Re: for all(@foo) {...}
On Sun, Apr 24, 2005 at 03:02:16PM +1000, Brad Bowman wrote:
: Hi,
:
: I'm trying to understand the following section in S03:
:
: S03/"Junctive operators"
:
: Junctions are specifically unordered. So if you say
: for all(@foo) {...}
: it indicates to the compiler that there is no coupling between loop
: iterations and they can be run in any order or even in parallel.
:
: Is this a "for" on a one element list, which happens to
: be a junction, or does the all() flatten?
No, S03 is probably just wrong there. Junctions are scalar values, and
don't flatten in list context. Maybe we need something like:
for =all(@foo) {...}
to iterate the junction.
: Is the whole block run once with 1,2 and 3, or does the
: junction go into the block and autothread each operation?
I expect =all(@foo) would do the former, while all(@foo) would do
the latter, in which case you might as well have used "given" instead.
: for all(1,2,3) {
:next if $_ < 2; # testing 1 or all(1,2,3) ?
:%got{$_} = 1;
: }
: say %got.perl; # "(('2', 1), ('3', 1))" or "()" ?
Well, { 2 => 1, 3 => 1 } is the more likely notation.
: The "no coupling" in s03 suggests to me that the right
: answer is "(('2', 1), ('3', 1))", but I'm just guessing.
I think =all(@foo) should do what you expect there. Without the =
it should return { 1 => 1, 2 => 1, 3 => 1 } since there's only one
loop iteration, and it is *not* true that all(1,2,3) < 2. If you'd
said
for any(1,2,3) {...}
then it would have done the "next", because 1 < 2.
I should say that I don't see that =all() is different from =any().
They each just produce a list in "random" order. Though I suppose,
if we say that =one(1,2,3) should randomly pick one value, then
=any(1,2,3) should pick anywhere from 1 to 3 values. And, of course,
=none(1,2,3) should return a list of all the things that aren't 1, 2,
or 3 in random order. Maybe a lazy implementation will be beneficial
at that point. :-)
Larry
for all(@foo) {...}
Hi,
I'm trying to understand the following section in S03:
S03/"Junctive operators"
Junctions are specifically unordered. So if you say
for all(@foo) {...}
it indicates to the compiler that there is no coupling between loop
iterations and they can be run in any order or even in parallel.
Is this a "for" on a one element list, which happens to
be a junction, or does the all() flatten?
Is the whole block run once with 1,2 and 3, or does the
junction go into the block and autothread each operation?
for all(1,2,3) {
next if $_ < 2; # testing 1 or all(1,2,3) ?
%got{$_} = 1;
}
say %got.perl; # "(('2', 1), ('3', 1))" or "()" ?
The "no coupling" in s03 suggests to me that the right
answer is "(('2', 1), ('3', 1))", but I'm just guessing.
Brad
--
To ask when you already know is politeness. To ask when you don't know
is the rule. -- Hagakure http://bereft.net/hagakure/
Re: Thunking semantics of :=
On Sun, Apr 24, 2005 at 03:37:23AM +, Nigel Sandever wrote: : On Sun, 24 Apr 2005 03:47:42 +0800, [EMAIL PROTECTED] (Autrijus Tang) wrote: : > : > Oh well. At least the same code can be salvaged to make iThreads : : Please. No iThreads behaviour in Perl 6. : : Nobody uses them and whilst stable, the implementation is broken in so many way. : : But worse, the underlying semantics are completely and utterly wrong. Are you confusing iThreads with pThreads? Or are you recommending we go back to the pThreads fiasco? >From what I've read, the trend in most modern implementations of concurrency is away from shared state by default, essentially because shared memory simply doesn't scale up well enough in hardware, and coordinating shared state is not terribly efficient without shared memory. If you are claiming that modern computer scientists are completely and utterly wrong in moving that direction, well, that's your privilege. But you should be prepared for a little pushback on that subject, especially as you are merely badmouthing something without goodmouthing something else in it's place. Larry
Re: Thunking semantics of :=
On Sun, 24 Apr 2005 03:47:42 +0800, [EMAIL PROTECTED] (Autrijus Tang) wrote: > > Oh well. At least the same code can be salvaged to make iThreads Please. No iThreads behaviour in Perl 6. Nobody uses them and whilst stable, the implementation is broken in so many way. But worse, the underlying semantics are completely and utterly wrong.
Re: -X's auto-(un)quoting?
Larry Wall wrote:
I suppose bare ^
is also available:
given open 'mailto:[EMAIL PROTECTED]' {
^say(...);
^close or fail;
}
That almost makes sense, given that $^a is like $_. It also points vaguely
upward toward some antecedent. I could maybe get used to that, if I
tried real hard for a long time. Almost makes we wish we could rename
$_ to $^ though. Hmm...
I like this.
Only I'd have C< .foo > means C< $_.foo > and C< ^foo > mean C<
$self.foo >, assuming $self is the first invocant.
Why swap them? because $_ is known for performing magical disappearing
acts all over the place, and the ^ ties in with the $^x of parameters.
As for shortcuts to $OUTER::_, perhaps $-, if it's not put to some
better usage, but anything beyond that is getting too obscure for common
usage.
-- Rod Adams
Re: Binding and the Proxy class
Juerd writes: > Ingo Blechschmidt skribis 2005-04-23 19:42 (+0200): > > BTW, is it possible to implement the Proxy class in pure Perl? (I don't > > think so.) > > It would have to be possible, because Perl 6 will be written in Perl 6. > > (I like that Perl 6 will be written in Perl 6, because as Perl 6 is very > fast, Perl 6 will probably be fast too. We don't need C for speed ;)) I don't like how Python is will be written in Python. Since Python is very slow, Python will probably be slow too. :-) Luke
Re: Thunking semantics of :=
On Sat, Apr 23, 2005 at 10:07:05PM +0200, Juerd wrote: : Autrijus Tang skribis 2005-04-24 3:58 (+0800): : > Please sanity-check the following: : > pugs> my ($x, @a); $x := @a[-1]; $x = 3; @a : > *** Error: Modification of non-creatable array value attempted : : Pass. (For reference: The error is in the second statement.) : : > pugs> my ($x, @a); $x := @a[0][1]; $x = 3; @a[0][1] : > 3 : : Pass. : : > pugs> my ($x, @a); $x := [EMAIL PROTECTED]; $x = 3 : > *** Error: Can't modify constant item : : Pass, provided that [EMAIL PROTECTED] (@a.elems) is rvalue. If it's lvalue, then @a : should grow to 3 elements instead. rvalue, I think. Extending an array should probably be a special method, though we might allow @a.elems = 3; or some such. Larry
Re: Thunking semantics of :=
Autrijus Tang skribis 2005-04-24 3:58 (+0800): > Please sanity-check the following: > pugs> my ($x, @a); $x := @a[-1]; $x = 3; @a > *** Error: Modification of non-creatable array value attempted Pass. (For reference: The error is in the second statement.) > pugs> my ($x, @a); $x := @a[0][1]; $x = 3; @a[0][1] > 3 Pass. > pugs> my ($x, @a); $x := [EMAIL PROTECTED]; $x = 3 > *** Error: Can't modify constant item Pass, provided that [EMAIL PROTECTED] (@a.elems) is rvalue. If it's lvalue, then @a should grow to 3 elements instead. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Thunking semantics of :=
On Sat, Apr 23, 2005 at 09:50:26PM +0200, Juerd wrote: > Autrijus Tang skribis 2005-04-24 3:47 (+0800): > > $x := @a[0];# vivified or not? > > Vivified, because you're taking a reference (not at language level) and > you can't have a reference (at internal level) pointing to something > that doesn't exist. At language level, you can, but only symbolically. Okay. Implemented as r2260, with full call-by-value semantics as defined by Larry's previous post. `bindings.t` passes under either semantics, as expected. Please sanity-check the following: pugs> my ($x, @a); $x := @a[-1]; $x = 3; @a *** Error: Modification of non-creatable array value attempted pugs> my ($x, @a); $x := @a[0][1]; $x = 3; @a[0][1] 3 pugs> my ($x, @a); $x := [EMAIL PROTECTED]; $x = 3 *** Error: Can't modify constant item Thanks, /Autrijus/ pgpgpMzuYZEer.pgp Description: PGP signature
Re: Thunking semantics of :=
Autrijus Tang skribis 2005-04-24 3:47 (+0800): > $x := @a[0]; # vivified or not? Vivified, because you're taking a reference (not at language level) and you can't have a reference (at internal level) pointing to something that doesn't exist. At language level, you can, but only symbolically. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Thunking semantics of :=
On Sat, Apr 23, 2005 at 10:21:56AM -0700, Larry Wall wrote: > : Now, those two semantics directly clash when the RHS can be > : interpreted both ways. One good example would be array dereference: > : > : my ($x, @a); > : $x := @a[-1]; > : @a = (1..100); > : say $x; > : > : Under the linking semantic, there is no location in RHS to bind yet. > : One possible interpretation is just autovivify it -- but [-1] is not > : autovivifiable, so it should throw out an fatal exception under the > : linking semantic right there. Under the thunking semantic, of course, > : it will work as expected. > > I would prefer the exception. Alright. I wish I had seen this mail earlier -- because I just implemented the call-by-name semantics with snapshotting of RHS pad. Oh well. At least the same code can be salvaged to make iThreads and serializable continuations work. So, hm. What does this do? my ($x, @a); $x := @a[0];# vivified or not? @a = (1..100); say $x; Thanks, /Autrijus/ pgpY7nocOXCNd.pgp Description: PGP signature
Re: -X's auto-(un)quoting?
> Personally I'd never use 3 levels or above. <..say> or <.say> is it. > Beyond that, I would start naming the topics. Also, I would only use > <..say> on quick and dirty code probably. > > But why are we so keen on finding a way to save a few characters isntead > of just naming the topic which leads to more readble code? If it's not > self-descriptive, I think it does more harm than good. > then how about alias $OUTER::_ with $__ as a special exception? it looks familiar (maybe too much), but as it would be used in quick and dirty code, there wouldn't be that much $_ to confuse it with. or is $__ already taken? brano tichy [EMAIL PROTECTED]
Re: -X's auto-(un)quoting?
On Sat, 23 Apr 2005 14:21:06 -0400, Juerd <[EMAIL PROTECTED]> wrote: Matt Creenan skribis 2005-04-23 14:19 (-0400): Hm.. didn't really think of that. Though, how often would that really happen? Often -- this is exactly the same problem as Python has with its significant indenting. Move code around and you have to manually adjust it to the new levels. The problem with ..foo is less apparent because you're likely to copy all the levels at once, and it's relative rather than absolute. Juerd Personally I'd never use 3 levels or above. <..say> or <.say> is it. Beyond that, I would start naming the topics. Also, I would only use <..say> on quick and dirty code probably. But why are we so keen on finding a way to save a few characters isntead of just naming the topic which leads to more readble code? If it's not self-descriptive, I think it does more harm than good.
Re: -X's auto-(un)quoting?
Matt Creenan skribis 2005-04-23 14:19 (-0400): > Hm.. didn't really think of that. Though, how often would that really > happen? Often -- this is exactly the same problem as Python has with its significant indenting. Move code around and you have to manually adjust it to the new levels. The problem with ..foo is less apparent because you're likely to copy all the levels at once, and it's relative rather than absolute. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
Mark A. Biggar skribis 2005-04-23 10:55 (-0700):
> After some further thought (and a phone talk with Larry), I now think
> that all of these counted-level solutions (even my proposal of _2.foo(),
> etc.) are a bad idea.
In that case, why even have OUTER::?
I agree, though, and have always found this, that using the full name
(binding one if it doesn't have one already) is the better solution.
given returns_object() -> $foo {
when SomeClass { ... }
}
I think we all agree that smart match (implied by when) should work on
$_. The following is consistent with the above:
method ($foo: @bar) {
when SomeClass { ... }
}
Only the first line changes, and everything still works as expected.
The same would work very well for method calls:
method ($foo: @bar) {
.method;
}
I would expect that if we change the first line back (less academically,
copied and pasted the code elsewhere), it would still work on the same
thing.
given returns_object -> $foo {
.method;
}
The block passed to given aliases the first argument to $_. Methods
should do the same. And I really beleave that using a : to separate
instead of , does not make the invocant any less the first argument.
> They have a similar problems to constructs like "next 5;" meaning jump
> to the next iteration of the loop 5 level out.
Yes, that's ugly.
> Any time you refactor you code and change levels, they break in a
> subtle and very hard to debug way, causing mysterious errors.
Same thing for having one thing default to $_ and another to $self, in a
way. If everything defaults to $_, which may or may not be the same
thing as $self, things become more predictable, and you can when
refactoring just copy the body of a loop to a new method without
breaking it.
> Just like the current Perl construct of "labeled loops" so that you
> can talk about the target loop explicitly, the proper solution for
> up-level access to $OUTER::OUTER::...::OUTER::_ is to create a named
> binding like "$uplevel_topic := $_;" at that upper level and then use
> that to refer to it at lower levels.
Indeed. Fortunately, many built in constructs involving blocks that get
arguments already set up that binding for you.
> Beside is "...foo();" seven of eight levels up?
A rather irrelevant question, IMHO. It is as irrelevant as the similar
"Is 5521243 approximately .5 million or 5.5 million?", because just as
you can write 5_521_243 to make the number more clear, you could write
... ... .foo();
to show it's 7 dots.
> Any other way than explicit naming is madness; leading to unreadable
> and unmaintainable code.
Not if implict naming (completely implicit, that is, so without any
indication of level even) is consistent in what it means. Currently,
things default to $_ in almost every place where a value is needed but
left out. I'd hate to see that change to some other variable for only a
portion of the operations now defaulting to $_.
Automatic binding of the invocant as $_ and the possibility to provide
your own name for the thing (either by specifying it in the signature or
by explicitly using the := operator) makes that .method defaulting to
working on $_ is not a problem.
A method's block shouldn't be too different from a given's block, or any
other closure for that matter. They should both topicalize using the
same semantics, IMO.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
On Sat, 23 Apr 2005 13:55:17 -0400, Mark A. Biggar <[EMAIL PROTECTED]> wrote:
After some further thought (and a phone talk with Larry), I now think
that all of these counted-level solutions (even my proposal of _2.foo(),
etc.) are a bad idea. They have a similar problems to constructs like
"next 5;" meaning jump to the next iteration of the loop 5 level out.
Any time you refactor you code and change levels, they break in a
subtle and very hard to debug way, causing mysterious errors. Just like
the current Perl construct of "labeled loops" so that you can talk about
the target loop explicitly, the proper solution for up-level access to
$OUTER::OUTER::...::OUTER::_ is to create a named binding like
"$uplevel_topic := $_;" at that upper level and then use that to refer
to it at lower levels. Beside is "...foo();" seven of eight levels
up? Any other way than explicit naming is madness; leading to
unreadable and unmaintainable code.
Hm.. didn't really think of that. Though, how often would that really
happen? You can just explicility refer to the topic if you refactor. So
long as there is another way, I'm not sure that problem constitutes not
putting in such a shortcut.
I do see this as a being a bit confusing though:
given open 'file a' {
given open 'file b' {
given open 'file c' {
.say(...);
..say(...);
...say(...);
}
}
}
Doesn't that just encourage writing confusing code? Also, does anyone
else initial read it as doing say on file a first, then b, then c; instead
of c, b, a?
Re: Binding and the Proxy class
Ingo Blechschmidt skribis 2005-04-23 19:42 (+0200): > BTW, is it possible to implement the Proxy class in pure Perl? (I don't > think so.) It would have to be possible, because Perl 6 will be written in Perl 6. (I like that Perl 6 will be written in Perl 6, because as Perl 6 is very fast, Perl 6 will probably be fast too. We don't need C for speed ;)) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
Matt wrote: On Sat, 23 Apr 2005 07:25:10 -0400, Juerd <[EMAIL PROTECTED]> wrote: Matt skribis 2005-04-22 21:55 (-0400): What about . for each level up you want to go? instead of 1.say, 2.say, 3.say you use .say, ..say, ...say (Ok, I'm just kidding.. really!) I read your message after I suggested the same thing (I'm too impatient to read all new messages before sending replies). Why were you just kidding? I think it's a great idea. Well I like it too. I just didn't think anyone would actually go for it. I guess I underestimated how crazy you guys are ;) After some further thought (and a phone talk with Larry), I now think that all of these counted-level solutions (even my proposal of _2.foo(), etc.) are a bad idea. They have a similar problems to constructs like "next 5;" meaning jump to the next iteration of the loop 5 level out. Any time you refactor you code and change levels, they break in a subtle and very hard to debug way, causing mysterious errors. Just like the current Perl construct of "labeled loops" so that you can talk about the target loop explicitly, the proper solution for up-level access to $OUTER::OUTER::...::OUTER::_ is to create a named binding like "$uplevel_topic := $_;" at that upper level and then use that to refer to it at lower levels. Beside is "...foo();" seven of eight levels up? Any other way than explicit naming is madness; leading to unreadable and unmaintainable code. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Binding and the Proxy class
Hi,
my $x = new Proxy: FETCH => { foo() }, STORE => { bar($^new) };
$x ~~ Proxy; # true
$x = 42; # neither foo nor bar called
$x ~~ Num; # true
my $y := new Proxy: FETCH => { foo() }, STORE => { bar($^new) };
$y ~~ Proxy; # false (unless foo returns a Proxy object)
$y = 42; # bar(42) called
$y ~~ Proxy; # still false (unless foo returns a Proxy object)
say $y; # foo() called
Correct?
BTW, is it possible to implement the Proxy class in pure Perl? (I don't
think so.)
--Ingo
--
Linux, the choice of a GNU | Row, row, row your bits, gently down the
generation on a dual AMD | stream...
Athlon!|
Re: Thunking semantics of :=
On Sat, Apr 23, 2005 at 06:51:04PM +0800, Autrijus Tang wrote:
: Greetings. In implementing :=, I have discovered two different
: set of semantics in explantations. I will refer them as "linking" and
: "thunking".
Congratulations--you've rediscovered "call by ref" and "call by name",
but computer scientists tend to associate those concepts with calls
for some reason. :-)
In fact, the name "thunk" was invented for Algol, because it did
call-by-name, and was widely reviled for its inability to swap
two parameters. Nevertheless, computer scientists liked the
"definitionalness" of call-by-name, and have used it to write
pseudocode for years. It's hard to implement efficiently, but it
does let you defer some decisions about lvalueness.
: The "linking" semantic is akin to hard links in filesystems.
: It takes the storage location in the RHS and binds its to the
: name in the LHS:
:
: $x := $x; # no-op
: ($x, $y) := ($y, $x); # swap
:
: The "thunking" semantic is akin to symbolic links in filesystems.
: It takes the expression in RHS and wraps it in an implicit closure,
: then give that closure a name to be triggered later.
: A12 has an example:
:
: $endpos := $string.chars;# thunk, changes as $string changes
As Juerd pointed out, a ref to an lvalue works just as well to track
changes. The := operator is intended to use hard linking semantics.
: Now, those two semantics directly clash when the RHS can be
: interpreted both ways. One good example would be array dereference:
:
: my ($x, @a);
: $x := @a[-1];
: @a = (1..100);
: say $x;
:
: Under the linking semantic, there is no location in RHS to bind yet.
: One possible interpretation is just autovivify it -- but [-1] is not
: autovivifiable, so it should throw out an fatal exception under the
: linking semantic right there. Under the thunking semantic, of course,
: it will work as expected.
I would prefer the exception.
: Assuming the thunking semantics however, I am not too sure about how
: this can possibly work:
:
: ($x, $y) := ($y, $x); # swap?
:
: One interpretation is that the RHS pad bindings are snapshotted,
: so future calls to $x always evaluates the bound "$y" at the RHS
: context, and hence give correct results. This would mean:
:
: my ($x, @a);
: $x := @a[0];
: @a := ($x, $x, $x);
: $x := 1;
: say @a; # (undef, undef, undef)
:
: Okay, that looks good to me. Should I go ahead and implement
: the thunking semantics?
No, I think just treat the RHS as a context that says: "Give me
an lvalue if you can, otherwise give me an rvalue". One of the
motivations for making {...} always return a closure is so that it
would be really easy to specify a thunk when you really want one.
But the flip side of that is we want to discourage implicit thunking
in favor of explicit thunking. One benefit of that is that we give
the optimizer more information about the intent of the programmer.
It will be better for efficiency if we don't have to clone a bunch
of closures unnecessarily.
We could make some kind of ruling that binding closures to a container
gives that closure the ability to proxy for the container if you use
the container as something other than a closure. But there are
probably inconsistencies in that approach, unless we only allow
such binding to containers that could not be used directly as a
a closure reference. Have to think about that some more.
Larry
Re: -X's auto-(un)quoting?
On Sat, 23 Apr 2005 07:25:10 -0400, Juerd <[EMAIL PROTECTED]> wrote: Matt skribis 2005-04-22 21:55 (-0400): What about . for each level up you want to go? instead of 1.say, 2.say, 3.say you use .say, ..say, ...say (Ok, I'm just kidding.. really!) I read your message after I suggested the same thing (I'm too impatient to read all new messages before sending replies). Why were you just kidding? I think it's a great idea. Juerd Well I like it too. I just didn't think anyone would actually go for it. I guess I underestimated how crazy you guys are ;)
Re: -X's auto-(un)quoting?
What about . for each level up you want to go? instead of 1.say, 2.say, 3.say you use .say, ..say, ...say (Ok, I'm just kidding.. really!) I read your message after I suggested the same thing (I'm too impatient to read all new messages before sending replies). Why were you just kidding? I think it's a great idea. I like it too. In normal writing ... acts as a kind of 'think back' operator. Even though the writer uses it to signal an afterthought - it also makes the reader 'think back' to what preceded the afterthought. Syntax like .say ..say ...say enables the writer to add an afterthought and the reader to 'think back' to precisely the right scope. It allows you to have N scopes too .say, that would be cool. I hope this doesn't cause trouble for yada yada because I really like that operator too. Nige
Re: Thunking semantics of :=
Autrijus Tang skribis 2005-04-23 18:51 (+0800):
> Now, those two semantics directly clash when the RHS can be
> interpreted both ways.
Not if methods for attributes like .chars promise to always return the
same variable, which would make even more sense if they were lvalue
methods. They can be put to use, like
.chars = 5; # truncate or pad
or they can be made read-only lvalues, as is a numeric literal:
$foo := 5;
$foo++; # error.
> Under the linking semantic, there is no location in RHS to bind yet.
> One possible interpretation is just autovivify it -- but [-1] is not
> autovivifiable, so it should throw out an fatal exception under the
> linking semantic right there. Under the thunking semantic, of course,
> it will work as expected.
But when do you do when the index is non-literal?
$foo := @bar[$bar];
Does this work like creating an lvalue closure { @bar[$bar] } and
calling it, does it bind to the @bar with $bar as it was at the moment
of binding?
Is it true that every thunking thing is essentially a compile time
bind, and linking(aliasing) is a runtime thing? If so, can the semantics
each have their own operator? :=, ::=. I don't know if this makes any
sense, but that has something to do with me never understanding the
purpose of ::=.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
Matt skribis 2005-04-22 21:55 (-0400): > What about . for each level up you want to go? > instead of 1.say, 2.say, 3.say > you use .say, ..say, ...say > (Ok, I'm just kidding.. really!) I read your message after I suggested the same thing (I'm too impatient to read all new messages before sending replies). Why were you just kidding? I think it's a great idea. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
Larry Wall skribis 2005-04-22 18:31 (-0700): > I should point out that we're still contemplating breaking .foo() so it > no longer means $_.foo(). I wish there were more keys on my keyboard... Which I think would be a very bad idea, so while I can (as long as no other decision has been made), I'm using the current syntax :) I even consider breaking compatibility with bare Perl 6, for my grammar, if that's necessary to get .foo to use the same implicit LHS as .[5]. Subs and loops are related, and aliasing the invocant as $_ the same way a loop aliases the loop variable as $_ makes sense to me. when you use a loop within a sub, do the same thing as when you use a loop within another loop: explicitly use the full name, or use OUTER::. > We do, after all, have better ways of declaring private methods and > functions now. so maybe we don't need to reserve _ for that anymore. I was planning on using prefixed underscore for macros that slurp up till the end of a line, so syntax highlighting could be adjusted for those things that would otherwise break. With non-underscore, I'd have to use a litter, or make my macro a prefix operator, which is more work. > And it would save two characters over $_.foo(). But recovering C > programmers will scream, and probably prefer _.foo(), even if it only > saves one character. _ on my keyboards is two keys, shift and -, while . is only one. In fact, I find $_.foo even easier to type than _.foo, and better looking. Especially because the $ sigil is part of the name now, _ without sigil should not be used. > Maybe it's time to raid Latin-1 for the next closest thing to a dot, > "middle dot": > ·say(...); > ·close or fail; Please, no. > But I'm sure some will argue that's too subtle. (Hi, @Larry.) String index for an array? > say¹(...); > close¹ or fail; > Then foo² would be $OUTER::_.foo(), foo³ would be $OUTER::OUTER::_.foo(). For that matter, I think repeating prefixed dots works just as well: .foo# $_.foo ..foo # $OUTER::_.foo # OUTER::$_.foo ...foo # $OUTER::OUTER::_.foo # OUTER::OUTER::$_.foo This shouldn't clash with yada, I think. (In the case it does (why would it?), adding parens is an obvious way to break ambiguity: (...).) > Yes, especially the c: scheme. :-) I have no pity for Win32 users :) For all I care, they can use file:///c|/... or the awful MSIE variant file://c:\foo\bar. But I guess it's safe to treat single-letter schemes as Win32/DOS volumes, as there are no single-letter URI schemes. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Thunking semantics of :=
Hi, Autrijus Tang wrote: > my ($x, @a); > $x := @a[0]; > @a := ($x, $x, $x); > $x := 1; > say @a; # (undef, undef, undef) hm, I'd expect @a to be (1, 1, 1) (WE = when evaluated): my ($x, @a);# $x is undef WE, @a is () WE $x := @a[0];# $x is undef WE, @a is () WE @a := ($x, $x, $x); # $x is undef WE, @a is (undef, undef, undef) WE # But those "undef"s are bound to @a[0] -- # @a := (@a[0], @a[0], @a[0]); $x := 1;# $x is 1 WE, @a[0] is 1 WE say @a; # (1, 1, 1) And: my ($x, @a);# $x is undef WE, @a is () WE $x := @a[0];# $x is undef WE, @a is () WE @a = ($x, $x, $x); # $x is undef WE, @a is (undef, undef, undef) WE # Those "undef"s are real undefs $x := 1;# $x is 1 WE, @a[0] is 1 WE say @a; # (1, undef, undef) Opinions? --Ingo -- Linux, the choice of a GNU | To understand recursion, you must first generation on a dual AMD | understand recursion. Athlon!|
Thunking semantics of :=
Greetings. In implementing :=, I have discovered two different set of semantics in explantations. I will refer them as "linking" and "thunking". The "linking" semantic is akin to hard links in filesystems. It takes the storage location in the RHS and binds its to the name in the LHS: $x := $x; # no-op ($x, $y) := ($y, $x); # swap The "thunking" semantic is akin to symbolic links in filesystems. It takes the expression in RHS and wraps it in an implicit closure, then give that closure a name to be triggered later. A12 has an example: $endpos := $string.chars;# thunk, changes as $string changes Now, those two semantics directly clash when the RHS can be interpreted both ways. One good example would be array dereference: my ($x, @a); $x := @a[-1]; @a = (1..100); say $x; Under the linking semantic, there is no location in RHS to bind yet. One possible interpretation is just autovivify it -- but [-1] is not autovivifiable, so it should throw out an fatal exception under the linking semantic right there. Under the thunking semantic, of course, it will work as expected. Assuming the thunking semantics however, I am not too sure about how this can possibly work: ($x, $y) := ($y, $x); # swap? One interpretation is that the RHS pad bindings are snapshotted, so future calls to $x always evaluates the bound "$y" at the RHS context, and hence give correct results. This would mean: my ($x, @a); $x := @a[0]; @a := ($x, $x, $x); $x := 1; say @a; # (undef, undef, undef) Okay, that looks good to me. Should I go ahead and implement the thunking semantics? Thanks, /Autrijus/ pgpMbay14Ela7.pgp Description: PGP signature
