Normalization of metaops

[Mark Lentczner]

The concept of which metaops can apply to which other ops is looking  
pretty clear.


The goal, as I understand it from Larry, is that while in general,  
metaops should be allowed, we want to disallow them where they either  
make no sense, or are very unlikely to be what the programmer thought  
they were doing.


In addition, it seems to me that since metaops should be applicable to  
user created ops, the particular tests the parser performs must be  
well defined because users will be annotating their operators to get  
them to have the right metaop applicability.


I propose the following:


Rop infix -- infix
Xop infix -- infix
op  prefix -- prefix
op  postfix -- postfix
op  infix -- infix

- the inner op should be value like, that is things
  like == and .= and ^ff^ don't ever really make sense here
- these should test for :value

[op]infix -- prefix
op= infix -- infix

- the inner op needs to be associative, and needs to produce a value
  of similar type to its arguments
- these should test for :iso
- [op] has an explicit provision for chained operators
- so [op] should support :assoc(chain) if the op is :value

!op infix -- infix

- the inner op must return a value that makes sense when used in a
  boolean context, and hence when negated
- this should test for :bool

The current levels would then have:

%methodcall
%autoincrement   :value
%exponentiation  :value :iso
%symbolic_unary  :value
%multiplicative  :value :iso
%additive:value :iso
%replication :value :iso
%concatenation   :value :iso
%junctive_and:value :iso
%junctive_or :value :iso
%named_unary :value
%nonchaining :value
%chaining:value :bool
%tight_and   :value :iso
%tight_or:value :iso
%conditional
%item_assignment
%loose_unary :value
%comma
%list_infix  :value :iso
%list_assignment
%list_prefix
%loose_and   :value :iso
%loose_or:value :iso
%sequencer

Two exceptions to these lists:
sym, gets :value and :iso
sym% gets :bool as well

I'm not so happy with these names, :boolish? :simple? I just don't  
know...


This does explicitly remove a few classes of operator from being used  
in hyper, reverse and cross: Such things as the sequencer ops,  
assignment, and method call.  Testing with the current form of STD.pm  
(r25127), not all of those things parse anyway.


I almost have a patch against STD.pm ready to go that implements this  
and passes teststd...  What do you think? Post it here? Check it in?   
This is a goofy idea, drop it?


- MtnViewMark

Re: Normalization of metaops

[Larry Wall]

On Sat, Jan 31, 2009 at 01:21:57PM -0800, Mark Lentczner wrote:
 Two exceptions to these lists:
   sym, gets :value and :iso
   sym% gets :bool as well

Also note that = is :value :iso despite being lumped with assignment.
I consider = to be equivalent to . in Lisp, so [=] is essentially
just an S-expr in disguise.

 I'm not so happy with these names, :boolish? :simple? I just don't  
 know...

I think :iso is fine, unless someone wants to weigh in with something
from group theory.

As for :bool, that is a bit more problematic if it can be construed as
a strict type check.  We want to express the concept of something that
can be used as a boolean.  :truthy maybe?  :iffy?

 This does explicitly remove a few classes of operator from being used in 
 hyper, reverse and cross: Such things as the sequencer ops, assignment, 
 and method call.  Testing with the current form of STD.pm (r25127), not 
 all of those things parse anyway.

As long as we can make explicit exceptions, that seems okay.  And we
will have exceptions as long as we lump disimilar operators together
in the same precedence level like item assignment and =.

Seems like unaries should also be labeled :iso if they return the same
type, even though we don't have a use for it yet.

 I almost have a patch against STD.pm ready to go that implements this  
 and passes teststd...  What do you think? Post it here? Check it in?   
 This is a goofy idea, drop it?

Seems fine, and I think I like the simplicity; go ahead and check it
in unless someone can spot a difficulty.  We can always fix anything
that goes haywire, or split one of the categories again if necessary.

Larry