Perl6 Operator List (REMAINING ISSUES)
Michael Lazzaro
issues remain before the ops list can be completed.
----
1) Need a definitive syntax for hypers,
^[op] and «op»
have been most seriously proposed -- something that keeps a
bracketed syntax, but solves ambiguity issues.
2) Possible inclusion of unary prefix ^, meaning "complement".
(Assuming doesn't conflict with (1))
3) Possible inclusion of "like"/"unlike" or similar as synonyms for ~~
!~. Which we don't have to decide now.
----
All other op issues, by my count, revolve around the meanings of
specific hyperop constructs. There is one, overriding question with
the hyperops, which is the precise relation between an op, an
assignment op, and their (three!) hyperop equivs:
A op B
A op= B
A ^[op] B
A ^[op=] B
A ^[op]= B
If we can formalize the precise relationship between the three hypers
in the presence of scalar and list (and hash?) values for A and B, I
believe we can answer nearly all the hyperop questions definitively.
For example:
@a ^[op] @b # array v array
$a ^[op] @b # scalar v array
@a ^[op] $b # array v scalar
$a ^[op] $b # scalar v scalar
@a ^[op=] @b # array v array
$a ^[op=] @b # scalar v array
@a ^[op=] $b # array v scalar
$a ^[op=] $b # scalar v scalar
@a ^[op]= @b # array v array
$a ^[op]= @b # scalar v array
@a ^[op]= $b # array v scalar
$a ^[op]= $b # scalar v scalar
Some of these are nonsensical, some of them aren't. So which are
which, and can someone demonstrate that the rule holds true for ALL
hyperoperators, as opposed to just MOST? ;-)
MikeL
Erik Steven Harrison
--
On Wed, 30 Oct 2002 16:37:09
Michael Lazzaro wrote:
>OK, by my count -- after editing to reflect Larry's notes -- only a few
>issues remain before the ops list can be completed.
>
>----
>
>1) Need a definitive syntax for hypers,
> ^[op] and +op;
> have been most seriously proposed -- something that keeps a
> bracketed syntax, but solves ambiguity issues.
Maybe this is a bit radical (but hey, I'm not ashamed) but why not do
what Larry proposed way back in Apoc. 1, namely, grabbing <> from
iterators. Angel Faus already made a proposal for
grabbing them for a qw() variant. I'd prefer stealing them for
<hyperop> meself. I love hyperops (vector ops, if you prefer), can't
easily type +hyperop;, and ^[hyperop] leaves a bad taste in my mouth.
Maybe we could give fuel to Cozen's fire by totally dropping
consistency, and generalize hypers to some quote like variant
allowing you to define your own delimiters. Hey! then maybe hyper is
spelled map . . .
-Erik
--
On Wed, 30 Oct 2002 16:37:09
Michael Lazzaro wrote:
>OK, by my count -- after editing to reflect Larry's notes -- only a few
>issues remain before the ops list can be completed.
>
>----
>
>1) Need a definitive syntax for hypers,
> ^[op] and +op;
____________________________________________________________
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
fear...@figaro.weizmann.ac.il
and also this :
%a ^[op]= @b # hash v array
%a ^[op]= $b # hash v scalar
%a ^[op]= %b # hash v hash
@a ^[op]= %b # array v hash
$a ^[op]= %b # scalar v hash
>
> Some of these are nonsensical, some of them aren't. So which are
> which, and can someone demonstrate that the rule holds true for ALL
> hyperoperators, as opposed to just MOST? ;-)
>
> MikeL
>
>
>
arcadi
Larry Wall
What would those mean? Are you thinking only of hashes with numeric keys?
Larry
fear...@figaro.weizmann.ac.il
no but hash can have property that tells how to turn its keys to
integer indexes if it fins itself in the ^[op] situation .
just like %hash can have a property that tells it how to behave in
regexp /<%hash>/ . And then just like here there may be some default
value for that property . I dont know what it should be . is it sane ?
%hash is if_in_vectorized_op_map_keys_to_integers_as { <some function
returning integer> }
arcadi .
fear...@figaro.weizmann.ac.il
as I understand , every such construct will be "macro preprocessed"
parser and in "real" program ( that is in parrot ) there will be no
vector operations in perl sence , only as optimizations . so I think
that if we are talking about oprator list , we just can state ( and we
did ) that such operators are present in language . their prcize
functionality may be defined or changed by pragma or module.
what I want to say is that we definitely have ^[op] staff so somebody
in or out of sanity will ask ( or make a mistake ) what is %a ^[op] %b
and the answer already is a question of ( Apo 29 ? ). the language
have beasts $x, @y, %z and they can talh through op , ^[op] , ...
so they will , or at least try . although by the laws of jungle
something can be made a taboo . But thats life...
arcadi .
Peter Haworth
messages]
On Wed, 30 Oct 2002 16:37:09 -0800, Michael Lazzaro wrote:
1) Need a definitive syntax for hypers,
> ^[op] and «op»
> have been most seriously proposed -- something that
> keeps a bracketed syntax, but solves ambiguity issues.
>
> 2) Possible inclusion of unary prefix ^, meaning "complement". (Assuming
> doesn't conflict with (1))
If ^ means xor (and complement), then we can't use it for hypering. Consider
this example:
@a ^[alpha_op] +3
You can parse this in two ways:
* "array a", "hyperop alpha_op", "unary plus", "literal 3"
* "array a", "binary xor", "call alpha_op and put result in arrayref",
"binary plus", "literal 3"
The operator doing the least at present seems to be ! (my recent attempts to
reclaim it aside). If we keep ^ as the only xor/complement operator, we can
use ! as the hyperoperator indicator without ambiguity:
@a ![alpha_op] +3
Or (since people seem to like using ^ for hyperness), we could steal ! back
as doing all the xor/complement things that ^ is doing now, and leave ^
doing just hyperstuff. This stops ! being a (mostly) synonym for ^, which I
didn't really like, but does bring back the confusion between !! and ||.
If we want to have a sigil meaning "the next set of brackets surround a
hyperoperator," it pretty much can't be the same as any of the other
operators, since that introduces ambiguity all over the place. This is
unfortunate, since perl seems to use every printable ASCII character for
something. Using French quotes gets around this, since they aren't being
used for anything else. OT3H, I can't find the «» keys on my keyboard, but
I'm sure I'm just not looking hard enough.
--
Peter Haworth p...@edison.ioppublishing.com
"Are you the police?"
"No ma'am, we're musicians."
fear...@figaro.weizmann.ac.il
>
> @a ^[alpha_op] +3
>
> You can parse this in two ways:
> * "array a", "hyperop alpha_op", "unary plus", "literal 3"
> * "array a", "binary xor", "call alpha_op and put result in arrayref",
> "binary plus", "literal 3"
>
I think this was already discusse dbefore .
^ - xor and ^[] vectorization can coexist because perl takes longest
known operator sequence ( and the vectorization is ^[] not "^ [ ]")
so ^[] is vectorization
and ^ [foo] *cannot*
just like ~~ is binding
and ~ ~ is ( string scalar context ( string scalar context (
so if you mean xor -- write ^ [...]
arcady