On Sun, Dec 05, 2004 at 12:05:46AM +0000, Matthew Walton wrote:
: I'm sorry, but from a C++ background, overriding postcircumfix:<( )> : feels far more natural to me than setting 'is default' on some method.
That only works for disambiguation if you know which .() to call in the first place. It seems likely that that .() maps straight to MMD and doesn't look for a singly dispatched .() at all. But maybe I'm just not understanding this.
No, that makes sense.
What you're talking about already sounds suspiciously like Aspect Oriented Programming.
I wouldn't know, I've never looked into it. Perhaps I should...
Any foo() can return a list. That list can be a Lazy list. So the ordinary return can say:
return 0...;
to return an infinite list, or even
return 0..., 0...;
to return a surreal list. Either of those may be bound to an array as its "generator of missing values". Assignment sort of implies copying, but I'm just saying that the copier could also be smart at least about infinities or indefinities (ohh, a cool new word), even if it flattens everything else.
That would be good. It would be nice to be able to copy infinite lists without having to flatten them first.
An object can play the Undef role. Or maybe undef can play Ref role. In any event, since a string is an object, the answer is "Yes, but an unthrown Exception object that can stringify would be better..."
I'll take either for now. I suspect an unthrown Exception will turn out to be the better solution, as it sounds much more useful. Except that I'm not quite sure how you'd notice it - I assume unthrown Exceptions would be expected to return false in Boolean context?
Next thing you'll be telling me is that all this partially evaluated code shouldn't have any side effects. :-)
Well of course it shouldn't. Confining all actions which have side effects to the IO monad makes it much easier to reason about programs and their behaviour.
Although I suspect anybody who tries to reason about something written in idiomatic Perl deserves the headache they're going to get. That doesn't mean I don't find Perl to be immensely fun to work with though. I believe Perl 6 will be even more immensely fun.
