Jonathan: Thanks for your comments. Some responses.
On Thu, Nov 13, 2008 at 11:54 PM, Jonathan Hseu <[EMAIL PROTECTED]> wrote: > I really think compiling to LLVM bytecode is the right way to go. The > homepage mentions that LLVM work began in March, but the source code doesn't > seem to use it at all. Is it still your intention to use LLVM? LLVM is a very impressive bit of infrastructure, but we got distracted by some more important issues. We'll get back to LLVM. Pragmatically, though, I have two concerns with LLVM that I don't know how to address: 1. It's written in an unsafe language, and therefore is very difficult to include in a BitC runtime. 2. It is starting to look like we need our own optimization infrastructure in order to efficiently avoid JIT compilation. Neither of these is insurmountable, and we may find solutions to both as we dig into LLVM more seriously. One thing that clang does really well is proper error messages. This is > also, to me, one of the main attractive properties of python (although the > errors are at runtime). g++, on the other hand, has completely > incomprehensible error messages if you make a mistake with anything that > uses templates. In my opinion, it would be a good move to make error > messages a focus early on. BitC actually does a very good job with some kinds of error messages that are well known to be hard, and we are pretty good at identifying locations of errors precisely. The messages themselves could certainly use improvement, and we need to do some work on error recovery in the parser. None of that is as important as getting a first working compiler into the field. I know that the language isn't final right now, but from what I've read, you > have most of the language finalized. There are still some features, like > literal types, that are useful but not vital to get it working. Actually, literal types are crucial. Without them we can't do the I/O subsystem right, and we also can't get certain kinds of re-use right. > If you were to work out the syntax for the language, it'd already be > useful for development. The advantage of getting it working early is that > you'd get to test what you have on a wider audience and perhaps attract > extra help. I agree that early use is important. The features that are currently blocking us are not things we can drop, and the first release needs to wait for them. The syntax for the language is unlikely to change in this release. One other minor issue I've been thinking about is: in some statically typed > languages, serialization is just a pain. C++ serialization libraries tend > to require implementation of a serialization function for each class, which > is fine for simple classes without pointers, but pointers tend to complicate > serialization (for example the timezone pointer in boost's datetime, which > prevented them from implementating serialization for timezone-dependent > datetimes). Python's pickle module (being automatic) is a very nice > solution, but is obviously not possible in many statically typed languages. > I'm not sure if it'd have any other uses, but for serialization, it'd be > useful to be able to iterate over fields of a struct or at least be able to > convert it to a (string, value) map and to be able to construct instances of > types from the fields. Not going to happen in a statically typed language without introspection. With introspection it becomes possible, but very delicate to do with any safety. The pointer traversal problem is a deep problem. While the pickle module is very useful, it doesn't always give you what you want. This isn't necessarily a problem that the runtime needs to solve. It would also be possible to do this with layered tools. Which way to go is not obvious, and I don't want to jump prematurely. I'm a little concerned about the increasing complexity of the language > recently. Particularly, literal types and the lifting solution that was > posted earlier seems like a huge workaround. I think that we would welcome a better solution. We don't have one. > I can understand the motivation for objects, but it falls under the > "added complexity" part. I think complexity tends to be a huge detractor > for languages like Haskell and C++ (where it's only useful to use a certain > subset of the language). Unfortunately, without the capsules work BitC fails at our primary objective, which is to be able to build a robust verifiable kernel. In consequence it's not an optional piece. But the complexity of capsules is actually very very small. Also, I'd be interested in helping if you're looking for it. Wonderful. I think that the easiest place for someone to help is probably in the library at the moment. Let me talk with Swaroop and get back to you.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
