All representations for a value should be inter-compatible; similar representation methods should handle values equally well? In any case, the domain "street addresses or numbers" may contain at least two distinct sets of representations, maybe more: N representations of numbers, N representations of street addresses, and possibly N representations capable of doing both ("string"). Those representations may not necessarily handle each other's stuff equally well, though all representations of a given value should be equally usable in any given context (converting to another, more appropriate representation as necessary.) Functions are defined over a given domain (input), with their range (output) also having a defined domain. Users of such functions should not have to worry about which representation is used for a given variable's stored value.
A variable (rather, any symbol) carries a domain, its content (or return value, in the case of functions) carries a representation. It seems like a given representation (00100101) should always be equal to itself, and representations that are translatable should be equal if appropriate, after (automatic) conversion.
Are two variables compatible based on the representations, or the domains, or both? Or something else? "15 meters" vs. "15 degrees celsius", or "room numbers" vs. "employee numbers" (both possibly constrained to the same integers between 1 and 200.) We could decide on compatibility based on the name of the domain the variable indicates (Nominative); we could also check domain constraints on the two variables to see if one automatically matches another (such as the domain of all integers and the domain of positive integers: all members of one are obviously members of the other); or we could run last-minute tests on the values to see if they could in fact be members of the other variable's domain, and are therefore compatible (via conversion.) We could also refuse to run any tests, and base this decision solely on a user-provided list of compatible domains, possibly with conversion function information included (this is very close to a nominative approach, where domains A and B are compatible though not equal, but are compatible only because the users have stated as such.) The problem with a nominative approach is that users could easily state something that is not true, and we would have invalid data flowing through function calls. As a pre-emptive "no", this is useful, but as a definitive "yes", it is not. [This paragraph should be moved to the 'Datatypes' article, as it has changed to favor domain-related techniques, not representation-related ones.]
A related note concerns graphical controls associated with variables: we often use various sizes of edit boxes, mask-edit controls (which can be overly rude about their format-checking), lists, spinner controls, checkboxes, dials, levers, scrollbars, pointers, etc. to show a value to a user and possibly allow the user to replace it with another equally valid value. How do we make the transition from a callback (which may obey a rule such as "the value must be between -5 and +5, and cannot be an even number") and a graphical control that attempts to guide the user into making a valid choice to reduce the number of beeps, message boxes, error log entries, etc. that will be expected to be provided to explain the system's refusal of the user's proposed value? (Yes, I know some people have had the bright idea of providing no feedback on error and positive feedback on success, but ... no.) Should (named?) domains be accompanied by additional GUI-control-specific configuration information to help the control guide the user? I envision a system in which GUI controls are picked by an outside system to match the types of data being presented for reading and/or writing by an application based on user's preferences. An example that comes to mind is that of the drop-down (combo box) vs. a series of radio buttons vs. a single-select list view; all of the above can be used for the same purpose, but users may have a preference or a particular control may be superior to the others under certain circumstances such as reduced screen space or differing quantities of entries to select from. Some users may want all of their number-entry fields to come equipped with calculators or math-parsers, or all of their text fields with spell-checkers, etc. Application builders should not be expected to make these decisions for users, and operating systems should not so rigidly define the list of possible GUI controls. (Mac OS X does provide spell-checking as a feature for all large text-edit controls, but there's no easy way to replace the control with another you like better, no plugin functionality, and no runtime decision-making.) As it is, most operating systems come with a very basic list of GUI controls they can handle for you, and any additional types of GUI controls you create will be restricted to your application or applications explicitly making use of your libraries (nothing even remotely automatic about it.) [The above should probably have its own article, particularly as it relates more to domains than representations, though it conceptually touches on representations in the GUI sense rather than the binary sense.]
There's something here about the idea of "implementation" and virtual functions, interfaces ... all representations having the same interface -- but that's not quite it either. I'm not trying to say that they should be so invisible you can't tell; if you have a domain like "points in space and names of people", you're terribly unlikely to have exactly the same functions available to you in each case: a few extra functions will exist for points in space, and others for names of people. A relation attribute (where_to_find_someone.info) might have the above domain, but that doesn't mean the values for that attribute will necessarily all have the exact same behavior under all circumstances. There will be cases where a function can be deemed appropriate for use on all values of a set without having to look at each one individually: providing its domain constraints with a sort of meta-value to look at and decide, in which case it's always good -- but sometimes we'll run a statement that narrows down the possibilities to just points in space, and want to use a function specific to that case ... I'm not too sure where I'm going with this. If individual functions can be somewhat implementation-agnostic, then the whole object-oriented ideal of implementations and functions being together gets muddled. If you can have a single function that works on 8 different implementations correctly, is that function part of each of their interfaces? I guess that comes down to my observation (elsewhere?) that object-oriented refers to several different decision-making systems all balled into one: namespaces, access to private parts, scope, etc.