In all my (not incredibly vast) experience with languages that offer
"with" type commands, I don't think I've ever actually been in a
situation where I wanted to "eat just one." It has always been 'compare
hideously nested structure member A to correspondingly hideous table
data B' or some such.
And because they fail when given multiples (or at least only support
one at a time) it always winds up being written:
temp = most.of->the->path[to].A;
with (most->of_the[path].to.B) {
do_something(temp.A, B);
}
which, once the debugger gets invoked, collapses into two temp
variables and a headscratch as to how anyone actually uses the keyword,
with the possible exception of those people who think 41-character
local structure-variable names are cool.
So I'm motivated to cheer for SOME kind of "with" behavior that
actually works for multiple sources. But is it too much to ask that it
be readable?
> Note that in terms of readability, you can always do:
>
> mumble $foo, $moo ->
> $bar is rw, $baz
As far as visuals, ouch. Double ouch when $foo and $moo are 20+
characters each.
Rather than relying on strict precedence, how about context awareness?
=Austin
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> : The obvious extension to given <value> is given <list>, as:
>
> It's not obvious to me that you'd want more than one topic at a time.
> And there's much to be said for defining C<given> as a C<for> that
> provides a scalar context rather than a list context.
>
> : given $foo -> $bar is rw, # I think this is more readable
> : $moo -> $baz is rw
> : {
> : ...
> : }
>
> I suspect that one is not going to happen, because the -> binds a
> list
> tightly to the {...}, being a way of declaring formal parameters.
> Just
> possibly we might figure out a way of distributing -> through a list,
> but that might make for some fairly contorted logic in anything that
> implements anything like C<given> or C<for>. It would have "collect"
> the parameters to a following block from the preceding list. It
> would
> also be more difficult to explain than as mere syntactic sugar for
> a C<sub>.
>
> But yes, it's pretty, and if we can figure out an easy way to do it,
> you might be able to say that. (Or at least, its equivalent as a
> C<for>.)
>
> : or
> :
> : given ($foo, $moo) -> ($bar is rw, $baz)
> : {
> : ...
> : }
>
> Note that in terms of readability, you can always do:
>
> mumble $foo, $moo ->
> $bar is rw, $baz
>
> Admittedly, it's still not as pretty as the first one. But we can't
> have the precedence both ways. Either the arrow governs the comma,
> or
> the comma governs the arrow.
>
> : What would the default-variable scheme do in this context?
>
> That's a problem. But a more basic problem is, what would a C<when>
> do?
>
> : (Please, no-one suggest nesting 5 or 6 of these.)
>
> If you're gonna alias a lot of variables, it's probably better to use
> a normal binding assignment.
>
> But that brings up another problem with your proposed syntax. As
> with
> normal binding assignment,
>
> $a := $b;
> $b := $a;
>
> doesn't serve to swap the values, so too you might not be able to say
>
> mumble $a -> $b,
> $b -> $a
> {
> ...
> }
>
> to mean
>
> mumble $a, $b -> $b, $a {
> ...
> }
>
> Well, we could probably make it work anyway, since the formal
> parameters
> aren't really introduced till the left curly. In this they do not
> function as C<my> does, which introduces names immediately. But
> there's
> sill a precedence snafu.
>
> And I think we have to allow for the case that there are no actuals
> to
> bind to the formals yet, which means we need an ordinarly looking
> parameter list after the ->. That is, as it currently stands, you
> can say
>
> my $closure = -> $a, $b { ... }
>
> as an equivalent to
>
> my $closure = sub ($a, $b) { ... }
>
> (The only difference being that the latter pays attention to "return"
> exceptions because it has an explicit "sub".)
>
> But if we changed the precedence of -> to fit inside list elements,
> it
> wouldn't work.
>
> Larry
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
