Re: RFC 143 (v1) Case ignoring eq and cmp operators
On Thu, Aug 24, 2000 at 03:40:00PM -, Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Case ignoring eq and cmp operators IMHO this problem is better solved by using =~ and its brethren, which already allow you to do the right thing for a far wider set of cases than just this one.
Re: RFC 143 (v1) Case ignoring eq and cmp operators
Perl6 RFC Librarian wrote: =head1 IMPLEMENTATION Probably has to be added to perl internals... I wonder what will happen with overloads though - is eq/i a new operator to overload or is the case-insensitivity somehow magically done by the Perl interpreter even though eq was overloaded? This probably could lead to problems... if we had a insensitive-string type, which is the appropriate thing to store case-insensitive data in, overloading Ccmp to work on it would IMO be a more general solution (assuming of course that $a eq $b expands to !($a cmp $b) )
Re: RFC 143 (v1) Case ignoring eq and cmp operators
Last week when I wrote "everything is an exception" this is what I was talking about. Nathan Torkington wrote: This raises another issue, though: You'd obviously want to have a module that collected together your favourite new operators. But if they were lexically scoped, they'd be lexically scoped to the module they were defined in, i.e. your collection rather than your main program. We're going to have to think of a way to consistently say "do this in my caller's lexical scope" without it becoming a nasty upvar hell. Nat If we use exceptions of some kind to handle syntax, encountering an exception of type "unknown-keyword:Cmp" could result in the subroutine definition getting run to clarify this piece of code. With lexically scoped Ccatch you could put a short declaration like Cuse syntax standard at the top level of your package, which would include a list of what words fall through to the default provided "core" definitions, and anything else would not get outside of that block to find clarifications for itself. This would effectively prevent the sort of global collision you are talking about, and would also allow creation of arbitrary module visibility scoping and versioning schemes. -- David Nicol 816.235.1187 [EMAIL PROTECTED] safety first: Republicans for Nader in 2000
Re: RFC 143 (v1) Case ignoring eq and cmp operators
David L. Nicol writes: If we use exceptions of some kind to handle syntax, encountering an exception of type "unknown-keyword:Cmp" could result in the subroutine definition getting run to clarify this piece of code. I'm nervous about this. I'm trying to picture what happens, and having trouble. Could you post some hypothetical code that would trigger the exception (including the loading of the module that defines the exception) so I can better see what you're proposing? If this was in last week's discussion, please send me a pointer to the archives. Thanks, Nat
RFC 143 (v1) Case ignoring eq and cmp operators
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Case ignoring eq and cmp operators =head1 VERSION Maintainer: Markus Peter [EMAIL PROTECTED] Date: 24 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 143 =head1 ABSTRACT Perl currently only has Ceq and Ccmp operators which work case-sensitively. It would be a useful addition to add case-insensitive equivalents. =head1 DESCRIPTION =head2 Problems with current ways to do it Perl currently knows basically two methods for checking of equality of strings case-insensitively: uc($a) eq uc($b) $a =~ /^$b$/i and for comparing them one: uc($a) cmp uc($b) The probably worst about these statements is that they look ugly. Also, they further complicate statements and they are counter-intuitive for beginners - why should I change the case of variables if I only want to compare them? The regexp mechanism has a case-insensitivity option (there's probably no proper way to simulate it there I admit). With this in mind most beginners will conclude the same is true for eq and cmp - after all Perl is strong in text processing so how could such a feature miss? Beginner code usually ends up using the case-insensitive regexps then instead of the easier to read uppercase/equals combination. =head2 Proposal We apply something similar to the regexp modifiers to Ceq and Ccmp as well, after a slash. The above examples would then be $a eq/i $b $a cmp/i $b This still leaves some room for future additions to eq and cmp if desired (stupid example: like ignoring all white space in the comparison or whatever comes up) =head1 IMPLEMENTATION Probably has to be added to perl internals... I wonder what will happen with overloads though - is eq/i a new operator to overload or is the case-insensitivity somehow magically done by the Perl interpreter even though eq was overloaded? This probably could lead to problems... =head1 REFERENCES perlop manpage for eq and cmp String.equalsIgnoreCase() method in Java
Re: RFC 143 (v1) Case ignoring eq and cmp operators
On Thu, Aug 24, 2000 at 03:40:00PM -, Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Case ignoring eq and cmp operators =head1 VERSION Maintainer: Markus Peter [EMAIL PROTECTED] Date: 24 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 143 =head1 ABSTRACT Perl currently only has Ceq and Ccmp operators which work case-sensitively. It would be a useful addition to add case-insensitive equivalents. Too special-case to do just 'case'. See the Unicode standard and tech reports about normalization. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 143 (v1) Case ignoring eq and cmp operators
At 10:56 AM 8/24/00 -0600, Tom Christiansen wrote: Also, they further complicate statements and they are counter-intuitive for beginners - why should I change the case of variables if I only want to compare them? Again, I reach the contrary conclusion: they say exactly what they are doing, rendering them clear and obvious to all involved. By your argument, one should not have to say abs($a) == abs($b) either, but should invent a sign-insensitive equality comparison instead of knowing how to use the extant == operator and abs function. While I don't know that I'd argue in favor of this feature request, your argument against misses the mark here. It's saying, essentially, that the difference between "P" and "p" is the same as the difference between -1 and 1. That, as they say, turns out not to be the case. The upper and lower-case versions of letters in many languages are essentially equivalent and it's reasonable to want them to be treated the same way when that's appropriate. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 143 (v1) Case ignoring eq and cmp operators
--On 24.08.2000 10:56 Uhr -0600 Tom Christiansen wrote: The probably worst about these statements is that they look ugly. To the contrary: in the case (ahem) of the application of lc() on the comparison's operand, they look especially beautiful. Depends on taste I guess... Also, they further complicate statements and they are counter-intuitive for beginners - why should I change the case of variables if I only want to compare them? Again, I reach the contrary conclusion: they say exactly what they are doing, rendering them clear and obvious to all involved. By your argument, one should not have to say abs($a) == abs($b) either, but should invent a sign-insensitive equality comparison instead of knowing how to use the extant == operator and abs function. With the same argument we can drop -- and ++, and while we're at it, the arithmetic minus in favor of +(-$num). In my consideration, a case-insensitive equality check is a rather common operation in Perl programs so it deserves its own operator. Power derives not from uncountably many special-purpose functions and syntax, but rather from the ability to combine primitive features *algorithmically* to arrive at the desired functionality. The factorial powers of combinatorics put to shame a merely linear increase in the number of available functions. I'd use C then if I'd agree completely with this statement. $a eq/i $b $a cmp/i $b You want ugly, I'll give you ugly. That's ***UGLY***. It's a syntactic anomaly that does not fall out of anything else in the language. The analogy to m//i or s///g is a false one, as those are not functions I still say it looks familiar even if it's a false analogy. Another possibility would be to use cmpi and eqi -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]
Re: RFC 143 (v1) Case ignoring eq and cmp operators
While I don't know that I'd argue in favor of this feature request, your argument against misses the mark here. It's saying, essentially, that the difference between "P" and "p" is the same as the difference between -1 and 1. That, as they say, turns out not to be the case. The upper and lower-case versions of letters in many languages are essentially equivalent and it's reasonable to want them to be treated the same way when that's appropriate. If you want to treat 1 and -1 as the same, you filter through abs(). If you want to treat a and A as the same, you filter through lc(). In neither case do you go creating new functions, when a generic filter will suffice. It's like making all programs understand some random new switch rather than creating one single filter program that produces the proper transmogrification. It's the Wrong Way. And you certainly don't go creating a brand new syntax! --tom
Re: RFC 143 (v1) Case ignoring eq and cmp operators
We need a way to mix eq, the things to be compared, and the operation
to be done on them before they are compared:
lc{ $foo eq $bar }
$foo eq (lc) $bar
$foo eq{lc} $bar
None of those are like any existing syntax in Perl. The current way:
lc($foo) eq lc($bar)
seems fine in comparison.
I'd say this argues for the parser to be told about new infix operators:
use operator
'eqi' = 'infix';
$blah eqi $bork
# rewritten as eqi($blah,$bork)
This raises another issue, though:
You'd obviously want to have a module that collected together your
favourite new operators. But if they were lexically scoped, they'd
be lexically scoped to the module they were defined in, i.e. your
collection rather than your main program. We're going to have to
think of a way to consistently say "do this in my caller's lexical
scope" without it becoming a nasty upvar hell.
Nat
Re: RFC 143 (v1) Case ignoring eq and cmp operators
At 11:33 AM 8/24/00 -0600, Tom Christiansen wrote: While I don't know that I'd argue in favor of this feature request, your argument against misses the mark here. It's saying, essentially, that the difference between "P" and "p" is the same as the difference between -1 and 1. That, as they say, turns out not to be the case. The upper and lower-case versions of letters in many languages are essentially equivalent and it's reasonable to want them to be treated the same way when that's appropriate. If you want to treat 1 and -1 as the same, you filter through abs(). If you want to treat a and A as the same, you filter through lc(). As I said, I wasn't arguing for or against the feature, merely pointing out that your argument against wasn't quite on-target. In most human languages, "Please" and "please" are the same word, though that's not the case with computer languages. The numbers 1 and -1 aren't the same, though. Personally I think I'm in favor of Nat's suggestion of allowing the definition of new infix operators and let this be taken care of in a module, but that's just passing the buck. (Not that it's a bad strategy, mind... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 143 (v1) Case ignoring eq and cmp operators
On Thu, Aug 24, 2000 at 10:28:51PM +0200, Bart Lateur wrote: On 24 Aug 2000 15:40:00 -, Perl6 RFC Librarian wrote: Perl currently only has Ceq and Ccmp operators which work case-sensitively. It would be a useful addition to add case-insensitive equivalents. Next you'll want case)insensitive hashes! Er... actually, that sounds rather useful, even more than your ideas, which can be easily emulated. Suppose you want to keep the case on the hash keys, because you enumerate them. But you still want to find hash entries in a case insensitive manner... tie, TIEHASH, FETCH. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 143 (v1) Case ignoring eq and cmp operators
Bart Lateur wrote: Suppose you want to keep the case on the hash keys, because you enumerate them. But you still want to find hash entries in a case insensitive manner... ...then you simply reach for Tie::CPHash on CPAN! -- John Porter
Re: RFC 143 (v1) Case ignoring eq and cmp operators
On Thu, 24 Aug 2000, Nathan Torkington wrote: You'd obviously want to have a module that collected together your favourite new operators. But if they were lexically scoped, they'd be lexically scoped to the module they were defined in, i.e. your collection rather than your main program. We're going to have to think of a way to consistently say "do this in my caller's lexical scope" without it becoming a nasty upvar hell. Not that it adds much information, but this is the lament of RFC 40. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 143 (v1) Case ignoring eq and cmp operators
Dan Sugalski writes: Personally I think I'm in favor of Nat's suggestion of allowing the definition of new infix operators and let this be taken care of in a module, but that's just passing the buck. (Not that it's a bad strategy, mind... :) Solve the generic problem, not a specific one. I want to compare case-insensitively" is a specific problem and it's idiocy to go down the road of a special syntax for everyone's different specific problem. Nat
Re: RFC 143 (v1) Case ignoring eq and cmp operators
I want four special new comparison operators. Firstly, " e q " That is, an operator that ignores any leading, any trailing, and treats all intraspace as equivalent. If the embedded space is confusing, I may consider suggesting an operator modifier, "/ ". Secondly, Eq, which operates only the so-called dictionary order, that is, ignoring all non-alphabetic characters (and case). I will possibly also want Cmp which will sort "foo200" before "foo1000". Thirdly, I want ==/R which will know that "v" is equal to 5, I need to keep my lists of Popes in good order. Fourthly, I want eq/multinlingual since I simply need to have "jouluaatto" eq "Christmas Eve" -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 143 (v1) Case ignoring eq and cmp operators
Case ignoring eq and cmp operators =head2 Problems with current ways to do it Perl currently knows basically two methods for checking of equality of strings case-insensitively: uc($a) eq uc($b) $a =~ /^$b$/i and for comparing them one: uc($a) cmp uc($b) The probably worst about these statements is that they look ugly. To the contrary: in the case (ahem) of the application of lc() on the comparison's operand, they look especially beautiful. Also, they further complicate statements and they are counter-intuitive for beginners - why should I change the case of variables if I only want to compare them? Again, I reach the contrary conclusion: they say exactly what they are doing, rendering them clear and obvious to all involved. By your argument, one should not have to say abs($a) == abs($b) either, but should invent a sign-insensitive equality comparison instead of knowing how to use the extant == operator and abs function. That makes little sense, as I'm sure you'll agree. Similarly, so too does the desire to have a new eq operator seem exceedingly misplaced. Power derives not from uncountably many special-purpose functions and syntax, but rather from the ability to combine primitive features *algorithmically* to arrive at the desired functionality. The factorial powers of combinatorics put to shame a merely linear increase in the number of available functions. Of lesser but not inconsequential importance is that it is easier on everyone if they don't have more distinct functions and syntax to remember. Would it really be better to have a -==- operator than for people to remember to use == with abs? Of course not. A programmer learns to use the tools in hand to create new things. $a eq/i $b $a cmp/i $b You want ugly, I'll give you ugly. That's ***UGLY***. It's a syntactic anomaly that does not fall out of anything else in the language. The analogy to m//i or s///g is a false one, as those are not functions, and do not syntactically take argument in the same way. Nothing else in Perl looks this way. --tom
