This Week In Perl 6 (7 - 13 Oct 2001)
You can subscribe to an email version of this summary by sending an empty message to firstname.lastname@example.org.
Please send corrections and additions to email@example.com.
There were 419 messages across 92 threads, with 74 authors contributing.
(61 posts) Tim Conrow
pointed out an inconsistency between Perl 6's proposed semantics of
NaN and the IEEE semantics found in other languages. (The subsequent debate
consisted mostly of each side trying to convince the other how Wrong it
The non-identity of
NaN makes sense in strongly type languages where a numerical entity can only
hold a number. There, the IEEE and mathematical notion of
NaN isn't so much that it isn't a number, but that it
is a number that just can't be represented. (As an integer, floating point
number, or +- infinity.) In this context, there's an infinitely small
probability that some non-representable number is numerically equivalent to
some other non-representable number, so the non-identity makes sense.
However, for languages (such as Perl) where numerics aren't a strongly-typed
unique entity, you've really two
NaN properties to consider.
You've got, as above, two
Nans-That-Really-Are-Numbers-But-Can't-Be-Represented-As-Such, but then you've
NaNs that aren't numbers because they simply aren't numbers.
In the latter case, it's less of the mathematical notion of
NaN, with its associated non-identity, than with non-numeric strings having
a generic notion of
NaN. (That's "Not A Number", as in, "That's Not a Number, It's a String.")
Given that notion, is makes sense for
NaNs to have an identity. Two non-numeric strings are equally Not A Number.
The confusion, as you can see, is how to merge these two rather orthogonal definitions of What is Not a Number into one language, and discussion continues.
(14 posts) A spin-off of the above thread mused about extending some of Perl's numerical string recognition capabilities (such as 1_000_000 for one million) inside strings themselves, and perhaps extending them to handle standard metric suffixes. Several syntaxes and ramifications were discussed, and a couple apparently clean solutions proposed.
(18 posts) John Williams
asked whether the hyperoperator (
^ ) would handle reduction:
I just read Apocalypse and Exegesis 3, and something stuck out at me because of its omission, namely using hyper operators for reduction.
$a ^+= @list; # should sum the elements of @list
Larry says @a ^+ 1 will replicate the scalar value for all a's, and Damian talks about doing summation with the reduce function without mentioning this compact syntax.
So am I overlooking some obvious reason why this won't work?
Damian Conway replied that no, it should indeed work, but would require
the lvalue to force reduction, which
reduce does not. (Without the lvalue, the scalar value would be extended to match
(16 posts) Dan Sugalski gave a quick rundown on Parrot Magic Cookies (PMCs) and how they work.
(18 posts) There was
some debate about
branch, and what each instruction is supposed to accomplish. Dan Sugalski:
Absolute addresses are, well, absolute addresses. Relative addresses are offsets from the current location.
I think the confusion's because the jump opcode's broken. When you say
It should jump to absolute address 12, not 12 bytes/words/opcodes from the current position.
Subsequent discussion attempted to discern which absolute address - the
absolute "virtual" address, similar to what the
branch operator uses, or the real machine address of an operator. The current
inclinations are for the latter, as that allows Parrot to jump between
- Tom Hughes added string transcoding and string comparisons.
- Dan Sugalski provided support for simple subroutines.
- Gregor Purdy committed a large cleanup to the op build architecture.
Work on Parrot 0.0.3 continues.
Bryan C. Warnock