Larry Wall writes: > The Principle of Maximum Differentiation of Similar Constructs also > tends to argue for eager =. Plus there's the fact that it's the sort > of restriction we can relax if we figure out how, but it would be hard > to impose if people started to rely on lazy assignment and then we > decided it was a bad idea.
I use = as my no-thinking, catch-all assignment. I'd really like lazy lists to be pervasive enough that I don't have to think about them any differently than I think about any other kind of list. Making = lazy and making = eager both have the same disadvantage, but in different places. If we make = lazy, then people who don't think about lazy lists will use it in modules and whatnot, and it will (at best) die when they try to write them to files or print them or do other things that infinite lists can't really do. On the other hand, if we make = eager, then people who write modules who don't think about lazy lists will be denying the users of their module lazy access when it would be perfectly acceptable. And I can't decide which is worse. But I think the latter is worse. The former puts the decision of how to use lazy lists on the module user, where the latter puts the decision on the module author. Just like C<use fatal>, we want the user to call the shots, because they're the one who knows how the module fits with the rest of the program. I think that as long as lazy lists die when you do things that you can't do to them to them (sic.), and they die with a nice error message that says where they were created, that lazy assignment should be fine. We who write perl6 will have to work a little harder, but we know that from Perl's philosophy anyway. And by harder, I mean to make the "close" example work; to make a filehandle understand that it has lazy lists attached to it and to flush itself when necessary. Of course, there are dragons hiding in that too. If you tie a lazy list to a filehandle and only ever plan to use its first two elements, and you close the filehandle while the list is still in scope, then a 100 megabyte file will give you trouble you never asked for. Maybe it's best to let the array decide. There are some lazy lists which are healthy to throw around recklessly, like C<1...>. There are others, like C<< <> >>, which have nasty ordering dependencies, and are best kept at the expression level and not assigned (only bound... but your ordering dependencies can bite you there, too). If arrays are lazy by default, that basically mean they're behaving as tied values (because you can do anything while you generate), and that we might as well outright remove the C<is tied> optimization restriction. And then we should remove it for scalars and hashes too, and (please) let it propogate through assignment if it wants to. I've always wondered how much we could actually optimize if we know things aren't tied anyway.... Junctions already do tie-like things without being tied (even though it's the *value* which is doing those things). Whew... stop for a breath here... </ramble> This is a hard problem. And it touches on a lot of my active concerns. For the time being, I'll buy your argument that it's easy to relax assigment to lazy, but hard to harden it up to eager. Luke
