I fell asleep last night reading the F# 3.0 spec - what do you expect - it's a language spec - and resumed this morning. Here are some reactions, though in no particular order.
*Short thoughts* Probably not worth discussing - I'm just catching my thoughts here. 1. I've never liked O'Caml syntax. I'm working hard to set that aside as I go through this. 2. In a lot of ways, F# is what BitC might have been if we'd started from O'Caml rather than Haskell. 3. F# appears to have a monstrously large core with a very small core inside that is trying to get out. That might just be me being optimistic. 4. It is interesting that F# and BitC made similar decisions regarding certain uses of constraint systems. Each language introduces some constraints that reflect underlying things known to the compiler. In BitC they are core type classes; in F# they are part of the language syntax, but they are qualitatively similar tricks. 5. The object system feels kludgy. At some level it feels like O'Caml and the CLi type system were kit-bashed together. 6. Allowing for the fact that BitC is going to have to bite the bullet and introduce *some* sort of object-like system, something similar to what F# did may not be a bad approach. Yes, I know everybody's going to want to talk about this. I'll start another email thread for it shortly. 7. I've always liked the units idea, just never had time to explore it much. 8. There are a bunch of corner cases in the specification that are clearly present to satisfy constraints imposed by CLR, e.g. the discussion of underspecified object identity in 6.9.24 of the 3.0 specification. 9. I need to dig deeper into the curried vs. uncurried signature stuff, and see how (if) the two are reconciled. 10. It's been clear for some time that BitC needs type abbreviations. *General* I wonder how much of the core syntax of F# could be implemented in the prelude if (a) the syntax had been selected to facilitate that and (b) the language supported a mixfix mechanism. *Features*: I like the notion of computation expressions, and I also like the sequence type notion. I'm not sure that these are things I want to use in very low level systems code, because the idioms are prone to induce heap allocation, but I can definitely see the value. I also like the notion of delayed expressions. I haven't looked at async expressions yet. Anybody have experience here? *iDisposable and Use* While I have mixed feelings about the IDisposable pattern, it does seem to me that it's a pattern that has served well in enough contexts to think about carefully, and I think that the language support provided by the "use" form is a reasonable thing to do. IDisposable kind of dodges the bullet about closure capture because the captured reference refers to an IDisposable that will have been disposed. In the presence of a region system, I wonder if this might not have been handled better with a release protocol defined in terms of region escape. In particular, I think it might be reasonable to say that when a region %r is released, any IDisposable object within that region should have it's IDisposable.Dispose() method called. The pattern is far from perfect, but it's also far from awful. The support for quoted expressions and static reflection (AST construction) is thought-provoking. I've considered doing something similar in BitC, but it would rely on defining a canonical AST (which hasn't been done *yet*). When combined with mixfix, I wonder whether this would effectively eliminate the need for a macro system? If you are going to admit pattern matching (which we took out of BitC), guarded patterns are the right thing. I have no foundational objection to patterns. We took them out because pattern compilation was too damned complicated and their use in combination with by-ref and mutable seemed to offer lots of opportunities to make mistakes. I think we now know how to avoid the mistakes, but I still feel ignorant about the compilation complexity. I have very mixed feelings about record types. One of the failings of O'Caml, in my view, is that it has a propensity for namespace pollution. Where records are concerned, I may be over-reacting, but let me come back to this. I do find it interesting that both BitC and F# ended up adopting the idea that unions, records, and so forth can have dotted names, and that these dotted names might include constructors. With the notable exception of records, the name resolution rules for F# and BitC appear to me to be very similar. Qualifier: my original dislike for record field names had to do with name space pollution. But if they are only valid inside record constructors that would mitigate a lot of my dislike for them. There's still an issue in my mind about Records vs. Maps, which I'll come to in a separate email.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
