Just some initial thoughts and syntax issues. I'll come back to it on
the conceptual side a little later.
On 11/10/05, Jonathan Lang <[EMAIL PROTECTED]> wrote:
>
> class complexRectilinear {
> has $.x, $.y;
Hmm, that might need to be
has ($.x, $.y);
However, inlining "has"s isn't possible, so there's really no reason
for that restriction. But it might be good just for consistency with
"my". But it also might not, because I'm always annoyed with those
parentheses.
> method infix:+ ($a is complexRectlinear, $b is complexRectilinear)
method infix:<+> (complexRectilinear $a, complexRectilinear $b)
> returns complexRectilinear {
> return new complexRectilinear($a.x + $b.x, $a.y + $b.y);
return new complexRectilinear: $a.x + $b.x, $a.y + $b.y;
> }
> ...
> method coerce:complexPolar () returns complexPolar {
> return new complexPolar ($.x * $.x + $.y * $.y, atn($.y / $.x) *
> (sgn($.x) || sgn($.y)));
> }
Hmm. I don't know why you marked this with coerce:? Maybe coerce:
marks a one-to-one correspondence; i.e. things that can be used
interchangably. But for now, I think you either mean:
method asComplexPolar ()
Or:
method coerce:<as> (--> complexPolar)
(that might take an argument of some sort)
> ...
> }
>
> ... and a similar definition for class polar.
>
> (Technically, coerce:complexPolar and infix:+ are "generators" in the
> sense that they create new instances of the class; but ISTR something
> about generators not being allowed in classes.)
Ahh, you read that in theory.pod. It's not clear that the "factory"
and "generator" abstractions are all that useful (I'm still looking
for a good use though). I just included them for symmetry (like
Maxwell :-).
Don't think that you're not allowed to return instances of the class
you are defining from methods. You can. Generators are more
restrictive: they say that any subclass must return an instance of
*itself* from that method; i.e. it probably wouldn't be able to use
your implementation. But that breaks subclassing laws, which is why
they aren't allowed in classes.
> You should then be able to say:
>
> union complex {
> class complexRectilinear;
> class complexPolar;
> }
>
> ...or something of the sort. At this point, you have the ability to
> freely represent complex numbers in either coordinate system and to
> switch between them at will. Am I right so far?
Hmm, that union looks like a backwards role. That is, you're creating
a role "complex" and saying that the interface of that role is
whatever is common between these two classes. Interesting idea... not
sure how fruitful that is though.
The idea of several isomorphic implementations of the same thing has
occurred to me several times, but I never figured out how it might
work. Let me think about that.
> multi exp($a is complex, $b is complex) returns list of complex { ... }
multi exp(complex $a, complex $b) returns List of Complex {...}
> However, if $b's real component isn't a rational number, you won't
> have a finite number of elements in the list. Here's where I get a
> little fuzzy: IIRC, there's some means of defining a list by providing
> an element generator:
>
> generator element($index) returns complex { ... }
>
> Is there a way of setting things up so that an attempt to ascertain
> the list's length would call a separate generator for that purpose?
>
> generator length() returns complex { ... }
>
> At any point above, am I abusing the concept of theories, or failing
> to use them to their fullest extent?
Well, you're not using generator correctly.
You're really just trying to define a lazy list or an iterator, right?
That most likely involves implementing some role:
role ComplexPowers does Lazy {...}
or:
role ComplexPowers does Iterator {...}
And then creating one of those objects from within your pow function.
Nothing deeply type-theoretical going on here.
> If $b's real component is
> rational, it makes some sense to treat [-1] as the last element in the
> list, [-2] as the second-to-last, and so on; but if $b's real
> component is irrational, there _is_ no positive end to the list, and
> it would make sense if [-1] referred to the first result that you
> reach by rotating in the clockwise direction from the primary result.
> Can an "infinitely long" list be set up so that [-1] still has
> meaning?
Hmm. I don't see why not. Though we haven't established the array
laws yet, you're probably not breaking any of them by doing that.
You can consider your array to be transfiniteish:
[ a[1], a[2], ..., a[-2], a[-1] ]
Understanding that no matter how long you iterate going forward,
you'll never get to a[-1].
> As an example,
> let's say that $b = 0.5. This means that the first result is rotated
> zero radians counterclockwise from $a's direction, and corresponds to
> [0]. [1] would correspond to being rotated pi radians, and the length
> generator would say that there are only two elements in the list.
> Could you set things up so that you could nonetheless access [2]
> (which is rotated by 2*pi radians), [3] (rotated by 3*pi radians), or
> possibly even have [-1] represent a rotation by -pi radians?
Well, it would certainly be okay to have an infinite list that had
that property. However, having the list report that its length is,
say, finite $n, and then having @list[$n] be something besides undef
may be breaking some law (but maybe not[1]).
What you're really doing is defining the indices mod $n. Maybe
there's some way to tell the compiler that your indices are defined
that way to allow this sort of behavior. Maybe you could make a
subclass of Array called ModArray or something that allowed this.
Maybe you're simply not allowed to use square brackets in a case where
the list is finite but defined for all indices.
But that's all theoretical formality. For the Perl practicioner, feel
free to break the laws if it helps you get your job done. :-)
Luke
[1] I think I'm going to embark on writing down the laws for a few of
our basic types so we can actually talk about this without speculating
so greatly.
