Possible Vector Operator Notations
Smylers
have problems, with some having significant impact elsewhere in the
language. After reading a few hundred mails on the subject I'm no
longer sure what I prefer, but thought I'd be in a better position to
have an opinion if I at least knew what the options were.
In case anybody else feels similarly, I've listed the main contenders
below together with salient points pertaining to them gleaned from this
list. (Credit to those who originally made them, and apologies for
omitting attributions from this compendium.)
The suggested syntax is demonstrated with the hypothetical C<op>
operator (presumably making it a hyper-hypo op):
* the "as we were" option: ^op
» Tilde is used for xor, underscore remains string concatenation.
» Consistent with previously published Perl 6 code samples.
» No character left for eating whitespace.
» No way of distinguishing precedence of vector assignment op.
» Slightly embarrasing to have so much discussion, go round in
circles a couple of times, and end up right where we started.
* the "xor is a double-sided not" option: ^op
» Exclamation mark is used for xor (in its various forms), leaving
tilde for concatenation and underscore for eating whitespace.
» Vector ops remain consistent with previous code samples.
» No way of distinguishing precedence of vector assignment op.
* the "looks like an array" option: [op]
» Seemed a nice idea, but doesn't work with other use of square
brackets.
* the "guillemot" option
» Inconvenient for those who don't live near the sea, and messy even
for those who do.
* the "guillemet" option: «op»
» Looks nice.
» Awkward to type for some people.
» May not be transmitted correctly in mailing lists and similar.
» May not be in the character set used by some people in the world.
» Has distinct characters for vector ops that have no other meaning
in Perl.
» Uses 'special' looking symbols for 'special' ops.
» Looks really nice.
» Looks really likely to cause confusion in mailing lists.
* the "mélange" option: ^[op]
» Xor continues to use caret.
» Overcomes problems with using just caret or square brackets.
» Easy enough to type.
» Looks ugly and/or unbalanced.
» Potential for confusion with overloading symbols used individually
elsewhere in Perl.
* the "either of the above" option: «op» and ^[op]
» Can choose the elegance of the guillemet or the type-ability and
encoding-neutral convenience of the mélange.
» The non-Ascii characters still cause hassle when they are
transmitted.
» The two variants don't look anything like each other.
» Everybody will have to learn both versions to be able to cope with
others' code.
* the "generic extensibility" option: «op» and `<<op`>>
» Backticks and two-character mnemonics from RFC1345 are used to
provide an Ascii-only alternative for some symbols.
» The Perl 5 use of backticks has to be provided some other way.
» It's neat to have a consistent way of typing special symbols.
» Possibly overkill if Perl doesn't introduce any standard non-Ascii
operators other than vector.
» Having more power in cryptic symbols rather than words may lead to
increased claims of Perl being unreadable.
» Still suffers from needing to be able to view and transmit
non-Ascii characters.
* the "temelliug" option: »op«
» Guillemets the conventional way round are used for qw().
» The same, unusual, symbols are used for two very different
purposes.
» Still the non-Ascii problems.
* the "how many characters?" option: <<op>>
» Bitwise shift operators are preceded with a plus (like other
bitwise ops are).
» Here-docs require the tag to be quoted.
» Vector operators take up five or six characters.
» Probably faster for many people to type than guillemets are.
(The second of each doubled character is very fast to type.)
» Vector bitwise shifts may look a little odd.
* the "single chevrons" option: <op>
» The Perl 5 'read a chunk' use of angled brackets needs to be
provided some other way.
» Not much to type.
» Potential (human, if not parser) confusion from same characters
being used elsewhere in Perl for comparisons and bitwise shifts.
* the "suggested but not much discussed" options:
~op
~~op
`op
`op`
*[op]
.[op]
=[op]
![op]
_[op]
:[op]
'[op]
~[op]
(>op<)
<)op(>
>)op(<
[>op<]
[)op(]
Phew! I'm slightly concerned at this list making Piers's job too easy,
but have tried to minimize that effect by posting on a Monday (meaning
that this mail is ineligible for inclusion in the next summary and is
likely to be out of date by the time of the following one).
Smylers
Simon Cozens
Thank you very, very much for this; this is supremely helpful.
> » No character left for eating whitespace.
That's a feature, not a bug! The space-eater alternately worries, confuses
and scares me.
--
I want you to know that I create nice things like this because it
pleases the Author of my story. If this bothers you, then your notion
of Authorship needs some revision. But you can use perl anyway. :-)
- Larry Wall
Damian Conway
> * the "looks like an array" option: [op]
>
> » Seemed a nice idea, but doesn't work with other use of square
> brackets.
Could be made to work. Suppose that every operator definition (explicit or
implicit) automagically also defined a variant with square brackets around it.
No ambiguity for any defined operator.
Of course you lose the ability to apply an arbitrary alphabetic function
across a vector of arguments, but maybe that's not such a terrible price.
Especially if we allow rvalue C<for> multi-stream loops, which give the
same functionality.
Damian
Piers Cawley
> Phew! I'm slightly concerned at this list making Piers's job too easy,
> but have tried to minimize that effect by posting on a Monday (meaning
> that this mail is ineligible for inclusion in the next summary and is
> likely to be out of date by the time of the following one).
Har har. If you don't think I've bookmarked that post you have another
think coming mate.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?