One conceptions of a "type" is to consider it as a logical representation of a particular set of operations, and a value is a member of that type if it supports those operations. Under this conception, as you say, either string ports would need to be a subtype of ports with "inside" as an additional operation, or file ports ought to support "inside" somehow if file ports and string ports are to have the same "type".
Another conception is to consider types as merely a label that we can attach to a value when it's useful, one trick in a bag of tricks for writing concise code.
The label isn't a precise promise, any more than if I scribble "living room stuff" on a box when I'm moving is a promise that the box is only going to contain precisely and only living room items. It's just a convenience to remind me to dump the box in the living room. Likewise labeling a value as a "port" or a "string" is helpful in a function that I want to take different actions depending on the label, but I don't have to be labeling the value in excruciating detail just to do that.
Under this second conception, a proposal to make (type (outstring)) or (inside (outfile)) return a different value would be met with a question "how would that help me write programs more concisely?"
Of the languages that I'm familiar with, Haskell really takes the idea of a type as a mathematical set of operations and implements it seriously. I found Haskell elegant and intriguing, but when I tried to write applications I found myself spending way too much time writing extra code to make the type checker happy. Which is supposed to pay off in fewer bugs, but not many of my bugs end up having been type related, so it wasn't actually helpful to me.
So in my own experience writing applications, Arc's not having a strict "set of operations" conception of type has been a big win. At least for me. Certainly I enjoy writing programs in Arc much more than I did in Haskell.
Of course, someone who prefers Haskell would likely have the opposite opinion.
> "how would that help me write programs more concisely?"
Ok. This is after all the most relevant question.
But my point is although it's not necessary to worry about the difference between outport and outfile from the user's point of view, it's certainly impossible to ignore them when you implement these functions. You kind of have to since you need to know whether or not inside is allowed for a particular object. Whether to make this information visible for the user is another question.
