Arc Forumnew | comments | leaders | submitlogin
Confusing types: string port and file port
1 point by zhtw 5488 days ago | 3 comments
I expect all output ports to work the same way because (at least) (type (outstring)) and (type (outfile)) gives me the same: 'output.

But inside doesn't work with file port.

I don't say it must. But either the types must be different or they must behave the same way. (Maybe inside for file ports should return nil? I don't know.)

Could anyone explain me the logic if this behavior is intentional?



3 points by aw 5488 days ago | link

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.

-----

1 point by zhtw 5487 days ago | link

> "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.

-----

2 points by aw 5488 days ago | link

One conceptions of a...

Ouch, I hate noticing I made a glaring typo after the edit window has closed...

-----