On Fri, 2005-01-28 at 07:43 -0800, Shawn Garbett wrote: > Does avoiding polymorphism and static type checking > exclude things like type classing in Haskell?
I don't know. Perhaps Swaroop does. Perhaps I should explain to everyone here that our group isn't really very knowledgeable about type systems, and in this regard our objective is to learn as little as we can and still competently get the job done. In this area, we want to reuse established work, not invent it. Our goal isn't to get sucked into the type system world. Our goal is to get a pragmatic solution built *quickly* for safe systems programs. As principle investigator in all this, my greatest fear concerning BitC is that it is extremely easy to get sucked into examination of type systems for *decades*. There are people who spend their entire careers on this, and they are much better trained at it than any of us are. So: I'm happy for us to consider anything simple and compelling, but it has to be both. I'm also willing to look at languages that take different approaches than ML, but I cannot say that I'm very eager to do so. It would slow us down alot. As it is, I'm not sure that polymorphism is going to be compatible with the object system I have in mind. But here is my litmus test: is it better to have a working, safe language a year from now with a mature type system that we can reason about two years from now, or is it better to spent the next decade screwing around to find the best type system on Earth, and the following decade formalizing it and figuring out how to prove stuff about it? Now if there is a type system out there that has the pragmatic utility of ML-style polymorphism but is known to be easier to reason about formally, *that* would be of great interest to me. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
