On Sun, Jul 13, 2014 at 12:22 PM, David Jeske <[email protected]> wrote:
> On Sun, Jul 13, 2014 at 9:45 AM, Jonathan S. Shapiro <[email protected]> > wrote: > >> One reason that inference is so important is that it allows those >> programmers to approach type system issues incrementally and as needed. >> When inference is incomplete - which is what makes you need to fiddle the >> type annotations - it stops being a way to ease in to the language and >> starts becoming an obstacle in its own right. >> > > IMO, this discussion is missing the elephant in the room, that one of the > big-undesirable properties of both dynamic-typing and inference-typing, is > the lack of human-readable coherent symbolic type documentation in the > code. > I'd be more inclined to worry about this if we didn't have full annotations at module boundaries. I suspect that type information on strictly internal procedures is something we'll get used to. But this actually raises another reason for inference to want to be complete. It means we can completely erase the programmer-specified types, re-run inference, and issue a warning if the programmer has specified a type that is less than complete. > For example, I like the idea of anonymous structures (where the > declaration requires field-names). However, I avoid and dislike tuples in > all their forms (including LISP/Scheme), because they introduce too much > under-named data and ad-hoc "order dependent contract" between different > places in the code. > I tend to agree, with two notable exceptions: 1. At procedure call: f(a,b) is application to a tuple 2. For multi-value return Though I have to say that in the standard C++ library they have used the Pair template for a bunch of things where I find that the need to name the fields is a pain in my ass. That's another case of multi-value return in disguise. One that is amplified by the fact that genericity is involved in that use case. > Do you see the issue? How do you hope to address it? > I do. I think that *some* of it is a matter of familiarity, but I think that there is definitely a real issue here. Of course, there's nothing that stops you from putting in the annotations. ...my main point is that if you give me a perfect interference system which > can handle any type relationship automagically, I won't choose it unless I > can cause it to be an error not to specify a typename in most place -- > because those type names are the documentation which makes the code > readable. > My guess is that you'll end up at a middle ground. You'll end up placing annotations at any external API of an object, but for private support code you'll annotate only where something is unusually complicated. Documentation is important, but readability is also important. Whether types help with readability is a matter of taste. I personally don't find that: arith 'a => fun add x : 'a y : 'a is x + y is clearer than fun add x y = x + y I find that I am using the C++11 auto keyword in a lot of idioms. Universally for iterators, as one example. But I am still declaring a lot of things as well. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
