On Fri, Oct 07, 2005 at 12:50:09 -0700, chromatic wrote:
> On Fri, 2005-10-07 at 12:49 +0200, Juerd wrote:
>
> > Ashley Winters skribis 2005-10-06 19:30 (-0700):
>
> > > > my Array $a = 97; # dies eventually, but when?
> > > Runtime -- cannot coerce Int value to Array
>
> > It is fully
On Fri, Oct 07, 2005 at 10:28:13 -0400, Austin Hastings wrote:
> But the point is that "resuming from an exception" (or
> appearing to) is not bound to "implemented with continuations".
What's the point?
Continuations are good for exactly this purpose. Parrot already
supports them. I see absolut
On 10/7/05, chromatic <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-10-07 at 17:43 -0600, Luke Palmer wrote:
>
> > No, you can't overload assignment at runtime because you can't
> > overload assigment at any time, so says the language spec (well, not
> > any formal spec; so says Larry as far as I remem
On Fri, 2005-10-07 at 17:43 -0600, Luke Palmer wrote:
> No, you can't overload assignment at runtime because you can't
> overload assigment at any time, so says the language spec (well, not
> any formal spec; so says Larry as far as I remember).
I'm wearing my "just a programmer, not a denizen of
On 10/7/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> On 10/7/05, chromatic <[EMAIL PROTECTED]> wrote:
> > On Fri, 2005-10-07 at 15:22 -0600, Luke Palmer wrote:
> > > But you are allowed to overload coersion. Essentially, every
> > > expression gets a coerce:($expr, $current_context) wrapped around
On 10/7/05, chromatic <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-10-07 at 15:22 -0600, Luke Palmer wrote:
> > But you are allowed to overload coersion. Essentially, every
> > expression gets a coerce:($expr, $current_context) wrapped around
> > it (where these are optimized away when they do nothin
On Fri, 2005-10-07 at 15:22 -0600, Luke Palmer wrote:
> On 10/7/05, chromatic <[EMAIL PROTECTED]> wrote:\
> > If I added a multisub for Array assignment so that assigning an integer
> > value set the length of the array, would 97 be compatible with Array?
> You're not allowed to overload assignm
On Fri, Oct 07, 2005 at 03:46:02PM -0600, Luke Palmer wrote:
> Uh no. Okay, when I said that they "don't close", I guess I meant
> they don't close like anonymous routines do. It works precisely like
> Perl 5's:
>
> sub foo {
> my $foo = 5;
> sub bar {
> return $f
On 10/7/05, Juerd <[EMAIL PROTECTED]> wrote:
> Luke Palmer skribis 2005-10-07 15:31 (-0600):
> > sub foo($x) {
> > sub bar() {
> > return $x;
> > }
> > return &bar;
> > }
> > foo(42).(); #
>
> Does this mean that this Perl 5 snippet no longer d
Luke Palmer skribis 2005-10-07 15:31 (-0600):
> Well, I see a cognitive downside. That is, package declarations (the
> default) don't create closures. It's like this:
> sub foo($x) {
> sub bar() {
> return $x;
> }
> return &bar;
> }
> foo(42).();
On 10/7/05, Juerd <[EMAIL PROTECTED]> wrote:
> Miroslav Silovic skribis 2005-10-07 13:07 (+0200):
> > Can an inline role be named?
> > 0 but role is_default {}
>
> This is a nice idea. It would require named roles (and to really be
> succesful, also classes, subs, methods, ...) declarations to be
>
On 10/7/05, chromatic <[EMAIL PROTECTED]> wrote:\
> If I added a multisub for Array assignment so that assigning an integer
> value set the length of the array, would 97 be compatible with Array?
You're not allowed to overload assignment.
But you are allowed to overload coersion. Essentially, ev
chromatic skribis 2005-10-07 12:50 (-0700):
> > > > my Array $a = 97; # dies eventually, but when?
> > > Runtime -- cannot coerce Int value to Array
> > It is fully determinable at compile time. 97 will never be compatible
> > with Array, so I see no reason to wait.
> If I added a multisub
On Fri, 2005-10-07 at 12:49 +0200, Juerd wrote:
> Ashley Winters skribis 2005-10-06 19:30 (-0700):
> > > my Array $a = 97; # dies eventually, but when?
> > Runtime -- cannot coerce Int value to Array
> It is fully determinable at compile time. 97 will never be compatible
> with Array, s
Yuval Kogman wrote:
>On Fri, Oct 07, 2005 at 02:31:12 -0400, Austin Hastings wrote:
>
>
>>Yuval Kogman wrote:
>>
>>
>>
>>>Stylistically I would tend to disagree, actually. I think it's cleaner to
>>>use exception handling for this.
>>>
>>>Also, this implies that you know that the errors are
Miroslav Silovic skribis 2005-10-07 13:07 (+0200):
> Can an inline role be named?
> 0 but role is_default {}
This is a nice idea. It would require named roles (and to really be
succesful, also classes, subs, methods, ...) declarations to be
expressions, but I see no downside to that.
Juerd
--
h
HaloO
Yuval Kogman wrote:
We have:
die: throw immediately
fail: return an unthrown exception, which will be thrown
depending on whether our caller, and their caller - every scope
into which this value propagates - is using fatal.
This is enough for normal excep
[EMAIL PROTECTED] wrote:
Would this work too?
0 but role {}
Most certainly, but you would have no way to refer to that role later,
so it is questionable how useful that construct is. No, it's not
questionable. That is a useless construct.
Luke
Can an inline role be named?
0 b
[EMAIL PROTECTED] wrote:
I'm not bashing your idea, because I think it has uses. But I'll
point out that all of these can be easily accompilshed by writing a
wrapper for open(). That would be the usual way to abstract this kind
of thing.
My take on this: resumable exceptions break encaps
Yuval Kogman skribis 2005-10-07 12:53 (+0200):
> On Fri, Oct 07, 2005 at 12:42:01 +0200, Juerd wrote:
> > For my Int $c = $float, though, I'd want coercion.
> > And I think it is wrong to have such a huge difference between literals
> > and values: if a variable coerces, a literal has to do so too.
On Fri, Oct 07, 2005 at 12:42:01 +0200, Juerd wrote:
> For my Int $c = $float, though, I'd want coercion.
>
> And I think it is wrong to have such a huge difference between literals
> and values: if a variable coerces, a literal has to do so too.
How do you tell the compiler "this must never be a
Ashley Winters skribis 2005-10-06 19:30 (-0700):
> > my Array $a = 97; # dies eventually, but when?
> Runtime -- cannot coerce Int value to Array
It is fully determinable at compile time. 97 will never be compatible
with Array, so I see no reason to wait.
Do remember that some programs r
Yuval Kogman skribis 2005-10-07 3:02 (+0200):
> > my Array $a = 97; # dies eventually, but when?
> > my Int $b = 3.1415; # dies at all?
> Both die at compile time, because the user explicitly contradicted
> him/herself. This is like saying
> my int = $x :: float;
For my Int
On Fri, Oct 07, 2005 at 05:23:55 +0100, Piers Cawley wrote:
> "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:
> >> > > Pi
On Fri, Oct 07, 2005 at 02:31:12 -0400, Austin Hastings wrote:
> 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
25 matches
Mail list logo
