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
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
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
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
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
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.
[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
[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
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
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
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
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
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 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
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
>
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:
> 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
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 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 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 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 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, 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, 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 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
25 matches
Mail list logo
