Think about maps. They exist for humans; they are a tool of understanding; we make them because the way we see the world doesn't let us easily understand all of a landscape at once just by being in it. The map-land relationship has the important feature that you can make many maps of the same land, but you can't make many lands of the same map.

Reading this metaphor into the realm of computer languages, the presentation on the screen seems like a map, and the meaning of the program like a landscape. To know the landscape of a program, it's nice to have a map -- some kind of text, or boxes and arrows, or something that helps navigate and understand this structure. And every program has just one structure and one meaning, but you could present that meaning in many ways. One landscape, many maps. One structure, many representations. It makes sense to have many maps, drawn at different scales and emphasizing different features. Think of the differences between a world map and a street map, a road map and a topo map. Why not have such varied maps of the same program?

The insight of representation independence is that the whole implementation of a language is just a map. Just as the notation on the screen works to realize the semantics in a way comprehensible to a human, the implementation works to realize it in a way comprehensible to a computer. And just as there are many ways of visually representing a program, there are many ways of implementing it.

It's really not such a stretch to say that the implementation or notation represents the semantics. In fact, it's rather silly not to. We currently design programming languages backwards, with the semantics shadowing the syntax, as if the map were the important part, and the land just a theoretical and somewhat optional adjunct to the map.

You probably have a GUI file browser (the Macintosh's Finder or something mimicking it) which shows your files as a bunch of icons. It probably gives you several options for how you see your files -- small or large icons, in a list or arranged two-dimensionally, files sizes and dates visible or hidden. If you have a command line, you can look at your files in a different, more textual way, which emphasizes low-level details more.

Despite the religious fervor of command line devotees, however, that command line is just a different presentation of the same thing -- the command line is not showing you the actual file system, at least not any more than the GUI is. And despite the religious fervor of graphical interface devotees, neither presentation is inherently better. They do different things, appropriate to different people and different purposes.

Lurking behind them both is the actual file system, which just doesn't care at all. You can use both the GUI and the command line at once, and it still won't care. Your hard drive sees some bits which are the actual physical layout of your file system, but even these are just a presentation of the magnetic fields in the drive. And neither the GUI nor the command line cares about all that -- parts of your file system might be located on a CD-ROM or across a network, and the command line and your file browser still ought to work fine, because the files still have the same structure and behavior.

That behavior, that structure, is completely abstract. It's independent of the way it's stored, and it's independent of how it's presented to the user. You can't really point at something and say "that's the true form of this file structure" -- open a different window and it will look different; copy it to a different device and it will be stored differently. The file system is representation independent.

This is why Eidola has a formal semantics. The semantics is an exact, unambiguous description of the structure and behavior of Eidola code. It separates what's part of the language -- what's important to the meaning of a program -- from the things that are just frosting, and it describes exactly what these structures can look like and how they can behave. This ensures that moving between representations doesn't gum up the code (as using the wrong Windows program to copy between FAT and NTFS can gum up your file names). Similar things, such as the POSIX file semantics, do exist for file systems, and work quite well.