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 Cs, as C is a subclass of C (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: This week's Perl Summary
Damian Conway wrote: Piers Cawley wrote: Acknowledgements But, of course, modesty forebade him from thanking the tireless Perl 6 summarizer himself, for his sterling efforts wading through the morasses that are P6-language and P6-internals Remembering e.g. perl6 operator threads, brrr, I just can say ... Thank-you, Piers! me2 Damian leo
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: nag Exegesis 2
> > my int ($pre, $in, $post) is constant = (0..2); > > > > Two things "type and property" that belong so together > > Do they? Surely the type and constancy of a variable are > entirely orthogonal to each other. Oh yes. Psycho-affectivly it is disturbing seeing the group of variables ($pre, $in, $post) teared apart from the initilizing (0..2). This is my second step in the brain when analysing it. And this is prone to problems like in: my int ($one, $two, $three, $four, $five, $six, $seven ) is Prop( 'camel', 'perl', 'camel', 'perl' ) = (0..6); where the distance grows with property-syntax-complexity. > Besides, if you want them near each other, you can write them > this way: > > my ($pre, $in, $post) returns int is constant = (0..2); > > Damian Same problem as above. Following fragments should stay adjacent: ($pre, $in, $post) = (0..2); and then fragments remains: my * returns int is constant Suggestion: it could be pieced to my constant int ($pre, $in, $post ) = (0..2); which i guess is far superior (of course i hadn't done any field testing and making statistics over it). Btw: it is self-explanatory for many cross-language-programmers. Excerpt: Ony of my fears orginate from the idea that someone new to perl6 could be put off by such hard nuts during the very basics of variable decleration. Murat
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" ?
> > In the above case int($var) == $var returns true when I > would want it > > to return false. > > 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 Cs, as C is a subclass of C > (I think). > > Luke and that should also work print "date" if $var ~~ PropertyDate( 'monthday' ); smart match against a property. 'isa' wouldn't help then ? Murat
Re: AW: nag Exegesis 2
> From: =?iso-8859-1?Q?Murat_=DCnalan?= <[EMAIL PROTECTED]> > Date: Sat, 4 Jan 2003 14:50:22 +0100 > > > > my int ($pre, $in, $post) is constant = (0..2); > > > > > > Two things "type and property" that belong so together > > > > Do they? Surely the type and constancy of a variable are > > entirely orthogonal to each other. > > Oh yes. Psycho-affectivly it is disturbing seeing the group of variables > ($pre, $in, $post) teared apart from the initilizing (0..2). This is my > second step in the brain when analysing it. And this is prone to > problems like in: > > my int ($one, $two, $three, $four, $five, $six, $seven ) is Prop( > 'camel', 'perl', 'camel', 'perl' ) = (0..6); > > where the distance grows with property-syntax-complexity. In Perl 5, my int ($one = 0, $two = 1, $three = 2); is a fatal error. I could argue for this to change, as to support better readability (and it would). It's obvious WIM, so why doesn't it DWIM (disclaimer: cannot be used as an argument for arbitrary features. Is not a slogan. I repeat, is not a slogan. :) ? If you say that: my int ($one = 0, $two = 1, $three = 2) is constant; is seperating related parts, I disagree. I don't think C has anything to do with C. Like Damian said, they're orthogonal concepts. > Suggestion: it could be pieced to > > my constant int ($pre, $in, $post ) = (0..2); > > which i guess is far superior (of course i hadn't done any field testing > and making statistics over it). It's not far superior. It's pretending like C is part of the type, which it isn't. > Btw: it is self-explanatory for many cross-language-programmers. Yes, but my int $foo is constant; Is self-explanatory for many language-speakers. If I recall, the set of cross-language-programmers is a proper subset of the set of language-speakers. It is clear which is clearer :). > Excerpt: Ony of my fears orginate from the idea that someone new to > perl6 could be put off by such hard nuts during the very basics of > variable decleration. What hard nuts? p6d is working on a fine nutcracker, in any case. Luke
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=de&lr=&ie=UTF-8&oe=UTF-8&threadm=1990S ep28.181057.16740%40odi.com&rnum=5&prev=/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: nag Exegesis 2
Luke Palmer wrote:
> In Perl 5,
>
> my int ($one = 0, $two = 1, $three = 2);
>
> is a fatal error. I could argue for this to change, as to support
> better readability (and it would). It's obvious WIM, so why doesn't
> it DWIM (disclaimer: cannot be used as an argument for arbitrary
> features. Is not a slogan. I repeat, is not a slogan. :) ?
The problem is that this couldn't work given the current semantics of
the assignment operator. The "return-value" of an assignment is the
lhs of the assignment, so
my int ($one = 0, $two = 1, $three = 2);
ends up becoming:
my int (0,1,2);
Which, of course, is a fatal error (partly because it doesn't make any
sense). This is why stuff like:
if (defined ($child = fork)) {
}
Works as expected.
The point that I am trying to get at is: just because it is obvious
WIM to a human reader doesn't mean that it will be easy for a compiler
to figure out, especially when the rest of the language works a
different way. List assignment is much easier to read anyways.
Joseph F. Ryan
[EMAIL PROTECTED]
This message was sent using the Webmail System hosted by OARDC Computing Services --
http://webmail.oardc.ohio-state.edu:8080
Re: AW: nag Exegesis 2
Murat Ünalan wrote:
Oh yes. Psycho-affectivly it is disturbing seeing the group of variables
($pre, $in, $post) teared apart from the initilizing (0..2). This is my
second step in the brain when analysing it. And this is prone to
problems like in:
my int ($one, $two, $three, $four, $five, $six, $seven ) is Prop(
'camel', 'perl', 'camel', 'perl' ) = (0..6);
where the distance grows with property-syntax-complexity.
Oh, *that's* what you're concerned about?
Then you're just not thinking in enough simultaneous dimensions:
my int ($pre, $in, $post) is constant
= (0,1, 2);
or even:
my int ($one,$two, $three, $four, $five, $six, $seven )
is Prop('camel', 'perl', 'camel', 'perl')
= (0, 1, 2, 3, 4, 5, 6 );
However, I have to say that I consider it a questionable practice to
declare multiple constants in a single statement. Which makes much of
this discussion moot from my point of view.
Damian
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: AW: nag Exegesis 2
> > where the distance grows with property-syntax-complexity.
>
> Oh, *that's* what you're concerned about?
> Then you're just not thinking in enough simultaneous dimensions:
>
>
> my int ($pre, $in, $post) is constant
> = (0,1, 2);
This could been written faster in a single line, without decorating with
extra newline+tab+tab+tab+tab:
my constant int ($pre, $in, $post) = ( 0, 1, 2 );
>
> or even:
>
> my int ($one,$two, $three, $four, $five, $six,
> $seven )
> is Prop('camel', 'perl', 'camel', 'perl'
>)
> = (0, 1, 2, 3, 4, 5,
> 6 );
dito.
> However, I have to say that I consider it a questionable
> practice to declare multiple constants in a single statement.
> Which makes much of this discussion moot from my point of view.
I intended to address property syntax in general (where constant is just
an example). So please don't proof me wrong with just taking a very
primitive example. My believe is to clear something fogged by syntax.
Back to natural reading:
my ( john, james, jim and tony ) are ( 42, 77, 32, 34
).
is a template for
my ($john, $james, $jim, $tony ) = ( 42, 77, 32, 34
);
could be in real world application for making statistics about average
age of webshop users:
my Customer('WebShop') AGE ( $john, $james, $jim, $tony ) = ( 42, 77,
32, 34 );
Murat
AW: AW: nag Exegesis 2
> Yes, but
>
> my int $foo is constant;
>
> Is self-explanatory for many language-speakers. If I recall,
> the set of cross-language-programmers is a proper subset of
> the set of language-speakers. It is clear which is clearer :).
You do "proof by best case scenario". In my previous posting i showed
how this can become complicated to read when the list grows.
To language-speakers: Why isn't my example language-speaker conform:
my ( john, james, jim and tony ) are ( 42, 77, 32, 34
).
is a template for
my ($john, $james, $jim, $tony ) = ( 42, 77, 32, 34
);
could be in real world:
my Application('Bricolage') USER ( $john, $james, $jim, $tony ) = (
'john camel', 'james content', 'jim parrot', 'tony perl' ;
Excerpt: why don't catch two mosquitos with one snatch... easy c++/java
and language-speaker migration.
Murat
AW: AW: "my int( 1..31 ) $var" ?
> 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
>
I think this is similar to "John Williams" suggestion:
print "creditcard" if CreditCard( $var ) eq 'VISA';
It is something different to scan a database of card types and return a
list of possible matches, instead
of just testing one requested card type. What if CreditCard is such a
routine
sub CreditCard
{
#connect to a "specific" database (VISA, MASTERCARD, ..)
#compare with "non-blocked or valid" cards
}
or
sub CreditCard
{
#cycle through all 800 CreditCard types and return matches
}
Then Damians suggetion
> print "creditcard" if $var.CreditCard ~~ 'VISA';
could mean heavy processing, but
print "creditcard" if $var ~~ CreditCard( 'VISA' );
would be short work.
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.
Murat
Re: AW: AW: nag Exegesis 2
Murat Ünalan wrote:
Then you're just not thinking in enough simultaneous dimensions:
my int ($pre, $in, $post) is constant
= (0,1, 2);
This could been written faster in a single line, without decorating with
extra newline+tab+tab+tab+tab:
It's source code. Four extra keystrokes is a negligible price to pay for the
clarity gained.
could be in real world application for making statistics about average
age of webshop users:
my Customer('WebShop') AGE ( $john, $james, $jim, $tony ) = ( 42, 77,
32, 34 );
And that shows precisely why Perl 6 does it the other way. Prepending extended
properties like that makes the declaration almost unreadable. Because it
separates the properties from the variables they qualify. Expecially compared
with:
my AGE ( $john, $james, $jim, $tony ) is Customer('WebShop')
= ( 42,77, 32, 34);
Besides which, multiple variables like this are almost always exactly the
wrong solution. Especially for statistical applications.
You really want:
my AGE %customers = ( John=>42, James=>77, Jum=>32, Tony=>34 );
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
AW: AW: AW: nag Exegesis 2
> And that shows precisely why Perl 6 does it the other way. > Prepending extended properties like that makes the > declaration almost unreadable. Because it separates the I shoot in my own foot. My example was extremly bad. Give me a better try: (1) my size(4), human DNA ($alpha, $beta, $gamma, $delta ) = ( 'atgc', 'ctga', 'aatt', 'ccaa' ); is so perfect, vs (2) my DNA ($alpha, $beta, $gamma, $delta) is human, size(4) = ( 'atgc', 'ctga', 'aatt', 'ccaa' ); which is so prone to overlook the "eucaryotic" property during i.e. debugging hassle. Why do code beautify (2) when (1) so crystal clear without it. And (1) is so close to natural language. BTW: are multiple properties separated with ',' ? This was my last try, promise! 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: AW: AW: nag Exegesis 2
Murat Ünalan wrote:
And that shows precisely why Perl 6 does it the other way.
Prepending extended properties like that makes the
declaration almost unreadable. Because it separates the
I shoot in my own foot. My example was extremly bad. Give me a better
try:
(1)
my size(4), human DNA ($alpha, $beta, $gamma, $delta ) = ( 'atgc',
'ctga', 'aatt', 'ccaa' );
is so perfect, vs
(2)
my DNA ($alpha, $beta, $gamma, $delta) is human, size(4) = ( 'atgc',
'ctga', 'aatt', 'ccaa' );
which is so prone to overlook the "eucaryotic" property during i.e.
debugging hassle. Why do code beautify (2) when (1) so crystal clear
without it.
Because (1) *isn't* crystal clear. At least, not to me. And certainly
not as readable as:
my DNA ($alpha, $beta, $gamma, $delta) is human size(4)
= ('atgc', 'ctga', 'aatt', 'ccaa');
or as useful as:
my DNA %sequence is human size(4) =
(alpha => 'atgc', beta => 'ctga', gamma => 'aatt', delta => 'ccaa'_;
And (1) is so close to natural language.
Perhaps to *your* natural language, but not to mine. :-)
And that's what it may come down to. Perhaps we just have to agree
to disagree on this question. You're not convincing me at all, and
I'm obviously not convincing you either.
BTW: are multiple properties separated with ',' ?
No. Whitespace or an C.
Damian
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: AW: AW: AW: nag Exegesis 2
> (1)
>
> my size(4), human DNA ($alpha, $beta, $gamma, $delta ) = ( 'atgc',
> 'ctga', 'aatt', 'ccaa' );
>
> is so perfect, vs
>
> (2)
>
> my DNA ($alpha, $beta, $gamma, $delta) is human, size(4) = ( 'atgc',
> 'ctga', 'aatt', 'ccaa' );
If I were concerned about this, I would either do it the way Damian
suggests
my DNA ($alpha, $beta, $gamma, $delta) is human size(4)
= ('atgc', 'ctga', 'aatt', 'ccaa');
Or I would just make it two lines:
my DNA ($alpha, $beta, $gamma, $delta) is human size(4);
($alpha, $beta, $gamma, $delta) = ('atgc', 'ctga', 'aatt', 'ccaa');
And then expect the compiler to do precisely the same thing. The
benefit I find in the second case is that I can now move it somewhere
else and have separate declarations and initializations.
the example in (1) looks like it's beind declared as a "size(4)" , with
"human" and "DNA" being somehow modifiers on "size(4)" (admittedly, if
it were the stated style, people would be expected to understand it, but
it would still be counterintuitive, IMO)
--attriel
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 Cs, as C is a subclass of C (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
