On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote: > Matt Fowles wrote: > > > >for (1, 2) -> ?$prev, $cur, ?$next { > > say "$prev -> $cur" if $prev; > > say $cur; > > say "$cur -> $next" if $next; > > say "next"; > >} > > > [...] > > I assume so because it's the only execution path that seems to work. But > that would be assuming there was always at least one non-optional > binding. Given that Luke's against all-optional signatures, too, I'll > withdraw that part of the suggestion. And with at least one required > binding, then there's no reason that we can't have the window extend on > both sides of the current value. > > Luke?
Hm, I'm being called upon now. Well, then I start to ask questions like: for 1..10 -> ?$a, $b, ?$c, $d, ?$e {...} Which simply doesn't make any sense to me. Also, figuring out such things (as is the case with lookbehind argumentS) needs a little bit too much knowledge about the signature of the function you're viewing. So instead of sticking that in the signature, we could do it with adverbs on for: for 1..10, :lookbehind(1) :lookahead(1) -> $cur, ?$left, ?$right { ... } You'll note that, unfortunately, the lookbehind has to come *after* the cur argument because it must be optional. Hmm... actually, that doesn't work, because at the beginning of the list you won't have a $left, and at the end you won't have a $right. It's possible that it's time to start kicking undef into gear. Until now in Perl culture, undef has been just a little bit special, with people not fearing to put it in lists and data structures. There may be benefit in making it more special, so that people shouldn't define their own meaning for it. Making exceptions undefs are a step in that direction. If we take another step in that exact same direction, we could make undefs exceptions (the converse of before): sub foo() { return undef; # almost the exact same as "fail" } That is, under "use fatal", all undef return values are converted into exceptions. That was somewhat beside the point, but not really. If undefs are a bit taboo--for example, actually writing "undef" in most code is considered bad style--then we can steal them for the language's purposes, such as passing to a for block as lookbehind and lookahead parameters when you're near the beginning or end of a list. It seems like I'm making a pretty big deal out of just passing undef when there is no look-behind/-ahead, but I really want to be able to distinguish between "there was an undef in the list" and "we're almost done, so there was actually nothing here". Of course, I still don't get to distinguish those, but a list with an undef in it becomes much less common. The way we can help ease the pain of undef not being available for user purposes anymore is to allow easy manipulation of Either types. If you define "easy" weakly, then union types give us that: union Maybe[::t] (Nothing, Just(::t)); Mmm, Haskellicious. But of course you wouldn't need to declare your types everywhere because of Perl's dynamic typing/type inference (depending on your mood). Nothing is nice, but I wouldn't call working with Just "easy" for Joe Schmoe. It's nice and safe, but it's annoying sometimes. What I might think I want is: union Maybe[::t] (Nothing, ::t); # not legal union syntax You lose a lot with that, though. For instance, Just(Nothing) becomes unrepresentable. And consequently, nested calls to things that return Maybes become woosy. So that's not a good idea. So allowing the definition of Maybe is a good start. But it's difficult to know whether Perl programmers will put up with it. It's easier--lazier--just to use undef. Maybe we ought to call the whole thing off. Undefs have no stigma, and everything is as usual. If you want to iterate over a list with lookahead and lookbehind, you shouldn't have put undefs in your list. The last thing to do, if we want to keep the undef status quo, is to define Maybe in the language and use it for things like for's lookahead binding. It's kind of like a "formal undef", something like "listen, it's pretty common that I won't give you a value here, so I'm going to mark it specially when I both do and do not". Again, not easy enough; too much abstraction to think about for an everyday task. I think my favorite so far is the previous paragraph's resolution. Just because it's my favorite doesn't mean I'm happy with it. Oh, right, and as for my favorite actual usage of for: for @list, :lookbehind(2) :lookahead(1) -> $behind1, $behind2, $value, $ahead { ... } Luke