<HTML><HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type></HEAD>
<BODY>
<DIV>
<DIV style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">Briefly - note that Go has a bunch of typed intrinsic built in "collections" - not extensible or scrutable - but typed and an interesting 80/20 design point...<BR><BR>J, in a field in Suffolk with 29999 other people...<BR><BR>Yes,<BR>that would mean when programmers remove something from a collection,<BR>they would have to downcast. Go programmers seem to tolerate it well<BR>enough.<BR></DIV></DIV>
<DIV dir=ltr>
<HR>
<SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">From: </SPAN><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><A href="mailto:lex@lexspoon.org">Lex Spoon</A></SPAN><BR><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">Sent: </SPAN><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">19/07/2013 14:22</SPAN><BR><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">To: </SPAN><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><A href="mailto:grace-core@cecs.pdx.edu">grace-core@cecs.pdx.edu</A></SPAN><BR><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">Subject: </SPAN><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">Re: [Grace-core] On Gradual Typing</SPAN><BR><BR></DIV>On Thu, Jul 18, 2013 at 5:40 PM, Kim Bruce <kim@cs.pomona.edu> wrote:<BR>> I've been running into this problem as I try to write statically typed code.<BR>> Hence I actually have types Block0<R>, Block1<T,R>, Block2<T1,T2,R>, ...<BR>> In these the Ti are the types of the parameters to the block, while R is its return<BR>> type. I do consider each of these to be different types whose common supertype is Object.<BR><BR>That looks like a very tractable way to handle block types. Fix the<BR>arity at compile time, and don't even have a generic "Block" type.<BR>Doing so means you are using the same sort of function types as are<BR>used in functional programming languages and in typed logics more<BR>broadly, so you can be sure you won't have any fundamental problems.<BR><BR>Going further, it might make since to be less cute and simply include<BR>function types in the type system. Either make "Block" be a keyword,<BR>or have syntax like "Int => String" for a Block that takes an integer<BR>and produces a string. If you put function types in the type system,<BR>you can actually get away with dropping type parameters, too. Yes,<BR>that would mean when programmers remove something from a collection,<BR>they would have to downcast. Go programmers seem to tolerate it well<BR>enough.<BR><BR>Speaking broadly, the design of a type checker can easily grow to be<BR>more engrossing than the design of the rest of the language. Rob Pike<BR>dropped generics from Go for this reason. Gilad Bracha dropped all<BR>types from NewSpeak for this reason. Design is about tradeoffs.<BR><BR>Anyway, it's just a thought. The main thing I wanted to say is that<BR>fixed-arity function/block types are likely to be much easier to deal<BR>with.<BR><BR>Lex<BR>_______________________________________________<BR>Grace-core mailing list<BR>Grace-core@cecs.pdx.edu<BR>https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core<BR></BODY></HTML>