On Fri, May 29, 2009 at 6:53 PM, Darren Duncan <dar...@darrenduncan.net> wrote:
> I had some thoughts lately about the Perl 6 operators, and wanted to bounce
> some ideas.
>
> --------
>
> Firstly, regarding the string replication ops as documented in Synopsis 3,
> 'x' and 'xx', I'm wondering whether it might be better to have something
> that incorporates a '~', since that operation is about catenation.
>
> Would perhaps '~*' work better than 'x' to signify better what the operation
> is doing; the '~' in this case means catenation and the '*' is meant to
> invoke 'multiply', not 'whatever'.  So '~*' means "catenate a multiple of
> times".
>
> This would then free up 'x' to be used for something else, if anything.
>
> As for a substitution for 'xx', I'm less sure about that.
>
> Thoughts?

I wouldn't mind 'x' becoming '~x' and 'xx' becoming 'x'; it strikes me
as a lot more intuitive - and I've wanted to see this done for a while
now.  I suppose that you might also introduce a '?x' and/or a '+x' to
complete the set, though for the life of me I can't think of how
they'd work or what they'd be good for.

> Secondly, regarding the Bool type, I think it would be useful for Perl 6 to
> define the full complement of dyadic logical operators, of which I count a
> few that you don't appear to already have.  Probably the best place is in
> Synopsis 32.
>
> Note that all the dyadic ops I am discussing are meant to be read as infix
> ops only.
>
> These are the boolean/logical ops you already have:
>
> Niladic ops aka value literals / constants:
> * Bool::False
> * Bool::True
>
> Monadic:
> * not aka !, but ¬ alias could be added
>
> Dyadic:
> * and aka &&, but ∧ alias could be added
> * or aka ||, but ∨ alias could be added
> * xor aka ^^ aka !===, but ⊻, ↮ aliases could be added
> * ===, but xnor, ↔ aliases could be added
>
> Now I'm not sure whether or not [also, andthen, orelse] have the desired
> semantics of any others or not, or whether [if, unless] could be used as a
> value-resulting infix operator or not.

<also andthen orelse> carry subtly varied semantics involving
short-circuiting behavior: andthen and orelse are like && and ||
except that they work off of success/failure instead of true/false;
"also" is an ordered, short-circuiting version of "&" (and thus
"all").  For some time now, I've wanted an analog for '|' and 'any' -
but the only name I can think of for it would be 'else', which has
some obvious clarity issues.

> But here are a few more dyadic:
> * nand aka ⊼ aka ↑
> * nor aka ⊽ aka ↓
> * implies aka imp aka →
> * nimp aka ↛
> * if aka ←
> * nif aka ↚
>
> For that matter, as you know, every single boolean/logical operator could
> also have a bitwise analogue, if people were so inclined.

Side note: one thing that I recently learned concerning implication
operators is that the direction of the implication doesn't necessarily
follow the direction of the arrow.  In particular, "A if B" is "A←B",
and "A only if B" is "A→B": in both of the original statements, the
implication flows right to left.

Most of these suggestions could be implemented in a "Unicode
Operators" module; I see little need to put them into the default
setting.  I'm leery of introducing new unicade operators that don't
have ASCII aliases, as you might be inclined to do with set operators.

--
Jonathan "Dataweaver" Lang

Reply via email to