Re: Ex4 smart match question
Damian Conway <[EMAIL PROTECTED]> writes:
> Incidentally, the table of C<=~> comparisons (Table 1) at:
>
> http://dev.perl.org/perl6/apocalypse/4
>
> suggests that hash/hash matching is equivalent to:
>
> match if grep exists $a{$_}, $b.keys
>
> I hope to convince Larry that it would be better if it were equivalent to:
>
> match if any($a.keys) =~ any($b.keys)
That certainly seems more 'smart matchy' (does that make sense?)
> so that each key is recursively C<=~>-matched against each key.
>
> I'd prefer that because if I hope to convince Larry to allow hash
> keys to be any scalar value (not just strings). That way the "keys
> as a set" idiom might actually be usable.
I thought he was already convinced of that one. And even if he's not,
setting up the smart match in the second form means less work when
someone does:
# Like a hash, but with arbitrary keys.
class Dictionary is HASH { ... }
Not that changing =~ would be that much work anyway...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Bracekets
At 2:33 PM +0100 4/7/02, Piers Cawley wrote: >"Jonathan E. Paton" <[EMAIL PROTECTED]> writes: >> but wait, there's more... what does: >> >> @multi_dim[$a][$b][$c] >> >> give? > >Who cares? So long as the intermediate results in >@multi_dim.[$a].[$b].[$c] respond to []. Hrm. Will they need to? That could arguably pass a three element key ($a,$b,$c) to @multi_dim which, conveniently being a three-dimensional array, returns a value itself. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Bracekets
> >> but wait, there's more... what does:
> >>
> >> @multi_dim[$a][$b][$c]
> >>
> >> give?
> >
> >Who cares? So long as the intermediate results in
> >@multi_dim.[$a].[$b].[$c] respond to [].
>
> Hrm. Will they need to? That could arguably pass a three
> element key ($a,$b,$c) to @multi_dim which, conveniently
> being a three-dimensional array, returns a value itself.
For certain definitions of "array", if you missed my earlier
post, then I forgot to say that @multi_dim is a mixed data
structure:
$a is a hash key
$b is an array index
$c is another hash key
So, if I try:
@multi_dim[$b][$a][$c]
then it's obviously going to break. But how can I, the
programmer, easily spot that? It's not as clear as:
@multi_dim{$a}[$b]{$c}
where I can see what I'm getting as I work through the
data structure.
In short, the suggestion was to aggregate [] and {}...
i.e. aggregate the notations for hashes and arrays.
Probably leaving Perl with:
* The thingy complex datastructure, you'll need to look
back to what I wrong earlier to find out what it is.
Oh, but it breaks without strict, cause you don't need
to tell it.
If it is meant to be an array and you have strict
turned off, then what should Perl store this as:
for my $outer (1..10) {
for my $inner (1..1000, 'A', 'B') {
@data[$outer][$inner] = <>;
}
}
[using Perl 5 syntax mixed with this idea]
To make the symbols {} and [] aggregate you'd have to
default [] to using hashes - and force it back to
arrays using explicit syntax. You can't automagically
decide that it's never going to be used like a hash.
I'm I beating this point to death, or do I have to write
the RPC:
"Keep the {} and [] notation for hashes and arrays"
or
"Save our array!"
to make it clear it'd probably be less popular than the
-> to . change, which I do... reluctanty... see the
benefit of.
Of course, if I have to do that I need the original
suggestion as an RPC too - so I can reference it.
If in doubt on this matter, see RPC 28:
http://dev.perl.org/rfc/28.pod
Jonathan Paton
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Re: Bracekets
Dan Sugalski <[EMAIL PROTECTED]> writes: > At 2:33 PM +0100 4/7/02, Piers Cawley wrote: >>"Jonathan E. Paton" <[EMAIL PROTECTED]> writes: >>> but wait, there's more... what does: >>> >>> @multi_dim[$a][$b][$c] >>> >>> give? >> >>Who cares? So long as the intermediate results in >>@multi_dim.[$a].[$b].[$c] respond to []. > > Hrm. Will they need to? That could arguably pass a three element key > ($a,$b,$c) to @multi_dim which, conveniently being a three-dimensional > array, returns a value itself. Oh ghod. I'm getting confused now. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Bracekets
On Mon, 2002-04-08 at 13:01, Jonathan E. Paton wrote:
> I'm I beating this point to death, or do I have to write
> the RPC:
>
> "Keep the {} and [] notation for hashes and arrays"
>
> or
>
> "Save our array!"
Let's boil this RFC down to one short phrase:
If {} goes away in Perl6, then everything you've heard about Perl6 being
"not really all that different from Perl5" is either a lie or a damned
lie. People keep saying "it's just Perl5, but instead of syntax X, you
now use syntax Y". Well, as both X and Y lists grow longer
I know this is harsh, but really folks, you're pulling Perl apart
looking at a half-dozen good features and building a new language around
them. I don't fault you for this (it's a great way to come up with a new
language), but I'm beginning to get the feeling that going from Perl5 to
Perl6 is going to be almost the same level of effort as going from
Pascal to ANSI C!
Also, just wondering:
$_[_][EMAIL PROTECTED] _=_0_-_
does that work the way I expect it to?
Re: Bracekets
Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Mon, 2002-04-08 at 13:01, Jonathan E. Paton wrote:
>
>> I'm I beating this point to death, or do I have to write
>> the RPC:
>>
>> "Keep the {} and [] notation for hashes and arrays"
>>
>> or
>>
>> "Save our array!"
>
> Let's boil this RFC down to one short phrase:
>
> If {} goes away in Perl6, then everything you've heard about Perl6 being
> "not really all that different from Perl5" is either a lie or a damned
> lie. People keep saying "it's just Perl5, but instead of syntax X, you
> now use syntax Y". Well, as both X and Y lists grow longer
>
> I know this is harsh, but really folks, you're pulling Perl apart
> looking at a half-dozen good features and building a new language around
> them. I don't fault you for this (it's a great way to come up with a new
> language), but I'm beginning to get the feeling that going from Perl5 to
> Perl6 is going to be almost the same level of effort as going from
> Pascal to ANSI C!
>
> Also, just wondering:
>
> $_[_][EMAIL PROTECTED] _=_0_-_
>
> does that work the way I expect it to?
Dunno, what do you expect it to do?. To my way of thinking there's
going to be a syntax error at the third '_'. But I'm not entirely
certain of that.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Bracekets
> > I'm I beating this point to death, or do I have to write
> > the RPC:
> >
> > "Keep the {} and [] notation for hashes and arrays"
> >
> > or
> >
> > "Save our array!"
>
> Let's boil this RFC down to one short phrase:
>
> If {} goes away in Perl6, then everything you've heard
> about Perl6 being "not really all that different from
> Perl5" is either a lie or a damned lie. People keep
> saying "it's just Perl5, but instead of syntax X, you
> now use syntax Y". Well, as both X and Y lists grow
> longer
I guess Luke is overruled, eh? Don't feel too bad
Luke... you can't win them all.
> I know this is harsh, but really folks, you're pulling
> Perl apart looking at a half-dozen good features and
> building a new language around them. I don't fault you
> for this (it's a great way to come up with a new
> language), but I'm beginning to get the feeling that
> going from Perl5 to Perl6 is going to be almost the
> same level of effort as going from Pascal to ANSI C!
Larry... you aren't going to make Perl totally different,
just remove the crud... right?
Don't forget, Damian is supposed to make the Energises
really complex looking... we want to know the advanced
features, the ones that make Perl different - and
better.
> Also, just wondering:
>
> $_[_][EMAIL PROTECTED] _=_0_-_
>
> does that work the way I expect it to?
Err.. DWIM will have to work hard on that one! I'd
expect one of Perl's parse errors... donno which
one like.
Jonathan Paton
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Re: Bracekets
On Mon, Apr 08, 2002 at 02:50:55PM -0400, Aaron Sherman wrote: > Also, just wondering: > > $_[_][EMAIL PROTECTED] _=_0_-_ > > does that work the way I expect it to? Well, my internal Perl 6 parser hadn't been used all that much, but if you expect this to be a syntax error, then I think you're correct. Perhaps you'd like to tell us how you think the above should be parsed and what it should do? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Bracekets
On Mon, Apr 08, 2002 at 07:56:11PM +0100, Piers Cawley wrote: > > Also, just wondering: > > > > $_[_][EMAIL PROTECTED] _=_0_-_ > > > > does that work the way I expect it to? > > Dunno, what do you expect it to do?. To my way of thinking there's > going to be a syntax error at the third '_'. But I'm not entirely > certain of that. To me, the third '_' seems like it'd be an unambiguous case of the concatenation operator. I still can't parse it, however; it looks like an attempt to modify a non-lvalue: $_.[_()] _ @_._() _= _0_() - _() That is: 1. Invoke the subroutine _ (name resolved in current scope) 2. Dereference the variable $_, yielding an array reference. 3. Retrieve the element of the referenced array whose index is the result of step 1. 4. Invoke the method _ on the array @_. 5. Concatenate the results of steps 3 and 4 6. Invoke the subroutine _0_ 7. Invoke the _ again (or retrieve the cached result from step 1) 8. Subtract #7 from #6 9. Append the result of step 8 to contents of the lvalue which is the result of step 5. This is where my interpretation fails because the result of step 5 is not an lvalue. Then again, it's probably using some syntax that I haven't internalized yet. -- Mark J. REED<[EMAIL PROTECTED]>
Re: Bracekets
"Mark J. Reed" <[EMAIL PROTECTED]> writes: > On Mon, Apr 08, 2002 at 07:56:11PM +0100, Piers Cawley wrote: >> > Also, just wondering: >> > >> >$_[_][EMAIL PROTECTED] _=_0_-_ >> > >> > does that work the way I expect it to? >> >> Dunno, what do you expect it to do?. To my way of thinking there's >> going to be a syntax error at the third '_'. But I'm not entirely >> certain of that. > To me, the third '_' seems like it'd be an unambiguous case of the concatenation > operator. I still can't parse it, however; it looks like an attempt to > modify a non-lvalue: > > $_.[_()] _ @_._() _= _0_() - _() > > That is: > 1. Invoke the subroutine _ (name resolved in current scope) > 2. Dereference the variable $_, yielding an array reference. > 3. Retrieve the element of the referenced array whose index is >the result of step 1. > 4. Invoke the method _ on the array @_. > 5. Concatenate the results of steps 3 and 4 > 6. Invoke the subroutine _0_ > 7. Invoke the _ again (or retrieve the cached result from step 1) > 8. Subtract #7 from #6 > 9. Append the result of step 8 to contents of the lvalue >which is the result of step 5. > > This is where my interpretation fails because the result of step 5 > is not an lvalue. How do you know that? '_' could be a method on its LHS that returns and object that responds to _=. But generally, I think it's weird. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Bracekets
On Mon, 2002-04-08 at 14:56, Piers Cawley wrote: > Aaron Sherman <[EMAIL PROTECTED]> writes: > > Also, just wondering: > > > > $_[_][EMAIL PROTECTED] _=_0_-_ > > > > does that work the way I expect it to? > > Dunno, what do you expect it to do?. To my way of thinking there's > going to be a syntax error at the third '_'. But I'm not entirely > certain of that. Sorry, I was a little punchy from support calls, and forgot the smily there. The first part of my message was meant to be serious, but this was just to humerously emphasise.
Re: Bracekets
On Mon, 2002-04-08 at 15:09, Mark J. Reed wrote:
> On Mon, Apr 08, 2002 at 07:56:11PM +0100, Piers Cawley wrote:
> > > Also, just wondering:
> > >
> > > $_[_][EMAIL PROTECTED] _=_0_-_
> > >
> > > does that work the way I expect it to?
> >
> > Dunno, what do you expect it to do?. To my way of thinking there's
> > going to be a syntax error at the third '_'. But I'm not entirely
> > certain of that.
> To me, the third '_' seems like it'd be an unambiguous case of the concatenation
> operator. I still can't parse it, however; it looks like an attempt to
> modify a non-lvalue:
>
> $_.[_()] _ @_._() _= _0_() - _()
Hmm... meant this to be silly, but this is now bringing up some
important things.
$_[_]
This to me, means
$_ . ['_']
But, only if {} goes away, as we still need the
$x{foo}
behavior, don't we?
_0_
This was my mistake. It would have to be 0_0_, to be a number, which
breaks my perfect string of underscores ;-)
Everything else that you say is as I expected it to be taken. It's
interesting how many people assumed it'd be a syntax error, though
Re: Bracekets
On Mon, 2002-04-08 at 15:12, Piers Cawley wrote: > "Mark J. Reed" <[EMAIL PROTECTED]> writes: > > > On Mon, Apr 08, 2002 at 07:56:11PM +0100, Piers Cawley wrote: > >> > $_[_][EMAIL PROTECTED] _=_0_-_ > > $_.[_()] _ @_._() _= _0_() - _() [...] > > This is where my interpretation fails because the result of step 5 > > is not an lvalue. > > How do you know that? '_' could be a method on its LHS that returns > and object that responds to _=. But generally, I think it's weird. Yes, I was thinking that there would be lvalue-methods or operator overloading of some sort in the _= Oh the joy of subtle code features, eh?
Re: Bracekets
On Mon, Apr 08, 2002 at 06:01:57PM +0100, Jonathan E. Paton wrote:
> To make the symbols {} and [] aggregate you'd have to
> default [] to using hashes - and force it back to
> arrays using explicit syntax. You can't automagically
> decide that it's never going to be used like a hash.
>
> I'm I beating this point to death, or do I have to write
> the RPC:
>
> "Keep the {} and [] notation for hashes and arrays"
>
> or
>
> "Save our array!"
Whilst I agree with that, I'd also like to find an easy way to allow me to
say (OK, in perl5 terms, because I'll make a mistake in perl6 terms)
$foo->[$bar];
and after I've written my program decide to swap $foo from being an array
into some sort of sparse array, without needing to replace all those [] with
{} if my "sparse array" happens to be a hash.
Or am I still stuck in perl5, where the "obvious" way to do a sparse array
is a hash, because doing tied array implementation is both
a) non-lazy and needs patience
b) slower
while perl6 is going to have fast ways to switch $foo to all manner of array
implementations without needing to touch the perl code?
[Anyway, what do I know about programming in Perl? I seem to spend more
time programming perl. :-)
Comments are for wimps, Perl is for regression tests]
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Unary dot
Damian Conway writes:
: > > use invocant 'self';
Hmm. My first inclination is to say it should be something like:
macro self { '%MY.frame.arg[0]' }
But suppose you want all .foo to refer to self and not to the current
topic. It would be problematic to have a macro whose name is "".
So you might say something like this:
use invocant "";
Still a bit odd syntactically, however. One is vaguely tempted to make
..foo(1)
mean self.foo(1). But then we'd see methods chock full of *that* even
when it wasn't necessary. Much rather see self.foo(1).
: > *Much* better name. You see, that's why you're the mad genius and I'm
: > just the lowly lab assistant. Marthter.
:
: And, given that I'm jutht Larry'th lowly lab aththithtant, that would
: theem to make you a meta-Igor!
:
: %-)
As Annie Oakley almost said, "Anything you can do, I can do meta."
Fortunately, Igority is transitive...
Larry
Re: Unary dot
Larry wrote:
> : > > use invocant 'self';
>
> Hmm. My first inclination is to say it should be something like:
>
> macro self { '%MY.frame.arg[0]' }
>
> But suppose you want all .foo to refer to self and not to the current
> topic. It would be problematic to have a macro whose name is "".
> So you might say something like this:
>
> use invocant "";
>
> Still a bit odd syntactically, however.
Perhaps a bare:
use invocant;
overrides unary dot within the lexical scope, causing it to default to using
each method's @_[0], rather than $_.
> One is vaguely tempted to make
>
> ..foo(1)
>
> mean self.foo(1). But then we'd see methods chock full of *that* even
> when it wasn't necessary. Much rather see self.foo(1).
Yep. Besides, since we're working towards having the unary version of operators
vaguely related to the binary version in Perl 6 (e.g. unary C<_>, unary C<+>,
unary C<.>), it would seem counterproductive to have unary C<..> utterly
unrelated to binary C<..>.
> Fortunately, Igority is transitive...
I thought that was maxim was: "Igorance is blithth".
Damian
Re: Bracekets
Aaron Sherman writes:
: On Mon, 2002-04-08 at 13:01, Jonathan E. Paton wrote:
:
: > I'm I beating this point to death, or do I have to write
: > the RPC:
: >
: > "Keep the {} and [] notation for hashes and arrays"
: >
: > or
: >
: > "Save our array!"
:
: Let's boil this RFC down to one short phrase:
:
: If {} goes away in Perl6, then everything you've heard about Perl6 being
: "not really all that different from Perl5" is either a lie or a damned
: lie. People keep saying "it's just Perl5, but instead of syntax X, you
: now use syntax Y". Well, as both X and Y lists grow longer
Your turn to panic, eh? :-)
Look, {} for hash subscripts is not going away in Perl 6. It's too
useful as documentation, if nothing else.
That being said, with an efficient tie-like interface for array
variables, it doesn't really matter if [] is passed something other
than an integer, as long as the implementation is expecting it. The
reason we're making ties declarative in Perl 6 is so that we don't have
to pessimize all arrays with that assumption, or even all tied arrays.
In the absence of such a declaration, the subscripts are "known" to be
consecutive integers, and the compiler is free to optimize based on
that assumption. Hash subscripts make no such promise.
: I know this is harsh, but really folks, you're pulling Perl apart
: looking at a half-dozen good features and building a new language around
: them. I don't fault you for this (it's a great way to come up with a new
: language), but I'm beginning to get the feeling that going from Perl5 to
: Perl6 is going to be almost the same level of effort as going from
: Pascal to ANSI C!
:
: Also, just wondering:
:
: $_[_][EMAIL PROTECTED] _=_0_-_
:
: does that work the way I expect it to?
Well, the $_ isn't a member of @_, if that's what you were expecting.
It's a syntax error after the second _, since that's a built-in unary
operator without a default. [...] will never autoquote like {...}.
It's just possible that you could get away with it by overloading _
to be argumentless:
sub _ () { ... }
Leaving that aside, the third _ is a valid binary _ for string concatenation..
The fourth _ is a valid part of @_, and a term is expected, so that's okay.
The fifth _ is a valid method name, and is probably in fact a universal
method corresponding to the universal unary _ operator.
The sixth _ is a valid part of an _= assignment operator.
The seventh _ is a valid unary _.
The eighth _ is not a part of the preceding number because numeric _
must have digits on both sides. So an operator is expected, meaning _
will be taken as another binary _.
Now a term is expected, so the - is unary, and the _ again is illegal
unless an argumentless _ has been declared.
I hope the meaning of your expression is now completely clear. :-)
Larry
Re: Unary dot
Damian Conway writes: : > Fortunately, Igority is transitive... : : I thought that was maxim was: "Igorance is blithth". That's not a maxim, that's a minim. Larry
Re: Unary dot
> : I thought that was maxim was: "Igorance is blithth". > > That's not a maxim, that's a minim. No need to get all crotchet-y. Damian
Re: Bracekets
>
>$a is a hash key
>$b is an array index
>$c is another hash key
>
>So, if I try:
>
>@multi_dim[$b][$a][$c]
>
>then it's obviously going to break. But how can I, the
>programmer, easily spot that? It's not as clear as:
>
>@multi_dim{$a}[$b]{$c}
>
>where I can see what I'm getting as I work through the
>data structure.
>
A glance at my email tells me that several messages about this are yet to come, but
I'll risk repeating someone else.
What, exactly is the issue here? If $a is a hash key, that is clear by the funny
character.
%hash[key][additional][levels][of][depth]
If we are worried about about accidentally giving a key where an index is expected, I
don't understand how the semantics are much more confusing that the current ones. A
string'll get converted to a number and get used creating silent errors, or raise a
warning, which is not made more clear by the precence of a brace. If we're talking
about while I'm coding then the level of indirection by making the thing a variable in
the first place defeats any advantage that having the braces might give. For a really
BIG structure, if your are going to forget where the hashes are, then the braces
aren't going to help - you'll just put 'em inthe wrong place.
Printing out the value should solve the problem regardless - the braces don't seem to
make this issue much more clear. (To me anyway. I get the nagging feeling I'm missing
something.)
As to the inspring issue about using [] for hashes, I say go for it if (and only if)
it is a signifigant improvement for the parser. The historical pressure here is high,
so it can't just be a little faster.
However, if this isn't the 'idiomatic' sematics, I can see Perl in non-strict form
silently using whatever is between the []'s regardless of what the reference is. I
wonder at a)what sort of speed penalty we may be looking at for this, b)what degree of
advantage it is for QnD scripts and c)whether or not things like refs should really be
given that lazy a usage. Like modules perhaps, unstrictness in refs might be
unjustifiable.
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Bracekets
> As to the inspring issue about using [] for hashes, I say go for it if > (and only if) it is a signifigant improvement for the parser. I would imagine it's not. The braces are one of the things that make Perl "feel" like Perl. My original post that inspired this gigantic discussion was simply a probing as to "why?" as opposed to "we should." I got my answer in many, many different ways, so I'm satisfied :). Luke
