Re: r28061 - docs/Perl6/Spec
Suggest s/right argument/right-hand argument/ Also suggest s/** 2/** $y/ since it seems strange to be referring to a right-hand argument which, in the example, is a constant. pugs-comm...@feather.perl6.nl wrote: Author: carlin Date: 2009-08-25 08:48:35 +0200 (Tue, 25 Aug 2009) New Revision: 28061 Modified: docs/Perl6/Spec/S03-operators.pod Log: [S03] Don't not use no double negatives Modified: docs/Perl6/Spec/S03-operators.pod === --- docs/Perl6/Spec/S03-operators.pod 2009-08-25 00:26:56 UTC (rev 28060) +++ docs/Perl6/Spec/S03-operators.pod 2009-08-25 06:48:35 UTC (rev 28061) @@ -569,7 +569,7 @@ $x ** 2 -If the right argument is not a non-negative integer, the result is likely to +Unless the right argument is a non-negative integer the result is likely to be an approximation. If the right argument is of an integer type, exponentiation is at least as accurate as repeated multiplication on the left side's type. (From which it can be deduced that CInt**UInt
r28061 - docs/Perl6/Spec
Author: carlin Date: 2009-08-25 08:48:35 +0200 (Tue, 25 Aug 2009) New Revision: 28061 Modified: docs/Perl6/Spec/S03-operators.pod Log: [S03] Don't not use no double negatives Modified: docs/Perl6/Spec/S03-operators.pod === --- docs/Perl6/Spec/S03-operators.pod 2009-08-25 00:26:56 UTC (rev 28060) +++ docs/Perl6/Spec/S03-operators.pod 2009-08-25 06:48:35 UTC (rev 28061) @@ -569,7 +569,7 @@ $x ** 2 -If the right argument is not a non-negative integer, the result is likely to +Unless the right argument is a non-negative integer the result is likely to be an approximation. If the right argument is of an integer type, exponentiation is at least as accurate as repeated multiplication on the left side's type. (From which it can be deduced that CInt**UInt
Re: Synopsis 02: Range objects
On 2009-Aug-24, at 4:17 pm, Daniel Ruoso wrote: Em Seg, 2009-08-24 às 23:50 +0200, Michael Zedeler escreveu: The most elegant solution would be if the data types themselves indicated their capabilities. One thing I think you missed entirely is the fact that the infix:.. operator is a multi sub, so it falls to regular dispatch semantics, But Michael's point was not about what's *possible*, but rather what's *reasonable*. Given that Ranges can act in two ways that lead to inconsistency, it would be less confusing to separate the list-kind from the interval-kind. For certain discrete ordered types, like Int, both ways work out the same, and since Ints are the most common and most obvious use for Ranges, it's easy to overlook the confusion. The case with strings is a good example: it really doesn't make sense that a value not produced by a range nevertheless lies between its endpoints. Why not have a separate Interval type? A Range might get implicitly cast to an Interval by using its endpoints; that leaves us open to the same confusion, although the context would help. # Assuming infix:between (Any, Interval) say 5 between [1, 10]; say 5 between 1 .. 10; say 'aaa' ~~ 'aa' .. 'ba'; # false say 'aaa' between aa ba; # true say 'aaa' between 'aa'..'ba'; # hm... Come to think of it, the word range suggests ordering (like the related word rank), so perhaps Range is the right name for the interval-type, and Series should be the type that produces a series of values that may or may not have an innate ordering. (For example, you could produce a Complex series with: 5+5i .. 10+10i :by(1+1i).) -David
Re: S26 - The Next Generation
Smylers pointed out: * Hence it must always parsed using full Perl 6 grammar: perl6 -doc Having a multi-character option preceded by a single hyphen doesn't play well with bundling of single-character options... You make many good points. Changed to: perl --doc Thanks, Damian
Re: Synopsis 02: Range objects
James Cloos wrote: Michael == Michael Zedeler mich...@zedeler.dk writes: Michael The Range 1.0001 .. 2.15 makes sense as an interval definition, but Michael there can hardly be a useful list definition without defining a step Michael size, at least, making it possible to use step sizes less than one. The obvious (default) choice for a step size would be the precision of the more precise of the two values. So 0.0001 in your example above. Well... maybe. How do you specify the intended precision, then? If I want the values from 1 to 2 with step size 0.01, I guess that writing 1.00 .. 2.00 won't be sufficient. Trying to work out the step size by looking at the precision of things that are double or floats doesn't really sound so feasible, since there are a lot of holes in the actual representation, so 1.0001 may become 1.0, yielding very different results. It could be really nice to come up with something dwimmy, but I can't really se any really good candidates, when it comes to floating point numbers and strings. If they were specified in hex float syntax, such as 0x1.01P0 .. 0x3.123P0, then the (default) step should be 0x0.001P0 (which is the same as saying 1.00390625 .. 3.071044921875 with a step size of 0.000244140625). Fair enough, but again - I guess they are translated straight to some internal representation where the information in this notation would be lost. Just like it would be in decimal notation. Michael Complex .. Complex - undef, exception or some other bad thing. Complex .. Complex should have a defined meaning in p6. A definition which is easy to compute would be the set of points contained by the square which has opposite corners at the two specified points. But is that useful? Complex numbers are mostly for mathematics, so I guess we have to look in that domain for a good use case. In that domain there is no natural ordering of complex numbers, and without some ordering, you may be able to decide what should be in the list to return, but not which order to use. I believe that anything we put into Perl 6 should have obvious use cases and fall natural into place in the domain that the construct in question belongs to. This means we have to come up with a design (there currently is no specification of Complex .. Complex), some kind of use case to as justification and finally a validation that ensures that the design is consistent with other things in the language. An example of an obvious inconsistency is ranges on strings compared to how cmp works. A better definition would be the set of points contained by the circle which has a diameter running between the two points. In that case, you'd really need a step size, since circles tend bend :-) Also, I'd like to see an obvious and intuitive ordering. In both cases, of course, including the points actually on the 1-manifold. Either choice has the same meaning on the real axis as .. generates when given real args, and is useful for interval arithmetic. Something for which p6 is well suited. I'll go and get my old topology book and see what I can find there, but I must admit that I'd prefer if Complex .. Complex was left undefined in the Perl 6 core, leaving it up to anyone to specify it later. Regards, Michael.
Re: S26 - The Next Generation
I promised some further thoughts; here they are:
As written, declarator aliasing attaches the alias to a piece of code,
and draws both the name and the alias from that. What about using a
special case of the declarator block for this? That is:
class Database::Handle { #=alias
has IO $!handle; #=alias
my Bool method open ($filename) {...} #=alias
=for para
Note that the Amethod method of class Aclass
stores the resulting low-level database handle
in its private Ahas attribute.
}
The rules for what gets aliased would be the same as the rules for
what gets annotated. This is more compact than the =alias directive
sans arguments approach, as you can put the alias on the same line as
the declarator to which it is bound.
The downside is that it runs opposite to what declarator blocks
usually do: instead of attaching some Pod to the ambient code, it
attaches a piece of the ambient code to Pod. That, and alias is
appearing in the declarator block where the Pod parser would be
expecting content. Perhaps you could use some other symbol to
distinguish a declarator alias from a declarator block: e.g., #=
represents a declarator alias, while #= represents a declarator block.
So:
class Database::Handle { #=
has IO $!handle; #=
my Bool method open ($filename) {...} #=
=for para
Note that the Amethod method of class Aclass
stores the resulting low-level database handle
in its private Ahas attribute.
}
Regardless of what syntax you use for declarator aliasing, I'd also
recommend some sort of numbering scheme if you alias more than one
declarator of the same type in the same lexical scope:
=alias
class Database::Handle {
=alias
has IO $!handle;
=alias
my Bool method open ($filename) {...}
=alias
my Bool method close() {...}
=for para
Note that the Amethod1 method of class Aclass
stores the resulting low-level database handle
in its private Ahas attribute, while the Amethod2
method closes that handle.
}
If you adopt the declarator block basis for declarator aliasing, you
could even let the documenter choose his own names:
class Database::Handle { #=
has IO $!handle; #=
my Bool method open ($filename) {...} #=m1
my Bool method close () {...} #=m2
=for para
Note that the Am1 method of class Aclass
stores the resulting low-level database handle
in its private Ahas attribute, while the Am2
method closes that handle.
}
This would be more robust, in that you could rearrange the components
of the block without getting the aliases mixed up. It might even be
worthwhile to make the names mandatory.
You might even allow a second parameter which could (for example) be
used to engage in introspection of the attached thing, thus allowing
you to alias aspects of it other than its name. But I'd consider this
to be part of the Pod extensibility, rather than a core feature. An
example:
my Bool method open ($filename) {...} #=m1
#=m1-type Type
=para Am1 is a Am1-type.
Result:
Copen is a Cmethod.
--
An unrelated possibility would be to allow empty A tags in a
declarator block, with 'A' being replaced with the name of the
declarator to which the block is attached:
class Database::Handle { #=[the A class handles a database.]
has IO $!handle; #=[the A attribute identifies the database
to be handled.]
my Bool method open ($filename) {...} #=[the A method opens
the database.]
}
This would attach the CDatabase::Handle class handles the
database. to class Database::Handle, the C$!handle attribute
identifies the database to be handled. to $!handle, and the Copen
method opens the database. to method open.
--
Jonathan Dataweaver Lang
Re: Synopsis 02: Range objects
Michael Zedeler wrote: The obvious (default) choice for a step size would be the precision of the more precise of the two values. So 0.0001 in your example above. Well... maybe. How do you specify the intended precision, then? If I want the values from 1 to 2 with step size 0.01, I guess that writing 1.00 .. 2.00 won't be sufficient. Trying to work out the step size by looking at the precision of things that are double or floats doesn't really sound so feasible, since there are a lot of holes in the actual representation, so 1.0001 may become 1.0, yielding very different results. It could be really nice to come up with something dwimmy, but I can't really se any really good candidates, when it comes to floating point numbers and strings. For floating point numbers, assume a default step size of 1, just like integers; use the :by adverb to specify a different step size, either by supplying a floating point number to be added in or by supplying a block that generates the next step when fed the current one. So: 1.00 .. 2.00 # 1.00, 2.00 1.00 .. 2.00 :by .01 # 1.00, 1.01, 1.02, ..., 1.98, 1.99, 2.00 Also, I want to second David Green's point: we're not talking Range and Interval here; we're talking Range and Series. A Series would be a kind of Range that has the additional ability of generating a list. The :by adverb would be a property of a Series, but not a Range. Using Num for your endpoints would result in a Series; using Complex for your endpoints should result in an error: Complex numbers don't have a viable definition of before or after, let alone between. -- Jonathan Dataweaver Lang
Re: Synopsis 02: Range objects
On Tue, Aug 25, 2009 at 5:58 PM, Jon Langdatawea...@gmail.com wrote: Also, I want to second David Green's point: we're not talking Range and Interval here; we're talking Range and Series. But a series refers to a more general concept than a discrete range. I still think Range and Interval fit better. using Complex for your endpoints should result in an error: Complex numbers don't have a viable definition of before or after, let alone between. Slight overstatement, IMO. Sure, complex numbers don't form an ordered field: given three numbers, z0, z1, and z2, you can't ask if z0 z1 or z0 z2, at least not without imposing some artificial ordering rule. Even without defining an ordering, though, you can meaningfully ask whether z0 lies within or outside the rectangle formed by z1 and z2, which is a viable (if nonlinear) definition of between. You can only get a Boolean answer, but it's a valid question. That's just nitpicking, though. It's perfectly reasonable to fail() if someone tries to construct a Range/Series/Interval out of Complex numbers. We can use a different class for complex rectangles if we need them. -- Mark J. Reed markjr...@gmail.com
Re: Synopsis 02: Range objects
Mark J. Reed wrote: On Tue, Aug 25, 2009 at 5:58 PM, Jon Langdatawea...@gmail.com wrote: Also, I want to second David Green's point: we're not talking Range and Interval here; we're talking Range and Series. But a series refers to a more general concept than a discrete range. I still think Range and Interval fit better. IME, range and interval are largely interchangeable terms. The only time that they aren't is when range is used in contrast to domain; and even there, it still doesn't refer to a list of discrete values. That's generally referred to as a sequence; unfortunately, that's a term that Perl has already co-opted. using Complex for your endpoints should result in an error: Complex numbers don't have a viable definition of before or after, let alone between. Slight overstatement, IMO. Sure, complex numbers don't form an ordered field: given three numbers, z0, z1, and z2, you can't ask if z0 z1 or z0 z2, at least not without imposing some artificial ordering rule. Even without defining an ordering, though, you can meaningfully ask whether z0 lies within or outside the rectangle formed by z1 and z2, which is a viable (if nonlinear) definition of between. You can only get a Boolean answer, but it's a valid question. It's also every bit as artificial as the ordering rules that can be imposed. It would be just as valid to ask whether z0 lies on the line segment that runs between z1 and z2, or within the smallest circle that includes z1 and z2. And if you _do_ establish an artificial ordering rule, it's also perfectly valid to ask if z0 is after z1 and before z2 (or vice versa, if z2 is before z1). That's just nitpicking, though. It's perfectly reasonable to fail() if someone tries to construct a Range/Series/Interval out of Complex numbers. We can use a different class for complex rectangles if we need them. Agreed. -- Jonathan Dataweaver Lang
Re: Synopsis 02: Range objects
On Tue, Aug 25, 2009 at 02:58:05PM -0700, Jon Lang wrote:
: Michael Zedeler wrote:
: The obvious (default) choice for a step size would be the precision of
: the more precise of the two values. So 0.0001 in your example above.
:
:
: Well... maybe. How do you specify the intended precision, then? If I want
: the values from 1 to 2 with step size 0.01, I guess that writing
:
: 1.00 .. 2.00
:
: won't be sufficient. Trying to work out the step size by looking at the
: precision of things that are double or floats doesn't really sound so
: feasible, since there are a lot of holes in the actual representation, so
: 1.0001 may become 1.0, yielding very different results.
:
: It could be really nice to come up with something dwimmy, but I can't really
: se any really good candidates, when it comes to floating point numbers and
: strings.
:
: For floating point numbers, assume a default step size of 1, just like
: integers; use the :by adverb to specify a different step size, either
: by supplying a floating point number to be added in or by supplying a
: block that generates the next step when fed the current one. So:
:
: 1.00 .. 2.00 # 1.00, 2.00
: 1.00 .. 2.00 :by .01 # 1.00, 1.01, 1.02, ..., 1.98, 1.99, 2.00
Note that your :by adverb is malformed; it must be :by(.01), or it's
parsed as a boolean :by followed by a term.
Another note, it's likely that numeric literals such as 1.23 will turn
into Rats rather than Nums, at least up to some precision that is
pragmatically determined.
: Also, I want to second David Green's point: we're not talking Range
: and Interval here; we're talking Range and Series. A Series
: would be a kind of Range that has the additional ability of generating
: a list. The :by adverb would be a property of a Series, but not a
: Range. Using Num for your endpoints would result in a Series; using
: Complex for your endpoints should result in an error: Complex numbers
: don't have a viable definition of before or after, let alone
: between.
We already make this distinction in the spec. A Range means an
interval, possibly annotated with a step, but this is meaningless
unless the range is iterated. An attempt to use such a Range in a
list produces a RangeIterator, which yields a series of values.
However, the name series operator is already reserved to mean
infix:... rather than infix:... So your second example above
basically turns into this series:
1.00 ... { $_ + 0.01 if $_ 2.00 };
except that 1.00 .. 0.00 produces (), not 1.00. A more exact
translation might be
() ... - $x = (1.00-0.01) { $x + 0.01 if $x 2.00 };
I am currently assuming such loops will default to Rat rather than
Num for numbers that aren't too far off the beaten path, where
on the beaten track is defined as rats that fit into a pair of
int64s or so, that is, which can be represented with rat64.
Larry
