> (open-input-file path [encoding])
> as in:
> (open-input-file path "utf")
> or:
> (open-input-file path "latin-1")

I'd say no.
How about

(write-string string . encoding)
  encoding <-- { latin1, utf8, utf16, unicode, ... }

(read-string string . encoding)
  encoding <-- { detect, latin1, utf8, utf16, unicode, ... }

Let's redefine these ports and primitives on ports.

Let's say a port is a like a door. Does a door care about
what's going through it? Does it care weather it is a piano,
a brick, a boy, a girl, a cat, a chair, a ball? NO, it does not.
It only cares about size. If it doesn't fit through the door, that's
a different matter. But that's what we would call a 'non-functional
requirement' to the door. It's function is to provide a gateway
that can be opened or closed, much like out Scheme port.

So, out scheme port is a door to a specific medium, weather it
is a file, socket, pipe, shared memory, printer, character device
or anything else, does not matter.

But the door must not put restrictions on the things that the
software engineer wants carry through it.

Suppose you were to paint a picture. Would you want to be restricted
to a pensil? Or would you also want to be able to use your hands, towels,
brushes, etc?

I think this is the essence of the discussion. It should not be
the ports that restrict the way they let information through. It should
be the primitives on the ports (like display, etc) that implement
the way information is put through the door.

Hans Oesterholt-Dijkema