1) Abgesehen von Typen gibt es Objekte.
2) Objekte sind entweder Variablen oder Funktionen.
3) Alle Objekte haben irgendwie einen Typ.
4) Variablen haben einen Storage.
   Storage kann entweder permanent sein (entspr. data section),
   oder entstehen und verschwinden (zb auf dem Stack).
5) Funktionen haben Code.
   Code kann zwar theoretisch auch entstehen und verschwinden,
   aber das ist sehr ungewhnlich und bleibt vorerst unbehandelt,
   also ist Code permanent.
6) Alle Objekte haben eine "Sichtbarkeit", die mageblich von
   ihrem Gltigkeitsbereich im Quellkontext bestimmt wird (scope).
7) Alle Objekte werden benutzt (referenziert).


Es lassen sich also drei Eigenschaften eines Objektes ausmachen:

a) Gltigkeitsbereich (scope) (siehe 6.)
  Dieser ist im Quellkontext wichtig und entfllt im Laufe der
  weiteren Verarbeitung, wird also aufgelst.

b) Realisierung (instance) (siehe 4+5.)
  Hier werden unterschieden:
    - permanente oder temporre Instanz
    - Daten oder Code Instanz
  Folgende Kombinationen folgen hieraus:
    - permanente Daten-Instanz: data
    - temporre Daten-Instanz: (zb Stack)
    - permanente Code-Instanz: code
    - temporre Code-Instanz: -entfllt-

c) Benutzung (usage) (siehe 7.)
  Alle Objekte werden irgendwie benutzt.
  Zunchst sind alle Benutzungen gleich, aber im Laufe der weiteren
  Verarbeitung wird sie mit Attributen versehen.


Daraus ergibt sich der folgende Vorschlag fr die interne Representation:
(Die in <spitze> Klammern gesetzten Attribute werden nachtrglich angebracht,
 sind also vom Evaluator noch nicht eingesetzt)

a) scope:
  (know (name type ref))
  (forget (ref))
  Dem Bezeichner <name> wird ein beliebiger, eindeutiger <ref>-Code zugewiesen.
  Der Bezeichner ist bis zum korrespondierenden forget gltig.

b) instance:
  (data (ref <size>))          permanente Daten-Instanz
  (code (ref) ...)      permanente Code-Instanz
  (emerge (ref <size>))        temporre Daten-Instanz
  (vanish (ref <size>))        Ende derselben.
  Das Paar emerge,vanish stellt quasi den Stackframe fr lokale Variablen dar.

c) usage:
  (use (name <ref> <access>))
  Die Benutzung ist zunchst unbestimmt, wird aber spter przisiert,
  also <access> zb read, write, call, reference.

Damit htten wir dann erstens eine saubere Trennung von Quellkontext
und Zielkontext und zweitens ein ziemlich simples aber mchtiges Konstrukt
fr den Typechecker. Der braucht zunchst mal nur alle (use) den (know/forget)
zuordnen (entweder mit overloading oder type-mismatch-Fehlern, zb),
kann dann von allen (know) ber den Typen die Gre ermitteln und als <size>
in (data/emerge/vanish) anbringen.

Dann hauen wir die (code) Knoten flach, und sind fertig :-)

Details:
- sowas wie "const" und "volatile" sind zunchst Attribute in (know) und
  werden spter in die Instanzen bertragen.
- "import" wird im (know) angegeben, denn es ist eine auswrtige Instanz,
  die hier verwendet wird, hingegen
- "export" wird im (data/code) angegeben, denn es ist eine eigene Instanz,
  die auswrtige sichtbar werden soll.

Nochmal zurck zu Punkt 1:
Typen haben keine Instanz, nur einen Scope. Also reichen zwei Knoten aus:
(knowtype (name ref type))
(forget (ref))

