Re: Coercion of non-numerics to numbers
On Mon, Mar 05, 2007 at 09:22:59AM -0800, Dave Whipp wrote: : I was wondering about the semantics of coercion of non-numbers, so I : experimented with the interactive Pugs on feather: : : pugs> +"42" : 42.0 : pugs> +"x42" : 0.0 : : I assume that pugs is assuming "no fail" in the interactive environment. : However, Is "0.0" the correct answer, or should it be one of "undef", or : "NaN"? It should probably warn by default since warnings are supposed to be on by default in Perl 6, but if that is supressed the return value should at least be an interesting value of undef containing the warning that would have been emitted, so that the warning can be issued later if the value is actually used. : In my experiments, I also noticed: : : pugs> my Int $a = "42" : "42" : pugs> $a.WHAT : ::Str : : : It seems that the explicit type of $a is being ignored in the : assignment. Am I right to assume this is simply a bug? Well, it's just not implemented, I think. Or more accurately, still in the process of being implemented, since the pugsers are madly working on metaobjects this week. : testcase (if someone with commit bits can add it): I'm sending you a commit bit so you can add tests. It's traditional to add yourself to AUTHORS as the first checkin to make sure things work. Larry
Re: [S09] "Whatever" indices and shaped arrays
On 2/27/07, Jonathan Lang wrote:
David Green wrote:
So I end up back at one of Larry's older ideas, which basically is:
[] for counting, {} for keys.
What if you want to mix the two? "I want the third element of row
5". In my proposal, that would be "@array[5, *[2]]"; in your
proposal, there does not appear to be a way to do it.
Unless the two approaches aren't mutually exclusive: "@array{5,
*[2]}". [...] Since this is an unlikely situation, the fact that
nesting square braces inside curly braces is a bit uncomfortable
isn't a problem: this is a case of making hard things possible, not
making easy things easy.
Oh, good point. Yes, I think that mixing them together that way makes sense.
It also suggests that you could get at the named keys by applying {} to *:
%foo[0, 1, *{'bar'}]; #first column, second row, "bar" layer
The one gotcha that I see here is with the possibility of
multi-dimensional arrays. In particular, should multi-dimensional
indices be allowed inside square braces? [...] With that promise,
you can always guarantee that the wrap-around semantics will work
inside [], while nobody will expect them to work inside {}.
Right, I don't see a problem with handling any number of dimensions that way.
Furthermore, you could do away with the notion of "shaped vs.
unshaped": just give everything a default shape. The default shape
for arrays would be '[*]' - that is, one dimension with an
indeterminate number of ordinals.
Meanwhile, shapes for {} would continue to use the current syntax.
'[$x, $y, $z]' would be nearly equivalent to '{0..^$x; 0..^$y; 0..^$z}'.
Agreed.
it can work in the usual way: start at 0, end at -1. It is useful
to be able to count past the ends of an array, and * can do this by
going beyond the end: *+1, *+2, etc., or before the beginning: *-1,
*-2, etc. (This neatly preserves the notion of * as "all the
elements" -- *-1 is the position before everything, and *+1 is the
position after everything else.)
Regardless, I would prefer this notion to the "offset from the
endpoint" notion currently in use. Note, however, that [*-1]
wouldn't work in the ordinals paradigm; there simply is nothing
before the first element. About the only use I could see for it
would be to provide an assignment equivalent of "unshift":
'@array[*-1] = $x' could be equivalent to 'unshift @array, $x'. But
note that, unlike the 'push'-type assignments, this would change
what existing ordinals point to.
I figured that *-1 or *+1 would work like unshift/push, which
effectively does change what the ordinals point to (e.g. unshifting
a P5 array). If the array is not extensible, then it should fail in
the same way as unshift/push would.
Meanwhile, {*-1} would only make sense in cases where keys are
ordered and new keys can be auto-generated. Note also that {*+$x}
is compatible with {*[$x]}: the former would reference outside of
the known set of keys, while {*[$x]} would reference within them.
Exactly.
-David
[svn:perl6-synopsis] r14311 - doc/trunk/design/syn
Author: larry Date: Mon Mar 5 19:01:16 2007 New Revision: 14311 Modified: doc/trunk/design/syn/S02.pod doc/trunk/design/syn/S03.pod doc/trunk/design/syn/S06.pod Log: the change back from .give to .leave was incomplete as noted by rhr++. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podMon Mar 5 19:01:16 2007 @@ -2469,7 +2469,7 @@ would work just as well. You can exit any labeled block early by saying -MyLabel.give(@results); +MyLabel.leave(@results); =item * Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podMon Mar 5 19:01:16 2007 @@ -2025,7 +2025,7 @@ If a C<*> (see the "Whatever" type in S02) occurs on the right side of a range, it is taken to mean "positive infinity" in whatever space the range is operating. A C<*> on the left means "negative infinity" -for types that support negative values. (The sign of those infinites +for types that support negative values. (The sign of those infinities reverses for a negative step.) If the C<*> occurs on one side but not the other, the type is inferred from the other argument. A star on both sides will match any value that supports the C role. Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podMon Mar 5 19:01:16 2007 @@ -1629,7 +1629,7 @@ blocks this can be optimized away to a "goto". All C declarations have an explicit declarator such as C or C; bare blocks and "pointy" blocks are never considered to be routines in that sense. To return -from a block, use C instead--see below. +from a block, use C instead--see below. The C function preserves its argument list as a C object, and responds to the left-hand C in a binding. This allows named return @@ -1775,10 +1775,10 @@ COUNT.leave; last COUNT; -However, the first form explicitly gives the return value for the +However, the first form explicitly sets the return value for the entire loop, while the second implicitly returns all the previous successful loop iteration values as a list comprehension. (It may, -in fact, be too late to give a return value for the loop if it is +in fact, be too late to set a return value for the loop if it is being evaluated lazily!) A C from the inner loop block, however, merely specifies the return value for that iteration:
Re: resumable exceptions and LEAVE/KEEP/UNDO blocks
On Mon, Mar 05, 2007 at 09:01:13AM -0800, Larry Wall wrote: > I don't see a problem here. I think you maybe missed the bit that says: > > A C block sees the lexical scope in which it was defined, but > its caller is the dynamic location that threw the exception. That is, > the stack is not unwound until some exception handler chooses to > unwind it by "handling" the exception in question. Yes, I did. I was grepping specifically for the bit on resumable exceptions and the quoted bit is 80 lines up so I missed it completely. Thanks for pointing me at it. [...] > To resume a resumable exception the correct thing to do is very > likely nothing. The outermost warning handler is what generally > resumes otherwise uncaught resumables. If you catch a warning, > it defaults to resuming when handled unless you rethrow it as fatal. OK, that makes sense. The reason that came up was because on Friday I had a good idea for a language feature that would have made a task I had been doing that day much easier. When I checked the spec, though, I found out it was already in. This is happening increasingly often, which should be reassuring to all concerned. -- "Listen to your users, but ignore what they say." - Nathaniel Borenstein http://surreal.istic.org/ Calm down, it's only ones and zeroes. signature.asc Description: Digital signature
Re: resumable exceptions and LEAVE/KEEP/UNDO blocks
On Mon, Mar 05, 2007 at 01:06:46PM +, Daniel Hulme wrote: : What happens if a resumable exception is propagated through a block with : a LEAVE, KEEP, or UNDO block? S04 seems to be a bit vague on this point. : It strikes me that what we want it to do is not execute them when the : exception is propagated, because we don't know whether it's going to be : resumed or not. If the exception is resumed by its handler, then that's : fine, as we can call the blocks at the usual time (when the blocks they : are attached to exit). If the exception is caught and handled and not : resumed, that would leave us with having to find all the LEAVE &c. : blocks and call them in the right order when the exception handler : exits. : : In either case, it looks like you have a problem. LEAVE &c. blocks will : often be used for things like database transactions, where we want to : ensure that some lock obtained on entering the block is released : promptly regardless of how the control flow jumps about. In such a : context, throwing a resumable exception that skips the LEAVE block, : farts about doing some potentially long computation in a higher-up : scope, and only calls the LEAVE block to release the lock at some later : date, seems to be far from the best choice. Sure, we can warn : programmers to make their resumable-exception handlers short, or to only : throw non-resumable exceptions from blocks that are likely to be called : in such circumstances. I suppose that would be an acceptable resolution, : but it has an aura of non--re-entrant signal handlers about it, so it : seems like the sort of thing I would like to avoid if anyone is clever : enough to think of something else to do. I don't see a problem here. I think you maybe missed the bit that says: A C block sees the lexical scope in which it was defined, but its caller is the dynamic location that threw the exception. That is, the stack is not unwound until some exception handler chooses to unwind it by "handling" the exception in question. Exiting blocks are not run until the decision is made to unwind the stack, which is *after* the exception handlers are run. So all the exception trampoline has to do to resume is just return; the resume continuation doesn't really have to be a real continuation in this case. : BTW, if one is handling a resumable exception, how does one resume it? I : couldn't find anything explaining how. Having a .resume method (or some : cutesier name) on the Resumable role would seem to make sense. To resume a resumable exception the correct thing to do is very likely nothing. The outermost warning handler is what generally resumes otherwise uncaught resumables. If you catch a warning, it defaults to resuming when handled unless you rethrow it as fatal. Larry
Coercion of non-numerics to numbers
I was wondering about the semantics of coercion of non-numbers, so I
experimented with the interactive Pugs on feather:
pugs> +"42"
42.0
pugs> +"x42"
0.0
I assume that pugs is assuming "no fail" in the interactive environment.
However, Is "0.0" the correct answer, or should it be one of "undef", or
"NaN"?
In my experiments, I also noticed:
pugs> my Int $a = "42"
"42"
pugs> $a.WHAT
::Str
It seems that the explicit type of $a is being ignored in the
assignment. Am I right to assume this is simply a bug?
testcase (if someone with commit bits can add it):
{
no fail;
my Int $a = "not numeric";
is $a.WHAT, ::Int, "coercion in initial assignment";
}
[svn:perl6-synopsis] r14310 - doc/trunk/design/syn
Author: audreyt
Date: Mon Mar 5 08:27:24 2007
New Revision: 14310
Modified:
doc/trunk/design/syn/S12.pod
Log:
* S12: Clarify that VAR(1) and VAR(@foo) are simply no-ops;
i.e., it applies to thiings other than Scalars, too.
Also fixed the postfix macro name and nomenclature
around .VAR.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podMon Mar 5 08:27:24 2007
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 27 Oct 2004
- Last Modified: 20 Feb 2007
+ Last Modified: 6 Mar 2007
Number: 12
- Version: 42
+ Version: 43
=head1 Overview
@@ -332,18 +332,23 @@
@keys = %hash.keys;
$sig = &sub.signature;
-Use the C pseudo-function on a scalar variable to get at its
+Use the prefix C macro on a scalar variable to get at its
underlying C object:
if VAR($scalar).readonly {...}
-There's also a corresponding postfix: macro that can be used
+C is a no-op on a non-scalar variables and values:
+
+VAR(1); # 1
+VAR(@x);# @x
+
+There's also a corresponding C<< postfix:<.VAR> >> macro that can be used
as if it were a method:
if $scalar.VAR.readonly {...}
(But since it's a macro, C is not dispatched as a real method.
-To dispatch to a real C<.VAR> method use the indirect C<$obj."VAR">
+To dispatch to a real C<.VAR> method, use the indirect C<$obj."VAR">
form.)
You can also get at the container through the appropriate symbol table:
[svn:perl6-synopsis] r14309 - doc/trunk/design/syn
Author: audreyt Date: Mon Mar 5 08:20:56 2007 New Revision: 14309 Modified: doc/trunk/design/syn/S05.pod Log: * S05: Minor fixup for this sentence no verb. Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podMon Mar 5 08:20:56 2007 @@ -1698,7 +1698,7 @@ be possible to know when to fire off the assertions without backchecks.) Ordinary quantifiers and characters classes do not terminate a token pattern. -Zero-width assertions such as word boundaries also okay. +Zero-width assertions such as word boundaries are also okay. Oddly enough, the C keyword specifically does not determine the scope of a token, except insofar as a token pattern usually
Re: for ... else
Larry Wall wrote:
On Mon, Mar 05, 2007 at 04:13:16PM +1030, Tom Lanyon wrote:
: Sounds like the following will work, but it doesn't seem 'nice'.
:
: for @invoice
: {
: .process;
: 1;
: } or fail 'No invoices to process';
Still think if there's no invoices it logically should be tested first.
If you don't want to repeat mentioning the array, how 'bout:
@invoice or fail 'No invoices to process'
==> for @() {
.process
}
or equivalently
@invoice or fail 'No invoices to process'
==> map {
.process
}
all assuming you don't like my original
for @invoice || fail 'No invoices to process'
{
.process
}
These should work, as long as you don't replace "fail 'no invoices to
process'" with something that returns a non-empty list.
That said, you could:
{
for =<> || fail 'no input'
{
.process
}
CATCH {
do_something_else if 'no input'
}
}
...where the 'no input' string is there only so that failures
generated by .process will propagate correctly.
--
This solution isn't generalizable beyond "for", though: you wouldn't
be able to use it for "while, "until", or "loop", all of which could
potentially follow the logic of "do something special if the loop
fails to run even once". Hmm...
while test -> $result {
do_something;
FIRST { do_something_else unless $result }
}
...except that I don't think that FIRST would run unless $result is true.
I suppose that you _could_ write:
if test {
repeat {
do_something
} while test
} else {
do_something_else
}
You'd be having to spell out the test twice, though.
--
Jonathan "Dataweaver" Lang
resumable exceptions and LEAVE/KEEP/UNDO blocks
What happens if a resumable exception is propagated through a block with a LEAVE, KEEP, or UNDO block? S04 seems to be a bit vague on this point. It strikes me that what we want it to do is not execute them when the exception is propagated, because we don't know whether it's going to be resumed or not. If the exception is resumed by its handler, then that's fine, as we can call the blocks at the usual time (when the blocks they are attached to exit). If the exception is caught and handled and not resumed, that would leave us with having to find all the LEAVE &c. blocks and call them in the right order when the exception handler exits. In either case, it looks like you have a problem. LEAVE &c. blocks will often be used for things like database transactions, where we want to ensure that some lock obtained on entering the block is released promptly regardless of how the control flow jumps about. In such a context, throwing a resumable exception that skips the LEAVE block, farts about doing some potentially long computation in a higher-up scope, and only calls the LEAVE block to release the lock at some later date, seems to be far from the best choice. Sure, we can warn programmers to make their resumable-exception handlers short, or to only throw non-resumable exceptions from blocks that are likely to be called in such circumstances. I suppose that would be an acceptable resolution, but it has an aura of non--re-entrant signal handlers about it, so it seems like the sort of thing I would like to avoid if anyone is clever enough to think of something else to do. BTW, if one is handling a resumable exception, how does one resume it? I couldn't find anything explaining how. Having a .resume method (or some cutesier name) on the Resumable role would seem to make sense. -- Waiter, waiter! There's a fly in my soup! That's not a bug, it's a feature. http://surreal.istic.org/ The Answer of the Oracle Is Always Death. signature.asc Description: Digital signature
