Complex planes
Today bacek++ implement complex logarithms in rakudo, and one of the tests failed because it assumed the result to be on a different complex plane. (log(-1i) returned 0- 1.5708i, while 0 + 3/2*1i was expected). Should we standardize on one complex plane (for example -pi = $c.angle pi like Complex.angle does)? Or simply fix the test to be agnostic to complex planes? Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Parrot 0.6.4
Hi, on behalf of the Parrot team, I'm proud to announce the release of Parrot 0.6.4 St. Vincent Amazon. Parrot 0.6.4 is available via CPAN, or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 0.6.4 News: - Documentation + removed a lot of old information from the FAQ + improved function level documentation - Configuration + removed the configuration item 'has_gnu_m4' + refactored ICU-detection - Languages + ChitChat - improved the Smalltalk implementation + Pipp - renamed Plumhead to Pipp - support for a lot of builtin functions. - Pipp now uses PHP specific data types. - converted from PCT with TGE to PCT with NQP actions - improvements in the PCT variant by using optok parsing - start of object support + pir - simple assignments work + json - added a PCT-based implementation of JSON parsing + lolcode - improved handling of symbols - added support for block handling - added support for globals + Lua - more tests + Rakudo - updated Range implementation - added enums - added generic type declarations (::T) - added runtime mixing of roles with 'does' and 'but' - added generic type declarations - fixed handling of implicit lexicals ($_, $!, and $/) - fixed implicit method calls on $_ - improved complex math builtins, added Complex - moved many builtins to class Any - declaration of lists of variables now work - improved test infrastructure - 910 additional passing spec tests since last release - more convergence with STD.pm grammar - added named 0-ary parsing and ops - Compilers + PCT: - allowed subroutine and method names to be a PAST tree that produces the name - Improved lexical handling - Tools + pbc_disassemble renamed from disassemble - Implementation + allowed .macro_const in PIR + added the flag :lexid(...) for subroutines + made multiple dispatch work for sub types + fixed garbage collection bug related to the metadata attached to a PMC_EXT structure + added a warning when using deprecated opcodes + simplified the stacks implementation + fixed C++ build + improved closure and lexical support + improved IMCC register allocator + added cache for all runtime-constant strings, reducing memory usage - Miscellaneous + improved OpenGL/GLU/GLUT bindings + added a standard profile for Perl::Critic coding standard testing + added support for smoke testing with Smolder + enabled use of Test::Harness 3.0 if available, but don't require it for 'make test' + added the executable 'parrot_config' to query Parrot configuration Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is August 19th 2008. Enjoy!
Re: meta_postfix:*
Jon Lang wrote: So you're suggesting that A op* n should map to [op] A xx n I don't think that that mapping works for Thomas' proposal of a repetition count on post-increment operator. I.e. $a ++* 3 is not the same as [++] $a xx 3 (which I think is a syntax error) and also not the same as $a++ * 3 Also, he's suggesting getting rid of the xx operator, and replacing it with ,* -- I'm sure I could get used to that
Re: meta_postfix:*
Dave Whipp wrote: Jon Lang wrote: So you're suggesting that A op* n should map to [op] A xx n I don't think that that mapping works for Thomas' proposal of a repetition count on post-increment operator. I.e. $a ++* 3 is not the same as [++] $a xx 3 (which I think is a syntax error) It is. Also, he's suggesting getting rid of the xx operator, and replacing it with ,* -- I'm sure I could get used to that Currently, it's being assumed that the repetition meta-operator will be appended to the operator, followed by the repetition count: $value op* $count This makes it difficult to apply the replication meta-operator to a prefix operator. However, a second option could be provided, where the meta-operator gets prepended: $count *op $value So: 5 *, $n === $n ,* 5 === $n, $n, $n, $n, $n $n ++* 5 === $n++)++)++)++)++ 5 *++ $n === ++(++(++(++(++$n And obviously the metaoperator is nonsensical when applied to a binary operator with different types of values on its left and right sides. As with other meta-operators, it should be possible to explicitly define a symbol that would otherwise be interpreted as a meta'd operator, because of efficiency; because the operator in question has capabilities above and beyond what the meta-operator would indicate; or because the operator in question doesn't bear any resemblance to the replicated use of a shorter operator. In particular, ** would be overloaded in this manner: to make reasonable sense, the count of a repetition meta-operator must be an unsigned integer of some sort, whereas exponents can be any type of number. Heck, they don't even have to be real. -- Jonathan Dataweaver Lang
