Re: [pugs]weird thing with say ++$
On 21 Apr, fayland wrote: : It has been published at perl6.language, but have no reply. That was to be expected, as it's no language-design specific issue, and therefore, unsuitable for p6l. : In perl v5.8.6 built for MSWin32-x86-multi-thread: : : my $i = 1; : print $i++, ++$i; # 1 3 : my $i = 1; : print ++$i, $i++; # 3 2 You're misleaded here, by thinking, scalar context is being enforced, which is not the case; the results of the increment operator operations (ops) on the scalar are being passed in (implicit) array context to the print builtin. Every Perl program, that gets compiled and interpreted, will be converted to a syntax tree initially. The following is a selected excerpt from the output of the core module B::Terse, which displays, what syntax tree we actually got hold of. LISTOP (0x3c013760) print OP (0x3c013780) pushmark UNOP (0x3c013700) postinc [2] OP (0x3c0136e0) padsv [1] UNOP (0x3c013740) preinc OP (0x3c013720) padsv [1] So, LISTOP indicates, that a list context is being encountered, which is not, what we actually want. The syntax trees for the two examples, provided above, don't differ that much, except, as you'd assume, in case of the ordering of the UNOPs. I don't see any way to explain, what's going wrong *exactly* by examining the syntax tree; that'd require digging into the internals, I'd assume. my $i = 1; and either print $i++; print ++$i; or print ++$i; print $i++; does what you assumed, it was supposed to do, but without having the compiler struggling against implicit assumptions. : in pugs: : : my $i = 1; : say $i++, ++$i; # 1 3 : : my $i = 1; : say ++$i, $i++; # 2 2 This leads me to think, Pugs has implemented the behaviour, that has been outlayed in Apocalypse 03: Operators, RFC 082 - Arrays: Apply operators element-wise in a list context, http://dev.perl.org/perl6/doc/design/apo/A03.html : which is right?(I think perl5 is) or it's different between Perl5 and Perl6? I'm not inclined to think, that Perl 5 is wrong here, as letting it assume array context, is in this context, like assuming, filling your fridge with food, it consists of, by randomly throwing some of it in, will come out sorted again; Perl 6 does, what the specifications urge upon it to do. : /Fayland Lam/ Steven
pass hash to sub expecting named params?
Will it be valid to pass a hash to a subroutine expecting named
params, if the hash keys match the names?
sub do_this (+$foo, +$bar) {
# whatever
}
%arg = (
:foo,
:bar,
);
do_this(*%arg);
I use this technique a lot, and it would be unfortunate to miss out on
the advantages of subroutine signatures and have to 'go back' to the
perl5-ish
sub do_this (*%args) { }
Carl Franks
Re: pass hash to sub expecting named params?
Carl Franks writes:
> Will it be valid to pass a hash to a subroutine expecting named
> params, if the hash keys match the names?
>
> sub do_this (+$foo, +$bar) {
> # whatever
> }
>
> %arg = (
> :foo,
> :bar,
> );
>
> do_this(*%arg);
Yep, and that's exactly how you do it, too. I believe that the * is
unnecessary (but still acceptable) if you're already in the named zone:
do_this(foo => 1, %arg); # ok
Luke
Re: pass hash to sub expecting named params?
That puts my mind at ease!
Many thanks,
Carl
On 4/25/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Carl Franks writes:
> > Will it be valid to pass a hash to a subroutine expecting named
> > params, if the hash keys match the names?
> >
> > sub do_this (+$foo, +$bar) {
> > # whatever
> > }
> >
> > %arg = (
> > :foo,
> > :bar,
> > );
> >
> > do_this(*%arg);
>
> Yep, and that's exactly how you do it, too. I believe that the * is
> unnecessary (but still acceptable) if you're already in the named zone:
>
> do_this(foo => 1, %arg); # ok
>
> Luke
>
Re: map { $_ => $_ } @foo
On Sun, Apr 24, 2005 at 04:39:04PM -0700, Larry Wall wrote:
> : Larry suggested that to keep it from being collapsed, we somehow
> : augment toplevel AST:
> :
> : map { $_ => $_; } @foo;
> : map { +($_ => $_) } @foo;
>
> Uh, I'm not sure what + would return for a Pair, but I'm pretty sure it's
> not a pair. A little P5ism sneaking in there? :-)
Aye, indeed. :-)
> : But here is a new idea: Since the parser knows that the bare block is
> : followed by no trailing comma, how about we using it as a disambiguating
> : device, and define that it never collapses?
> :
> : map { $_ => $_ } @foo; # closure
> : map { $_ => $_ }, @foo; # hash
>
> A block can be arbitrarily long. I worry about disambiguating it by
> something could come lines later. It's the /x problem all over again.
> Plus, I think many folks would rather think of the closure comma as
> optional rather than mandatorily missing. Besides, if they can't
> keep the {...} straight, they're not gonna keep the comma straight either.
Okay, I concur. r2319 now renders the trailing comma / adverbial colon
orthogonal to closure collapsing again; I have also implemented your
top-level-expression rule from an easlier thread. So to disambiguate,
one has to write this now:
map { $_ => $_; } @foo;
This works too:
map { ;$_ => $_ } @foo;
But () is still only a grouper, so this won't do:
map { ($_ => $_) } @foo;
Does this make sense?
Thanks,
/Autrijus/
pgppdAs3gEUYk.pgp
Description: PGP signature
Re: [pugs]weird thing with say ++$
Steven Philip Schubiger skribis 2005-04-25 5:41 (+0200): > That was to be expected, as it's no language-design specific issue, > and therefore, unsuitable for p6l. > : print ++$i, $i++; # 3 2 > You're misleaded here, by thinking, scalar context is being enforced, > which is not the case; the results of the increment operator operations (ops) > on the scalar are being passed in (implicit) array context to the print > builtin. I don't know how it's called on other levels, but we're still calling that list|slurpy|plural context. "array context" looks too much like "Array context", which is something else. In array context, @foo is passed as the array that it is. In list context, it is flattened. Big and very important difference. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: turning off warnings for a function's params?
David Storrs writes:
> I image we've all written logging code that looks something like this
> (Perl5 syntax):
>
> sub foo {
> my ($x,$y) = @_;
> note("Entering frobnitz(). params: '$x', '$y'");
> ...
> }
>
> This, of course, throws an 'uninitialized value in concatenation or
> string' warning when your test suite does this:
>
> is( foo(undef, undef), undef, "foo(undef, undef) gives undef" );
>
> How would I best solve this problem in Perl6?
Of course, no ordinary definition of a note() sub will work, since the
concatenation happens before note is even touched. However, a macro
could do it. It might go something like this:
macro note(Perl::Expression $expr)
is parsed(/$ := /)
{
$expr.compile(:warnings(0));
}
Luke
goto, enter, leave, etc. (Was: Re: -X's auto-(un)quoting?)
Larry Wall wrote:
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...
What is the status of my proposal to reserve the indirect object syntax
for calls on $_ and the .method form for the invocant in (single)methods?
Thus .method *always* expands to $?SELF which of course isn't available
outside of method definitions.
This postfix colon call syntax has to go with a new syntax for landing sites
into code positions like we have goto for jumping out. I proposed to call
the goto partner 'land' but it could also be the enter function which
defines the entry points into a block, calling the ENTER blocks if
coming from the outside or so. Typical entry points that come to mind
are before/after parameter (type) check. BTW, does goto call all LEAVE
blocks that are left and all ENTER blocks that are entered? If not all,
which ones are picked?
Then the example becomes
given open 'mailto:[EMAIL PROTECTED]' {
say: (...); # space needed to avoid &say:(...) syntax?
close: or fail; # or even 'close or fail'
}
This postfix colon syntax is basically needed only if a different entry
point into the dispatch of e.g. close shall be taken. A plain close starts
from MMD, while close: starts from namespace scoped single dispatch on $_
and fails over to MMD. Either syntax '$_.close' and 'close $_:' is already
valid and both need more chars when interpolated: "$_.close()" or "{$_.close}"
and "{close $_:}".
But some whitespace rules are needed to disambiguate
method: option; #1
from
method :option; #2a
and
method:option; #2b
Case #1 calls method on $_ with the return value of option,
while cases #2 call method with adverbial modifier option set
to true.
A nice extension that also saves the trailing ; is to say that
a single indirect method call in a line autoterminates or some such.
I mean to warp the postfix colon indirect object syntax into doing
double duty as statement separator. Well, actually the
semicolon is half a colon in that respect :)
Then we get:
given baz()# $_ := baz() or with temp?
{
bar:# $_.bar()
blubb: # $_.blubb()
whatever: # $_.whatever()
}
and
method foo()# foo( $?SELF: )
{
.bar;# $?SELF.bar()
.blubb; # $?SELF.blubb()
.whatever; # $?SELF.whatever()
}
and combined:
method foo()# foo( $?SELF: )
{
# given foo() works syntactically but could recurse infinitly
given baz() # temp $_ := baz()
{
.bar; # $?SELF.bar()
blubb: # $_.blubb()
.whatever: # MMD whatever( $?SELF, $_: )
}
}
BTW, are the two method examples valid without a surrounding class scope?
I think it's not strictly needed because foo would be added to class Any.
Hmm, this would also produce:
$obj.method $foo, $bar: $x, $y, $z;
to mean
method( $obj, $foo, $bar: $x, $y, $z );
and of course
$obj.method: $x, $y, $z;
means
method( $obj, $_: $x, $y, $z );
--
TSa (Thomas Sandlaß)
Re: Calling junctions of closures
Brad Bowman wrote:
my $a = rand(); # runtime variable
my $result = one(any( sub { $a+1}, sub { $a-1} ),sub { $a+3 }).();
say $result.perl;
If $a was 0.5 I'd guess
$result = one(any(1.5, 0.5), 3.5)
is this the case?
IIRC the .perl method produces a string from which an equal value
can be recreated, so e.g. $result == eval( $result.perl ). This forces
a once through evaluation of the junction. So, yes I think your result
is one of the possible 4. The other three are the two numbers in the any()
swapped and the number and the any() of the one() swapped.
OTOH, the junctions will be stored before the .perl call as e.g.
one(any(Ref of Sub, Ref of Sub), Ref of Sub) with the three subs
beeing mutually different. The .perl method might then just be
propagated down to give e.g. 'sub { $a + 1 }' and not call the subs.
But I've no idea how a closed over value is printed. So it could
also be 'sub { \0.5 + 1 }' or 'sub { $Full::Path::To::a + 1 }'.
This is coupled with the questions how references work and how they
are printed.
What I don't like of the Junctive Debates is that many people think about
junctions as specific forms of list. And I haven't managed to understand
the relation between MMD and the code warping needed to get autothreaded
junctions.
--
TSa (Thomas Sandlaß)
Re: -X's auto-(un)quoting?
I think the original (or the "latest original") reason for breaking .meth from
meaning $_.meth is that $_ is transitory and there was no way back to the
nameless invocant. In the absense of having a way back, I and others
strongly advocated breaking the link. I think we hated to do it.
Now if we can introduce another way back so that we can always get to the
invocant if we want to, then I'd say lets leave .meth always working on $_ .
It does have beauty and simplicity.
So then, to get back to the invocant... I can't say that I liked many of the
proposals. The one that seemed to have merit though was $^. I'd propose the
following.
meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the invocant
$^.meth; # is the invocant
$^1.meth; # is the first invocant
$^2.meth; # is the second invocant
for 1 .. 10 {
$_.say; topic of for
.say; # use $_
$^.say; # stringifies invocant 1
$^1.say; # stringifies invocant 1
$^2.say # stringifies invocant 2
}
}
The rules then are simple. .meth always operates on $_. $_ is always the
current topic. $_ defaults to the invocant of the method. $^1 refers to the
first invocant. $^ is an alias for $^1. $^n refers to the nth invocant.
Nice and simple. No conflict with existing naming conventions.
Paul
Re: How do I... tie hashes/arrays?
Larry Wall wrote: Depends on whether the user is actually expecting equal MMD there, or tie-breaking between multi methods within the particular class. My gut-level feeling is that they expect the latter. With combined .method and method: syntax we also could have a nice top priority or innermost single invocant that possibly redispatches outwards. With sufficient type information the selection might already happen at compile time. : > ... However, that being : > said, there's enough flexibility in the FETCH/STORE proxy that you : > could "defactor" the identification code out to the various handlers : > and get the same benefit. : : Well, isn't the "defactorized" code just a bunch of multi subs? I don't think of it that way. Considering the code is bound to a particular proxy object before it is ever called, it seems to fall even more into the category of multi method rather than multi sub. This is one of the big flying leaps that Perl 6 is trying to take. We've had lots of MMD implementations in the world, but Perl 6 is attempting to make that orthogonal to all the other scoping mechanisms, I agree. We have: 1) backwards/forward along the call chain 2) outwards/inwards for lexical scopes 3) specificity on the (ordered) set of invocant arguments including lexical scopes and class scopes. If there's prior art, I'm not aware of it. The Cecil people have done some research under which pre-conditions a global MMD can be broken up into modularized MMD without loosing type safety. This limits Perl6's innovation to providing a nice syntax for it and making type safety optional---or better two ends of a spectrum. Actually I hope type safety is not really optional but deferred to runtime exceptions or undefined values that eventually result in an exception. I suppose the non-brain-burning view of it is that any extra lexical or class scope dimension just turns into an extra absolute constraint on which subset of the global subs of that short name can be called. Well, isn't MMD just another non-local control flow exception? At the first level the object's vtable is some kind of pre-calculated dispatch. From there on it goes outwards through lexical dispatchers. -- TSa (Thomas Sandlaß)
Re: [pugs]weird thing with say ++$
On 25 Apr, Juerd wrote: : I don't know how it's called on other levels, but we're still calling : that list|slurpy|plural context. "array context" looks too much like : "Array context", which is something else. I confess, it's likely a bad habit, to coin it "array context" on p6l, although it refers to Perl 5, where it I have seen it more than once - perhaps, overly abused too. : In array context, @foo is passed as the array that it is. In : list context, it is flattened. Big and very important difference. You're supposedly right. : Juerd Steven
Re: -X's auto-(un)quoting?
Paul Seamons skribis 2005-04-25 9:52 (-0600):
> a way back
What is this "way back" you repeatedly mention?
If it is having a name for the invocant, then there has always been one:
method foo ($self:) {
for (1..10) {
$self.method(.sqrt)
}
}
Or, well, two:
method foo {
my $self := $_;
...
}
Three, even:
method foo {
my $self = \$_;
for (1..10) {
$$self.method(.sqrt)
}
}
And probably even more. TAMT0WTDI! :)
> Now if we can introduce another way back so that we can always get to the
> invocant if we want to, then I'd say lets leave .meth always working on $_ .
> It does have beauty and simplicity.
Agreed!
> $^.meth; # is the invocant
> $^1.meth; # is the first invocant
> $^2.meth; # is the second invocant
I don't understand the concept of multiple invocants. How does that
work?
$^ as an alias for the invocant works for me, because "" sorts before
anything else, and the invocant's just the 0th argument.
> The rules then are simple. .meth always operates on $_. $_ is always the
> current topic. $_ defaults to the invocant of the method.
Yes! The problem isn't that this hasn't already been thought of -- it is
the current spec even.
However, the discussion is about changing these simple, clear, and
useful rules to a more complex situation of choosing a default based on
what the default will be used for, making the default for methods the
invocant rather than $_. I hate those plans and would love to see the
current spec, that is as you decribe above, implemented in the "final"
version.
(Or well, I believed this was the spec until I tried finding it. I can
find the stuff about .method defaulting to $_ in S12, but $_ being an
alias for the invocant is harder to find.)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: [pugs]weird thing with say ++$
Steven Philip Schubiger skribis 2005-04-25 18:44 (+0200): > I confess, it's likely a bad habit, to coin it "array context" on > p6l, although it refers to Perl 5, where it I have seen it more than > once - perhaps, overly abused too. That's old Perl5-ese. There was a big jargon change when people started to realise and agree that having two things both called arrays or lists was confusing. There are still some occurrences of "array context" left, but in reality, even in Perl 5, that should only refer to the context in which an array is expected, as provided by a \@ prototype. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: turning off warnings for a function's params?
On Mon, Apr 25, 2005 at 05:18:11AM -0600, Luke Palmer wrote:
> David Storrs writes:
> > sub foo {
> > my ($x,$y) = @_;
> > note("Entering frobnitz(). params: '$x', '$y'");
> > ...
> > }
> > This, of course, throws an 'uninitialized value in concatenation or
> > string' warning when your test suite does this:
> > is( foo(undef, undef), undef, "foo(undef, undef) gives undef" );
> > How would I best solve this problem in Perl6?
>
> Of course, no ordinary definition of a note() sub will work, since the
> concatenation happens before note is even touched.
Exactly; that's why I asked "how would I solve this", instead of "how
would I write note()".
> However, a macro could do it. It might go something like this:
>
> macro note(Perl::Expression $expr)
> is parsed(/$ := /)
> {
> $expr.compile(:warnings(0));
> }
>
> Luke
Cool. But that seems to turn off all warnings during the compilation
of the expression--I only want to get rid of the (expected)
'uninitialized' warning. Will there be a way to do finer-grained
control?
--Dks
--
[EMAIL PROTECTED]
Re: turning off warnings for a function's params?
David Storrs skribis 2005-04-25 10:00 (-0700):
> Cool. But that seems to turn off all warnings during the compilation
> of the expression--I only want to get rid of the (expected)
> 'uninitialized' warning. Will there be a way to do finer-grained
> control?
compile("no warnings :undef; $expr").
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?
> What is this "way back" you repeatedly mention?
>
> If it is having a name for the invocant, then there has always been one:
>
> method foo ($self:) {
> for (1..10) {
> $self.method(.sqrt)
> }
> }
>
> Or, well, two:
>
> method foo {
> my $self := $_;
> ...
> }
>
> Three, even:
>
> method foo {
> my $self = \$_;
> for (1..10) {
> $$self.method(.sqrt)
> }
> }
By this reasoning - why have a shortcut to any of the invocants at all? This
thread has headed in the direction of finding a way to figure out how to call
methods on the invocant without using the signatures name. On a method call
without a signature and without invoking Perl5isms there would not be a "way
back" to the invocant once you enter nested block.
The point of all of this discussion is to not have to set $self to anything.
The argument for .meth as opposed to $self.meth of $_.meth was that .meth was
clear enough to mean the current topic and was a nice huffmanization.
> method foo ($self:) {
> for (1..10) {
> $self.method(.sqrt)
> }
> }
That works great - so long as I specify the signature. I'm lazy, I don't want
to type the signature all the time. Consider:
method foo {
for 1 .. 10 {
$^.method(.sqrt);
}
}
Still pretty readable. I kind of like $^1 too which seems to behave like
$^variable quite nicely. I guess that $^1 should actually be $^0 so that we
are properly zero indexed. At this point - it sort of looks like Perl5's
$_[0] except now $^0 is just an alias and and it gets all of the attributes
given by the signature (should a signature be given) - plus we don't have to
deal with the [EMAIL PROTECTED] array.
> Or, well, two:
>
> method foo {
> my $self := $_;
> ...
> }
If I didn't like typing the signature - why would I want to type all of that
code to bind the variable? I'm lazy. The signature wouldv'e been shorter.
That looks Perl5ish.
> Three, even:
Same argument as the last with a different "aliasing."
Yes, I know there "can be" a "way back." In this thread, none of the examples
give one using existing Perl 6 syntax. They are all proposing new ways.
This is one more.
Paul
Re: -X's auto-(un)quoting?
Juerd wrote: However, the discussion is about changing these simple, clear, and useful rules to a more complex situation of choosing a default based on what the default will be used for, making the default for methods the invocant rather than $_. I hate those plans and would love to see the current spec, that is as you decribe above, implemented in the "final" version. I think your basic error in perception is that $_ is a runtime variable while the invocant(s) are more a design time assumption of what the method is working on. Perl6 has invented the notion of topic as a global lexically scoped variable that is orthogonal to the invocant and non-invocant parameters of (multi) methods. We have two distinct names for these two concepts: $_ and $?SELF. Additional multi method invocants need names anyway. E.g. in methods of GUI classes the invocant would be the selected widget and the topic the event. (Or well, I believed this was the spec until I tried finding it. I can find the stuff about .method defaulting to $_ in S12, but $_ being an alias for the invocant is harder to find.) My reading is that the two concepts have developed concurrently and only recently some pitfalls were identified when they are combined. -- TSa (Thomas Sandlaß)
Re: -X's auto-(un)quoting?
Paul Seamons wrote:
> Yes, I know there "can be" a "way back." In this thread, none of the
> examples give one using existing Perl 6 syntax. They are all proposing new
> ways. This is one more.
Sorry if this sounded brash. I have a habit of not figuring out that there is
more of the message to read.
Juerd wrote:
> $^ as an alias for the invocant works for me, because "" sorts before
> anything else, and the invocant's just the 0th argument.
Didn't see that in your response - I responded to the first topic section but
failed to see there was another.
Juerd wrote:
> I don't understand the concept of multiple invocants. How does that
> work?
If my ability to parse the Synopses was very good, I'd tell you where I saw
mention of it - or maybe it was in the mailing list. Either way that is the
point of the colon in the:
method foo ($self: $arg1, $arg2) {}
So that in theory there would be
method foo ($self, $otherself: $arg1, $arg2) {}
In the end, I'd just like the rules for what .meth does and what $_ is to be
concise and clear - whatever the sytax is that is adopted.
Paul
Re: -X's auto-(un)quoting?
Paul Seamons wrote:
method foo {
for 1 .. 10 {
$^.method(.sqrt);
}
}
I would make that:
method foo
{
for 1 .. 10
{
.method sqrt: # $?SELF.method( $_.sqrt() )
}
}
Then usage is:
my $x = "blubb";
$x.foo; # $x.method( sqrt(1) ) .. $x.method( sqrt(10) )
Iff "blubb" has got a method .method that takes a Num as param ;)
--
TSa (Thomas Sandlaß)
Re: -X's auto-(un)quoting?
Paul Seamons skribis 2005-04-25 11:12 (-0600): > By this reasoning - why have a shortcut to any of the invocants at all? This > thread has headed in the direction of finding a way to figure out how to call > methods on the invocant without using the signatures name. On a method call > without a signature and without invoking Perl5isms there would not be a "way > back" to the invocant once you enter nested block. > The point of all of this discussion is to not have to set $self to anything. > The argument for .meth as opposed to $self.meth of $_.meth was that .meth was > clear enough to mean the current topic and was a nice huffmanization. Agreed, but you put it as if there was no way of getting there, instead of there being a way that isn't satisfactory. I agree that having a short way to use the invocant is good, and like your $^ proposal. I still don't understand what the "second invocant" could be, though. Another character that has no prefix meaning yet is >. <> are a bit overused already, but perhaps this can fit in. It has the benefit of being shift+dot on a US keyboard :P > That works great - so long as I specify the signature. I'm lazy, I > don't want to type the signature all the time. Consider: When will people realise that this "problem" is exactly the same thing as what you get when two other topicalizers are nested, and TREAT it like exactly the same problem, so that a solution can be invented that solve both "problems" in one stroke. This said, I really do think the ^ thing is nice. But if you really think not having a short syntax to reach something in a higher level block is a problem, then be consistent and declare nested given/for blocks a problem too. The "current invocant" problem is really not that much different from the "outer topic" "problem", or, in larger scope, the "outer block" problem, which is solved with labels. outer topic problem name it, or use OUTER:: outer block problem name it (label it) invocant problemname it! or use $?SELF The same problem comes up whenever things can nest. So I'm more or less expecting discussion about outer rule problem outer class|grammar problem (?) parent process %ENV problem (learn to live with it) parent object problem (familiar...) Whether or not naming it is the answer in every occassion is a good question. Probably when dealing with parent stuff, it is not, because we want those things to be anonymous more often than the other things. 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?
Thomas Sandlaß skribis 2005-04-25 19:30 (+0200): > .method sqrt: # $?SELF.method( $_.sqrt() ) I don't like your solution simply because I don't like indirect object calls. I avoid to and want to continue to avoid them, and do want a short way for $_. Besides that, I think whatever default is chosen should be consistently applied to both syntaxes. Of course, the same consistency prescripbes that $_ be that default... 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?
Thomas Sandlaß skribis 2005-04-25 19:13 (+0200): > I think your basic error in perception is that $_ is a runtime variable > while the invocant(s) are more a design time assumption of what the > method is working on. $_ is the *topic*. Its role in design and thinking is gigantic. The funny thing is that in this way, the invocant is just that: being important for design and thinking, and that makes it... a topic. Following this, considering the topic and the invocant the same thing works. Until you temporarily change the topic, which means that if you want the previous topic, you have to be more specific when referring to it. This is consistent with natural languages as well. Having two topics, one for the short stuff ($_, sentence) and one for the long stuff ($self, paragraph) makes sense too. I recall having read that Japanese had something like that. But making the default thing you're referring to anything but the most recent (in programming: innermost) topic, is madness. (While typing this, I realised that there may be, in English, a difference between subject and topic. If that's true, please educate me.) > E.g. in methods of GUI classes the invocant would be the selected widget > and the topic the event. In my thinking, the event would not be named, because it is not something you operate on. Events just happen - it should be the name of the method, and the code inside should very rarely need that information (except when needed to call a supermethod, for example). The event being the topic makes sense only if all events are handled by the same method, in which you use a dispatch table. But OO itself is a pretty neat dispatching machine already. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
use junction
I think it would be great to be able to use a junction with use: use strict & warnings; A disjunction could mean any of the listed modules suffices. This comes in handy when you code something that will work with any of three XML parsers. Although because ordering matters, the // operator is perhaps better. But "use strict & warnigs;" looks great and I wonder if it can work. 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?
Paul Seamons wrote:
So then, to get back to the invocant... I can't say that I liked many of the
proposals. The one that seemed to have merit though was $^. I'd propose the
following.
meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the invocant
$^.meth; # is the invocant
$^1.meth; # is the first invocant
$^2.meth; # is the second invocant
I'm starting to get confused at the "need" for all these special
variables. I vote that we steal from prior art in numerous other
languages and just auto-set $SELF or $THIS or whatever and call it done.
Having .method assume $SELF is an added nicety, but if it introduces
added parsing problems then it's hardly worth it.
OR, choose $^ and don't set $SELF (or $?SELF or whatever), but having
dup short and long names is a waste, since people will always chose the
short one (who uses English in Perl 5, really?)
-Nate
Re: -X's auto-(un)quoting?
> > meth foo {
> > $_.meth; # defaults to the invocant
> > .meth; # operates on $_ which defaults to the invocant
> > $^.meth; # is the invocant
> > $^1.meth; # is the first invocant
> > $^2.meth; # is the second invocant
>
> I'm starting to get confused at the "need" for all these special
> variables. I vote that we steal from prior art in numerous other
> languages and just auto-set $SELF or $THIS or whatever and call it done.
The problem is that there is no globally safe name to use that uses letters
only. Also there is a certain line noise problem (which may not really be a
problem - but looks like one once we have a more concise alternative):
method foo {
$SELF.prop = $SELF.meth($SELF.get_foo, $SELF.get_bar);
$SELF.say("Hello " ~ $SELF.prop);
}
That looks considerably more messy than:
method foo {
$.prop = .meth(.get_foo, .get_bar);
.say("Hello " ~ $.prop);
}
Perl syntax is wonderful for being able to say as much as possible without
losing meaning - assuming you can read perl. The short identifiers are able
to express a lot in a little space.
> Having .method assume $SELF is an added nicety, but if it introduces
> added parsing problems then it's hardly worth it.
The .method problem isn't about parsing - it is about knowing which variable
it applies to.
Current syntax would do:
method foo ($self:) {
return grep { $self.is_ok( .value ) } $self.info_pairs;
# .value called on the topic $_
}
Proposed syntax previous to this thread
method foo {
return grep { .is_ok( $_.value ) } .info_pairs;
# .is_ok called on invocant not the topic
}
Proposed syntax in this thread (among various others)
method foo {
return grep { $^.is_ok( .value ) } $^.info_pairs;
# .value called on the topic
}
The goal is to be able to be concise yet intuitive - so that you could do:
my @good_objects = grep { .is_ok } @candidate_objects;
> OR, choose $^ and don't set $SELF (or $?SELF or whatever), but having
> dup short and long names is a waste, since people will always chose the
> short one (who uses English in Perl 5, really?)
That is the goal - to find some nice variable that looks vaguely usable and
that people won't rebel against using.
Paul
surprising consequences
Assuming the following are true:
A: "if" is now a normal function
B: "foo() + 3" is (foo) + 3, foo doesn't get 3.
Then does that mean we're stuck with:
C: "if($foo) { say 'foo' }" being a syntax error?
I currently think A is wrong. Am I right?
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?
Paul Seamons skribis 2005-04-25 13:02 (-0600):
> method foo ($self:) {
>return grep { $self.is_ok( .value ) } $self.info_pairs;
># .value called on the topic $_
> }
I think that to be fair, you have to leave out the redundant $self
there.
return grep { $self.is_ok( .value ) } .info_pairs;
> Proposed syntax in this thread (among various others)
> method foo {
> return grep { $^.is_ok( .value ) } $^.info_pairs;
> # .value called on the topic
> }
I think that also wanted:
method foo {
return grep { ^is_ok( .value ) } ^info_pairs;
# .value called on the topic
}
> That is the goal - to find some nice variable that looks vaguely usable and
> that people won't rebel against using.
Variable or alternative for the dot.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
calls and parens
Which assumptions are wrong?
foo (3) + 4;# foo(7)
foo(3) + 4; # foo(3)
foo.(3) + 4;# foo(3)
foo .(3) + 4; # foo(3)
$foo (3) + 4; # syntax error
$foo(3) + 4;# $foo(3)
$foo.(3) + 4; # $foo(3)
$foo .(3) + 4; # $foo(3)
$o.m (3) + 4; # syntax error
$o.m(3) + 4;# m(3)
What do these mean?
$o.m .(foo) # m(foo) or m().(foo) ???
$o.m.(foo) # m(foo) or m().(foo) ???
In the case of m(foo), m().(foo) is the obvious way to call the returned
sub.
In the case of m().(foo), I would not have any idea how to put
whitespace in between method and opening paren.
This leads me to believe that $o.m.(foo) and $o.m .(foo) are $o.m(foo).
-
Parens cannot be used to group an expression which is then
used as a method name:
$o.("on_" ~ %methods{$event}).(); # $o(...)
Is there a way to do this without temporary variable?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Quickcheck of context of index expressions
Another quick check on expression context for indexed expressions. Please sanity-check the return value of want() below: @x[0] = want(); # scalar context @x[want()] = $_; # scalar context @x[want()] = @_; # scalar context @x[0,] = want(); # list context @x[want(),] = $_; # list context @x[want(),] = @_; # list context $_ = @x[want()]; # scalar context @_ = @x[want()]; # list context Thanks, /Autrijus/ pgpQvZn38vOod.pgp Description: PGP signature
Re: surprising consequences
Juerd wrote:
Assuming the following are true:
A: "if" is now a normal function
B: "foo() + 3" is (foo) + 3, foo doesn't get 3.
Then does that mean we're stuck with:
C: "if($foo) { say 'foo' }" being a syntax error?
I currently think A is wrong. Am I right?
Juerd
There will always be various control constructs that cannot be written
as an equivalent function. Otherwise, there is no way to write the
higher level ones.
I suspect that "goto" and "if" are on this list. Possibly they are the
only things on this list, but "return" is a strong contender.
Additionally, any predicate form cannot be a "normal function". You
might be able to define an &infix:, but getting to where you don't
need the {}'s on the LHS block, and getting a proper list on the RHS
gets rather abnormal.
Something that crossed my mind while writing this: Does
for { say } <== @a;
Work?
-- Rod Adams
Re: surprising consequences
Rod Adams skribis 2005-04-25 14:37 (-0500):
> There will always be various control constructs that cannot be written
> as an equivalent function. Otherwise, there is no way to write the
> higher level ones.
Not a problem, because we're using something to bootstrap, and the perl
6 you'll be using to run your Perl 6 scripts will be in compiled form,
free of any need to parse itself.
Self-definition is a wonderful thing.
> Something that crossed my mind while writing this: Does
>for { say } <== @a;
> Work?
If for's just a function that takes a slurpy list, then I see no reason
why not.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Quickcheck of context of index expressions
On Tue, Apr 26, 2005 at 03:33:44AM +0800, Autrijus Tang wrote:
> Another quick check on expression context for indexed expressions.
> Please sanity-check the return value of want() below:
>
> @x[0] = want(); # scalar context
> @x[want()] = $_; # scalar context
> @x[want()] = @_; # scalar context
> @x[0,] = want(); # list context
> @x[want(),] = $_; # list context
> @x[want(),] = @_; # list context
> $_ = @x[want()]; # scalar context
> @_ = @x[want()]; # list context
Oh, and under the S02 rules above (the index expression inherits
outer context on RHS), Pugs currently does this:
$_ = %x{ 1, 2 }
--- reduces to ---
$_ = %x{ [1, 2] }
--- reduces to ---
$_ = %x{ "1 2" }
Which is, well, very surprising. Where did I get wrong?
Thanks,
/Autrijus/
pgpWPjfDiyNHu.pgp
Description: PGP signature
Re: surprising consequences
Juerd writes:
> Assuming the following are true:
>
> A: "if" is now a normal function
Almost. It's a statement-level form, which looks like a normal function
except for the statement: prepended on its name. Such constructs (which
include for, while, the whole gang) have a few special properties:
* They can't be used intra-expression.
say 3 + if foo() { 4 } else { 5 }# error!
* An opening brace anywhere (not inside brackets) in operator position
gets passed to them:
sub foo ([EMAIL PROTECTED]);
sub bar ([EMAIL PROTECTED]);
if foo 1, bar 2 { ... }
^ belongs to the if
You could use if() intra-expression like so:
say 3 + &statement().({foo()}):{4}:{5};
(Ick).
Luke
Re: calls and parens
Juerd writes:
> Which assumptions are wrong?
>
> foo (3) + 4;# foo(7)
> foo(3) + 4; # foo(3)
> foo.(3) + 4;# foo(3)
> foo .(3) + 4; # foo(3)
>
> $foo (3) + 4; # syntax error
> $foo(3) + 4;# $foo(3)
> $foo.(3) + 4; # $foo(3)
> $foo .(3) + 4; # $foo(3)
>
> $o.m (3) + 4; # syntax error
> $o.m(3) + 4;# m(3)
none(@above)
> What do these mean?
>
> $o.m .(foo) # m(foo) or m().(foo) ???
> $o.m.(foo) # m(foo) or m().(foo) ???
>
> In the case of m(foo), m().(foo) is the obvious way to call the returned
> sub.
>
> In the case of m().(foo), I would not have any idea how to put
> whitespace in between method and opening paren.
>
> This leads me to believe that $o.m.(foo) and $o.m .(foo) are $o.m(foo).
Yep.
> Parens cannot be used to group an expression which is then
> used as a method name:
>
> $o.("on_" ~ %methods{$event}).(); # $o(...)
Well, you can't do that anyway. It has to be:
$o.::("on_" ~ %methods{$event}).()
Which I believe does the right thing anyway.
Luke
Re: -X's auto-(un)quoting?
Paul Seamons wrote:
meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the invocant
$^.meth; # is the invocant
$^1.meth; # is the first invocant
$^2.meth; # is the second invocant
I'm starting to get confused at the "need" for all these special
variables. I vote that we steal from prior art in numerous other
languages and just auto-set $SELF or $THIS or whatever and call it done.
The problem is that there is no globally safe name to use that uses letters
only. Also there is a certain line noise problem (which may not really be a
problem - but looks like one once we have a more concise alternative):
I understand the purported problem, but what I'm saying is that it
really isn't one. Variables magically coming into existence doesn't seem
to be a problem for any language but Perl 6. Many other languages set
"this" automagically.
> method foo {
> $SELF.prop = $SELF.meth($SELF.get_foo, $SELF.get_bar);
> $SELF.say("Hello " ~ $SELF.prop);
> }
I'm not sure the point of this block; it's hardly horrific. Any external
script would have to say:
$invocation = new Class;
$invocation.meth($invocation.get_foo, $invocation.get_bar);
If the point is that $^ saves typing over $?SELF then I agree; my point
is simply that we pick one or the other, instead of both/aliases/etc.
-Nate
Re: -X's auto-(un)quoting?
Juerd writes: > (While typing this, I realised that there may be, in English, a > difference between subject and topic. If that's true, please educate > me.) Well, from a non-linguist's point of view, they are two very different things. My brother asked me to take out the trash. I asked him to do it. I believe that the subject there is "my brother" in the first sentence and "I" in the second. The topic is either "to take out the trash" or just "the trash" throughout (English speakers wouldn't have any trouble allowing it to be both). Interesting, this is the same kind of reasoning (and backwards naming) that I used when I proposed ` as the "subjective" dot. Speaking of such a dot, there are things I like about ^ and things I don't. It is fairly visually intrusive on the one hand. On the other, it's on the top of the line rather than the bottom, which makes a nice contrast from the regular dot. As alternatives, Damian has suggested Âmeth(), and I've suggested Âmeth(). They both look wrong. I'm not even sure we're on the right track, changing the dot (changing the dot also includes Thomas's proposal: his dot is just postfix). I do think that considering the distinction between "subject" and "topic" is important to getting it right, however. Luke
Re: -X's auto-(un)quoting?
Nathan Wiger skribis 2005-04-25 13:35 (-0700): > My point is simply that we pick one or the other, instead of > both/aliases/etc. But TIMTOWTDI. One way may be great for writing maintainable code, while the other is useful in oneliners (including single line method definitions). 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?
Nathan Wiger writes:
> Paul Seamons wrote:
> >>> meth foo {
> >>>$_.meth; # defaults to the invocant
> >>>.meth; # operates on $_ which defaults to the invocant
> >>>$^.meth; # is the invocant
> >>>$^1.meth; # is the first invocant
> >>>$^2.meth; # is the second invocant
> >>
> >>I'm starting to get confused at the "need" for all these special
> >>variables. I vote that we steal from prior art in numerous other
> >>languages and just auto-set $SELF or $THIS or whatever and call it done.
> >
> >
> >The problem is that there is no globally safe name to use that uses
> >letters only. Also there is a certain line noise problem (which may not
> >really be a problem - but looks like one once we have a more concise
> >alternative):
>
> I understand the purported problem, but what I'm saying is that it
> really isn't one. Variables magically coming into existence doesn't seem
> to be a problem for any language but Perl 6. Many other languages set
> "this" automagically.
>
> > method foo {
> > $SELF.prop = $SELF.meth($SELF.get_foo, $SELF.get_bar);
> > $SELF.say("Hello " ~ $SELF.prop);
> > }
>
> I'm not sure the point of this block; it's hardly horrific.
I think it is. It's obviously a matter of taste. But all those $SELFs,
in my opinion, really take away from the meaning of the code. I loathe
reading such Perl 5 OO code, for precisely the same reason. We already
have a shorthand (which is an only-hand in some cases) for accessing
attributes:
method foo {
$.prop = $self.meth($.foo, $.bar);
$self.say("Hello $.prop");
}
And it seems natural to go for methods too, especially since attributes
are allowed just to be fancy methods.
I have always wondered what would happen if we blurred the distinction
altogether. It's tricky, because you need direct access to implement
accessors. But since variables for which accessors are not
automatically generated are already marked as $:, perhaps it is an
option:
class Point {
has $.x is rw;
has $.y is rw;
has Pdl $:coords;
method set_coords(Pdl $new) {
($.x, $.y) = ($new  $:coords.inverse  Pdl.new($.x, $.y)).list;
$:coords = $new;
}
method swap_coords() {
$.set_coords(Pdl([0, 1; 1, 0])); # calls a method with $. syntax
}
}
Luke
Re: -X's auto-(un)quoting?
Juerd wrote:
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
My point is simply that we pick one or the other, instead of
both/aliases/etc.
But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
definitions).
Then I suggest "use English" for Perl 6 too. I think you'll find that,
like Perl 5, people always use the short forms.
Has ANYONE on this list ever done something like this?
use English;
if ($OSNAME =~ /MSWin32/) {
$OUTPUT_AUTOFLUSH++;
local $WARNING = 0;
print "Windoze\n" or die "Can't print: $OS_ERROR";
}
I'd bet everyone would write that as:
if ($^O =~ /MSWin32/) {
$|++;
local $^W = 0;
print "Windoze\n" or die "Can't print: $!";
}
Crap, I had to open the Camel just to find the long names. :-)
-Nate
P.S. I know this is the first time I've spoken up on Perl 6
in 5-ish years, so nice to "see" you all once again
Re: -X's auto-(un)quoting?
Nathan Wiger wrote:
Juerd wrote:
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
My point is simply that we pick one or the other, instead of
both/aliases/etc.
But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
definitions).
Then I suggest "use English" for Perl 6 too. I think you'll find that,
like Perl 5, people always use the short forms.
Has ANYONE on this list ever done something like this?
use English;
if ($OSNAME =~ /MSWin32/) {
$OUTPUT_AUTOFLUSH++;
local $WARNING = 0;
print "Windoze\n" or die "Can't print: $OS_ERROR";
}
Not exactly a fair comparison, since it's common to not "use English"
due to the $& issue.
I suspect that if that was not the case, it would be used more.
-- Rod Adams
