On Wed, Oct 05, 2005 at 13:00:55 -0600, Luke Palmer wrote:
I don't think it was a how is this possible, but more of a what
business does it have?. And as far as I gathered, they're saying
pretty much what you've been saying, but in a different way. It's
about the continuation boundary; that
On Wed, Oct 05, 2005 at 13:41:37 -0700, Dave Whipp wrote:
Reading this thread, I find myself wondering how a resumable exception
differs
from a dynamically scropted function. Imagine this code:
This is sort of like what I mean, except that there is no
encapsulation breakage, since the
On 10/5/05, Damian Conway [EMAIL PROTECTED] wrote:
Luke wrote:
I'm just wondering why you feel that we need to be so careful.
Because I can think of at least three reasonable and useful default behaviours
for zipping lists of differing lengths:
# Minimal (stop at first exhausted
Luke Palmer wrote:
zip :: [a] - [b] - [(a,b)]
It *has* to stop at the shortest one, because it has no idea how to
create a b unless I tell it one. If it took the longest, the
signature would have looked like:
zip :: [a] - [b] - [(Maybe a, Maybe b)]
Anyway, that's just more of the
On Wed, 5 Oct 2005 19:24:47 +0200, Yuval Kogman wrote:
On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
Piers Cawley wrote:
Exactly which exception is continued?
The bottommost one. If you want to return to somewhere up its
On Thu, Oct 06, 2005 at 10:31:50AM -0600, Luke Palmer wrote:
If we make zip return a list of tuples rather than an interleaved
list, we could eliminate the final 1/3 of those errors above using the
typechecker. That would make the for look like this:
for @a Y @b - ($a, $b) {...}
I like
Dave Whipp skribis 2005-10-06 9:57 (-0700):
Given that my idea about using optional binding for look-ahead didn't
fly, maybe it would work here, instead:
@a Y @b - $a, $b { ... } # stop at end of shortest
@a Y @b - $a, ?$b { ... } # keep going until @a is exhaused
@a Y @b - ?$a,
On 10/6/05, Juerd [EMAIL PROTECTED] wrote:
for @foo Y @bar Y @baz - $quux, $xyzzy { ... }
is something you will probably not see very often, it's still legal
Perl, even though it looks asymmetric. This too makes finding the
solution in arguments a non-solution.
Don't be silly. There's
Cbut properties get attached to a value, and are available when the
value is passed to other functions/ etc. I would like to be able to
define a property of a value that is trapped in the lexical scope where
it is defined. The example that set me thinking down this path is
sub foo( $a, ?$b =
On Thu, Oct 06, 2005 at 18:11:38 +0100, Peter Haworth wrote:
The highest level exception is the only one a caller has any right to deal
with, but even then it doesn't really know what will happen if it resumes
some random continuation attached to the exception.
But then we gain nothing
On 10/6/05, Dave Whipp [EMAIL PROTECTED] wrote:
sub foo( $a, ?$b = rand but :is_default )
{
...
bar($a,$b);
}
sub bar( $a, ?$b = rand but :is_default )
{
warn defaulting \$b = $b if $b.is_default;
...
}
It would be unfortunate if the is_default property attached in foo
On 10/6/05, Yuval Kogman [EMAIL PROTECTED] wrote:
when i can't open a file and $! tells me why i couldn't open, i
can resume with an alternative handle that is supposed to be the
same
when I can't reach a host I ask a user if they want to wait any
Luke Palmer skribis 2005-10-06 14:23 (-0600):
my role is_default {} # empty
sub foo($a, ?$b = 0 but is_default) {...}
Would this work too?
0 but role {}
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
On 10/6/05, Juerd [EMAIL PROTECTED] wrote:
Luke Palmer skribis 2005-10-06 14:23 (-0600):
my role is_default {} # empty
sub foo($a, ?$b = 0 but is_default) {...}
Would this work too?
0 but role {}
Most certainly, but you would have no way to refer to that role later,
Autrijus convinced me that we have to really nail down the semantics
of type annotation without use static. Let's first nail down what
I meant by semantics in that sentence. Basically, when do various
things get checked? Run time or compile time (not coercion; I have a
proposal for that
On Thu, Oct 06, 2005 at 17:44:10 -0600, Luke Palmer wrote:
Autrijus convinced me that we have to really nail down the semantics
of type annotation without use static. Let's first nail down what
I meant by semantics in that sentence. Basically, when do various
things get checked? Run time
On Thu, Oct 06, 2005 at 14:27:30 -0600, Luke Palmer wrote:
On 10/6/05, Yuval Kogman [EMAIL PROTECTED] wrote:
when i can't open a file and $! tells me why i couldn't open, i
can resume with an alternative handle that is supposed to be the
same
when I can't
On 10/6/05, Luke Palmer [EMAIL PROTECTED] wrote:
So we're in line one of a Perl program, with static typing/inference
disabled (or at least inference *checking* disabled; perl may still
use it for optimization). When do the following die: compile time
(which includes CHECK time), run time, or
Peter Haworth [EMAIL PROTECTED] writes:
On Wed, 5 Oct 2005 19:24:47 +0200, Yuval Kogman wrote:
On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
Piers Cawley wrote:
Exactly which exception is continued?
The bottommost one. If
19 matches
Mail list logo
