We have arranged for a room for a Grace presentation/discussion at ECOOP tonight at 5:15 p.m. Please come to George Fox lecture theater 5/6 for the presentation. We will go out to dinner somewhere after the session (suggestions on where to go are welcome).
If you would like to learn more about Grace but cannot come to that session, please contact Kim or James at the meetings this week and we will make time to meet with you.
We are anxious for feedback on our language design, so please come if you can.
The Grace workshop to work through details of the language design — particularly regarding types vs classes remains on Saturday, for people staying longer.
PS – sorry about the short notice: Kim’s flight out of the US was delayed, and we we’re sure when he would get to Lancaster. Luckily he made it, so we’ll go ahead with the BOF this evening
Some comments on Kim’s presentation:
(1) Some [advanced] students were accidentally offended by Kim’s comment that we weren’t interested in the opinions of [novice] students.
(2) If Grace really wants to have a statically typed and a dynamically typed language coexisting and interoperable, then this causes some (perhaps) surprising features. Interoperability usually means that not all dynamically typed programs are legal statically typed programs BUT that statically typed programs must be legal dynamically typed programs, when types are erased. Hence, you’re building in type erasure, which given your comments about generics, you don’t actually want to do. Also “match” would make sense only with classes and values, not with types. (You can’t match on something erased)
(3) Kim mentioned keeping track of the entire structural type so that it would be easy to go back and forth between statically and dynamically typed, but functions AND methods don’t have a storable type, and so you would need the “Blame” semantics that Wadler and Findler suggested for functions crossing the statically typed/dynamically typed boundary for types too.
(4) I hope you don’t add variance annotations.
(5) Option types plus generics plus match look like a mess.
One or two people in the audience wanted ML data types, but I can see that it would be a problem. (But if you added datatypes, perhaps you could have match ONLY for values and datatypes, then you don’t
permit people to write OO using match instead of dynamic dispatch).
(6) Integers (bignums) should be primitive, not rationals. Loops, strong induction etc. Arrays indexed by rationals?
Thanks for those comments, John, they’re great.
re (2) – so we’re trying a dynamically typed model where (most) variables don’t have types, but objects may have all their types. This is one place where we need (lots) more experience!
re (3) – we’d need blame if we wanted to report errors precisely 🙂
I’m hoping we can leave the details of error reports up to the implementation,
so we don’t have to require the contract wrapping needed for blame.
re (5) – yes – what do you suggest instead?
re (6) – we’ve gone around this lots. Perhaps we need to make a distinction between what numeric types are presented first to novices and which types are the basis of the implementation. For example, I could imagine having a primitive fixed-size MutableArray, and Sequence implemented in terms of that.
But for teaching the language, you’d start wit the Sequence not the MutableArray.
Re your (6): I would like a fixed sized array to be available as well as the extensible array since I teach how to create dynamically resized arrays from fixed size ones. But it’s OK if both are in the library and if people are taught to use ArrayList or its renaming.
But back to my (6): I think Integers are a better main number type than rational. Because nth etc should take integers not rational numbers.
BTW: If you’re separating type from class, and you have a Number type, then I can imagine people adding new classes that implement Number, unless you make Number sealed.
I would like a fixed sized array to be available
of course. The question is what types the library deals in. My current guess (and we haven’t really started to any more than guess about the library) is that there will be an immutable fixed size sequence thing and a mutable variable sized thing. For some better values of “thing”.
I think Integers are a better main number type than rational.
Yes, I can see that. But what about division? We certainly mean to separate type from class; an earlier version had an abstract Number type with a bunch of subclasses. But then all the binary methods got difficult really fast – having the core library work with just one Number type seems like the simplest thing that could possible work…
Regarding Integers versus rationals:
Division is an issue, but if you have (even the possibility for) more than one Numeric type, with only structural (or rather behavioral!) subtyping, any binary method will be difficult to implement.
Regarding variance: after discussions on Saturday, I think if we’re (primarily) structural, we don’t need variance annotation, because specific types can always be manufactured post-hoc.
In nominal languages, this generally isn’t possible – so variance seems to be required to create the variant types from the core definition.