It would behoove @Larry to examine the optional type constraints
system proposed for Javascript:TNG (see link from
developers page).  I therefore assume that they have done so, but
others would benefit by doing likewise. :)

On 4/15/08, TSa <[EMAIL PROTECTED]> wrote:
> HaloO,
> John M. Dlugosz wrote:
> > This needs to be fleshed out.  Decisions need to be made.
>  > Anyone want to discuss it with me?
> I want to. But give me time. Meanwhile you could read
> e.g. <>.
> This deals with F-bounded polymorphism in a tutorial
> style. A generalisation of that is Constraint Bounded
> Polymorphism as given in the papers of the WASP Group
> at <>. Another inspiration
> is the CDuce language <> which is
> built around semantic subtyping.
> My point is that Perl 6 so far has defined a syntax
> for type markup but hardly defined how typing works
> ---I remember the "pain but no gain" thread. It might
> actually be the case that optional typing means that
> you need a module that implements it.
> I personally see types as the semantics of the code
> with the added benefit of being machine readable and
> thus can assist you in reasoning about the code.
> A type system is a tool just like an IDE allows you
> to browse the code, e.g. jumping to the definition of
> a class or all invocations of a method etc.
> There are two fundamental type errors in Perl 6:
>    1) a) no or b) ambiguous targets for dispatch
>    2) non-bindable args in non-dispatch position
> 1a and 2 can be easily avoided with slurpy Any
> protos. So the only remaining offender is 1b. And
> that might be pragmatized to just call them all.
> So we sort of end up with the impossibility of
> type errors :)
> Your concerns so far have been with the typing of
> assignment and binding. The former is easy because
> it involves the creation of a new value. Thus one
> can dispatch $x = $y on the container type of $x
> and the value type of $y and store the result in
> $x. So here you get an error of type 1 if any.
> Binding is more complicated because there is no
> new value involved but you want two containers
> to share a value. This is where Larry's view concept
> comes in to avoid the invariance problem of rw
> containers. OTOH the synopsis say that binding
> replaces the container, so
>    my Int $x = 13;
>    my Str $y = 'foo';
>    $y := $x;
>    $y = 42; # OK, type of $y now Int
> but that contradicts the fact that binding happens
> when functions are called
>    sub foo (Dog $d) { say $d; }
>    my Int $x = 23;
>    foo $x;  # $d := $x makes type of $d Int and prints 23?
> Note also that binding is specced only for scalars so far.
> Not for elements of an array or hash!
> Regards, TSa.
> --
> The Angel of Geometry and the Devil of Algebra fight for the soul
> of any mathematical being.   -- Attributed to Hermann Weyl

Sent from Gmail for mobile |


Reply via email to