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.
: What if you do 'is default' on two methods? Compile-time error?
Syntactically legal, and semantically legal if they have different MMD
signatures. Otherwise a compile time error if the compiler can catch
it then, but I wouldn't require a compiler to do so if it's onerous.
Seems like it ought to be pretty easy though, if one has a way of
doing a "test" dispatch without really dispatching, and we need something
like that to resolve a reference like &abs<complex>.
: What if
: you're opening up someone else's class and want to override the existing
: default (okay, so you shouldn't be doing that in an OOP world, but what
: if you are? What if you're like me and like Perl's delightful mishmash
: of paradigms while simultaneously liking other languages for their
: purity? What if I actually talk about something relevant?)
I suppose you could always wrap it instead. What you're talking about
already sounds suspiciously like Aspect Oriented Programming.
: >: # other thingies:
: >:
: >: sub foo { ... };
: >: @array = @&foo # all the results of foo, lazily.
: >
: >Don't see the need for that when
: >
: > @array := foo()
: >
: >does laziness implicitly already. Maybe even
: >
: > @array = foo()
: >
: >maintains laziness if it sees an infinite iterator in the return
: >value of foo(). Or maybe it blows up and tells you to use ":="
: >to avoid trying to make a copy. That's probably cleaner.
:
: This is going to take me a while to get my head round... Does this
: particular foo() return an iterator? Or is it something which is
: iterated? Have I missed a bit of a synopsis or apocalypse which would
: make all this clear to me or are we still in handwaving mode?
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.
: >Exceptions should not be used for
: >something so mundane as running out fo values.
:
: Amen to that! One reason I ran screaming from Java was having to catch
: ArrayOutOfBoundsException all the time. And all those exceptions which
: the compiler forces you to catch. They're handy, but there is a limit. I
: prefer return values which can indicate if they're valid or not. undef
: is excellent for that :-)
:
: A string pretending to be undef can be even better. Can we still do
: that? I seem to recall it being in something at some point along the way.
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..."
: >If that's necessary to keep the Lazy from blocking when it runs out
: >of values. Just like an ordinary array, a Lazy has to be aware of
: >when it is out of values, and when it should call into some meta-Lazy
: >for more iterator values. And I suppose that meta-Lazy could in
: >turn have a meta-meta-Lazy, which could have a meta-meta-meta-Lazy,
: >and now my brane hurts.
:
: And soon your entire program consists of code which may or may not ever
: be evaluated. Welcome to Haskell :-)
Next thing you'll be telling me is that all this partially evaluated
code shouldn't have any side effects. :-)
Larry
