> Well, in my example, I still identify that "this input requires a > filename" and "that input requires a config file". If you don't follw > that, then too bad for you. The same thing if a C function asks for a > process ID and you give it your phone number... True. And that's a difference between a programming language and a person. A person would use "common sense" not to do something that's "too bad for her". Programs don't have that common sense, but some design choices in programming languages may help reducing the gap and prevent people that write code to make too many mistakes. > Defining a new type always requires come code. In Overflow the > implemented types are: Int, Float, Double, String, Bool, Vector<T>, > Stream, ... I understood Overflow works well for its purpose. That's good and well. We're just discussing the principles, not argueing about your design. You say above that in your example you still "identify it as a filename" or "identify it as a config file". Is that implemented somehow or specified in the doc or something else ? > If we start adding types for flags, filenames, ... then it becomes > endless. We'd need to divide "Vector" in "3D vector", "2D vector", > "AudioFrame", "FIRFilter", "IIRFilter", .... and the same for all > types. As for any language, the semantics can be taken into account > with the variable name (or in this case, the input name). Not all types need be on the same level. Hierarchies are good for this. And classes of equivalent terms. And ontologies and logics. It all depends how far you want to go and how complicated you want to get. But that doesn't mean it's bad "per se" and we shouldn't mention it here, does it? -- Nicolas Chauvat http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France)