First a little context about myself, as I think it's useful to frame my response. My experience of programming has, roughly, been python -> scheme -> (learning) haskell. I'm very interested in reliable and secure systems programming that can be trusted be it using formal methods, code audits or whatever else is appropriate for a given project. Hopefully I'll be kicking the sysadmin/light programming habit to head to University next autumn.
On 19 October 2010 17:34, Jonathan S. Shapiro <[email protected]> wrote: > > So I suppose the question now is: where should type annotation be in the BitC > precedence hierarchy? I prefer that it bind tightly, but this probably just > reflects the fact that I'm coming from C, and that is what is familiar. Is > there a strong or compelling reason to have it bind loosely (other than the > mixfix complications)? My feeling is that having type annotation binding tightly, possibly even tighter than function application, makes for easy to read code - it seems to remove a level of indirection. My expectations, biased by real world experience of annotations in margins and sticky-notes (heady stuff I know!), is that a type annotation would refer to whatever it's nearest to. In fact, until reading this thread, I thought haskell type annotations had high precedence simply because high precedence seemed so intuitive that I hadn't even considered that they'd work any other way. I'm unsure whether or not the locality of annotation and subject would be worth having parens all over the place to deal with the situations Wren mentioned as I've not travelled far enough with haskell to have experienced it. I hope the thoughts of somebody with a little (ok a lot) less experience are useful. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
