Re: Coupla Questions
Damian Conway wrote:
>
> Graham wrote:
>
>> Now I may be wrong here, but I thought I remembered something about
>>
>> .foo being the same as $_.foo
>
> It's certainly a possibility.
>
>> In which case you could do
>>
>>for (%database.$accountnumber) {
>>
>>.interestearned += $interestrate * .balance
>>
>>}
>
> Larry doesn't favour using C thus, beause it introduces a sly
> list context. That argument convinced me.
>
> But there might well be another keyword for the same idea and that might tie
> into switch statements too.
>
> Damian
The data working group settled on %_ for this, as I recall it was
a consensus without objection.
--
David Nicol 816.235.1187
Signature closed for repaving
Re: Coupla Questions
Graham wrote:
> Now I may be wrong here, but I thought I remembered something about
>
> .foo being the same as $_.foo
It's certainly a possibility.
> In which case you could do
>
>for (%database.$accountnumber) {
>
>.interestearned += $interestrate * .balance
>
>}
Larry doesn't favour using C thus, beause it introduces a sly
list context. That argument convinced me.
But there might well be another keyword for the same idea and that might tie
into switch statements too.
Damian
Re: Coupla Questions
On Mon, Jun 11, 2001 at 10:39:51PM -0500, David L. Nicol wrote:
> Hopefully, we'll get a "with" operator and everything:
>
> with %database.$accountnumber {
>
> .interestearned += $interestrate * .balance
>
> }
>
> anything short of that, in my opinion, is merely trading old ugly for
> new ugly.
Now I may be wrong here, but I thought I remembered something about
.foo being the same as $_.foo
In which case you could do
for (%database.$accountnumber) {
.interestearned += $interestrate * .balance
}
Graham.
Re: Coupla Questions
Damian Conway wrote:
>
> Graham asked:
>
>> IIRC there was some suggestion of a class being able to declare
>> elements to be accessable as methods in this was.
>>
>> So if $ref is of a known type and 'a' was declared in that way,
>> the parser would take $ref.a and turn it into $ref.{a}
>
> This is intended. I'm not sure Larry's decided the exact mechanism yet.
Hopefully, we'll get a "with" operator and everything:
with %database.$accountnumber {
.interestearned += $interestrate * .balance
}
anything short of that, in my opinion, is merely trading old ugly for
new ugly.
Re: Coupla Questions
On Tue, Jun 12, 2001 at 09:20:20AM +1000, Damian Conway wrote: > Subscripts don't fit here at all. And, in my option, shouldn't be made too. Oh good, I was hoping you would say that; I misunderstood your message from the 7th of June further up this thread to mean that dot was optional in subscripting. If dot's "just" a method, property or dereference operator that makes it a whole host easier to deal with. -- I've looked at the listing, and it's right! -- Joel Halpern
Re: Coupla Questions
> What I was asking, in a roundabout way, was if
> $foo.bar.baz
> makes sense; your answer suggests that it does. In which case, we can
> teach the parser that a property query is just like a method call is
> just like a hash or array element (with optional dereference if you're
> calling $foo.{bar} instead of %foo.{bar}.)
Subscripts don't fit here at all. And, in my option, shouldn't be made too.
It's:
%foo{bar}
@foo[$bar]
not:
%foo.{bar}
@foo.[$bar]
The dereferencing dot is an error there.
I believe it's vitally important not to mix everything together syntactically
(or semantically!)
Damian
Re: Coupla Questions
On Tue, Jun 12, 2001 at 09:08:04AM +1000, Damian Conway wrote:
>> Can properties have properties?
> No, but their scalar values can.
What I was asking, in a roundabout way, was if
$foo.bar.baz
makes sense; your answer suggests that it does. In which case, we can
teach the parser that a property query is just like a method call is
just like a hash or array element (with optional dereference if you're
calling $foo.{bar} instead of %foo.{bar}.)
--
You're not Dave. Who are you?
Re: Coupla Questions
Graham asked:
> IIRC there was some suggestion of a class being able to declare
> elements to be accessable as methods in this was.
>
> So if $ref is of a known type and 'a' was declared in that way,
> the parser would take $ref.a and turn it into $ref.{a}
This is intended. I'm not sure Larry's decided the exact mechanism yet.
> This would have the benefit of not loosing encapsulation and
> also the performance of not having to call a method which would
> just look like
>
> sub a(Foo $self) :lvalue { $self->{a} }
>
> (Did I get that syntax right ? probably not :)
Try this:
sub a(Foo $self) is rw { $self{a} } # or $self.{a}
Damian
Re: Coupla Questions
Simon asked: > Are properties subscriptable? (Can the value of a property be a > reference that can be dereferenced?) Property values can be any scalar value, including array, hash, and code refs. > Can properties have properties? No, but their scalar values can. Damian
Re: Coupla Questions
> > $ref.{a}can be $ref{a}
>
> which can also be
>
> $ref.a
>
> can it not?
Err..no.
$ref.{a}/$ref{a} is an access on a hash element through the hashref in $ref.
$ref.a is a call to the method a() of the object referred to by $ref.
Damian
Re: Coupla Questions
On Wed, Jun 06, 2001 at 04:30:56PM +0100, Simon Cozens wrote: > I'm sure I'll think of some more questions Are properties subscriptable? (Can the value of a property be a reference that can be dereferenced?) Can properties have properties? -- The complex-type shall be a simple-type. ISO 10206:1991 (Extended Pascal)
Re: Coupla Questions
On Thu, Jun 07, 2001 at 08:15:46AM +0100, Simon Cozens wrote:
> On Wed, Jun 06, 2001 at 07:21:29PM -0500, David L. Nicol wrote:
> > Damian Conway wrote:
> > > $ref.{a}can be $ref{a}
> > which can also be
> > $ref.a
>
> Dereferencing a hashref is the same as accessing a property?
IIRC there was some suggestion of a class being able to declare
elements to be accessable as methods in this was.
So if $ref is of a known type and 'a' was declared in that way,
the parser would take $ref.a and turn it into $ref.{a}
This would have the benefit of not loosing encapsulation and
also the performance of not having to call a method which would
just look like
sub a(Foo $self) :lvalue { $self->{a} }
(Did I get that syntax right ? probably not :)
Graham.
Re: Coupla Questions
On Wed, Jun 06, 2001 at 07:21:29PM -0500, David L. Nicol wrote:
> Damian Conway wrote:
> > $ref.{a}can be $ref{a}
> which can also be
> $ref.a
Dereferencing a hashref is the same as accessing a property?
I hope not.
--
Did you know that 1 barn yard atmosphere = 9.2e-17 erg?
Re: Coupla Questions
On Thu, Jun 07, 2001 at 01:17:45AM +0100, Simon Cozens wrote: > On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote: > > Can someone post a few ? I am open to what are the pros/cons > > but right now my mind is thinking " Whats the benefit of making > > $a=(1,2,3); be the same as $a=[1,2,3]; when it could do something > > different, ie what it does in perl5" > > A reason against making the behaviours ($foo=array vs. $foo=list) > different would be that you're then making lists and arrays more > distinct than necessary. Does this make $foo a reference, or the number > of elements: But if you change () consider, how do you do $min = (localtime(time))[1]; and if () creates a reference what does $x = (1 + 2) * 3; it's still () in a scalar context. IIRC when Larry covered this, he did not suggest changing (), but changing the meaning of the , in the scalar context. () is a grouping contruct, not a list generator. Graham.
Re: Coupla Questions
Damian Conway wrote:
> $ref.{a}can be $ref{a}
which can also be
$ref.a
can it not?
Re: Coupla Questions
Graham Barr <[EMAIL PROTECTED]>:
>On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote:
>> [EMAIL PROTECTED] writes:
>> :> What should $foo = (1,2,3) do now? Should it be the same as what
>> :> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC
does what
>> :> $foo = \@INC; does now.) Putting it another way: does a list in
scalar
>> :> context turn into a reference, or is it just arrays that do that?
>> :
>> : Just arrays, I believe.
>>
>> That hasn't actually been decided yet. There are good arguments on
>> both sides.
>
>Can someone post a few ? I am open to what are the pros/cons
>but right now my mind is thinking " Whats the benefit of making
>$a=(1,2,3); be the same as $a=[1,2,3]; when it could do something
>different, ie what it does in perl5"
I'm wondering if () should keep its functionality as a list composer at all.
Perhaps it should just be:
$foo=($a, $b); #$foo is equal to $b
$foo=[$a, $b]; #$foo is an array ref
$foo={$a, $b}; #$foo is a hash ref
@foo=($a, $b); #same as @foo=$b (what would that do?)
@foo=[$a, $b]; #@foo is an array containing $a and $b
@foo={$a, $b}; #@foo is an array containing $a, '', $b, '' (?)
%foo=($a, $b); #same as %foo=$b (what would that do?)
%foo=[$a, $b]; #%foo is a hash containing $a => $b (?)
%foo={$a, $b}; #%foo is a hash containg $a => '', $b => '' (?)
Thus,
($a, $b)=($c, $d); #$b=$d
[$a, $b]=[$c, $d]; #$a=$c; $b=$d; (except inline)
{$a, $b}={$c, $d}; # ???
This means that each of the wraparound things has exactly one meaning,
regardless of context. It also gives () back its C meaning, grouping stuff
together so it'll be evaluated first, instead of a meaning that can be
different in different contexts. (In general, I think that "syntactic
operators" like parenthesis and comma should behave the same regardless of
scalar/list context, while functions should behave differently. That's just
my bias, though. Feel free to laugh at me if I'm wrong here.)
--Brent Dax
[EMAIL PROTECTED]
Re: Coupla Questions
On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote: > Can someone post a few ? I am open to what are the pros/cons > but right now my mind is thinking " Whats the benefit of making > $a=(1,2,3); be the same as $a=[1,2,3]; when it could do something > different, ie what it does in perl5" A reason against making the behaviours ($foo=array vs. $foo=list) different would be that you're then making lists and arrays more distinct than necessary. Does this make $foo a reference, or the number of elements: $foo = (@bar=(1,2,3)); or this: $foo = @bar = (1,2,3); But on the other hand, what about? $foo = (1,2,3); @bar = (1,2,3); $foo = @bar; # Array in scalar context, so ref? @bar = (1,2,3); $foo = (@bar); # "List" in scalar context, so number? ($foo) = @bar; # Array in list context, ...? ($foo) = (@bar); # List in list context, ...? But then, what does this do? $foo = (3, 4, @bar, 5); Is the 2nd element treated as a "scalar context", so you get a reference to @bar in there, or does list flattening still apply? See, if you make $a=(1,2,3) take a reference just like $a=[1,2,3], this frees up [] for something else. You could have () for flattening and [] for non-flattening lists. (Something somehow seems LISP-like about that idea, but it's been too long...) So that's an argument for, uh, something me going to sleep, I think. Oh, one last thing: is $a = @foo; # Perl 6 equivalent to $a = [ @foo ]; # Makes a copy or $a = \@foo; # Takes a direct reference ? The former extends to lists, the latter doesn't. -- I don't understand how people can think SCSI is anything more quirky than a genius with peculiar dietary requirements in a world where the creators of Notes, and their new owners, are allowed to walk the streets without fearing for their very lives. - Graham Reed, asr
Re: Coupla Questions
On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote: > [EMAIL PROTECTED] writes: > :> What should $foo = (1,2,3) do now? Should it be the same as what > :> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what > :> $foo = \@INC; does now.) Putting it another way: does a list in scalar > :> context turn into a reference, or is it just arrays that do that? > : > : Just arrays, I believe. > > That hasn't actually been decided yet. There are good arguments on > both sides. Can someone post a few ? I am open to what are the pros/cons but right now my mind is thinking " Whats the benefit of making $a=(1,2,3); be the same as $a=[1,2,3]; when it could do something different, ie what it does in perl5" Graham.
Re: Coupla Questions
[EMAIL PROTECTED] writes: :> What should $foo = (1,2,3) do now? Should it be the same as what :> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what :> $foo = \@INC; does now.) Putting it another way: does a list in scalar :> context turn into a reference, or is it just arrays that do that? : : Just arrays, I believe. That hasn't actually been decided yet. There are good arguments on both sides. Larry
Re: Coupla Questions
On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote: > But it's not as *convenient* as "unadorned" interpolation. Disagree. "Adorning" a piece of syntax reminds the programmer that something out of the ordinary is happening. It's a mental speed limit sign - a traffic light, if you like - that forces you to slow down to work out what's really going on. Briefly: Complicated syntax is a GOOD THING for complicated semantics. /foo.$bar.baz/can be accidentally speed-read as /foo.bar.baz/ /foo.$($bar.baz)/ means "Uhoh, something's going on". -- Premature optimization is the root of all evil. -- D.E. Knuth
Re: Coupla Questions
> > But it's not as *convenient* as "unadorned" interpolation.
>
> Sometimes convenient has to give way
Here we differ. I think the frequency of the
/$var.ident(whatever)/
pattern is likely to be low enough that method interpolation is a
better use for the syntax.
> > Expecially if we expect method calls to be frequently interpolated.
>
> I don't hear people screaming because it's difficult in perl5,
Mainly because they use /$var->{raw_attribute}/, which we want to discourage.
And which won't be available on opaque objects.
> so I doubt it will be very frequent.
Perl 6's interface is likely to be far more OO than Perl 5's, so this may not
be the case. For example: Perl 5's $#array syntax becomes something
like @array.length (i.e. a method call)
> But even the $() is easier than the current perl5 way to do it.
There we definitely do agree :-)
Damian
Re: Coupla Questions
On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote: >> But with the above you still have abiguity, for example what does this do >> >> $bar =~ /$foo.colour($xyz)/; > > "Looks like a method call with parens, so *is* a method call with parens." > > >> I may be remembering about interpolation into strings as "$file.ext" is >> going to be common. But I do think the $() approach is clean and >> unambiguous > > I agree wholeheartedly. Good. > But it's not as *convenient* as "unadorned" interpolation. Sometimes convenient has to give way > Expecially if we expect method calls to be frequently interpolated. I don't hear people screaming because it's difficult in perl5, so I doubt it will be very frequent. But even the $() is easier than the current perl5 way to do it. Graham.
Re: Coupla Questions
> But with the above you still have abiguity, for example what does this do > > $bar =~ /$foo.colour($xyz)/; "Looks like a method call with parens, so *is* a method call with parens." > I may be remembering about interpolation into strings as "$file.ext" is > going to be common. But I do think the $() approach is clean and > unambiguous I agree wholeheartedly. But it's not as *convenient* as "unadorned" interpolation. Expecially if we expect method calls to be frequently interpolated. Damian
Re: Coupla Questions
On Thu, Jun 07, 2001 at 07:43:55AM +1000, Damian Conway wrote: > >> >> So, to match $foo's colour against $bar, I'd say >> >> >> >> $bar =~ /$foo.colour/; >> > >> > No, you need the sub call parens as well: >> > >> > $bar =~ /$foo.colour()/; >> >> Hm, I thought Larry said you would need to use $() to interpolate >> a method call. So this would be >> >> $bar =~ /$($foo.colour)/; > > That was not my understanding. At least not for (pseudo-)method calls. But with the above you still have abiguity, for example what does this do $bar =~ /$foo.colour($xyz)/; I may be remembering about interpolation into strings as "$file.ext" is going to be common. But I do think the $() approach is clean and unambiguous Graham.
Re: Coupla Questions
> >> So, to match $foo's colour against $bar, I'd say > >> > >> $bar =~ /$foo.colour/; > > > > No, you need the sub call parens as well: > > > > $bar =~ /$foo.colour()/; > > Hm, I thought Larry said you would need to use $() to interpolate > a method call. So this would be > > $bar =~ /$($foo.colour)/; That was not my understanding. At least not for (pseudo-)method calls. But many things are still in flux and I may well have missed a meeting. ;-) Damian
Re: Coupla Questions
On Thu, Jun 07, 2001 at 06:37:26AM +1000, Damian Conway wrote: > >> So, to match $foo's colour against $bar, I'd say >> >> $bar =~ /$foo.colour/; > > No, you need the sub call parens as well: > > $bar =~ /$foo.colour()/; Hm, I thought Larry said you would need to use $() to interpolate a method call. So this would be $bar =~ /$($foo.colour)/; Graham.
Re: Coupla Questions
> So, to match $foo's colour against $bar, I'd say
>
> $bar =~ /$foo.colour/;
No, you need the sub call parens as well:
$bar =~ /$foo.colour()/;
> Great, but how do I match $foo followed by any character followed by the
> literal "colour"?
$bar =~ /$foo.colour/;
> Would I have to use "\Q"?
No. You could use the $(...) scalar interpolator instead:
$bar =~ /$($foo).colour/;
> >> print "ok 5" unless ref ($a=(1,2,3))'
> ^^
Sorry, in my haste I missed that twist. You are, of course, correct.
> >> Oh, hrm. Shouldn't it be $a{test2}?
> > Yes. Or $a.{test}
>
> So "." isn't necessarily the "property" operator, then? OK.
> Time to spend more quality time with YACC. :(
Now there's an oxymoron, if ever I heard one. ;-)
Damian
Re: Coupla Questions
Thanks *very* much for your answers; I still have a lot of work left
to do, it seems. But I'm still a little confused:
On Thu, Jun 07, 2001 at 06:08:23AM +1000, Damian Conway wrote:
>> Should properties interpolate in regular expressions? (and/or strings)
> Do you mean property look-ups via the pseudo-method syntax?
> In that case, yes they should
So, to match $foo's colour against $bar, I'd say
$bar =~ /$foo.colour/;
Great, but how do I match $foo followed by any character followed by the
literal "colour"? Would I have to use "\Q"?
> Err. I *would* expect sub call iterpolation in regexes, since they will
> interpolate in qq{...} contexts, and that's what a regex basically is.
Fair enough.
> /&bar($baz,$quux)/; # match interpolated value of call to
Ah, good. Much easier to parse.
> Just arrays, I believe.
Good, that's what was planning on.
>> print $a->{test2};
> die "Unexpected > after subtraction operation. Did you mean $a.{test2}???"
Urgh. OK, arrow is dead. That also makes things easier. Probably.
>> print "ok 5" unless ref ($a=(1,2,3))'
^^
> No. Equivalent to ref($a=3), I believe
Since ref($a=3) is undef, that should print "ok 5".
>> Oh, hrm. Shouldn't it be $a{test2}?
> Yes. Or $a.{test}
So "." isn't necessarily the "property" operator, then? OK.
Time to spend more quality time with YACC. :(
--
"If you want to travel around the world and be invited to speak at a lot
of different places, just write a Unix operating system."
(By Linus Torvalds)
Re: Coupla Questions
> Should properties interpolate in regular expressions? (and/or strings)
Do you mean property look-ups via the pseudo-method syntax?
In that case, yes they should
> I don't suppose they should, because we don't expect subroutines to.
> (if $foo =~ /bar($baz,$quux)/;? Urgh, maybe we need m//e)
Err. I *would* expect sub call iterpolation in regexes, since they will
interpolate in qq{...} contexts, and that's what a regex basically is.
But what you showed is not the syntax for it:
/bar($baz,$quux)/; # match bar then match-and capture
# matches of interpolated value of $baz,
# a comma, interpolated value of $quux
/&bar($baz,$quux)/;# match interpolated value of call to
# bar with two args
> What should $foo = (1,2,3) do now? Should it be the same as what
> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
> $foo = \@INC; does now.) Putting it another way: does a list in scalar
> context turn into a reference, or is it just arrays that do that?
Just arrays, I believe.
> Currently I have:
>
> % ./perl -l
> printf "This is Perl version %vd\n", $^V;
> %foo = (test=>"ok 1", test2=>"ok 3");
> print %foo{test};
Yes
> print "ok 2" if ref ($a=%foo);
Yes. Though C would be a better test
> print $a->{test2};
die "Unexpected > after subtraction operation. Did you mean $a.{test2}???"
> print "ok 4" if ref @INC;
Yes
> print "ok 5" unless ref ($a=(1,2,3))'
No. Equivalent to ref($a=3), I believe
> Does that look right?
60% right, at least. ;-)
> > print $a->{test2};
>
> Oh, hrm. Shouldn't it be $a{test2}?
Yes. Or $a.{test}
> That works too, at any rate.
> Does that mean that arrow between variable and subscript is optional,
There is no arrow. Only dot.
And yes, it's optional anywhere the dot acts like a /\b/ boundary:
$ref.[1]can be $ref[1]
$ref.{a}can be $ref{a}
$ref.(@args)can be $ref(@args)
$ref.meth() CAN'T be$refmeth()
Disclaimer: Rules #1 and #2 apply to all of the above.
Damian
Re: Coupla Questions
On Wed, Jun 06, 2001 at 04:30:56PM +0100, Simon Cozens wrote:
> print $a->{test2};
Oh, hrm. Shouldn't it be $a{test2}? That works too, at any rate.
Does that mean that arrow between variable and subscript is optional,
or should this be some kind of error? Or should it mean something else
altogether?
--
It starts like fascination, it ends up like a trance
You've gotta use your imagination on some of that magazine romance
And these bones--they don't look so good to me
Jokers talk and they all disagree
One day soon, I will laugh right in the face of the poison moon
Coupla Questions
I've been working on, uh, let's call it a "Perl 6 emulator" recently,
and I've come unstuck about a few things.
I'm sure I'll think of some more questions, but here we go for now:
Should properties interpolate in regular expressions? (and/or strings) I
don't suppose they should, because we don't expect subroutines to.
(if $foo =~ /bar($baz,$quux)/;? Urgh, maybe we need m//e)
What should $foo = (1,2,3) do now? Should it be the same as what
$foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
$foo = \@INC; does now.) Putting it another way: does a list in scalar
context turn into a reference, or is it just arrays that do that? If
so, how can we disambiguate hashes from lists?
Currently I have:
% ./perl -l
printf "This is Perl version %vd\n", $^V;
%foo = (test=>"ok 1", test2=>"ok 3");
print %foo{test};
print "ok 2" if ref ($a=%foo);
print $a->{test2};
print "ok 4" if ref @INC;
print "ok 5" unless ref ($a=(1,2,3))'
This is Perl version 6.0.0
ok 1
ok 2
ok 3
ok 4
ok 5
Does that look right?
--
Every little bit of seaweed kelps.
