Rod Adams <[EMAIL PROTECTED]> wrote: > Suppose funky_test is a derivative of C< printf >. Only this printf let's > you feed it a junction for the format, and it will sort through them and see > which one matches best depending on actual number of parameters, parameter > types, etc. Ordinarily, this would be fairly cool stuff. > But let's say you instead wanted it to print the same data with all the > different formats. With my calling, you could make the distinction rather > easily. With yours, you have to set up the looping yourself.
I would argue that this function is badly designed. Junctions are intended to ultimately be used in boolean tests. That's why the values of the junction have an any/all/one/none relationship. The proper data structure here is an array. (Actually, ironically enough, it's probably a set, not an array.) IMHO, there are three cases where it's legitimate to specifically ask for junctions to be passed in: 1. When it makes absolutely no sense to use a junction in a particular function, especially one with side effects.[1] 2. When doing some sort of junction-aware serialization, a la Storable or Data::Dumper. 3. When the author of the function can optimize the way junctions are handled without changing their basic semantics. Outside of these cases, it's probably wrong. A junction is *not* a meaningless data structure to be slung around at will; it is a construct that implies a certain type of behavior when used. > > The caller is not in a position to know if the callee is internally > > structured in such a way that passing in a raw junction makes sense. > > Sure > they are. It's called reading the documentation. If it doesn't say it can > handle junctions, it probably can't. I don't want to have to stop in the middle of a hundred-line function to think, "Does Store::Market.get act sanely when I give it a junction? Do I need to explode it manually, or will it handle the junction nicely on its own?" Nor do I want to work in a language where most functions don't handle a basic construct elegantly, even when they can. > About the only thing is could return > would be a lazy list of junctions. And about the only places C< .. > gets > used is inside C< for > and inside array slice indices. Lists of junctions > certainly make no sense in a for loop... the loop cannot simultaneously exit > and not exit at the same time. You don't think this makes sense? (C<for> itself wouldn't autothread; the calls and operators inside the loop body would.) for 1|2, 3|4, 5|6 { ... } (Actually, Synopsis 3 talks about what happens when you give C<for> a single junction--essentially, it loops over the contents of the junction in whatever order it feels is most optimal. But in this case we're giving it an array of junctions, which presumably would act differently) > Feeding a list of junctions into an array > slice index is asking for what? Another list of junctions out? Synopsis 3: print if @foo[any(1,2,3)] [1] Note, however, that this needs to be done carefully. For example, while it doesn't really make sense for the string arguments of a call to C<print> to be junctions, the object argument is another matter entirely: #!/usr/bin/perl6 # naive tee $OUT=$OUT & open("> $_") for @ARGS; print or die "Can't write to $!.filename: $!" for *$IN; # Or however it's done this week -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker "I used to have a life, but I liked mail-reading so much better."
