<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Mar 21, 2014, at 9:27 AM, Andrew P Black <<a href="mailto:black@cs.pdx.edu">black@cs.pdx.edu</a>> wrote:<br><div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br>On 20 Mar 2014, at 18:23 , James Noble <<a href="mailto:kjx@ecs.vuw.ac.nz">kjx@ecs.vuw.ac.nz</a>> wrote:<br><br><blockquote type="cite"><blockquote type="cite" style="font-family: Times-Roman; font-size: 17px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">That said, I LIKE using type to mean set of methods and with their types. I believe that it's what type OUGHT to mean, in an OO language. But the "type theorists" don't agree ...<br></blockquote></blockquote></div></blockquote><div><br></div>I'm not sure which type theorists you mean. Almost all theoretical work in OO languages (at least in the 90s) used structural types and types meant the set of public methods and their types.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><blockquote type="cite"><br>and that's what it means in Grace, and will continue to mean in Grace. <br></blockquote><br><div><br></div><div>Good. Hence my proposal that we write</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><b>const</b> Boolean = <b>type</b> {&& (SelfType) -> SelfType, || (SelfType) -> SelfType, ... }</div><div><br></div><div><b>const</b> is like <b>def</b>, but you can't override it in sub-objects, and the value must be knowable at compile time.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Andrew</div><div><br></div></div></blockquote></div><br><div>I'm also unhappy with the change we recently adopted (and I'm not thrilled with Tim's proposal either). I'd be happy saying that only type names could be used to associate types with constants, variables, and methods, and thus only the right hand side of type definitions include type expressions. This eliminates all ambiguity (I believe) and leads to simple clear syntax. Thus,</div><div><br></div><div>type S = T & {...}</div><div>is perfectly fine, while</div><div>var a:{...} := ...</div><div>is not.</div><div><br></div><div>If that is not acceptable, my second choice would be to write types with {|...|}. It has the advantage of being easy to type (the keys are both shifted and are right next to each other on the keyboard) and look very much like object definitions.</div><div><br></div><div>I don't like using both type and interface as it will be hard for students to know when to use each.</div><div><br></div><div>Kim</div></body></html>