Re: AW: my int( 1..31 ) $var ?
Christian Renz wrote: Now, I might be stupid, but I keep asking myself what you would need a property for in this example. Yes. It's important to remember that the shiny new hammer of properties is not necessarily the appropriate tool to beat on *every* problem. :-) Damian
Re: 'my int( 1..31 ) $var' ?
Attriel wrote: Well, in general I think it would be good to have some mechanism for determining the type of the data rather than the type of a representation of the contained value. Why? One of the nice things about Perl is that coercian takes care of these kind of things so that you don't have to worry about them. If you pass a string containing a sequence of digit characters when an integer is expected, Perl just works it out. If I have 0, it's possible I might at some point (this having been user input perhaps) have some reason to care whether it was an integer or a string. How would the user distinguish when providing the input? The Perl 5 ways of reading input -- whether from the keyboard, a file, or a form on a webpage -- yield strings. Even if the user thinks she has provided an integer, the program gets a string (but that doesn't matter). For validation purposes things like Regexp::Common are currently handy for determining whether provided input can be treated as a number or an integer or whatever. Perl 6's ability to use its own grammar rules should make those kinds of things considerably easier. I know I hate the fact that, in almost every lang I use, adding the strings 014 and 231 requires me to do ' + string1 + + string2 ' Fortunately Perl isn't one of those languages. In general you need for either variables or operators to be typed. JavaScript has problems with untyped variables and addition/concatenation; PHP has problems with string/numeric comparisons. Many languages 'solve' this problem by ensuring all variables have types. Perl goes the other way and ensures operators are sufficiently typed, having C+ and C., and Clt and C . Perl 5 fell down in having the bitwise operators behave differently with numbers and strings; Perl 6 fixes this by having different operators for each operation. So the type that data has previously been (albeit possibly only in the mind of the user who entered it) isn't particularly useful; if the data can be coerced to that type (or any other required type), then that is sufficient. ... I imagine there might exist cases where the information is useful ... I'm struggling to think of any -- if you come up with some please could you mail them so I can understand your viewpoint better. Needing to know about this kind of thing strikes me as most unPerlish. Smylers
Re: my int( 1..31 ) $var ?
Luke Palmer wrote: From: Joe Gottman [EMAIL PROTECTED] Date: Fri, 3 Jan 2003 22:25:16 -0500 JG == Joe Gottman [EMAIL PROTECTED] writes: JG Speaking of which, is there a run-time test to check if a variable JG is of JG integral type? Something like JG print date if ($var is int) (1 = $var = 31); the old standby is: int( $var ) == $var I'm not sure if this works. my $var = 0; # Notice the quotation marks print is integer if (int($var) == $var); In the above case int($var) == $var returns true when I would want it to return false. Why? It returns true in perl5; 0 certainly is an integer value. print date if $var.isa(int); print date if isa $var: int; print date if $var ~~ int; Those should all work. IMO the first reads the best. That will also work for CInts, as CInt is a subclass of Cint (I think). These only determine if $var is of type int or Int. However: my $var = 0; # or my $var = 0; # or my int $var = 0; # or my num $var = 0; # all 4 cases should print is integer print is integer if int $var == $var; This should work as a more generic method to test Integer *value*, rather than type, which IMHO is more useful (and more commonly wanted). This message was sent using the Webmail System hosted by OARDC Computing Services -- http://webmail.oardc.ohio-state.edu:8080
Re: my int( 1..31 ) $var ?
[EMAIL PROTECTED] (Joe Gottman) writes: In the above case int($var) == $var returns true when I would want it to return false. Why should you care? Perl 6 isn't going to be that strictly typed, is it? -- I wish my keyboard had a SMITE key -- J-P Stacey
AW: my int( 1..31 ) $var ?
It's also far slower. Constructing a 31-element list, junctionizing it, This might well be done at compile-time. And/or, lazily. So the cost of these two steps is likely to be negligible. then testing against each element vs. 2 numeric comparisons. Yes. That's a significant cost in this case. My example was bad. I intended something with more behind it. print creditcard if $var == CreditCard( 'VISA' ); wich should do a mod10 on $var and then match a regex or something. I think one could say CreditCard( 'VISA' ) is then the property. And after reading further seeing it could be smart matched like: print creditcard if $var ~~ CreditCard( 'VISA' ); Brought to a point: Properties could be also smart matched. Murat
AW: my int( 1..31 ) $var ?
my $var = 0; # or my $var = 0; # or my int $var = 0; # or my num $var = 0; # all 4 cases should print is integer print is integer if int $var == $var; This should work as a more generic method to test Integer *value*, rather than type, which IMHO is more useful (and more commonly wanted). I agree. And i found an interesting thread about that in comp.object http://groups.google.de/groups?hl=delr=ie=UTF-8oe=UTF-8threadm=1990S ep28.181057.16740%40odi.comrnum=5prev=/groups%3Fq%3DVariable%2BTypes%2 BVs%2BValue%2BTypes%26hl%3Dde%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3 D1990Sep28.181057.16740%2540odi.com%26rnum%3D5 Murat
Re: AW: my int( 1..31 ) $var ?
On Sat, 4 Jan 2003, Murat Ünalan wrote: print creditcard if $var == CreditCard( 'VISA' ); wich should do a mod10 on $var and then match a regex or something. I think one could say CreditCard( 'VISA' ) is then the property. And after reading further seeing it could be smart matched like: print creditcard if $var ~~ CreditCard( 'VISA' ); Brought to a point: Properties could be also smart matched. Wouldn't it be easier to say: print creditcard if CreditCard( $var ) eq 'VISA'; ~ John Williams
Re: AW: my int( 1..31 ) $var ?
Murat Ünalan wrote:
print creditcard if $var ~~ CreditCard( 'VISA' );
Brought to a point: Properties could be also smart matched.
Properties *can* be smart-matched:
print creditcard if $var.prop().{CreditCard} ~~ 'VISA';
or:
print creditcard if $var.prop{CreditCard} ~~ 'VISA';
or:
print creditcard if $var.CreditCard ~~ 'VISA';
Damian
AW: my int( 1..31 ) $var ?
Why should you care? Perl 6 isn't going to be that strictly typed, is it? Not even optional ? Murat
Re: AW: AW: my int( 1..31 ) $var ?
On Sun, 5 Jan 2003, Murat Ünalan wrote:
Properties *can* be smart-matched:
print creditcard if $var.prop().{CreditCard} ~~ 'VISA';
or:
print creditcard if $var.prop{CreditCard} ~~ 'VISA';
or:
print creditcard if $var.CreditCard ~~ 'VISA';
I think this is similar to John Williams suggestion:
print creditcard if CreditCard( $var ) eq 'VISA';
Well, no. In my suggestion, CreditCard is a sub which checks whether $var
is a valid credit card, returning the card type.
In Damian's example, he is assuming $var already has a property assigned
to it called CreditCard possibly containing the value 'VISA'. So his has
less processing they either of ours.
The problem I see with:
print creditcard if $var ~~ CreditCard( 'VISA' );
is that CreditCard does not know what $var is. Even if you overload the
smartmatch operator on $var's class, it is still comparing $var with the
value returned from CreditCard.
sub CreditCard
{
#connect to a specific database (VISA, MASTERCARD, ..)
#compare with non-blocked or valid cards
}
...
Excerpt: My concept is to have a twofold view about properties. One
thing that is attributing a type during decleration, and something that
could verified against in other context. All my thinking on that
orginates from Damians Attribute::Type.
Hopefully i do not confuse you too much.
A sub is not a property. It might be a method, which could sometimes look
like a property (as in Damian's third example), but you have strayed so
far away from properties that you are talking about something else now.
~ John Williams
Re: AW: my int( 1..31 ) $var ?
Now, I might be stupid, but I keep asking myself what you would need a
property for in this example. To me, it totally confuses the
underlying structure. When was the last time you asked an integer to
identify itself as a valid credit card number?
It is _not_ a property of the integer that it is a valid cc number,
rather it happens that it will be accepted as valid _by a certain
authority_. So why not go and ask the authority? Compare the case to a
phone number -- the phone number itself doesn't know if its valid. You
could only check a certain format (if e.g. in the USA, in Germany,
that would be very hard). To check the validity, query a directory
server or ask a phone to dial the number. Don't check the number
itself.
To provide even stronger evidence against using properties, consider
the fact that a credit card number will only be accepted with an
expiration date and -- with good merchants -- the three or four-digit
security code on the back of the card. Now you're up to doing
something like
# funky syntax ahead
my $cc = [ num = 8765 4321, expdate = 0799, code = 123 ];
# do magic
# ...
print I'm rich! if $cc.prop{CreditCard(CAMELCARD)};
Ouch! I may be conservative, but again I think you should go and ask
the authority (ie., a validation service). The authority in this case
probably is already encapsulated in a CPAN module and could look like
this:
use CreditCard::Validation;
deduct(10_000_000) if validate($number, $expdate, PERLIAN EXPRESS);
or something like
use CreditCard::Validation qw(ISA CAMELCARD MONKSCLUB);
deduct(10_000_000) if validate($number, $expdate, $bankcode);
depending on your tastes. Yep, it doesn't use funky perl 6 syntax, but
it SWIMs (Says What I Mean, ie. it is readable).
Greetings,
Christian
--
[EMAIL PROTECTED] - http://www.web42.com/crenz/ - http://www.web42.com/
If God were a Kantian, who would not have us till we came to Him from
the purest and best motives, who could be saved?
-- C.S. Lewis, The Problem of Pain
Re: 'my int( 1..31 ) $var' ?
print date if $var.isa(int); print date if isa $var: int; print date if $var ~~ int; Those should all work. IMO the first reads the best. That will also work for CInts, as CInt is a subclass of Cint (I think). These only determine if $var is of type int or Int. However: my $var = 0; # or my $var = 0; # or my int $var = 0; # or my num $var = 0; # all 4 cases should print is integer print is integer if int $var == $var; This should work as a more generic method to test Integer *value*, rather than type, which IMHO is more useful (and more commonly wanted). Well, in general I think it would be good to have some mechanism for determining the type of the data rather than the type of a representation of the contained value. If I have 0, it's possible I might at some point (this having been user input perhaps) have some reason to care whether it was an integer or a string. I know I hate the fact that, in almost every lang I use, adding the strings 014 and 231 requires me to do ' + string1 + + string2 ' since if I 'string1 + string2' I get integer addition and end up with a single number 245, or ' + string1 + string2' becomes the string 245. I've come to accept it, and I realize that 'var-typed(string1) + var-typed(string2)' takes more characters, looks uglier, and is generally more annoying in all ways for that problem, but I imagine there might exist cases where the information is useful ... I suppose it could be stored at input time as a ... variable property (?) that the program sets, but once it's read, I'm not sure the information exists in any meeans to produce the information FOR the property, so it would have to be set in the input functions themselves ... Admittedly, the value-type is goin to be more interesting in a large majority of the cases, so it probably SHOULD continue being the default low-effort result ... I had a point. I think I made it in there. --attriel
Re: my int( 1..31 ) $var ?
Murat Ünalan wrote: print date if $var is int( 1..31 ); I don't think that the type needs to be specified here, especially if the variable has already been declared to be of the required type, so a junction should be sufficient: print date if $var == any(1 .. 31); Smylers
Re: my int( 1..31 ) $var ?
On Friday, January 3, 2003, at 08:55 AM, Smylers wrote: Murat Ünalan wrote: print date if $var is int( 1..31 ); I don't think that the type needs to be specified here, especially if the variable has already been declared to be of the required type, so a junction should be sufficient: print date if $var == any(1 .. 31); I was under the impression the smart match operator would cover that implicitly. print date if $var =~ 1..31; Has this changed somewhere without my noticing it? Hmmm... thinking about another form of the above, I wonder... is there a postfix version of given? print date if 1..31 given $var;
Re: my int( 1..31 ) $var ?
On Friday, January 3, 2003, at 12:00 PM, Chris Dutton wrote: print date if 1..31 given $var; Except that this would always be true. Nevermind, I'm an idiot.
Re: my int( 1..31 ) $var ?
--- Smylers [EMAIL PROTECTED] wrote: Murat Ünalan wrote: print date if $var is int( 1..31 ); I don't think that the type needs to be specified here, especially if the variable has already been declared to be of the required type, so a junction should be sufficient: print date if $var == any(1 .. 31); Smylers Superpositions in the core? You're kidding, right? What's wrong with if 1 = $var = 31? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: my int( 1..31 ) $var ?
On Fri, Jan 03, 2003 at 10:58:49AM -0800, Mr. Nobody wrote: --- Smylers [EMAIL PROTECTED] wrote: junction should be sufficient: print date if $var == any(1 .. 31); Superpositions in the core? You're kidding, right? What's wrong with if 1 = $var = 31? My understanding was that junctions were most definitely in the core. As to what's wrong with the example you give...nothing. If you like it, by all means use it. But, (1) TIMTOWTDI, (2) Smyler's version is more visually concise (although, granted, it actually takes a few extra chars), (3) Smyler's version puts the variable (the important thing in the expression) on the left instead of the in the middle, and (4) IMHO, Smyler's version reads better as English. --Dks
Re: my int( 1..31 ) $var ?
Date: Fri, 3 Jan 2003 12:06:24 -0500 From: Chris Dutton [EMAIL PROTECTED] On Friday, January 3, 2003, at 12:00 PM, Chris Dutton wrote: print date if 1..31 given $var; Except that this would always be true. Nevermind, I'm an idiot. You're not such an idiot. You just got one word wrong: print date when 1..31 given $var; There is definitely postfix Cwhen. Cfor, and Cwhile are postfix, so I don't see why Cgiven wouldn't be. Miko seems to want it enough. But, in accordance with Larry's Nope, still can't chain [postfix conditions,] this would not be very useful. Hopefully he'll reconsider whether you can chain them or not? :) Luke
Re: my int( 1..31 ) $var ?
Chris Dutton wrote: On Friday, January 3, 2003, at 08:55 AM, Smylers wrote: Murat Ünalan wrote: print date if $var is int( 1..31 ); print date if $var == any(1 .. 31); I was under the impression the smart match operator would cover that implicitly. Ah, yes; of course it does. print date if $var =~ 1..31; Has this changed somewhere without my noticing it? No -- I just forgot about it. But now you bring it up, I do remember that the symbol changed, so I think it should be: print date if $var ~~ 1..31; Smylers
Re: my int( 1..31 ) $var ?
David Storrs wrote: On Fri, Jan 03, 2003 at 10:58:49AM -0800, Mr. Nobody wrote: --- Smylers [EMAIL PROTECTED] wrote: junction should be sufficient: print date if $var == any(1 .. 31); Superpositions in the core? You're kidding, right? Yeah, somehow they just slipped right in there without anybody on this mailing list really noticing -- and certainly without any long threads discussing the syntax for their operator incarnations and the knock-on effect that could have on other operators ... What's wrong with if 1 = $var = 31? ...nothing. If you like it, by all means use it. But, (1) TIMTOWTDI, (2) Smyler's version is more visually concise (although, granted, it actually takes a few extra chars), (3) Smyler's version puts the variable (the important thing in the expression) on the left instead of the in the middle, and (4) IMHO, Smyler's version reads better as English. Those are stylistic things, and to some degree a matter of taste. More importantly the junction version -- or even better, the smartmatch version as pointed out by Chris Dutton -- work for arbitrary sets, not just ranges of consecutive values. Smylers
Re: my int( 1..31 ) $var ?
--- Smylers [EMAIL PROTECTED] wrote: David Storrs wrote: On Fri, Jan 03, 2003 at 10:58:49AM -0800, Mr. Nobody wrote: --- Smylers [EMAIL PROTECTED] wrote: junction should be sufficient: print date if $var == any(1 .. 31); Superpositions in the core? You're kidding, right? Yeah, somehow they just slipped right in there without anybody on this mailing list really noticing -- and certainly without any long threads discussing the syntax for their operator incarnations and the knock-on effect that could have on other operators ... I looked through the p6l archives, there really wasn't much discussion about it. What's wrong with if 1 = $var = 31? ...nothing. If you like it, by all means use it. But, (1) TIMTOWTDI, (2) Smyler's version is more visually concise (although, granted, it actually takes a few extra chars), (3) Smyler's version puts the variable (the important thing in the expression) on the left instead of the in the middle, and (4) IMHO, Smyler's version reads better as English. It's also far slower. Constructing a 31-element list, junctionizing it, then testing against each element vs. 2 numeric comparisons. I know where my money is... Those are stylistic things, and to some degree a matter of taste. More importantly the junction version -- or even better, the smartmatch version as pointed out by Chris Dutton -- work for arbitrary sets, not just ranges of consecutive values. Wanting to do this for arbitrary lists dosen't need junctions. if grep $_ == $var, @mylist suffices. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: my int( 1..31 ) $var ?
[EMAIL PROTECTED] (Mr. Nobody) writes: I looked through the p6l archives, there really wasn't much discussion about it. http://groups.google.com/groups?q=superpositions+group%3Aperl.perl6.language finds 141 articles. -- An ASCII character walks into a bar and orders a double. Having a bad day? asks the barman. Yeah, I have a parity error, replies the ASCII character. The barman says, Yeah, I thought you looked a bit off. -- from Skud
Re: my int( 1..31 ) $var ?
Various folks wrote: Superpositions in the core? You're kidding, right? Nope. They're in (this week at least!) What's wrong with if 1 = $var = 31? ...nothing. If you like it, by all means use it. But, (1) TIMTOWTDI, (2) Smyler's version is more visually concise (although, granted, it actually takes a few extra chars), (3) Smyler's version puts the variable (the important thing in the expression) on the left instead of the in the middle, and (4) IMHO, Smyler's version reads better as English. It's also far slower. Constructing a 31-element list, junctionizing it, This might well be done at compile-time. And/or, lazily. So the cost of these two steps is likely to be negligible. then testing against each element vs. 2 numeric comparisons. Yes. That's a significant cost in this case. Wanting to do this for arbitrary lists dosen't need junctions. if grep $_ == $var, @mylist suffices. Except that it's much uglier (and hence less maintainable) than: if $var == any(@mylist) Moreover, in this case, junctions may well be faster, since they short-circuit and Cgrep probably still doesn't. Damian
Re: my int( 1..31 ) $var ?
- Original Message - From: Mr. Nobody [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 03, 2003 1:58 PM Subject: Re: my int( 1..31 ) $var ? --- Smylers [EMAIL PROTECTED] wrote: Murat Ünalan wrote: print date if $var is int( 1..31 ); I don't think that the type needs to be specified here, especially if the variable has already been declared to be of the required type, so a junction should be sufficient: print date if $var == any(1 .. 31); Smylers Superpositions in the core? You're kidding, right? What's wrong with if 1 = $var = 31? For one thing they're not equivalent. my $var = 2.5; print date if $var == any(1..31); print in interval if 1 = $var = 31; Speaking of which, is there a run-time test to check if a variable is of integral type? Something like print date if ($var is int) (1 = $var = 31); Joe Gottman
Re: my int( 1..31 ) $var ?
JG == Joe Gottman [EMAIL PROTECTED] writes: JG Speaking of which, is there a run-time test to check if a variable is of JG integral type? Something like JG print date if ($var is int) (1 = $var = 31); the old standby is: int( $var ) == $var uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: my int( 1..31 ) $var ?
- Original Message - From: Uri Guttman [EMAIL PROTECTED] To: Joe Gottman [EMAIL PROTECTED] Cc: Perl6 [EMAIL PROTECTED] Sent: Friday, January 03, 2003 10:06 PM Subject: Re: my int( 1..31 ) $var ? JG == Joe Gottman [EMAIL PROTECTED] writes: JG Speaking of which, is there a run-time test to check if a variable is of JG integral type? Something like JG print date if ($var is int) (1 = $var = 31); the old standby is: int( $var ) == $var I'm not sure if this works. my $var = 0; # Notice the quotation marks print is integer if (int($var) == $var); In the above case int($var) == $var returns true when I would want it to return false. Joe Gottman
