Re: renaming or adding some operators
On May 29, 2009, at 22:33 , Jon Lang wrote: 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. I have seen x (alt. y) used in print, so maybe alt? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
Re: renaming or adding some operators
On May 30, 2009, at 15:38 , Larry Wall wrote: Perhaps something like use *; should pull in all the Unicode operators. Which if course means that any golfing would start with *; ⨷ perhaps? It only makes sense that a Unicode operator be used to pull in all of Unicode. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
Re: renaming or adding some operators
Brandon S. Allbery KF8NH allbery-at-ece.cmu.edu |Perl 6| wrote: ⨷ perhaps? It only makes sense that a Unicode operator be used to pull in all of Unicode. Bravo. If you can't type that, you won't find it useful!
Re: renaming or adding some operators
Buddha Buck wrote: 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. There are 16 dyadic logical operators, not all of which make sense to have.You name 10. I think you answered your own criticism right there. The ones I didn't mention are ones that don't make sense to have. 2 of the 16 dyadic operators always result in false or true respectively, regardless of the arguments, same as 2 of the 4 monadic operators, and same as the only 2 niladic operators, contradiction/⊥ and tautology/⊤; only the last make sense to have. Another 2 of the 16 always result in a certain one or other of the arguments, respectively, regardless of the value of the second argument; they are like 1 of the 4 monadic operators that always results in its argument, and so isn't useful. Another 2 of the 16 always result in the opposite of the previous 2 I mentioned, and these are like the only 1 useful monadic operator, not/¬, that returns the opposite of its argument. This then leaves 10 dyadic operators that are actually useful, of which Perl (and most languages) clearly includes 3 as standard infix operators: and, or, xor/!===, === (xnor), which leaves 6 others of which AFAIK implies/→ is the most commonly used of those. Now, clearly ←,↚ are redundant with →,↛ if you just switch the operands around, but then by the same token ,≤/= are also redundant with ,≥/= if you just switch the operands, but it is useful to have both versions regardless. I'm certain I know the semantics of these (and chooses the minimum of the two, or the maximum, xor checks for difference, xnor checks for sameness), but I'm uncertain of some of the rest... But here are a few more dyadic: * nand aka ⊼ aka ↑ true unless both operands are true * nor aka ⊽ aka ↓ true if both operands are false * implies aka imp aka → true unless left operand true and right operand false. * nimp aka ↛ true if left operand true and right operand false? * if aka ← true unless left operand false and right operand true * nif aka ↚ true if left operand false and right operand true? See these urls which were 2 of my primary references when building my lists: http://en.wikipedia.org/wiki/Logical_connective http://www.rbjones.com/rbjpub/logic/log048.htm They should give you all the details. The other six, which don't depend on the value of both operands, would (if they existed) have the names false, left, right, nright, nleft, and true. I believe traditionally they are called: contradition, p, q, ¬q, ¬p, tautology (where p and q are the names of the arguments). Thirdly, there are I'm sure a number of other aliases that could be added to other ops, such as ≤ and ≥ for = and =, and ≠ for one of the inequality operators, although that last one would probably make more sense if = was the equality test operator, so maybe best to avoid ≠ then. Perhaps ≡ and ≢ as aliases? Well that's a thought, since those actually talk about 'identical' rather than 'equal', though I believe for purposes of logic (ignoring geometry say) they mean exactly the same thing, and I prefer the = and ≠ symbols. For all of that matter, I think that Perl 6 would look a lot prettier if it used = as the generic equality test op (what === is used for now) and used the likes of := for assignment/binding/etc. I don't know if using = for assignment is actually liked by people because they think it looks better or just because it has momentum say from Perl 5 and C et al. Probably the single main advantage I can see for needing a single character there is it combines easily with infix ops to make =foo ops, not that this still can't be done another way. Larry, did you choose = for assignment and == etc for comparison because you thought that looked prettier, or because that was the C/etc convention that you decided to copy? -- Darren Duncan
Re: renaming or adding some operators
Darren (): 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 like 'x' for string replication and 'xx' for list replication. To me, they share a sort of symmetry with '*' and '**' that at least help as a mnemonic to their use. There's a bit of symbolism in using 'x' for strings repetition too. You may want an asterisk in your version of the operator because the asterisk symbolizes multiplication/repetition to you, but the 'x' looks like a cross operator, and indicates to me that some kind of multiplication is going on here, but not the regular one. I can read '$text x 5' as 'dollar text times five' in a way that feels very natural. // Carl
Re: renaming or adding some operators
Thoughts:
Your nomenclature makes me think you are coming from an APL background.
!=== is already generated from ===, and compares the identity of any two
objects. It works on binary values since they are value types, but
that's not the proper usage, and Perl separates out the concerns.
Some of the things you mention do indeed make sense as a principle form
for an operator, with the current way a digraph. For example, =. It's
been a digraph approximation for so many decades that we have
forgotten. My editor shows the ≤ when it formats =.
exists has already been changed to an adverb on the lvalue, but I
suppose a macro could still be made to work.
Darren Duncan darren-at-darrenduncan.net |Perl 6| 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?
Was that operator called 'x' because it was the best or because that
was how Perl 5 did it, and Perl 6 wanted to not change things if it
didn't need to?
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.
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.
Thirdly, there are I'm sure a number of other aliases that could be
added to other ops, such as ≤ and ≥ for = and =, and ≠ for one of
the inequality operators, although that last one would probably make
more sense if = was the equality test operator, so maybe best to avoid
≠ then.
Lots of the other ones I can think of apply to sets, and the
ext/Set.pm bundled with Pugs already documents them quite well.
However, I think some set ops could also be used with hashes. For
example, an alternate way of spelling exists %foo{$bar} is $bar ∈
%foo or %foo ∋ $bar.
So, any thoughts?
-- Darren Duncan
Re: renaming or adding some operators
John M. Dlugosz wrote: Your nomenclature makes me think you are coming from an APL background. Actually, I've never used APL. The main influences for the terminology I use, besides Perl which is my favorite general purpose language, is the field of relational databases, both the SQL language and other database languages, which are heavily tied to the domains of logic and math etc, so I use math/logic-based terminology a lot. I've also studied a wide variety of languages and appreciate functional ones, though I haven't really used them at all. I also appreciate OO languages. !=== is already generated from ===, and compares the identity of any two objects. It works on binary values since they are value types, but that's not the proper usage, and Perl separates out the concerns. I prefer to conceptualize all values as immutable, and if you have something that is mutable, it isn't a value but a container; the identity of every value is itself, and all values are distinct by definition. I appreciate Perl 6's design, with the distinct ===, eqv, =:=, ==, eq operators. I know what === is for. I also know that given its current design, === and !=== just happen to have the same semantics as logical xnor and xor when given 2 Bool inputs, and so they serve the purpose. Having distinct xnor and xor operators is useful from partly a documentation perspective and from error-checking; a strict compiler or runtime should complain if non-Bool inputs are given to them. Some of the things you mention do indeed make sense as a principle form for an operator, with the current way a digraph. For example, =. It's been a digraph approximation for so many decades that we have forgotten. My editor shows the ≤ when it formats =. I thought so, and that's why its good to take advantage of the real thing when we are able to, and take the approximated spellings for what they are, approximations. exists has already been changed to an adverb on the lvalue, but I suppose a macro could still be made to work. Sure. -- Darren Duncan
Re: renaming or adding some operators
On Fri, May 29, 2009 at 11:06:46PM -0700, Darren Duncan wrote: Larry, did you choose = for assignment and == etc for comparison because you thought that looked prettier, or because that was the C/etc convention that you decided to copy? Neither beauty nor convention, really. I chose it for the same reason that C chose it: Assignment is much more common than testing equality, so this is pure Huffman. This was specifically mentioned in the original rationale for the design of C, because by percentage there were more mathematicians in programming then than there are today. So there was certainly some pressure to use = for equality back in the day, and I give KR credit for helping establish the Huffman principle. Certainly the Huffman principle was largely ignored by the designers of COBOL. The first time I saw that you call a subroutine with perform, I said to myself, Something's desperately wrong here. Why didn't they just use 'do'? Which you'll notice is how Perl 1 called subs. Of course, eventually I figured out that two characters is still too long for that, so I changed it to 1 character, , a little slow to realize that the correct answer was 0 characters... :) These days I try to be stupid about other things instead. Larry
Re: renaming or adding some operators
On Fri, May 29, 2009 at 08:45:06PM -0700, Darren Duncan wrote: So does anyone else have thoughts on that? Actually, I think ~x is kinda ugly. And I like the mnemonic value of x returning one thing and xx returning multiple things. And in the bitwise ops ~ doesn't indicate postprocessing. And given that we've only used a ~ modifier in bitops, people would look at ~x and try to figure out what kind of bitop it was meant to indicate. And in any case, it would be silly to actually implement string replication in terms of list replication. So by all means feel free to speculate on what a mathematical syntax module might tweak, but there are lots of obvious and not-so-obvious reasons to keep the standard operators pretty much the way they already are. Most of the current-day tweaks are driven by semantic simplifications, not the desire to refactor S03 yet again in pursuit of some kind of completist agenda, which you know can never entirely satisfy the mathematicians. :) Larry
Re: renaming or adding some operators
John M. Dlugosz said [off-list]: Darren Duncan darren-at-darrenduncan.net |Perl 6| wrote: I also know that given its current design, === and !=== just happen to have the same semantics as logical xnor and xor when given 2 Bool inputs, and so they serve the purpose. Having distinct xnor and xor operators is useful from partly a documentation perspective and from error-checking; a strict compiler or runtime should complain if non-Bool inputs are given to them. With the heritage as a free-typed language, the use of different operators rather than overloading an operator based on type was a core feature of Perl. You might not have two typed Bool arguments. You have two arguments which might be considered boolean, or numeric, or string, depending on what I want of it at the moment. So !=== between two arrays still does the Bool meaning, and asks if one is empty and the other not. More serious with strings, which can be strings or the serialized form of something else. === with strings will be False if one contains 0 and the other contains false, when both are the same as XML attribute values of type XSD:boolean. Actually, I'll correct myself. In Perl, I would expect the boolean-specific operators like and/or/xor/etc to accept any values at all as arguments, and evaluate them in a boolean context, using each object's notion of truthness. But my point is that, though the behaviour of xor and !=== is very different in the general case, when given two actual Bool arguments, their semantics would be the same, and so someone working in a pure Bool context would get the desired behaviour from !=== and === treated as xor and xnor. -- Darren Duncan
Re: renaming or adding some operators
On 2009-May-29, at 7:53 pm, Darren Duncan wrote:
Thirdly, there are I'm sure a number of other aliases that could be
added to other ops, such as ≤ and ≥ for = and =, and ≠ for
one of the inequality operators, although that last one would
probably make more sense if = was the equality test operator, so
maybe best to avoid ≠ then.
Probably. I would really like to see the obvious symbols defined,
though, for two reasons:
1) Being able to use real symbols (e.g. ≤ instead of crude ASCII
approximations) will make Perl code look ever so pretty and make all
the other kids envious. (Envy is, of course, one the great
programmers' virtues, the one that makes us steal all the best bits
from other languages!)
2) It will discourage people from abusing operators that already have
well-defined standard meanings. For example, if there is no ∑,
somebody might be tempted to use it for multiplication; or to use √
for checking something; or + for concatenating strings, etc.
However, I think some set ops could also be used with hashes. For
example, an alternate way of spelling exists %foo{$bar} is $bar
∈ %foo or %foo ∋ $bar.
I think that one's ambiguous as to whether $bar exists as a key or a
value.
$bar ∈ @foo; $bar ∈ %foo.keys; $bar ∈ %foo.values; ∃ %foo{bar}
-David
Re: renaming or adding some operators
It occurs to me that, while I don't want to pull in all the possible Unicode operators by default, we should make it easy to do so. Perhaps something like use *; should pull in all the Unicode operators. Which if course means that any golfing would start with *; to pull in all the possible operators in non-strict mode, and turn on the mode where methods can be specified by the first few unique characters, and maybe turn off mandatory whitespace in a few spots. :) Larry
Re: renaming or adding some operators
On Sat, May 30, 2009 at 01:09:01PM -0600, David Green wrote:
I think that one's ambiguous as to whether $bar exists as a key or a
value.
$bar ∈ @foo; $bar ∈ %foo.keys; $bar ∈ %foo.values; ∃ %foo{bar}
Generally when hashes have been used as sets we've taken the keys
to be the set, not the values, since the keys guarantee uniqueness.
However, even defining it that way, a hash should really be considered
a set *container* rather than a set, since sets are immutable, and
hashes aren't. This is why we distinguish the Set type from the
KeySet type.
But tagmemically speaking, it's perfectly fine to *use* a hash
as if it were a set.
Larry
Re: renaming or adding some operators
David Green david.green-at-telus.net |Perl 6| wrote: On 2009-May-29, at 7:53 pm, Darren Duncan wrote: Thirdly, there are I'm sure a number of other aliases that could be added to other ops, such as ≤ and ≥ for = and =, and ≠ for one of the inequality operators, although that last one would probably make more sense if = was the equality test operator, so maybe best to avoid ≠ then. Probably. I would really like to see the obvious symbols defined, though, for two reasons: 1) Being able to use real symbols (e.g. ≤ instead of crude ASCII approximations) will make Perl code look ever so pretty and make all the other kids envious. (Envy is, of course, one the great programmers' virtues, the one that makes us steal all the best bits from other languages!) 2) It will discourage people from abusing operators that already have well-defined standard meanings. For example, if there is no ∑, somebody might be tempted to use it for multiplication; or to use √ for checking something; or + for concatenating strings, etc. I agree. The original non-ASCII characters, introduced 9 years ago, are at least Latin-1. But in for a penny, in for a £, eh? The symbols ≤, ≥, and ≠ are u+2264, u+2265, and U+2260 respectively. That's pretty far afield from Latin-1 or any national code page character sets. They are part of the Mathematical Operators block at U+22xx. Checking the fonts installed with Windows, coverage of that block is very sparse. But, those three in particular, and a hand full of others, are present in most fonts, including plain (not the Unicode) Arial, Courier New, and Lucida Console. Even most of the ornamental fonts have those three. One reason might be because ≥ and ≤ are in the DOS OEM code page from ancient BIOS history. Now the existing « » synonym of is a digraph which I believe is mapped at the parser level. Is that because the quoting needs to be understood at a deeper level than just defining operators? I'm wondering if there is any benefit or necessity of making = and = digraphs for the single-char form, as opposed to just making the operators synonyms. I guess the latter means that any overloading would have to cover both explicitly to avoid confusing people. Note that ≥ and ≤ are bidi mirroring characters in the Unicode Properties. So if someone were crazy enough to use them as brackets, then the digraph equivalent should work as well, right? Anyway, I support the idea of making ≤, ≥, and ≠ the principle operators and having =, =, and != as synonyms for them. But, the synonyming would need to be automatic and complete, so that someone can overload infix:≤, for example, and someone else using that module can write = and no worries. Although personally I think someone defining a new class would just give it the Ordered role and supply the minimum two methods for that, and then all the relational operators would just work. I'd also like to point out that there are other variations, such as ≦ and ≶ so it is easy to get carried away. These others don't have the widespread font support that the proposed 3 enjoy. We should leave all the others for the math guys to use in specialized modules, and not be in the core language. I would also endorse using Π or π as synonyms for Pi or pi (or is it PI?). The Latin-1 fractions ¼, ½, ¾ could be Rat constants, since I can't imagine them being used for anything else. There is a full set of them in the Number Forms block. But, those are not Letters. They have a Unicode class of Number, other. I'm more interested in making sure that someone _can_ easily define ℝ as a type name than in providing that by default.
Re: renaming or adding some operators
On Sat, May 30, 2009 at 04:50:02PM -0500, John M. Dlugosz wrote: Note that ≥ and ≤ are bidi mirroring characters in the Unicode Properties. So if someone were crazy enough to use them as brackets, then the digraph equivalent should work as well, right? No, they'd only function as digraphs in the infix syntactic category. Bracketing chars are outside of any such category. Perl 6 is very careful to recognize macro-like things only where they would make sense for their particular category. That's part of the magic of STD, that it generates different lexers at each choice point in the grammar, and does so just-in-time, based on the current language definition. Now, within a particular syntactic category you can have conflicts, and with other categories that are ORed in to it; for example, prefixes share LTM space with terms and circumfixes, for instance. So we do have to be a little careful about defining other termish things that start '' though, since '«'can introduce a term. That's one of the reasons heredocs don't use that notation any more. But that only interferes with spots where a term is expected. There is a corresponding conflict at postfix position, but the two are causally unrelated. I hesitate to call them digraphs even, since to me that kinda implies they're translated without regard to context, as by a preprocessor, and they're not. I'm more interested in making sure that someone _can_ easily define ℝ as a type name than in providing that by default. Indeed, getting close enough is one of the underlying design themes of Perl 6. As to whether we're close to do the operator aliasing in a mostly digraphic fashion, I'm not sure. Currently a macro for an infix would be given the AST of the left argument to play with, and the opportunity to influence the parse of its right argument. This is overkill for a mere alias. We may need to distingish single-token substitution macros from macros that govern the ASTs around them in order to make such operator canonicalization painless, I think. Larry
Re: renaming or adding some operators
Larry Wall larry-at-wall.org |Perl 6| wrote: Indeed, getting close enough is one of the underlying design themes of Perl 6. As to whether we're close to do the operator aliasing in a mostly digraphic fashion, I'm not sure. Currently a macro for an infix would be given the AST of the left argument to play with, and the opportunity to influence the parse of its right argument. This is overkill for a mere alias. We may need to distingish single-token substitution macros from macros that govern the ASTs around them in order to make such operator canonicalization painless, I think. Yes. A context-sensitive (e.g. infix) token-for-token exchange that is easily defined as such without letting the user get into too much trouble. If the operator names can read this table too, then it won't matter which is the real one. Someone can declare an overloaded operator with either name, as well as call it with either name.
Re: renaming or adding some operators
On Fri, 29 May 2009, Jon Lang wrote: 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. How about if xx became x, and then we did things like: [~] @list x $count ...to get the string replciation? HTH, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: renaming or adding some operators
Jon Lang wrote: 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. I don't think that every ~foo needs a corresponding +foo or ?foo. Sometimes doing that makes sense, and other times not. So your idea may work on its own. And actually if 'x' became '~x' and 'xx' became 'x', I think that would increase the amount of symmetry with other sets of Perl 6 operators, where plain 'foo' is the most generic version and adding ~ or + or ? etc is making specialized versions or post processing. So then, 'x' simply means make a list of repeated items, and the ~ prefix means post-process with catenation. So does anyone else have thoughts on that? * ===, but xnor, ↔ aliases could be added By the way, another alias for the above is 'iff' (if and only if) 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. Thanks for the reminder. So then, none of those are analogous to distinct boolean operators. But here are a few more dyadic: * nand aka ⊼ aka ↑ * nor aka ⊽ aka ↓ * implies aka imp aka → * nimp aka ↛ * if aka ← * nif aka ↚ 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. I thought that the direction did matter, and that's why there are distinct versions in each direction. It's like how and are the same thing but with the direction reversed, or subset/superset or contains/contained-by. If you read A → B as A implies B then that's the same as if A then B, then the cause-effect reads left to right, which does follow the direction of the arrow, like Perl's if cond() then action(). If you read A ← B as A if B, that the cause-effect reads right to left, like Perl's action() if cond(). So practically speaking then, these operators would be served by Perl's basic conditionals if each conditional block resulted in the thing specified when the condition is true, and some appropriate other value otherwise, so they can be used in an expression. But since its probably saner to keep the existing 'if' etc as statements, then just make new ones as expressions; while using the same keyword, they wouldn't conflict due to different usage syntax. 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. All of the logic operators I proposed *do* have ASCII aliases, which is the alphanumeric terms: same as we have [not, and, or, xor], we have [iff/xnor, nand, nor, implies/imp, nimp, if, nif], so I don't see a problem here. Separately, while I support that one should be able to use all the Perl 6 features without touching trans-ASCII characters if they don't want to, we shouldn't be afraid to exploit them in the default setting; any exploitations would just be aliases for the operator names. See ext/Set.pm again for an example of how this could work. Besides-which, on modern computers, you usually can read all the Unicode characters, whose use would probably make code more readable (and prettier), and if you have a decent toolset, it is easy to type those characters too. I mean, what modern system doesn't support input methods by default? People in most parts of the world must be able to write their non-Latin characters efficiently on Latin keyboards somehow right? So just use the same method to write your math/etc symbols. I'm doing so right now and its hardly any slower than typing ASCII characters. (Note, unlike say Chinese where there could be tens or hundreds of thousands of characters, I would anticipate that a Perl 6 standard setting that exploits Unicode would only involve a few dozen math/etc symbols, not too many to deal with I think.) -- Darren Duncan
Re: renaming or adding some operators
Timothy S. Nelson wrote: How about if xx became x, and then we did things like: [~] @list x $count ...to get the string replciation? Maybe you meant this? [~] $item x $count I like that a lot. And we could still have ~x as a shorthand for that specific case since it would likely be used often enough. -- Darren Duncan
Re: renaming or adding some operators
Darren Duncan wrote: 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. I thought that the direction did matter, and that's why there are distinct versions in each direction. It's like how and are the same thing but with the direction reversed, or subset/superset or contains/contained-by. If you read A → B as A implies B then that's the same as if A then B, then the cause-effect reads left to right, which does follow the direction of the arrow, like Perl's if cond() then action(). The point is that it's equally valid to read A → B as A only if B, with the cause-effect going from B to A. You have the same truth table for both A only if B and if A then B, so they use the same logical operator; but the cause/effect flow is reversed between them. -- Jonathan Dataweaver Lang
Re: renaming or adding some operators
On Fri, 29 May 2009, Darren Duncan wrote: Timothy S. Nelson wrote: How about if xx became x, and then we did things like: [~] @list x $count ...to get the string replciation? Maybe you meant this? [~] $item x $count No, I'm pretty sure I meant what I wrote. But if x coerced $item into a list (treated it as a list of one item), then that would work too. I like that a lot. And we could still have ~x as a shorthand for that specific case since it would likely be used often enough. Well, if we think it warrants it. About the only P5 operator I use less than x are the bitwise ones, and the '...' operator. And maybe modulus. If I only had the one replication operator to remember, I think I'd prefer it. But I'm happy with whatever Larry decides. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
