On Fri, Mar 12, 2004 at 05:32:33AM -0500, Austin Hastings wrote:
: Boo, hiss.
:
: Two things:
:
: 1- I'd rather use "inplace" than self.
What is this "place" thing? I want the object to do something to itself
reflexively, which may or may not involve places...
: 2- I'd rather it be AFTER, than BEFORE, the name, because
:
: method sort
: method sort:inplace
:
: reads, and more importantly SORTS, better than
:
: method inplace:sort
: method sort
Well, that's a point that has some weight, but...
: To wit:
:
: method :infix:<=>(Array, Array) returns Scalar
: method :infix:==(Array, Array) returns Boolean
: method :infix:!=(Array, Array) returns Boolean
: method :infix:===(Array, Array) returns Boolean
: method :infix:!==(Array, Array) returns Boolean
: method :infix:x(Array) returns Array
: method :infix:x:inplace(Array is rw)
:
: ### Note: How to handle [undef]? return-undef, or PHP-like push?
: method :postfix:[](Array is rw, ?Scalar) returns Scalar
:
: ### Inplace-only?
: method clear(Array is rw) returns Boolean
:
: method compact(Array) returns Array
: method compact:inplace(Array is rw)
: ### Inplace-only?
: method delete(Array is rw, Int) returns WHAT, exactly?
:
: method difference(Array, Array) returns Array #A-B
: method differences(Array, Array) returns Array #(A-B) + (B-A)
: method exists(Array, Scalar) returns Boolean
: method flatten(Array) returns Array
: method flatten:inplace(Array is rw) returns Array
: method grep(Array, Code) returns Array
: method includes(Array, Scalar) returns Boolean
: method index(Array, Scalar) returns Int
: method intersect(Array, Array)
: method is_empty(Array) return Boolean
: method join(Array, String)
: method length(Array)
: method map(Array, Code) returns Array
: method pack(Array, String) returns String
: method reverse(Array) returns Array
: method reverse:inplace(Array is rw)
: method rindex(Array) returns Int
:
: ### Boy are these likely to be wrong!
: method sort(Array, ?Code) returns Array
: method sort:inplace(Array is rw, ?Code)
:
: ### Inplace-only?
: method splice(Array is rw, ?Int, ?Int, ?Array)
:
: method union(Array, Array) returns Array
: method unique(Array) returns Array
: method unique:inplace(Array is rw)
:
: ### Inplace-only?
: multi method fill(Array is rw, Scalar, Int, Int)
: multi method fill(Array is rw, Scalar, Int)
: multi method fill(Array is rw, Scalar, Array)
: ### Inplace-only?
: multi method pop(Array is rw, ?Int) returns Array
: multi method pop(Array is rw) returns Scalar
: ### Inplace-only?
: multi method unshift(Array is rw, Scalar) returns Array
: multi method unshift(Array is rw, Array) returns Array
: ### Inplace-only?
: multi method push(Array is rw, Array) returns Array
: multi method push(Array is rw, Scalar)
: ### Inplace-only?
: multi method shift(Array is rw, Int) returns Array
: multi method shift(Array is rw) returns Scalar
:
: multi sub each(Array) returns Iterator # HOW does this work?
But you can put the declarations in whatever order you want regardless
of the default collation order, so this is kind of a weak argument unless
you're writing a tool, in which case you could certainly ignore whatever
prefixes you like when you sort.
: (Note also that :...fix sorts better than in-, post-, and pre-. I'd like to
: suggest changing
: them, since it costs nothing and results in a mild improvement in automation
: behavior.)
The main reason those are out front is to reduce grammatical ambiguity
when you use an operator sub name where a term is expected. That is,
it's harder to parse:
$x = +:foo();
correctly than
$x = foo:+();
Even with sort:inplace, how does the parser know that the name is
"sort:inplace", or whether the user is trying to pass a pair :inplace
to the "sort" routine? The foo:-style prefixes are "reserved" in
general, but the :foo pair is not, and it would be a mistake to start
introducing reserved pairs, I think, much like the Perl 5 problem
that ARGV is truly global while ARGH is not.
: > > Another interesting question, if the "postfix:.=foo" mess is defined
: > > with as self:foo, should infix:+= be defined as self:+ instead?
: > > In other words, should the <op>= syntax really be a metasyntax like
: > > hyperoperators, where you never actually have to define a C<»+«>
: > > operator, but the hyperoperator is always autogenerated from ordinary
: > > C<+>? So basically any infix:<op>= gets remapped to self:<op>.
: >
: > I think that would be cleaner.
:
: Alternatively, is there a valid reason to *need* to define your own
: hyperoperator?
:
: That is, can you code C< @a +« $x > better than C< @a.map {return $_ + $x}
: >? I suspect that it's possible to do so, particularly for such simple cases
: as assignment. (Hint: Persistent objects, database, one SQL statement per
: assignment.)
:
: So perhaps I should ask for an :infix:=« operator override?
I'm extremely leary of giving people the right to break the "hyper"
contract. Which they will do left and right if given opportunity.
The hyper contract says
@a »operator« @b
always applies the operator in parallel to corresponding elements.
I don't want people using »« for other higher-order mathmatical
operators that just happen to work on arrays of multiple elements.
They can find their own operators for that...
But if there were a way of keeping the contract while giving the
flexibility to the implementor, that would be okay.
: > > On the other hand, it also means that
: > > someone can say silly things like:
: > >
: > > $a cmp= $b
: > > $a ~~= $b
: > >
: > > I suppose we could simply disallow meta-= on non-associating operators.
: > > Can anyone come up with a non-associating binary operator that *should*
: > > have an assignment operator? The basic definition of non-associating
: > > seems to be that the type of the arguments is incompatible with the
: > > type produced by the operator. Which is precisely the problem with
: > > something like
: > >
: > > $a cmp= $b
: > >
: > > insofar as $a is being treated as a string at one moment and as a
: boolean
: > > at the next.
: >
: > I think it's "merely" a philosophical problem.
: >
: > After all, we don't complain when people write:
: >
: > $a = $a cmp $b;
: >
: > So should we complain when people write exactly the same thing, only as:
: >
: > $a cmp= $b;
: >
: > Stylistically, they're equally as abhorrent, but Perl users aren't
: expecting
: > the Stylish Inquisition.
: >
:
: So long as you allow modifiers in there, as:
:
: $a cmp:i:n=8= $b;
:
: I'm okay with it. Good luck with <=>=
We're thinking that adverbs on infix ops have to go after the right arg:
$a cmp= $b :i:n(8);
That is, op modifiers are only allowed where an op is expected. Otherwise
we can't use a general :foo() syntax for pairs when terms are expected.
Larry
