PRE / POST in loops
Arthur Bergman
I just got a question from Lee Pumphret regarding Hook::Scope POST in
loops.
Currently it treats every iteration as a scope entry and scope exit so.
for(1..3) {
POST { print 2 };
print 1;
}
will print "121212",
Since perl6 seems to have a NEXT {} block for doing this, how is POST
and CATCH supposed to
be used in conjunction with loop scopes.
Arthur
Luke Palmer
> Date: Thu, 2 Jan 2003 19:21:04 +0100
> Cc: l...@leeland.net
> From: Arthur Bergman <aber...@cpan.org>
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
The difference between POST and NEXT is simply that POST fails to
refrain from executing after the final iteration, while NEXT does not.
You example is correct. In addition,
for 1..3 {
print 1;
NEXT { print 2 }
}
Prints "12121".
NEXT is really a kind of PRE block, contrary to what the example may
lead you to believe. So,
for 1..3 {
print;
NEXT { print }
}
Prints "12233", not "11223".
As I recall, CATCH can be used inside any block that contains an
expression that may throw an exception.
for 1..Inf {
die "Bonkers";
CATCH {
print;
}
}
Prints "Bonkers".
I hope this clarified things.
Luke
Andy Wardley
> The difference between POST and NEXT is simply that POST fails to
> refrain from executing after the final iteration, while NEXT does not.
Or in other words:
The difference between POST and NEXT is that POST executes after the final
iteration, while NEXT does not.
NEXT happens before the next item, POST happens after each item.
> I hope this clarified things.
It has failed to refrain from unenlightening me. :-)
A
Murat Ünalan
Damian conway's Attribute::Types suggests
"my $date : INTEGER(1..31);"
but i think
"my int( 1..31 ) $date"
is more like a c++/java
"Integer date( 1, 31 );"
and a weddig of both should fit perl6 best. Would mean:
my int( 1..31 ) $var;
$date = 23; # okay
$date = 32; # KABOOM!
I have some additional idea, when someone dislikes the tie-like
behaviour: an explicit testing with
print "date" if $var is int( 1..31 );
I think this suggestion should had been packed into a RFC, but when
the RFC-process closed i was still in my perl baby-shoes.
Murat
Smylers
> 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
Chris Dutton
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;
Chris Dutton
> print "date" if 1..31 given $var;
Except that this would always be true. Nevermind, I'm an idiot.
Mr. Nobody
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
David Storrs
> --- Smylers <Smy...@stripey.com> wrote:
> > junction should be sufficient:
> >
> > print "date" if $var == any(1 .. 31);
>
>
> 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
Luke Palmer
> From: Chris Dutton <ch...@cmb-enterprises.com>
>
> 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 C<when>. C<for>, and C<while> are postfix,
so I don't see why C<given> 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
Smylers
> 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
Smylers
> On Fri, Jan 03, 2003 at 10:58:49AM -0800, Mr. Nobody wrote:
>
> > --- Smylers <Smy...@stripey.com> 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
Murat Ünalan
about the "type and property" syntax. "Exegesis 2 - Any variables to
declare?" suggests:
my int ($pre, $in, $post) is constant = (0..2);
Two things "type and property" that belong so together are visually so
disrupted, which hurts. Additionally it is so confusing for a mainly
c++/java/c# that he would mixup "perl property" with his "c++ object
declaration" (resulting in a hard learning curve during p6 basics).
While the type "int" is more the "object" he would have expected. My
suggestion for alternativ syntax:
my constant int ($pre, $in, $post) = (0..2);
my int is constant ($pre, $in, $post) = (0..2);
This also protects from overlooking somewhere trailing properties in
growing variable lists, like in:
my int ($one, $two, $three, $four, $five, $six, $seven, $eight, $nine,
$ten) is constant = (0..9);
or complex property collections
my int ($one, $two, $three, $four, $five, $six, $seven ) is Prop(
'camel', 'perl', 'camel', 'perl' ) = (0..X);
In "alternativ syntax":
my constant int ($one, $two, $three, $four, $five, $six, $seven,
$eight, $nine, $ten) = (0..X);
here i had just looked in the head and see whats it.
my int Prop( 'camel', 'perl', 'camel', 'perl' ) ($one, $two, $three,
$four, $five, $six, $seven ) = (0..6);
here i had just looked at the tail and can count how many vars to
initialize (more like perl5, nothing disturbing inbetween).
Addition: I have an idea ;) Also i think one could recycle decleration
"is" for testing values in non-declerational-context. What if i have a
"propertyless" variable and want to test whether its would suffice a
property's spirit. When "is" would result in a boolean value i could
write my unloading perl6 like:
my ($var, $a);
print "this is a month day" if $var is Any(1..31);
print "this is a valid email" if $var is Email( 'mxcheck' );
print "debug: var was constant" if $var is constant;
print 'MasterCard' if $a is CreditCard( 'MASTER' );
print 'VISA' if $a is CreditCard( 'VISA' );
print 'i am confused' if $a is SocialNumber( 'US' );
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
boolean expr
Greetings,
Murat
PS: Sorry for opening a new thread, but after rereading my last stupid
question i realized that i wasn't using perl6-talk. So i reread apo/exe
and reconfigured my whole intention ;)
Mr. Nobody
> David Storrs wrote:
>
> > On Fri, Jan 03, 2003 at 10:58:49AM -0800, Mr. Nobody wrote:
> >
> > > --- Smylers <Smy...@stripey.com> 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.
Simon Cozens
> 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
Damian Conway
>>>>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
C<grep> probably still doesn't.
Damian
Damian Conway
> http://groups.google.com/groups?q=superpositions+group%3Aperl.perl6.language
> finds 141 articles.
Thanks, Simon.
BTW, searching for "junctions" as well (i.e. the new name for the concept)
adds an extra 70 or so articles.
Damian
Simon Cozens
> > http://groups.google.com/groups?q=superpositions+group%3Aperl.perl6.language
> > finds 141 articles.
>
> adds an extra 70 or so articles.
Some of which are superimposed! :)
Oh, and Mr. Nobody - if you still don't think it's been argued against
properly, look at any one of my posts from those threads. :)
--
> I never thought I'd say this, but you're getting very strange.
Thank God: I thought it was everybody else.
- J-P Stacey
Damian Conway
> 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.
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
Joe Gottman
----- Original Message -----
From: "Mr. Nobody" <mrnob...@yahoo.com>
To: <perl6-l...@perl.org>
Sent: Friday, January 03, 2003 1:58 PM
Subject: Re: "my int( 1..31 ) $var" ?
> --- Smylers <Smy...@stripey.com> 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
Uri Guttman
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 ------ u...@stemsystems.com -------- 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
Joe Gottman
----- Original Message -----
From: "Uri Guttman" <u...@stemsystems.com>
To: "Joe Gottman" <jgot...@carolina.rr.com>
Cc: "Perl6" <perl6-l...@perl.org>
Sent: Friday, January 03, 2003 10:06 PM
Subject: Re: "my int( 1..31 ) $var" ?
> >>>>> "JG" == Joe Gottman <jgot...@carolina.rr.com> 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
Luke Palmer
> Date: Fri, 3 Jan 2003 22:25:16 -0500
>
> > >>>>> "JG" == Joe Gottman <jgot...@carolina.rr.com> 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.
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 C<Int>s, as C<Int> is a subclass of C<int> (I think).
Luke
Joseph F. Ryan
>>> From: "Joe Gottman" <jgot...@carolina.rr.com>
>>> Date: Fri, 3 Jan 2003 22:25:16 -0500
>>>
>>> "JG" == Joe Gottman <jgot...@carolina.rr.com> 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 C<Int>s, as C<Int> is a subclass of C<int> (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
Simon Cozens
> 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
Murat Ünalan
> >
> > 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
Murat Ünalan
> > 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
Murat Ünalan
> 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 C<Int>s, as C<Int> is a subclass of C<int>
> (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
Luke Palmer
> 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<constant>
has anything to do with C<int>. 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<constant> 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
Murat Ünalan
> # 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
Joseph F. Ryan
> 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
ryan...@osu.edu
Damian Conway
> 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
John Williams
>
> 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
Damian Conway
>
> 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
Murat Ünalan
>
> 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 <wise> <uncles> ( john, james, jim and tony ) are ( 42, 77, 32, 34
).
is a template for
my <property> <type> ($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
Murat Ünalan
>
> 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 <wise> <uncles> ( john, james, jim and tony ) are ( 42, 77, 32, 34
).
is a template for
my <property> <type> ($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
Murat Ünalan
>
> 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
Damian Conway
> 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
Murat Ünalan
> typed, is it?
Not even optional ?
Murat
Murat Ünalan
> 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
John Williams
> > 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';
> >
>
> 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
Damian Conway
> 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<is>.
Damian
Christian Renz
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
--
cr...@web42.com - 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
Attriel
>
> 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
Attriel
>> 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 C<Int>s, as C<Int> is a subclass of C<int> (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
Smylers
> 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 C<lt> 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
Murat Ünalan
>
> my DNA %sequence is human size(4) =
> (alpha => 'atgc', beta => 'ctga', gamma => 'aatt',
> delta => 'ccaa'_;
oh , this is damn *PERFECT* !
a) easy reading
b) 'type' and 'property' adjacent without hopping through list
of varnames or complex property-constructs
c) "variable/keys" adjacent to init value
You sold that to me.
Then i could pray to the god of the camel herdsman, that
my DNA human size(4) ($alpha, $beta, $gamma, $delta)
= ('atgc', 'ctga', 'aatt', 'ccaa');
may be activated through perl6 custom parser options 8-) Or even
my DNA human size(4) ($alpha = 'atgc', $beta = 'ctga', $gamma =
'aatt', $delta = 'ccaa')
which i could sell my perl6-beginner classes even easier.
> Perhaps to *your* natural language, but not to mine. :-)
I have a german background. But my litte english-vs-perl6 example sounds
not so odd to me (what doesn't mean to much):
my <aged> <uncles> ( john, james, jim, tony ) are
( 102, 99, 88, 79 )
while 'are' stands for '=' and of course the initializing integers
wouldn't match the type 'uncle'.
Thanks for your patience with me,
Murat
Simon Cozens
> I have a german background. But my litte english-vs-perl6 example sounds
> not so odd to me (what doesn't mean to much):
>
> my <aged> <uncles> ( john, james, jim, tony ) are
> ( 102, 99, 88, 79 )
Actually, I think this sounds more natural too, but I think it's just a
matter of personal taste. And when it comes down to it, the personal
taste of the language designers is really all that counts. :)
--
"Ah," said Arthur, "this is obviously some strange usage of the word
'safe' that I wasn't previously aware of."
Attriel
>> 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
having slept now, the same thought occurs to me ... I think I wasthinking
of the user typing "0" to show that they're putting it in in string
context ... but then the variable would hold ""0"" ... which seems like
it'd solve the problem itself, at that point, since a user defined entity
can now /\"\d+\"/ to find out if it's built that way even if it does
collapse back to a number
>> 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
I should learn not to read/respond when i'm tired :o I was thinking of
all the Java & JS I've been doing the last couple weeks. Perl I'd just do
"$a$b" and be done with it.
>> ... 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.
Yeah, since the user would have to in some way dicatate that it was a
string value (typing "0" or such), the code will actually receive enough
information to build that if the programmer wants it. And I have ZERO
idea what I was thinking of as a "useful case" ... But since it is
user-garnerable information, and no cases are springing to mind, I retract
my earlier comments and say that it might be interesting in some case, but
in the same case it is feasible to simply allow the programmer to generate
it rather than killing ops generating it automatically ...
--attriel
(I'll quit posting just before I go to bed now :o)
Miko O'Sullivan
> From: Luke Palmer <fibo...@babylonia.flatirons.org>
>
> 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. :) ?
But it has such a Johnnie Cochran sound to it: "It's obvious WIM, you must
DWIM". Language design by catch phrase...
-miko
Miko O'Sullivan
Programmer Analyst
Rescue Mission of Roanoke
Damian Conway
> 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
Damian Conway
> Then i could pray to the god of the camel herdsman, that
>
> my DNA human size(4) ($alpha, $beta, $gamma, $delta)
> = ('atgc', 'ctga', 'aatt', 'ccaa');
>
> may be activated through perl6 custom parser options 8-)
*Any* consistent syntax may be activated through perl6 custom parser options.
Whether it *should* be is, of course, another matter entirely. ;-)
> I have a german background.
BTW, I wasn't criticizing your English. Someone who's German is as poor as mine
doesn't have the right. ;-)
> But my litte english-vs-perl6 example sounds
> not so odd to me (what doesn't mean to much):
>
> my <aged> <uncles> ( john, james, jim, tony ) are
> ( 102, 99, 88, 79 )
That's perfect English. But not necessarily good programming language design.
> Thanks for your patience with me,
It's not a matter of patience. You raise important issues (which I very much
appreciate), and it's my job -- and my desire -- to address them.
Damian
Tom Rathborne
> Murat Ünalan wrote:
> > 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.
Absolutely, as is the range. The type is multi-valued, whereas the
constancy is boolean. I propose 'is' and 'not' for specifying boolean
properties of variables.
> Besides, if you want them near each other, you can write them this way:
>
> my ($pre, $in, $post) returns int is constant = (0..2);
Hrm ...I prefer the variable and optional assignment at the end.
How about keywords that act like one-argument functions and which can
appear in any order, followed by the variable name(s) and, optionally,
= <value(s)>:
my range (0..7) returns int ($oblique, $literary, $reference) = (0,
2, 7);
which would be equivalent to
my returns int range (0..7) ($oblique, $literary, $reference) = (0,
2, 7);
and how about a range with type specified for some elements, and
constant?
my range (0..7) is constant ($one, $pi, $two) = (1 returns int,
3.14159, 2);
or ...
my @numbers = ('one' is constant, 2.0 returns float, 3 returns int);
and to override defaults ...
my is constant returns str @numbers = ('1' not constant, 2 returns
int, 3.0);
(the 3.0 would be cast to a string immediately; the 2 would not.)
Suppose you want a global variable (with limited scope):
my global Math::Crazy:: returns float is constant $close_to_pi =
3.14159;
So $close_to_pi appears as a global to anything under Math::Crazy::.
'is' could take other arguments for boolean properties, like 'is
locked', should you wish Perl to ask the operating system to never
swap this variable; Perl could consolidate such variables in one page
to minimize the
number of locked pages.
Oh, and say you'd like to declare and set some variables, which share
type/scope/etc, in a more readable fashion. Use a block:
my global :: is constant returns float range (0..7)
{ $tolkein => 2, $slept => 1, $here => 8 };
and to put everything in one:
my global Math::Crazy:: returns float is constant is locked range
(-2..+7) {
$close_to_pi not constant => 3.14159,
$close_to_zero => -0.0000001,
$close_to_e => 2.7,
$close_to_rho => 1.618,
};
which would be the same as:
my range (-2..+7) is constant returns float is locked global
Math::Crazy::
($close_to_pi not constant, $close_to_zero, $close_to_e,
$close_to_rho)
= (3.14159, -0.0000001, 2.7, 1.618);
... just to make sure TMTOWTDI.
Cheers,
Tom