On Mon, 12 Mar 2007 17:41:27 -0700, Larry Wall wrote:
> On Fri, Mar 02, 2007 at 01:33:50PM -0500, Ryan Richter wrote:
> : while ($_ = %state{@@w}.pick).say {
>
> You maybe don't want each word on a separate line...
They did that in the original for some reason. In the unlikely event
that I want to sit down and read the output I can use |fmt :)
> : - Does shift do what I'm expecting it to do with a multidim array?
>
> I have my doubts. Overloading that word to mean shifting the entire
> dimension seems like it could cause conceptual collisions down the
> road. There a good chance it should just shift the value out of the
> first Capture without removing the Capture from the list of Captures.
>
> And a shaped array might be different yet, shifting off the entire slice
> corresponding to first element of the first dimension.
>
> But in either case I wouldn't expect it to remove a dimension. Now,
> it's possible that @@w.shift would remove the dimension, since it
> treats the slice Capture as an individual element.
OK, that sounds good.
> Rather than trying to maintain @w as a multidimensional array where
> each slice ever only has one value, why not just use ordinary shift
> and push on an ordinary array, and then %state{[;[EMAIL PROTECTED] instead?
> Should
> still have the theoretical advantage of storing the keys in a tree over
> duplicating all the prefix keys. (For that reason I wouldn't go as far
> as to recommend a hash keyed on tuples, which presumably would duplicate
> prefixes.)
Yeah, I wrote it that way to begin with. The version I posted was sort
of designed to maximize the number of language questions.
> : - Am I using the @ and @@ sigils correctly? I think I could just use @@
> : everywhere (right?), but I tried to use it only where needed. Do I
> : need an @@ on the method invocant or anywhere else?
>
> Should only need it where you want to distinguish chunky from smooth,
> at least according to the current definition. But I'm not entirely
> sure we aren't confusing things here.
What do you mean by that?
> : - As I understand it, the way I have it written the anonymous mixin is
> : applied to the value in @w and not to the @w container. If I did
> : something like @w = 1,2,3 that would clobber the mixin, right? Does
> : the hyperop-assignment avoid that?
>
> I don't think you want the mixin on the value, since @w.adv will be called
> on the container, not on the value. An array container is not required
> to be able to treat its value as a single object.
>
> In any case, by precedence you're applying the mixin to result of
> the xx, not the result of the [;], which makes @w.adv even less
> likely to work.
Yeah, that was a really weird idea... I have a lot of those in case you
can't tell :)
Should we just assume that any of those things replaces the immutable
list and therefore clobbers any mixins? I.e. a mixin on a value is part
of the immutableness?
> : - Can for <>.slurp.split {...} be trusted to not use a huge amount of
> : memory for large inputs?
>
> No, any .slurp is pretty much guaranteed to use memory. Also, split no
Right, I expected an eager slurp but a lazy split (comb). I envisioned
an eager split/comb consuming much more memory than an eager slurp, but
I guess that doesn't make much sense.
> longer has a default. You probably want
>
> for $*ARGS.comb {...}
Perfect, thanks.
-ryan
