HaloO,
I fear I'm addicted...
Luke Palmer wrote:
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 fo
e a few reasons behind this:
1) If I'm not using type annotations in my code, I shouldn't be forced
to go out of my way to satisfy the typechecker before my program will
even run, just because I used external subs that have (incompatible)
type annotations. Of course, my program will
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
CHECK is run.
> > As for the first argument, presumably people put type annotations on
> > their code so that we can do some reasoning and tell them about
> > errors.
>
> I don't want to use a module off of 6PAN that breaks my code because its
> type annotations have le
I don't care *how* I accomplish it, as long as I don't have to
root around in the source code of Perl 6 itself to make it work.
> As for the first argument, presumably people put type annotations on
> their code so that we can do some reasoning and tell them about
> errors.
I
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
t be argued until we see some numbers (but I have a hunch,
because not optimizing away the _many_ do-nothing coersions, you are
effictively adding a complex trace condition in a debugger; and you
have seen how slowly those run). As for the first argument,
presumably people put type annotations on
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:\
> 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 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 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
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
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
18 matches
Mail list logo
