Luke Palmer wrote:
> Just some initial thoughts and syntax issues. I'll come back to it on
> the conceptual side a little later.
I'm looking forward to it.
> Jonathan Lang wrote:
> > 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:?
Neither do I; I was assuming that the purpose of coerce: is to allow
implicit type conversions - that is, if I feed a complexRectilinear
object into an argument slot that's looking for a complexPolar object,
this method would be called implicitly and the result would be used
instead.
> > ...
> > }
> >
> > ... 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 :-).
FWIW, I didn't read theory.pod as thoroughly as I probably should
have, nor did I grasp it as well as I would like. But when I looked
at the concept of "virtual lists", the union/factory/generator triad
seemed to be, conceptually, a perfect fit: the "virtual list" is
actually a union, whose factory includes generators that produce
information about the "list" on demand. More generally, a union would
be the appropriate tool for the magic behind what Perl 5 used ties
for.
> 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.
I'm not sure I'm following this.
> > 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.
That wasn't the intent; the intent was to define a
"something-or-other" C<complex> that represents the fact that whatever
does this sometimes behaves like a complexRectilinear and other times
behaves like a complexPolar. Even the underlying information (the
attributes involved) may vary from role to role, though what those
attributes represent ought to be the same regardless of which role is
in use.
> 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.
C<union> was probably a bad name for it, especially considering that
theory.pod already uses C<union> for a very specific purpose.
C<choice> might have been a better name.
> > 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.
That's the most traditional way, yes; but is there anything wrong with
the concept of implementing it based on a factory instead of a role?
> > 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] ]
I'm not so much thinking that so much as:
[ ..., a[-2], a[-1], a[0], a[1], a[2], ... ]
When dealing with a finite list of powers, you'd still have the
(open-ended on both sides) list above for the purpose of accessing
individual elements, although if @a.count == 3 then @a[-1] should
produce something that represents the same place on the number plane
that @a[2] does - though not neccessarily using the same numbers, at
least not when looking at it using the polar coordinate system.
--
Jonathan "Dataweaver" Lang
