Re: === and array-refs
At 11:16 PM -0600 8/16/06, David Green wrote: On 8/15/06, Darren Duncan wrote: At 2:51 PM -0600 8/15/06, David Green wrote: [...] You are right, but we have both Seq and Array types, so depending which one you use, you want either the === or eqv operators to do what you want. There is no reason that === should say 2 Array are equal; we have eqv for that, or use 2 Seq instead of 2 Array if you want === to return true on the same values. Is Seq vs Array the right distinction here? A Seq is immutable, so I can't change its size, for instance, which is not what I want. I just want [1,2] to be === to [1,2], or [1,2, [EMAIL PROTECTED] to be equal to [1,2, [EMAIL PROTECTED] but !=== [1,2, [EMAIL PROTECTED] -- eqv won't work in the latter case (regardless of Seq vs. Array -- I didn't think it made a difference here). As a lead-in, I should say that Synopsis 3 has a good and complete explanation of these matters and has had it for several weeks, in my opinion. Since you are wanting to compare two mutable Array, just use the eqv operator, which will do everything you want in a terse and easy to understand manner. Generally speaking, the direct use of === is more for specialized purposes, somewhat like the direct use of =:= is. If one can't tell the difference between === and eqv, they most likely want snapshot semantics anyway, and so might as well forget === exists, and just use eqv everywhere. There's no point arguing that === should deeply compare mutable types when you already have eqv to do that. Continuing on like you appear to be is like saying that the + operator should be useable to concatenate two Str, when we have the ~ operator for that. Arguing that === should deeply compare mutable types is like arguing that + should contactenate two Str. -- Darren Duncan
Re: Dumb doc question...
On 8/16/06, Agent Zhang <[EMAIL PROTECTED]> wrote: On 8/17/06, Mark J. Reed <[EMAIL PROTECTED]> wrote: > Where can I find a pod2html that groks the p6 version of POD? I want > to format my fresh-from-svn copies of the doc... > ... And there're also an online HTML version of the Perl 6 Spec: http://dev.perl.org/perl6/doc/synopsis.html This version automatically updates from the SVN repository every few hours. Unfortunately, S29 is not available there -- it only provides a pointer to http://svn.openfoundry.org/pugs/docs/Perl6/Spec/Functions.pod and the pod file just isn't as pretty as the nicely formatted HTML available for all the other synopses. =thom "Adults are always asking kids what they want to be when they grow up because they are looking for ideas." --Paula Poundstone
Re: === and array-refs
On 8/17/06, Darren Duncan <[EMAIL PROTECTED]> wrote: Generally speaking, the direct use of === is more for specialized purposes, somewhat like the direct use of =:= is. If one can't tell the difference between === and eqv, they most likely want snapshot semantics anyway, and so might as well forget === exists, and just use eqv everywhere. For me === feels like it should be the operator with "easier" semantics, i.e. the operator which perl-newbies would first want to learn, so it feels like the semantics of === and eqv should be swapped. === is a lot nearer to what many other languages uses for they comparison than more cryptic eqv. Also, == does "simpler" comparison than eq, so I feel that === should also do "simpler" (to understand) comparison than eqv -- Markus Laire
Random grammar typo in S02
Just noticed this on line 474: "Variables with native types does not support undefinedness"
String length
S02 states that there is no ".length" method on Str's (or for cumulative element length of Arrays); you have to ask explicitly for the units you want to count . But then it goes on to define the StrPos and StrLen types, which are unit-agnostic. So why not have a .length that returns a StrLen? I envison some method or sub wanting to have access to the length of a string, without necessarily having the string itself available, in a context where the caller wouldn't know what level of Unicode abstraction to use.
Numerification of Order:: constants
S03, lines 418-420: "[cmp] always returns C, C, or C (which numerify to -1, 0, or +1)." Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In which case it would be clearer to put them in respective order above...
Re: Numerification of Order:: constants
-- Original message -- From: "Reed, Mark (TBS)" <[EMAIL PROTECTED]> > S03, lines 418-420: "[cmp] always returns C, > C, or C (which numerify to -1, 0, or +1)." > > Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In > which case it would be clearer to put them in respective order above... > "$a cmp $b" has always been define as sign($a - $b), so the above numerification are correct. Thnk of them as describing the sequence ($a, $b). if the sequence is increasing then "$a, cmp $b" returns Order::Increase or -1. Mark Biggar -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: === and array-refs
On 8/17/06, Darren Duncan wrote: At 11:16 PM -0600 8/16/06, David Green wrote: I just want [1,2] to be === to [1,2], or [1,2, [EMAIL PROTECTED] to be equal to [1,2, [EMAIL PROTECTED] but !=== [1,2, [EMAIL PROTECTED] -- eqv won't work in the latter case (regardless of Seq vs. Array -- I didn't think it made a difference here). [...] Since you are wanting to compare two mutable Array, just use the eqv operator, which will do everything you want in a terse and easy to understand manner. No, look at the example I've been using. Two arrays (1, 2, [EMAIL PROTECTED]) and (1, 2, [EMAIL PROTECTED]) clearly have different (unevaluated) contents. "eqv" only tells me whether they have the same value (when @x and @y are evaluated). That's a different question -- yes, it's the more common question, but I think the comparison I want to make is just as reasonable as ===, except there's no easy way to do it. -David
Re: Numerification of Order:: constants
On 8/17/06, Reed, Mark (TBS) wrote: S03, lines 418-420: "[cmp] always returns C, C, or C (which numerify to -1, 0, or +1)." Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In which case it would be clearer to put them in respective order above... Maybe you could view it either way, although I think going the other way around would make more sense only if the names were Order::Lower, ::Same, ::Higher. S03 matches the old cmp semantics in that "3<=>4" returns -1, which represents increasing order because reading left-to-right, we go from 3 up to 4. However, what I'm wondering is whether Order::Same is "but true" and the others "but false"? (Which makes cmp in boolean context the same as eqv, but it seems to make sense that way.) -David
Re: Numerification of Order:: constants
On Thu, Aug 17, 2006 at 11:27:21AM -0600, David Green wrote: : However, what I'm wondering is whether Order::Same is "but true" and : the others "but false"? (Which makes cmp in boolean context the same : as eqv, but it seems to make sense that way.) We should not be encouraging people to use cmp to mean eq. All that will do is result in Great Confusion. Larry
Re: Numerification of Order:: constants
I don't know if I've made this clear, but over the last few years I've been treating "but True" and "but False" as design smells. They're fine as a workaround for dire circumstances and uncooperative types, but you'll not find me designing very many of the core interfaces to use them, or other run-time mixins, for that matter. Solutions involving "but" will generally be rejected, in other words. Larry
Re: === and array-refs
On 8/16/06, David Green wrote:
$a=[1, 2, [EMAIL PROTECTED];
$c=[1, 2, [EMAIL PROTECTED];
$d=[1, 2, [EMAIL PROTECTED];
$a =:= $c; #false, different variables
$a === $c; #true, same elements make up $a and $c
$a eqv $c; #true, same elements therefore same values
$a === $d; #false, [EMAIL PROTECTED] and [EMAIL PROTECTED] are
different refs
So $a, $c, and $d may all have the same *value*
(or "snapshot", when evaluated all the way down
through nesting and references), i.e. they might
be eqv, but only $a and $c are === because they
have the same contents [unevaluated contents]
and $d doesn't.
(Actually $a===$c above should be false.) Given
that === answers the question "are these things
the same object", what's the solution for my
original motivation of comparing two items for
their unevaluated contents? "Eqv" evaluates
everything (both references and nested
containers) down to immutable values; I want to
follow nested structures all the way down, but
not evaluate/deref any variable references.
For the one-dimensional $a and $c given above, I could do something like:
?all(@[EMAIL PROTECTED], grep {$^a === $^c} zip(@$a; @$c))
For multidimensional/nested arrays, I could check
that they're the same size with $a.shape eqv
$b.shape, but I believe grep (or map, etc.) work
only one-dimensionally. I don't think using
hyperoperators would work either, because $a
»===« $c would deref the contained @x before
applying ===, right?
Plus hyperops return a nested structure, and I'm
looking for a single bool -- I think hyperising
"all" around the whole result would work
Hyperops also upgrade dimensions that don't match
between the RHS and LHS, which is not always what
you want.
So perhaps what I'm looking for is more syntactic
sugar for easily traversing nested data
structures in different ways.
-David
Re: === and array-refs
On Thu, Aug 17, 2006 at 12:18:55PM -0600, David Green wrote: : So perhaps what I'm looking for is more syntactic : sugar for easily traversing nested data : structures in different ways. Quoth S03: If that's not enough flexibility, there is also an C function that can be passed additional information specifying how you want canonical values to be generated before comparison. This gives C the same kind of expressive power as a sort signature. Larry
Re: === and array-refs
On 8/17/06, David Green <[EMAIL PROTECTED]> wrote: >$a=[1, 2, [EMAIL PROTECTED]; >$c=[1, 2, [EMAIL PROTECTED]; >$d=[1, 2, [EMAIL PROTECTED]; > >So $a, $c, and $d may all have the same *value* >(or "snapshot", when evaluated all the way down >through nesting and references), i.e. they might >be eqv, but only $a and $c are === because they >have the same contents [unevaluated contents] >and $d doesn't. In this case, it seems like [===] @$a, @$c would do what you want, yes? It would return true, while [===] @$a,@$d would return false... In the general case - well, I think the thread demonstrates that it's hard to define a general case for what you want to do. Based on your example, I assumed you wanted one-level dereferencing, regardless of the contents. But it sounds like what you want is infinite dereferencing as long as the referent is anonymous, and no dereferencing if the referent is a named variable? That doesn't seem like a common enough case to warrant sugar to me; what am I missing? -- Mark J. Reed <[EMAIL PROTECTED]>
Re: === and array-refs
David Green wrote: No, look at the example I've been using. Two arrays (1, 2, [EMAIL PROTECTED]) and (1, 2, [EMAIL PROTECTED]) clearly have different (unevaluated) contents. "eqv" only tells me whether they have the same value (when @x and @y are evaluated). That's a different question -- yes, it's the more common question, but I think the comparison I want to make is just as reasonable as ===, except there's no easy way to do it. does "*$a === *$b" work? I.e. splat the two arrays into sequences, and then do the immuable compare on those sequences.
Invocant name in S12
I was just reading through S12, and it doesn't seem to ever actually state that the default invocant name is "self". (Is it self? Or is it $?SELF, which doesn't appear at all?) S12 mentions declaring an explicit invocant with : in the method signature, and that it's optional; and then later on in the context of attributes it uses "self" as if it's already been talked about, but I can't find an introduction of the term anywhere... -- Mark J. Reed <[EMAIL PROTECTED]>
[svn:perl6-synopsis] r11113 - doc/trunk/design/syn
Author: larry
Date: Thu Aug 17 16:08:34 2006
New Revision: 3
Modified:
doc/trunk/design/syn/S04.pod
Log:
Some leave simplifications.
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podThu Aug 17 16:08:34 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 19 Aug 2004
- Last Modified: 15 Aug 2006
+ Last Modified: 17 Aug 2006
Number: 4
- Version: 35
+ Version: 36
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -504,13 +504,14 @@
To return a value from a pointy block or bare closure, you either
just let the block return the value of its final expression, or you can
use C. A C by default exits from the innermost block.
-But you may change the behavior of C with selector adverbs:
+But you may change the behavior of C with a selector as the
+first argument:
-leave :from(Loop) :label <== 1,2,3; # XXX "with"?
+leave Loop where { .label ~~ 'LINE' }, 1,2,3;
The innermost block matching the selection criteria will be exited.
-The return value, if any, must be passed as a list. To return pairs
-as part of the value, you can use a feed operator:
+The return value, if any, must be passed as the second and subsequent
arguments.
+To return pairs as part of the value, you can use a feed operator:
leave <== :foo:bar:baz(1) if $leaving;
[svn:perl6-synopsis] r11115 - doc/trunk/design/syn
Author: larry
Date: Thu Aug 17 16:39:38 2006
New Revision: 5
Modified:
doc/trunk/design/syn/S06.pod
Log:
More old use of multiple invocant terminology changed to longnames.
Added mechanism for both short and long switch names.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podThu Aug 17 16:39:38 2006
@@ -13,9 +13,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 21 Mar 2003
- Last Modified: 14 Aug 2006
+ Last Modified: 17 Aug 2006
Number: 6
- Version: 49
+ Version: 50
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -481,21 +481,10 @@
print $obj.get_name();
$obj.set_name("Sam");
-Multimethod and multisub invocants are specified at the start of the parameter
-list, with a colon terminating the list of invocants:
-
-multi sub handle_event ($window, $event: $mode) {...} # two invocants
-multi method set_name ($self, $name: $nick) {...} # two invocants
-
-If the parameter list for a C contains no colon to delimit
-the list of invocant parameters, then all positional parameters are
-considered invocants. If it's a C or C,
-an additional implicit unnamed C invocant is prepended to the
-signature list.
-
For the purpose of matching positional arguments against invocant parameters,
the invocant argument passed via the method call syntax is considered the
-first positional argument:
+first positional argument when failover happens from single dispatch to
+multiple dispatch:
handle_event($w, $e, $m); # calls the multi sub
$w.handle_event($e, $m);# ditto, but only if there is no
@@ -509,14 +498,28 @@
# fall-back to set_name($obj, "Sam")
$obj.set_name("Sam"); # same as the above
-Passing too many or too few invocants is a fatal error if no matching
-definition can be found.
-
An invocant is the topic of the corresponding method or multi if that
formal parameter is declared with the name C<$_>. A method's first
invocant always has the alias C. Other styles of self can be
declared with the C pragma.
+=head2 Longname parameters
+
+Much like ordinary methods give preference to the invocant,
+multimethods and multisubs can give preference to earlier parameters.
+These are called I; see S12 for more about the semantics
+of multiple dispatch. Syntactically, longnames are declared by
+terminating the list of important parameters with a semicolon:
+
+multi sub handle_event ($window, $event; $mode) {...}
+multi method set_name ($self: $name; $nick) {...}
+
+If the parameter list for a C contains no semicolon to delimit
+the list of invocant parameters, then all positional parameters are
+considered invocants. If it's a C or C,
+an additional implicit unnamed C invocant is prepended to the
+signature list unless the first parameter is explicitly marked with a colon.
+
=head2 Required parameters
@@ -2534,3 +2537,14 @@
parameters, but still give you access to nested matches through those
parameters, just as any C object would. Of course, in this example,
there's no particular reason the sub has to be named C.
+
+To give both a long and a short switch name, you may use the pair
+notation. The key will be considered the short switch name, while
+the variable name will be considered the long switch name. So if
+the previous declaration had been:
+
+sub MAIN (:f($frompart), :t($topart), [EMAIL PROTECTED])
+
+then you could invoke the program with either C<-f> or C<--frompart>
+to specify the first parameter. Likewise you could use either C<-t>
+or C<--topart> for the second parameter.
[svn:perl6-synopsis] r11116 - doc/trunk/design/syn
Author: larry
Date: Thu Aug 17 16:45:20 2006
New Revision: 6
Modified:
doc/trunk/design/syn/S12.pod
Log:
Added explicit mention of "self" by suggestion of markjreed++.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podThu Aug 17 16:45:20 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 27 Oct 2004
- Last Modified: 9 Aug 2006
+ Last Modified: 17 Aug 2006
Number: 12
- Version: 19
+ Version: 20
=head1 Overview
@@ -160,8 +160,9 @@
method doit (MyName $self: $a, $b, $c) { ... }
method doit (::?CLASS $self: $a, $b, $c) { ... }
-Declaration of the invocant is optional. You need not declare
-its type, since the lexical class of the invocant is known in any
+Declaration of the invocant is optional. You may always access the
+current invocant using the keyword C. You need not declare the
+invocant's type, since the lexical class of the invocant is known in any
event because methods must be declared in the class of the invocant,
though of course the actual (virtual) type may be a derived type of
the lexical type. You could declare a more restrictive type, but
Re: === and array-refs
On Thu, Aug 17, 2006 at 12:00:17AM -0700, Darren Duncan wrote: > As a lead-in, I should say that Synopsis 3 has a good and complete > explanation of these matters and has had it for several weeks, in my > opinion. > > Since you are wanting to compare two mutable Array, just use the eqv > operator, which will do everything you want in a terse and easy to > understand manner. I'd just like to point out that S03 is back-arsewards here - it explains === first, and then explains eqv in terms of ===. Since eqv is the familiar thing people will want most of the time, and === is the weird thing that isn't used very often, it would make far more sense to explain them the other way around (and probably confuse less people). Understanding === should not be a prerequisite for understanding eqv.
Re: NEXT and the general loop statement
On 8/16/06, Larry Wall <[EMAIL PROTECTED]> wrote:
: Is the output 01234 or 12345?
I'd say 01234 on the theory that the 3-arg loop is really saying:
$n = 0;
while $n < 5 {
NEXT { ++$n }
NEXT { print $n }
}
and also on the theory that block exiting blocks always run in reverse order.
Wasn't NEXT supposed to do something tricky, such as being mutually
exclusive with LAST? I remember a debate some time ago where some
complained "but that would be hard to implement", and the solution
being mostly correct but failing in this case.
I seem to recall NEXT being created in order to do things like this:
for @objs {
.print;
NEXT { print ", " }
LAST { print "\n" }
}
We also might consider using perl6's hypothetical features to
implement NEXT correctly in all cases (except for those cases where
the loop update condition cannot be hypotheticalized).
Luke
Re: === and array-refs
Quoth [EMAIL PROTECTED] ("Mark J. Reed"):
> On 8/17/06, David Green <[EMAIL PROTECTED]> wrote:
> > >$a=[1, 2, [EMAIL PROTECTED];
> > >$c=[1, 2, [EMAIL PROTECTED];
> > >$d=[1, 2, [EMAIL PROTECTED];
> > >
> > >So $a, $c, and $d may all have the same *value*
> > >(or "snapshot", when evaluated all the way down
> > >through nesting and references), i.e. they might
> > >be eqv, but only $a and $c are === because they
> > >have the same contents [unevaluated contents]
> > >and $d doesn't.
>
> In this case, it seems like [===] @$a, @$c would do what you want,
> yes? It would return true, while [===] @$a,@$d would return false...
>
> In the general case - well, I think the thread demonstrates that it's
> hard to define a general case for what you want to do. Based on your
> example, I assumed you wanted one-level dereferencing, regardless of
> the contents. But it sounds like what you want is infinite
> dereferencing as long as the referent is anonymous, and no
> dereferencing if the referent is a named variable?
Surely that's a meaningless distinction? A named variable can become
anonymous if its name goes out of scope; an anon can be bound to a name.
Just to make sure I've got all this straight:
=:= compares names
=== compares containers
eqv compares values
So given an array @W,
my @X := @W;# @X =:= @W
my @Y = @W;# @Y === @W but @Y !=:= @W
my @Z = @W.clone; # @Z eqv @W but @Z !=== @W
? This seems like a useful set of distinctions to me...
Ben
--
The cosmos, at best, is like a rubbish heap scattered at random.
Heraclitus
[EMAIL PROTECTED]
RE: NEXT and the general loop statement
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 17, 2006 8:44 PM
> To: Perl6 Language List
> Subject: Re: NEXT and the general loop statement
> Wasn't NEXT supposed to do something tricky, such as being mutually
> exclusive with LAST? I remember a debate some time ago where some
> complained "but that would be hard to implement", and the solution
> being mostly correct but failing in this case.
>
> I seem to recall NEXT being created in order to do things like this:
>
> for @objs {
> .print;
> NEXT { print ", " }
> LAST { print "\n" }
> }
>
Is this even possible? This would require Perl to know which iteration is
going to be the last one. In many cases there is no way to know this:
repeat {
RE: NEXT and the general loop statement
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 17, 2006 8:44 PM
> To: Perl6 Language List
>
> Wasn't NEXT supposed to do something tricky, such as being mutually
> exclusive with LAST? I remember a debate some time ago where some
> complained "but that would be hard to implement", and the solution
> being mostly correct but failing in this case.
>
> I seem to recall NEXT being created in order to do things like this:
>
> for @objs {
> .print;
> NEXT { print ", " }
> LAST { print "\n" }
> }
>
> We also might consider using perl6's hypothetical features to
> implement NEXT correctly in all cases (except for those cases where
> the loop update condition cannot be hypotheticalized).
Is this even possible? This would require Perl to know which iteration is
going to be the last one. In many cases there is no way to know this:
repeat {
$num = rand;
print $num;
NEXT {print ',';}
LAST {print "\n";}
} while $num < 0.9;
If rand is a true random-number generator it would take a time machine to
determine whether to call NEXT or LAST.
(Sorry for the double post.)
Joe Gottman
Re: === and array-refs
在 2006/8/18 上午 3:31 時，Ben Morrow 寫到： Just to make sure I've got all this straight: =:= compares names === compares containers eqv compares values =:= evaluates both sides as lvalue -- that's VAR() -- and compare them with ===. === evaluates both sides as rvalue and, for container (mutable) types, compares their pointer address. eqv evaluates both sides as rvalue and, for container (mutable) types, compares their content values. None of the three coerces their arguments to concatenated List (aka list flattening, aka slurpy context). So given an array @W, my @X := @W;# @X =:= @W my @Y = @W;# @Y === @W but @Y !=:= @W my @Z = @W.clone; # @Z eqv @W but @Z !=== @W Your Array example would be correct with the $ sigil: my $w = [1,2,3,4]; # Scalar containing Array my $x := $w; # $x =:= $w my $y = $w; # $y === $w but $y !=:= $w my $z = $w.clone; # $z eqv $w but $z !=== $w However, &infix:<=> when its left-hand side is an array, has an different signature (and indeed, different precedence) than when its left-hand side is a scalar: my $y = $w; # does not flatten $w my @Y = @W; # does flatten @w, essentially doing a .clone my @Z = @W.clone; # same as "my @Z = @W" really. So the two assignments (@Y and @Z) above turns out to be the same thing, and neither will make "===" hold afterwards. Cheers, Audrey PGP.sig Description: This is a digitally signed message part
Re: NEXT and the general loop statement
On Thu, Aug 17, 2006 at 11:45:06PM -0400, Joe Gottman wrote:
> > -Original Message-
> > From: Luke Palmer [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, August 17, 2006 8:44 PM
> > To: Perl6 Language List
> >
> > Wasn't NEXT supposed to do something tricky, such as being mutually
> > exclusive with LAST? I remember a debate some time ago where some
> > complained "but that would be hard to implement", and the solution
> > being mostly correct but failing in this case.
> >
> > I seem to recall NEXT being created in order to do things like this:
> >
> > for @objs {
> > .print;
> > NEXT { print ", " }
> > LAST { print "\n" }
> > }
> >
> > We also might consider using perl6's hypothetical features to
> > implement NEXT correctly in all cases (except for those cases where
> > the loop update condition cannot be hypotheticalized).
>
>
>
> Is this even possible? This would require Perl to know which iteration is
> going to be the last one. In many cases there is no way to know this:
>
>repeat {
> $num = rand;
> print $num;
> NEXT {print ',';}
> LAST {print "\n";}
> } while $num < 0.9;
>
> If rand is a true random-number generator it would take a time machine to
> determine whether to call NEXT or LAST.
> (Sorry for the double post.)
Depends on when it fires I guess. Your example might be equivalent to
this perl5ish:
while (1) {
$num = rand;
print $num;
last if $num < 0.9;
print ","; # NEXT
}
print "\n"; # LAST
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
