On Fri, Nov 11, 2005 at 06:21:53AM +0000, Luke Palmer wrote:
: 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.
It's not about inlining in general, but particularly about the
relationship of precedence with assignment. And you presumably
*can* say:
has ($.x, $.y) = (1, 2);
to mean the same as:
has $.x = 1;
has $.y = 2;
Likewise
state ($.x, $.y) = (1, 2);
means
state $.x = 1;
state $.y = 2;
: > 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;
<rampantspeculation>
Given the new relationship between
$obj.method(...)
and
$obj.method: ...,
I'm wondering if we can make the same relationship between
method $obj(...)
method $obj: ...
That is, : becomes more of a Haskellish $ operator. I speculated this
earlier when I wanted to change
$obj.method :{...}
into
$obj.method: {...}
But "foo $bar(...)" is probably too ambiguous with a possible foo list
operator unless we were to require : on all calls to list operators:
print: 1,2,3
That's likely to inspire mutiny. Though we could perhaps get away
with requiring the colon only on list operators that have more than
one argument, on the theory that
foo 1;
is always the same as
1.foo;
</rampantspeculation>
: 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.
And what's the common "role" of a scalar that can have a string
implementation in several abstraction levels, plus any number of native
integer/float and bignum/bigfloat implementations hiding behind it?
Interesting question.
: > 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].
I believe we already said you could pop or refer to the end of an
infinite array in A6/Appendix B.
: > 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.
All is fair if you predeclare.
: 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.
While you're there, also think about the gray area between arrays and hashes,
and whether .[...] subscripts are just a specialized form of .{...} subscripts.
Larry
