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 boundar
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 inte
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 exhau
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 t
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 somew
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
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 ->
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. Th
C 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 = rand
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" proper
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
http://convolution
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 r
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 com
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
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
> >
> >
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 tim
"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?
>> > >
Yuval Kogman wrote:
>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 t
20 matches
Mail list logo
