Context of hash slices; quotation adverbs
Roie Marianer
I'm back with more quoting construct madness.
First, context of hash slices:
Hash slices with {} notation are trivially either scalars or lists:
$h{'foo'} = want(); # Scalar
$h{'foo','bar'} = want(); # List
With <> notation the same thing happens:
$h<foo> = want(); # Scalar
$h<foo bar> = want(); # List
But when you start interpolating, you get into a big mess:
h<\qq[$interpolated]> = want(); # ???
h<<$foo>> = want(); # ???
Secondly, quotation adverbs (S02) that take arguments could theoretically be
variables that only exist during runtime
q:c(rand) (Do we interpolate {this}?)
(It would be even worse if "this" had a closing paren in it)
That's complete madness, but with regexps it makes complete sense - sometimes
rx:nth($n)/something/;
The general problem is that some adverbs affect parsing, while others take
place only during runtime - and they all have the same syntax. I'll think a
bit more myself about how to solve this, but I thought I'd throw it out there
as well.
--
-Roie
v2sw6+7CPhw5ln5pr4/6$ck2ma8+9u7/8LSw2l6Fi2e2+8t4TNDSb8/4Aen4+7g5Za22p7/8
[ http://www.hackerkey.com ]
Brent 'Dax' Royal-Gordon
> : First, context of hash slices:
> : Hash slices with {} notation are trivially either scalars or lists:
> : $h{'foo'} = want(); # Scalar
> : $h{'foo','bar'} = want(); # List
>
Tangentially, that makes me wonder: is there a difference between
scalar context and one-element array context?
--
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
"I used to have a life, but I liked mail-reading so much better."
Larry Wall
: Larry Wall <la...@wall.org> wrote:
: > : First, context of hash slices:
: > : Hash slices with {} notation are trivially either scalars or lists:
: > : $h{'foo'} = want(); # Scalar
: > : $h{'foo','bar'} = want(); # List
: >
: > Right.
:
: Tangentially, that makes me wonder: is there a difference between
: scalar context and one-element array context?
Certainly, same distinction as Perl 5 makes. The only difference
is that Perl 6 can evaluate a list lazily, so it might not actually
have to generate the entire list if you only want the first value.
Larry
Roie Marianer
> : h<\qq[$interpolated]> = want(); # ???
> : h<<$foo>> = want(); # ???
>
> just force the RHS here to list context, and rely on the RHS to add
> extra context as necessary if they really mean scalar. If something
> really is always producing a scalar value, it doesn't matter if it's
> called in list context.
That makes sense, but that would make
%num_of_lines<file> = @file
not DWIM... of course that would translate into
%num_of_lines<file> = scalar @file
so maybe that's OK.
> Any bit of expression by default evaluates at ordinary run time, but can
> be forced to evaluate earlier by surrounding context.
What you're saying is that
BEGIN { $c=1 }
$c=0;
q:c($c)/.../
interpolates, because the $c in line three is evaluated after the $c in line
one but before the $c in line two, right? If you don't obfuscate on purpose
(like I did), that makes sense.
Larry Wall
: > : But when you start interpolating, you get into a big mess:
: > : h<\qq[$interpolated]> = want(); # ???
: > : h<<$foo>> = want(); # ???
: >
: > I think that, as with functions called in unknown context, we should
: > just force the RHS here to list context, and rely on the RHS to add
: > extra context as necessary if they really mean scalar. If something
: > really is always producing a scalar value, it doesn't matter if it's
: > called in list context.
:
: That makes sense, but that would make
: %num_of_lines<file> = @file
: not DWIM... of course that would translate into
: %num_of_lines<file> = scalar @file
: so maybe that's OK.
Eh, no, I wouldn't call that one "unknown context". I'd call it scalar.
: > Any bit of expression by default evaluates at ordinary run time, but can
: > be forced to evaluate earlier by surrounding context.
: What you're saying is that
: BEGIN { $c=1 }
: $c=0;
: q:c($c)/.../
: interpolates, because the $c in line three is evaluated after the $c in line
: one but before the $c in line two, right? If you don't obfuscate on purpose
: (like I did), that makes sense.
Yes. The main problem is that you have to make sure the "my $c" isn't
hidden in an inner block. This wouldn't work:
BEGIN { my $c=1 }
$c=0;
q:c($c)/.../
Note that
my $c = BEGIN { 1 };
doesn't quite work either. However, we'll probably end up
my $c will begin { $_ = 1 };
or some such. Compile-time binding
my $c ::= 1;
probably also works, or maybe you have to write:
my $c ::= \1;
Larry
Kurt Hutchinson
> %num_of_lines<file> = @file
> not DWIM... of course that would translate into
> %num_of_lines<file> = scalar @file
> so maybe that's OK.
In order to promote proper syntactical thinking, note that this is now
spelled:
%num_of_lines<file> = @file.elems;
because the Perl 5 way would put a reference to @file in the hash.
Scalar context always makes references now, from what I understand.
Larry Wall
: On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote:
: > That makes sense, but that would make
: > %num_of_lines<file> = @file
: > not DWIM... of course that would translate into
: > %num_of_lines<file> = scalar @file
: > so maybe that's OK.
:
: In order to promote proper syntactical thinking, note that this is now
: spelled:
:
: %num_of_lines<file> = @file.elems;
Or more succinctly:
%num_of_lines<file> = +@file;
: because the Perl 5 way would put a reference to @file in the hash.
: Scalar context always makes references now, from what I understand.
Interestingly, a stored reference would track the current number of
lines rather than taking a snapshot. But you should definitely think
of it as storing a reference rather than the number of lines, because
the ref will certainly behave differently in string context.
Larry
Wolverian
> %num_of_lines<file> = +@file;
>
> : because the Perl 5 way would put a reference to @file in the hash.
> : Scalar context always makes references now, from what I understand.
>
> Interestingly, a stored reference would track the current number of
> lines rather than taking a snapshot. But you should definitely think
> of it as storing a reference rather than the number of lines, because
> the ref will certainly behave differently in string context.
>
> Larry
How sane would it be to put a reference to the instance method in the
hash? I think Perl 6 doesn't actually support that directly, but one can
always do:
%num_of_lines<file> = List::elems.assuming(@file);
I'm not sure if the currying works correctly there. How does one curry
the invocant? (I'm thinking about a situation when the method doesn't
specify the invocant explicitly in the signature, if that makes any
difference.)
I like the whole idea of bound references (to use the Pythonic term),
although Python's syntax lends itself better to such use. Sometimes I
wish we would require parentheses on every method and sub call. Then a
reference to the method/sub would be simply its name without the parens.
I hope I never have to design my own language. I would be schizophrenic
before the day ends.
--
wolverian
Larry Wall
: On Mon, Apr 18, 2005 at 04:00:53PM -0700, Larry Wall wrote:
: > %num_of_lines<file> = +@file;
: >
: > : because the Perl 5 way would put a reference to @file in the hash.
: > : Scalar context always makes references now, from what I understand.
: >
: > Interestingly, a stored reference would track the current number of
: > lines rather than taking a snapshot. But you should definitely think
: > of it as storing a reference rather than the number of lines, because
: > the ref will certainly behave differently in string context.
: >
: > Larry
:
: How sane would it be to put a reference to the instance method in the
: hash?
It seems like a sane thing to me, but that's a rather low standard.
: I think Perl 6 doesn't actually support that directly, but one can
: always do:
:
: %num_of_lines<file> = List::elems.assuming(@file);
That would need to be
%num_of_lines<file> = &List::elems.assuming(@file);
or it would assume you're trying to call a class method on a class
named List::elems.
: I'm not sure if the currying works correctly there. How does one curry
: the invocant? (I'm thinking about a situation when the method doesn't
: specify the invocant explicitly in the signature, if that makes any
: difference.)
It looks like we're getting positional currying in addition to named,
so the syntax above should work. But as it currently stands
the invocant always has an alias of $_, so you could presumably say
%num_of_lines<file> = &List::elems.assuming(_ => @file);
: I like the whole idea of bound references (to use the Pythonic term),
: although Python's syntax lends itself better to such use. Sometimes I
: wish we would require parentheses on every method and sub call. Then a
: reference to the method/sub would be simply its name without the parens.
Myself, I'd rather have the possibility of list operators. But you've
probably noticed that already. :-)
: I hope I never have to design my own language. I would be schizophrenic
: before the day ends.
That's backwards. You have to be schizophrenic before the day starts.
Larry