Re: unusual invocants
Quoth tho...@sandlass.de ("TSa (Thomas =?utf-8?q?Sandla=C3=9F?=)"):
>
> Here is a direct syntax for the freeze feature of the paper:
>
> class C does T1 does T2
> {
> freeze T1::x for foo;
> freeze T2::x for bar;
> method x {...} # for all other methods
> }
>
> The implementation is strait forward: on entry to foo and bar
> the dispatch table of the invocant is temporarily patched to
> contain the right x. After the call the original is restored.
Isn't this just sugar for something like
class C does T1 does T2
{
method foo {
my $tmp = self but role {
method x { return self.T1::x }
};
return $tmp.foo;
}
method x { ... }
}
(Excuse me if I have any syntactic details wrong.)
The most important detail here is that the *class* gets to pick which
imported methods need to be wrapped. Most of the time you want a method
x in the class to be called from a method foo in the role: that's the
point.
What this doesn't fix is that some other code (outside the class) will
be expecting C::x to have T1::x semantics, and some will be expecting it
to have T2::x semantics. If these are contradictory, there is no way to
write an x which works. That's where the 'hats' idea comes in, so you
could write something like
class C does T1 does T2
{
method T1::x { ... }
method T2::x { ... }
}
and have callers that thought they were getting a T1 call the
appropriate override. However, there's still a problem with callers that
know they have a C: which method do they get?
AFAICS the only real solution to this is something like COM, where you
say 'I would like to talk to this object as though it were a T1 now'.
Might it be possible to use the type system to make this less painful
than it usually is?
Ben
[perl #69955] [PATCH] Add mkdir() builtin
# New Ticket Created by Geoffrey Broadwell
# Please include the string: [perl #69955]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=69955 >
The attached patch adds an implementation (and POD) for a mkdir()
builtin. (And also removes trailing whitespace from a blank line in the
function above.)
-'f
diff --git a/src/builtins/io.pir b/src/builtins/io.pir
index b816877..69cdf88 100644
--- a/src/builtins/io.pir
+++ b/src/builtins/io.pir
@@ -162,7 +162,7 @@ true value is returned.
push_eh failure
os.'chdir'(newdir)
pop_eh
-
+
# Update $*CWD and we're done.
$S0 = os."cwd"()
$P0 = box $S0
@@ -175,6 +175,47 @@ true value is returned.
.tailcall '!FAIL'('Unable to change to directory "', newdir, '"')
.end
+
+=item mkdir STRING [, MODE]
+
+Creates a new directory, optionally setting specific permissions (which
+are modified by the user's umask). If omitted, the permissions default
+to 0o777 (full access to all).
+
+ mkdir '/new/dir';
+ mkdir '/new/dir', 0o755;
+
+On success a true value is returned.
+
+=cut
+
+.sub 'mkdir'
+.param string newdir
+.param intmode :optional
+.param inthas_mode :opt_flag
+
+# Default mode to 0o777
+if has_mode goto have_mode
+mode = 0o777
+ have_mode:
+
+# Try to create the directory; if we fail, exception thrown, so catch
+# it and fail if needed.
+.local pmc os
+os = root_new ['parrot';'OS']
+push_eh failure
+os.'mkdir'(newdir, mode)
+pop_eh
+
+# Success, we're done.
+$P0 = get_hll_global ['Bool'], 'True'
+.return ($P0)
+
+ failure:
+pop_eh
+.tailcall '!FAIL'('Unable to create directory "', newdir, '"')
+.end
+
=back
=cut
[perl #69959] [BUG] Rakudo regression in t/spec/S02-lexical-conventions/unicode.t
# New Ticket Created by "Kyle Hasselbacher" # Please include the string: [perl #69959] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=69959 > The first test labeled "Unicode named params (1)" in t/spec/S02-lexical-conventions/unicode.t is failing. I did a git bisect, which said the first bad commit could be any one of these: 8ef8369afc8814e27f7ecde61ac9ecec864e4e50 b2e07427b56d8d55afb76d4f18b206dce35b1539 dc9e98e08d7ed8f22bcf230fbe9ec18b2d4748ba ca65997219c535c5853c781ea66332d82319c16c These were all commit points that I couldn't test because they didn't build on my system. My test for a particular commit was to do this: git clean -xdf ; perl Configure.pl --gen-parrot ; nice make -j 3 ; make testable ; make t/spec/S02-lexical-conventions/unicode.t
r28880 - docs/Perl6/Spec
Author: lwall
Date: 2009-10-22 17:31:38 +0200 (Thu, 22 Oct 2009)
New Revision: 28880
Modified:
docs/Perl6/Spec/S02-bits.pod
Log:
[S02] refine global linkage policies
Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2009-10-22 11:00:55 UTC (rev 28879)
+++ docs/Perl6/Spec/S02-bits.pod2009-10-22 15:31:38 UTC (rev 28880)
@@ -13,8 +13,8 @@
Created: 10 Aug 2004
-Last Modified: 8 Oct 2009
-Version: 183
+Last Modified: 22 Oct 2009
+Version: 184
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -2067,16 +2067,43 @@
All Perl code can see C anyway as the outermost lexical scope,
so there's no need to also put such things into C.
-The C package itself is rooted at C.
-The C package is rooted at C. You will note
-that C is not the parent of C. However, searching
+The C package itself is accessible via C.
+The C package is accessible via C.
+The C package is not the parent of C. However, searching
up the dynamic stack for context variables will look in all nested
dynamic scopes (mapped automatically to each call's lexical scope,
-not package scope) out to C; once all the dynamic scopes are
+not package scope) out to the main dynamic scope; once all the dynamic scopes
are
exhausted, it also looks in the C package and then in the
C package, so C<$*OUT> typically finds the process's standard
-output handle.
+output handle. Hence, C and C serve as extra outer
+dynamic scopes, much like C and C function as extra outer
+lexical scopes.
+Extra C scopes keep their identity and their nesting within C,
+so you may have to go to C several times from C before you get
+to C. Normally, however, there is only the core setting, in which
+case C ends up meaning the same as C which is the same
+as C.
+
+Extra C scopes are treated differently. Every compilation unit has
+its own associated C package. As the currently compiling
+compilation unit expresses the need for various other compilation units,
+the global names known to those other units must be merged into the new
+unit's C. (This includes the names in all the packages
+within the global package.) If two different units use the same global
+name, they must generally be taken to refer to the same item, but only if
+the type signatures can be meshed (and augmentation rules followed, in the
+case of package names). If two units provide package names with
+incompatible type signatures, the compilation of the unit fails. In other
+words, you may not use incompatible global types to provide a union type.
+However, if one or the other unit underspecifies the type in a compatible
+way, the underspecified type just takes on the extra type information as it
+learns it. (Presumably some combination of Liskov substitution, duck-typing,
+and run-time checking will prevent tragedy in the unit that was compiled with
+the underspecified type. Alternately, the compiler is allowed to recompile or
+re-examine the unit with the new type constraints to see if any issues are
+certain to arise at run time, in which case the compiler is free to complain.)
+
Any context variable declared with C in the user's main program
(specifically, the part compiled with C as the current package)
is accessible (by virtue of being in C) as a context variable
@@ -2084,8 +2111,14 @@
vars do *not* look in C for anything. (They I look in
C if you're running under a setting distinct from C,
if that setting defines a dynamic scope outside your main program,
-such as for the C<-n> or C<-p> switch.)
+such as for the C<-n> or C<-p> switch.) Context variables declared
+with C in the C or C packages do not need to
+use the C<*> twigil, since the twigil is stripped before searching
+those packages. Hence, your environment variables are effectively
+declared without the sigil:
+augment package GLOBAL { our %ENV; }
+
=item *
You may interpolate a string into a package or variable name using
r28881 - docs/Perl6/Spec
Author: lwall Date: 2009-10-22 17:55:21 +0200 (Thu, 22 Oct 2009) New Revision: 28881 Modified: docs/Perl6/Spec/S02-bits.pod Log: [S02] document desire to have decimal literals biased toward Rat storage Modified: docs/Perl6/Spec/S02-bits.pod === --- docs/Perl6/Spec/S02-bits.pod2009-10-22 15:31:38 UTC (rev 28880) +++ docs/Perl6/Spec/S02-bits.pod2009-10-22 15:55:21 UTC (rev 28881) @@ -14,7 +14,7 @@ Created: 10 Aug 2004 Last Modified: 22 Oct 2009 -Version: 184 +Version: 185 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -2694,6 +2694,12 @@ ((1 / 2) * 3) / 4 +Decimal fractions not using "e" notation are also stored as C values: + +6.02e23.WHAT # Num +1.23456.WHAT # Rat +1.1 == 11/100# True + =item * Complex literals are similarly indicated by writing an addition of
Rakudo Perl 6 development release #22 ("Thousand Oaks")
Announce: Rakudo Perl 6 development release #22 ("Thousand Oaks")
On behalf of the Rakudo development team, I'm pleased to announce the
October 2009 development release of Rakudo Perl #22 "Thousand Oaks".
Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine
(see http://www.parrot.org). The tarball for the October 2009 release
is available from http://github.com/rakudo/rakudo/downloads
Due to the continued rapid pace of Rakudo development and the frequent
addition of new Perl 6 features and bugfixes, we recommend building Rakudo
from the latest source, available from the main repository at github.
More details are available at http://rakudo.org/how-to-get-rakudo.
Rakudo Perl follows a monthly release cycle, with each release code
named after a Perl Mongers group. The October 2009 is code named
"Thousand Oaks" for their amazing Perl 6 hackathon, their report at
http://www.lowlevelmanager.com/2009/09/perl-6-hackathon.html, and
just because I like the name :-)
Since the 2009-08 release, Rakudo Perl builds from an installed Parrot
instead of using Parrot's build tree. This means that, unlike previous
versions of Rakudo Perl, the "perl6" (or "perl6.exe") executables only
work when invoked from the Rakudo root directory until a "make install"
is performed. Running "make install" will install Rakudo and its
libraries into the Parrot installation that was used to build it, and
then the executables will work when invoked from any directory.
This release of Rakudo requires Parrot 1.7.0.
For the latest information on building and using Rakudo Perl, see the
readme file section titled "Building and invoking Rakudo". (Quick note:
the "--gen-parrot" option still automatically downloads and builds
Parrot as before, if you prefer that approach.)
Some of the specific changes and improvements occuring with this
release include:
* Rakudo is now passing 32,582 spectests, an increase of 17,085 passing
tests since the September 2009 release. With this release Rakudo is
now passing 85.0% of the available spectest suite.
* We have a huge increase in the number of spectests relating to the
Complex and Rat numeric types.
* Complex numbers are now implemented as a Perl 6 class, and supports all
trigonometric functions from the specification.
* Rakudo has a new signature binder which makes calling routines
and operators much faster, and allows binding of positional
arguments by name.
* Rakudo has improved signature introspection, better errors relating to
signatures and signature literals are now supported.
* Rakudo now supports accessing outer lexical variables from classes and
packages.
* Some new variants of the series operator are now implemented.
* When configuring Rakudo with --gen-parrot, the --optimize flag is now
passed to Parrot's Configure.pl
The development team thanks all of our contributors and sponsors for
making Rakudo Perl possible. If you would like to contribute,
see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org
mailing list, or ask on IRC #perl6 on freenode.
The next release of Rakudo (#23) is scheduled for November 19, 2009.
A list of the other planned release dates and codenames for 2009 is
available in the "docs/release_guide.pod" file. In general, Rakudo
development releases are scheduled to occur two days after each
Parrot monthly release. Parrot releases the third Tuesday of each month.
Have fun!
-Scott
--
Jonathan Scott Duff
perlpi...@gmail.com
r28882 - docs/Perl6/Spec
Author: lwall Date: 2009-10-22 18:21:29 +0200 (Thu, 22 Oct 2009) New Revision: 28882 Modified: docs/Perl6/Spec/S02-bits.pod Log: [S02] tweak Rat to max out at rat64 by default Modified: docs/Perl6/Spec/S02-bits.pod === --- docs/Perl6/Spec/S02-bits.pod2009-10-22 15:55:21 UTC (rev 28881) +++ docs/Perl6/Spec/S02-bits.pod2009-10-22 16:21:29 UTC (rev 28882) @@ -672,6 +672,15 @@ Numeric values in untyped variables use C and C semantics rather than C and C. +However, for pragmatic reasons, C values are guaranteed to be +exact only up to a certain point. By default, this is the precision +that would be represented by a C type, that is, with a numerator +and denominator consisting of C values. Cs that would require +more than 64 bits of storage in either numerator or denominator are +automatically converted to Cs. (If rationals are defined by a +role, it may be possible to instantiate a C type with a different +maximum precision.) + =item * Perl 6 should by default make standard IEEE floating point concepts
Re: unusual invocants
HaloO,
Ben Morrow wrote:
Isn't this just sugar for something like
Yes it is. My intent was to lighten the burden. I think we can agree
that Ovid's problem can be solved by means of the current spec and
some support syntax could be easily added.
What this doesn't fix is that some other code (outside the class) will
be expecting C::x to have T1::x semantics, and some will be expecting it
to have T2::x semantics. If these are contradictory, there is no way to
write an x which works. That's where the 'hats' idea comes in, so you
could write something like
class C does T1 does T2
{
method T1::x { ... }
method T2::x { ... }
}
and have callers that thought they were getting a T1 call the
appropriate override. However, there's still a problem with callers that
know they have a C: which method do they get?
I have the following proposal to integrate the problem with the type
system. We simply say that roles have an invocant slot in their
type signature that is filled by the class they are composed into.
That is 'class C does R' creates the type R[C:] which is distinct
from R[A:] for 'class A does R'. These two are of course applicable
where plain R is expected because this means R[Object:] and we have
covariance in the invocant parameter.
As a limiting case the role has type R[R:] that is an empty anonymous
class with only the role composed. This can of course not be
instanciated. Using that as a constraint e.g. in a signature or a
container means that neither R[A:] nor R[C:] are applicable. However
they can implement coercion routines C::R and A::R that convert the
object and these are invoked when needed. So an extreme class might
provide coercion routines to all its roles without loosing the identity
of the object. And perhaps these might be generated automatically for
easy cases.
Consider the cartesian versus polar complex number example. Here one
provides a role Complex and two classes Cartesian and Polar that do
that role and implement conversion routines to each other. Then some
optimized multi subs might be written that require Complex[Polar:] and
Complex[Cartesian:]. Others just use Complex and are happy with both
representations.
AFAICS the only real solution to this is something like COM, where you
say 'I would like to talk to this object as though it were a T1 now'.
Might it be possible to use the type system to make this less painful
than it usually is?
The invocant slot of the role signature is sort of implied in the spec
already! I also like this because a type in Perl 6 is then always
written as SomeRole[SomeClass:]. Classes without explicit roles are
Any[SomeClass:] and untyped is Any[Object:]. Note that a class C doing
multiple roles spawns several types R1[C:], R2[C:], etc and the class
name is a short form of their juxtaposition.
So a typical CPAN module might provide a role together with classes
that implement it in different ways and the users can nicely choose
between them and add their own implementations. Users and such split
modules can then use the roles and classes as bases for their own
development.
Note that this also allows more specific signatures like
foo( Order[::T:] $x, Order[T:] $y ) which guarantees comparability of
$x and $y without relying on mixed case MMD. Also we might have
explicit specializations Order[Real:] that provides <, <=, > and
>= in addition to before and after. Likewise for Order[Str:] which
is of course not applicable to Order[Real:] without coercion of
Str to Num which does Real.
The default Rat is then just Rat[rat64:] for example. And the
instanciating class might also be defaulted lexically. Essentially
all types are then denominated in this form which uniquely identifies
a role/class combination by means of the colon in brackets after the
name.
Regards TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: r28881 - docs/Perl6/Spec
pugs-comm...@feather.perl6.nl writes: > +1.1 == 11/100# True New math? :) Eirik -- O misbegotten pile of festering aardvark's fewmets! O vile unwashed ill-doer! I blast you with the curse of the mad witch of Wickham! May every boychild born to you , and to your sons, and to your sons' sons, even unto the Seventh Generation, be born male! (well I told you she was mad!).
r28883 - docs/Perl6/Spec
Author: moritz Date: 2009-10-22 19:34:58 +0200 (Thu, 22 Oct 2009) New Revision: 28883 Modified: docs/Perl6/Spec/S02-bits.pod Log: [S02] use old school math, Eirik++ Modified: docs/Perl6/Spec/S02-bits.pod === --- docs/Perl6/Spec/S02-bits.pod2009-10-22 16:21:29 UTC (rev 28882) +++ docs/Perl6/Spec/S02-bits.pod2009-10-22 17:34:58 UTC (rev 28883) @@ -2707,7 +2707,7 @@ 6.02e23.WHAT # Num 1.23456.WHAT # Rat -1.1 == 11/100# True +0.11 == 11/100 # True =item *
role invocant slot in type sig (was: unusual invocants)
HaloO,
On Thursday, 22. October 2009 18:31:16 I wrote:
> The invocant slot of the role signature is sort of implied in the spec
> already! I also like this because a type in Perl 6 is then always
> written as SomeRole[SomeClass:]. Classes without explicit roles are
> Any[SomeClass:] and untyped is Any[Object:]. Note that a class C doing
> multiple roles spawns several types R1[C:], R2[C:], etc and the class
> name is a short form of their juxtaposition.
Here is an improvement of the concept that also allows to settle the
Dogwood case in the Dogwood class. The change is that plain Foo does
not mean Foo[Object:] but denotes the F-bound fixpoint type Foo[Foo:].
A class Bar doing Foo still creates the type Foo[Bar:] but also enters
the subclass relation between Bar and Foo so that Foo[Bar:] <: Foo[Foo:]
makes Bar instances applicable where Foo is required.
The class Dogwood however might be written as
class Dogwood does Dog[Dogwood:] does Wood[Dogwood:]
{
method Dog {...}
method Wood {...}
method bark {...}
}
where the explicit invocant type prevents the creation of the
subclass relations between Dogwood and Dog and Wood. So in an
environment which requests plain Dog a Dogwood instance is only
applicable after the call of the coercion routine which could
setup things so that Dog::bark is dispatched to. Environments
that want Dogwood::bark need to explicitly coerce Dogwood instances
to Dog[Dogwood:] which actually is a no-op. But then other non-Dogwood
Dog doers are excluded unless they have a Dogwood coercion routine.
Or they use the Dogwood class directly.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
[perl #69967] tests available
This is an automatically generated mail to inform you that tests are now
available in t/spec/S04-declarations/constant.t
commit 4384f9e3c5d22e1bbdf564c98773a2b1538e23eb
Author: moritz
Date: Thu Oct 22 19:48:21 2009 +
[t/spec] tests for RT #69967, constant declarations and classes
git-svn-id: http://svn.pugscode.org/p...@28884
c213334d-75ef-0310-aa23-eaa082d1ae64
diff --git a/t/spec/S04-declarations/constant.t
b/t/spec/S04-declarations/constant.t
index b207465..e7aa000 100644
--- a/t/spec/S04-declarations/constant.t
+++ b/t/spec/S04-declarations/constant.t
@@ -246,6 +246,21 @@ plan *;
'assign constant its own value from expression';
}
+#?rakudo skip 'RT 69967'
+{
+constant C = 6;
+class A {
+constant B = 5;
+has $.x = B;
+has $.y = A::B;
+has $.z = C;
+}
+
+is A.new.x, 5, 'Can declare and use a constant in a class';
+is A.new.y, 5, 'Can declare and use a constant with FQN in a class';
+is A.new.z, 6, 'Can use outer constants in a class';
+}
+
done_testing;
# vim: ft=perl6
[perl #69893] tests available
This is an automatically generated mail to inform you that tests are now
available in t/spec/S14-traits/routines.t
commit fc49b0b54fe7d1a6e4f342c54dfac79dc9a25736
Author: moritz
Date: Thu Oct 22 19:59:04 2009 +
[t/spec] Tests for RT #69893, wrapping subroutines in traits
git-svn-id: http://svn.pugscode.org/p...@28885
c213334d-75ef-0310-aa23-eaa082d1ae64
diff --git a/t/spec/S14-traits/routines.t b/t/spec/S14-traits/routines.t
index d7e4691..a43c77f 100644
--- a/t/spec/S14-traits/routines.t
+++ b/t/spec/S14-traits/routines.t
@@ -1,7 +1,7 @@
use v6;
use Test;
-plan 8;
+plan *;
# L
@@ -38,4 +38,20 @@ is &cheezburger.description, 'tasty', 'named trait handler
applied other role s
is lolcat(), "undescribable", 'can call sub that has had a trait applied to it
by named param without arg';
is &lolcat.description, 'missing description!', 'named trait handler applied
other role without argument';
+#?rakudo skip 'RT 69893'
+{
+my $recorder = '';
+role woowoo { }
+multi trait_mod:(Routine $c, woowoo) {
+$c.wrap: sub {
+$recorder ~= 'wrap';
+}
+}
+sub foo is woowoo { };
+lives_ok &foo, 'Can call subroutine that was wrapped by a trait';
+is $recorder, 'wrap', 'and the wrapper has been called once';
+}
+
+done_testing();
+
# vim: ft=perl6
r28886 - docs/Perl6/Spec
Author: moritz Date: 2009-10-22 23:41:42 +0200 (Thu, 22 Oct 2009) New Revision: 28886 Modified: docs/Perl6/Spec/S05-regex.pod Log: [S05] allow multiple aliases as per IRC consesus Modified: docs/Perl6/Spec/S05-regex.pod === --- docs/Perl6/Spec/S05-regex.pod 2009-10-22 19:59:04 UTC (rev 28885) +++ docs/Perl6/Spec/S05-regex.pod 2009-10-22 21:41:42 UTC (rev 28886) @@ -1163,6 +1163,14 @@ $ = +Multiple aliases are allowed, so + + + +is short for + +$ = $ = + If the first character after the identifier is whitespace, the subsequent text (following any whitespace) is passed as a regex, so:
Int/Rat max precision (was Re: r28882 - docs/Perl6/Spec)
pugs-comm...@feather.perl6.nl wrote: Author: lwall Date: 2009-10-22 18:21:29 +0200 (Thu, 22 Oct 2009) New Revision: 28882 Modified: docs/Perl6/Spec/S02-bits.pod Log: [S02] tweak Rat to max out at rat64 by default Modified: docs/Perl6/Spec/S02-bits.pod === --- docs/Perl6/Spec/S02-bits.pod2009-10-22 15:55:21 UTC (rev 28881) +++ docs/Perl6/Spec/S02-bits.pod2009-10-22 16:21:29 UTC (rev 28882) @@ -672,6 +672,15 @@ Numeric values in untyped variables use C and C semantics rather than C and C. +However, for pragmatic reasons, C values are guaranteed to be +exact only up to a certain point. By default, this is the precision +that would be represented by a C type, that is, with a numerator +and denominator consisting of C values. Cs that would require +more than 64 bits of storage in either numerator or denominator are +automatically converted to Cs. (If rationals are defined by a +role, it may be possible to instantiate a C type with a different +maximum precision.) + =item * Perl 6 should by default make standard IEEE floating point concepts What is the simplest way then to ensure all your Rat math is unlimited precision by default, same as your Int math? I would expect those 2 types to be consistent with each other in that way. Or are Int values now also guaranteed to be exact only up to int64, and then automatically change to Num? Now I can understand why you might make that change to Rat's default behaviour, expecially if users are getting a Rat by default simply for writing their numbers in a certain format like 3/4 or 1.3 and they may have actually wanted inexact semantics. Thinking further, my interpretation of what you said above is that the Rational role is now basically saying that a number is represented in terms of numerator/denominator and that certain operators are supported, but now it is sounding like the details of whether the operators will produce Rational results or Num results is now determinable on a per-class basis, so we may end up working with types like "Rat32", "Rat64", "BigRat" (just this one being unlimited precision), etc after all. Is that where you're going with this? Presumably then with the Integer role we'll also have types like "Int32", "Int64", "BigInt" that do the role and also convert to a Num when their bounds are exceeded? Does that sound about right? If it is, then I propose the following: 1. Have some classes like the above, eg Rat32+BigRat+Int32+BigInt etc pre-defined portably in the language spec, and make it so that plain "Int" and "Rat" are simply declared as installation-specific aliases for one of those more specific-named types. These alias definitions are defined in the setting or something and would be defined to match the largest values that either can be efficiently handled on the particular platform or are likely to be needed by the users with exact precision. 2. And then, people who want to be guaranteed that specific numeric semantics are portable across all Perl 6 implementations, with a possible hit in performance, would explicitly use say Rat64 or BigRat etc in their code, and those for whom the precise semantics don't need to be portable, can just use plain "Rat", and know they'll get the best that the implementation thinks it can deliver with good efficiency. 3. As a middle-ground, still do #1 but also let users redefine what "Int" and "Rat" alias on a per-program basis, so they can still choose the 64 or Big etc option explicitly for portable behavior, but they only have to write the plain "Rat" etc in all their code. What do you think about that? Note that names can change, but I think being able to do what I stated would go further to let more users have what they want than under-serving a large number in favor of another large number. -- Darren Duncan
[perl #69610] tests available
This is an automatically generated mail to inform you that tests are now
available in t/spec/integration/return-from-method-in-hash.t
commit 456b11e2d2a338ad59b61069680da1350ca32d91
Author: kyle
Date: Fri Oct 23 03:36:49 2009 +
[t/spec/integration] Test for RT #69610
git-svn-id: http://svn.pugscode.org/p...@28889
c213334d-75ef-0310-aa23-eaa082d1ae64
diff --git a/t/spec/integration/return-from-method-in-hash.t
b/t/spec/integration/return-from-method-in-hash.t
new file mode 100644
index 000..55e20ce
--- /dev/null
+++ b/t/spec/integration/return-from-method-in-hash.t
@@ -0,0 +1,18 @@
+use v6;
+use Test;
+plan *;
+
+# RT #69610
+
+class RT69610 {
+method rt69610() {
+return self;
+}
+}
+
+ok( { "foo" => &RT69610::rt69610 }.( RT69610.new ) ~~ RT69610,
+"Can return from method called from a hash lookup (RT 69610)" );
+
+done_testing;
+
+# vim: ft=perl6
