Re: Context of hash slices; quotation adverbs
On Mon, Apr 18, 2005 at 04:00:53PM -0700, Larry Wall wrote: %num_of_linesfile = [EMAIL PROTECTED]; : 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_linesfile = 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 signature.asc Description: Digital signature
Re: Context of hash slices; quotation adverbs
On Tue, Apr 19, 2005 at 02:14:04AM +0300, wolverian wrote: : On Mon, Apr 18, 2005 at 04:00:53PM -0700, Larry Wall wrote: : %num_of_linesfile = [EMAIL PROTECTED]; : : : 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_linesfile = List::elems.assuming(@file); That would need to be %num_of_linesfile = 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_linesfile = 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
Re: Context of hash slices; quotation adverbs
: 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_linesfile = @file
not DWIM... of course that would translate into
%num_of_linesfile = 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.
--
-Roie
v2sw6+7CPhw5ln5pr4/6$ck2ma8+9u7/8LSw2l6Fi2e2+8t4TNDSb8/4Aen4+7g5Za22p7/8
[ http://www.hackerkey.com ]
Re: Context of hash slices; quotation adverbs
On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote:
: : 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_linesfile = @file
: not DWIM... of course that would translate into
: %num_of_linesfile = 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
Re: Context of hash slices; quotation adverbs
On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote: That makes sense, but that would make %num_of_linesfile = @file not DWIM... of course that would translate into %num_of_linesfile = scalar @file so maybe that's OK. In order to promote proper syntactical thinking, note that this is now spelled: %num_of_linesfile = @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.
Re: Context of hash slices; quotation adverbs
On Mon, Apr 18, 2005 at 06:44:55PM -0400, Kurt Hutchinson wrote: : On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote: : That makes sense, but that would make : %num_of_linesfile = @file : not DWIM... of course that would translate into : %num_of_linesfile = scalar @file : so maybe that's OK. : : In order to promote proper syntactical thinking, note that this is now : spelled: : : %num_of_linesfile = @file.elems; Or more succinctly: %num_of_linesfile = [EMAIL PROTECTED]; : 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
Context of hash slices; quotation adverbs
Hi all,
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:
$hfoo = want(); # Scalar
$hfoo 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 ]
Re: Context of hash slices; quotation adverbs
On Sun, Apr 17, 2005 at 07:54:18PM +0300, Roie Marianer wrote:
: Hi all,
: I'm back with more quoting construct madness.
Kewl, d00d.
: 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.
: With notation the same thing happens:
: $hfoo = want(); # Scalar
: $hfoo bar = want(); # List
Right.
: 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.
: Secondly, quotation adverbs (S02) that take arguments could theoretically be
: variables that only exist during runtime
: q:c(rand) (Do we interpolate {this}?)
Nope, 'cuz rand never gets up to 1, and int() always truncates. On the
other hand, if you'd said this...
q:c(rand 2) (Do we interpolate {this}?)
then we'd have exactly the problem you're talking about--it'd compile
as an interpolator 50% of the time.
: (It would be even worse if this had a closing paren in it)
It's no worse than picking random source filters:
BEGIN {
if (int rand 2) {
require Cleverness;
}
else {
require Idiocy;
}
}
: That's complete madness, but with regexps it makes complete sense - sometimes
: rx:nth($n)/something/;
Yep.
: 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.
Any bit of expression by default evaluates at ordinary run time, but can
be forced to evaluate earlier by surrounding context. Basically it's
the same difference between the additions in:
push @foo: $a + $b;
use FOO: $a + $b;
Given that eval ... is equivalent to something like
Perl.parse(...).compile.run
and that the pair in question is already partially compiled to some
form, it seems like you just have to throw a .run or a .compile.run
in there somewhere. Or if you really, really want to force later
evaluation than normal evaluation time, a macro could wrap up the
thunk as an implicit closure and pass that to the call, much as ??::
does delayed evaluation of either its ?? or its :: clause. But that's
going to be an unusual case, and we want it to remain an unusual case,
so we're not going to go thunk-mad in a call-by-name fashion.
Then again, you can always change it: All is fair if you predeclare.
Standard Perl exists only between the #! and the first declaration.
Larry
Re: Context of hash slices; quotation adverbs
Larry Wall [EMAIL PROTECTED] 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?
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: Context of hash slices; quotation adverbs
On Sun, Apr 17, 2005 at 08:00:00PM -0700, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall [EMAIL PROTECTED] 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
