It would behoove @Larry to examine the optional type constraints system proposed for Javascript:TNG (see link from firefox.com 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. <http://www.dcs.shef.ac.uk/~ajhs/classify/index.html>. > 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 <http://wasp.cs.washington.edu>. Another inspiration > is the CDuce language <http://www.cduce.org> 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 | mobile.google.com Mark J. Reed <[EMAIL PROTECTED]>
