>> I'm just suggesting the same for the ~ character:
>>
>> ~~ smart-match
>> ~ concatenate
>> ~| stringy bitwise OR
>> ~> append args
>> <~ invocate
>
> This is where I get lost. I see 4 different concepts being overloaded
> onto '~'.
>
> In the first it indicates 'match' just as it always has for =~ and !~.
> In the second, it is being used for concatentation - nothing to do with
> matching. In the third it is being used to cast stringwisely - nothing
> to do with matching or concatenation. In the fourth and fifth it is
> being used to re-order arguments - nothing to do with matching,
> concatenation (well, possibly concatenation of argument lists) or
> stringwise casting.
Well, I always used =~ // for strings, and (from what I gather) ~~ is the
uber =~ in that it can figure out types and meaningfully guess what
"matches" means, so I see the first 3 as "string toys", just as the -- -
and -= were all "subtraction"
I'll give you that ~> and <~ don't do stringy things, though :) But I
think they'd be read, once it's more than theories in email messages ;o,
as single ops (like the ->) rather than "squiggly and arrow" it'd be
"squigglyarrow" ... I think the major concern would, to me, be that ~> and
-> are kinda close, visually, and I imagine nearly indistinguishable in
some fonts :/
> I would like to see '~' kept for matching and just matching. It is well
> known in this role and is analogous to the "roughly equals" operator in
> the Real World (extended ASCII character 247 - just don't ask me to type
> it).
Now you've given them ideas :) we're all gonna be typing ≈ (OK, so,
all I can get is that it's unicode 2248; still haven't figured out how to
ACTUALLY type it :o Alt-247(˜) seems to be the wrong character though and
I don' see it anywhere on my HTML ascii chart :/
> I also think '_' should be used for concatenation because it's in
> keeping with the existing use of 123_456.
That actually reads like _ is a null character "This is not the character
you are looking for. There is no character, there is only zool" kinda
thing ... I know it's concat, but it reads more like a "visual separation
character that is COMPLETELY ignored by the parser, except insofar as to
explicitly ignore it"
> As a prefix character to indicate stringwise (numberwise, bitwise, etc)
> casting, can we not use a single character prefix, e.g. 's' for string,
> 'n' for number, 'b' for bitwise, 'v' for 'vector', and so on?
>
> $a s| $b; # stringwise
> $a b| $b; # bitwise
> $a n| $b; # numberwise
> @a v| @b; # vector
> @a vsn| @b; # vector stringwise bitwise
I think this was brought up during the operators thread (I admit, I only
skimmed it ... I had 6 or 7 versions in my inbox when I got to it :/) and
the "against"s pointed out that it would mandate whitespace separation
(although, some of the coders I know could live with some mandatory style
guidelines, ugh) ...
>> I mean, compare:
>> @a ~> grep {...} ~> map {...} ~> sort ~> @a;
>> with:
>> @a |> grep {...} |> map {...} |> sort |> @a;
>>
>> I don't know about *your* font, but in mine the ~> and <~ versions are
>> at least twice as readable as the |> and <| ones.
>
> In my font, or perhaps more importantly, to my eye, the |> and |< are
> more readable. But regardless, I think it's more important to make the
To me, for some reason, |> reads as a forward gate "Do not continue unless
the previous item was true; if it was, feed the result here" ... <|
doesn't read like much, and |< looks like some 1337 h4xx0r trying to be
cool, honestly :o It just looks broken! As an op, I would expect it to
translate to "OR Less Than" and I can't come up with how to use that "$a
== 7 |< 200" I guess :o
And would the consistency rules require them to be:
~> ~< ? so that the ops look similar? (If so, I'm gonna vote that ~<
looks like a fish and is just weird :)
--attriel
