TCustomVariantType benutzen

[Flogo]

Hi,
Ich habe vor eine kleine Interpretersprache mit folgendem Aufbau zu schreiben:

Delphi-Quellcode:

TBefehlsBlock = class(TList)
  [...]
  public
    property Items[Index: Integer]: TBefehl [...]
  end;

  TBefehl = record
    BefehlsID: Integer;
    Argumente: Array of Variant;
  end;

Die Argumente eines Befehls sollten auch wieder Befehlsblöcke aufnehmen können. Aus diesem Grund will ich den Varianttyp erweitern. Mit der Hilfe bin ich so weit gekommen, dass ich jetzt einen packed record habe in dem mein Typ und einige Lückenfüller drinstehen

Delphi-Quellcode:

  TBefehlVarData = packed record
    VType: TVarType;
    Reserved1, Reserved2, Reserved3: Word;
    Befehle: TBefehlsBlock;
    Reserved4: LongInt;
  end;

Außerdem habe ich noch eine Klasse von TCustomVariantType abgeleitet

  TVarArgument = class(TCustomVariantType); Leider weiß ich jetzt nicht weiter. Die (englische ) OH benutzt hier einige Funktionen wie VarDataCopyInd ohne weiteren Kommentar und verweißt immer wieder auf Units, die ich in meiner PE nur als *.dcu hab.
Ich hoffe jemand kann mir einen Stoß in die richtige Richtung geben

[Flogo]

Gut Nach einem halben Tag OH blättern bin ich nicht viel weitergekommen. Ich weiß noch nicht mal ob ich als Klasse für meine Argumente weiter Variant benutzen muss oder den von mir erstellten Typ TVarArgument. Außerdem sieht es so aus als müsste ich ca 10-20 Methoden überschreiben um einen bleibigen Variant in meinen Typ umzuwandeln, um mehrere meiner Typen zu addieren usw.
Allerdings brauche ich diese ganzen Funktionen doch gar nicht
Ich will doch gar keine Typenumwandlung (außer vielleicht von Sting nach Integer und von String nach Real aber die gehen ja auch mit dem "normalen" Variant) und Addition macht erst Recht keinen Sinn.

Ich glaube ich werde versuchen mir meinen eigenen "Variant-Klon" als Erbe von TList zu schreiben.
Oder ich lasse in jedem Argument immer ein Variant und einen TBefehlsBlock zu und setze dann im Variant eine Konstant wenn der Befehl benutzt werden soll.
Mit anderen Worten: Ich habe aufgegeben

[marabu]

Gibst du immer so schnell auf? Es ist einfach kein guter Ansatz gewesen. Wenn du funktionale Elemente in deine little language einbaust, musst du deren Verschachtelungen ja nicht in den internen Code-Listen nachbilden. Es ist durchaus best practice, wenn du bei der einfachen und klaren Tabelle als interner Speicherstruktur bleibst. Bei funktionalen Sprachen wird die Tabelle dann lediglich selbstrekursiv. Warum fängst du aber auch gleich mit der vollen Komplexität an? Schraub doch etwas zurück und implementiere erstmal einen Parser für eine vereinfachte Grammatik. Kleine Schritte bringen auch Erfolgserlebnisse.

Grüße vom marabu

[Flogo]

Zitat von marabu:

Gibst du immer so schnell auf? Es ist einfach kein guter Ansatz gewesen.

Genau! Das war der falsche Ansatz! Ich hab nur den Ansatz aufgegeben, nicht gleich das ganze Projekt.

Zitat von marabu:

Wenn du funktionale Elemente in deine little language einbaust, musst du deren Verschachtelungen ja nicht in den internen Code-Listen nachbilden. Es ist durchaus best practice, wenn du bei der einfachen und klaren Tabelle als interner Speicherstruktur bleibst. Bei funktionalen Sprachen wird die Tabelle dann lediglich selbstrekursiv. Warum fängst du aber auch gleich mit der vollen Komplexität an? Schraub doch etwas zurück und implementiere erstmal einen Parser für eine vereinfachte Grammatik. Kleine Schritte bringen auch Erfolgserlebnisse.

Grüße vom marabu

Ich bin nicht ganz sicher ob ich das alles richtig verstanden habe (was genau meinst du mit "selbstrekursiv" und "funktional"). Im Prinzip habe ich meine Befehle ja in Tabellen, nur das ich mir durch mehrere Tabellen das Springen innerhalb dieser Tabelle(n) ersparen will.


Wenns jemand interessiert:
Ich bin jetzt auf Records mit variant-Teil umgestiegen. Da ich keine Typenumwandlung und nur eine beschränkte Anzahl an möglichen Typen habe, ist dieser Record hier viel besser geeignet (und sogar nur halb so groß wie ein Variant). Außerdem kann ich hier auch noch Kontrollen durchführen , ob der richtige Typ in der Variable steckt bevor ich sie zurückgebe. Ok das würde bei einem Variant sicher auch irgendwie gehen aber hier weiß ich wie es geht.

[marabu]

Zitat von Flogo:

was genau meinst du mit "selbstrekursiv" und "funktional"

Selbstrekursive Tabellen kennst du vielleicht als Stücklisten oder bill-of-material. Im Datenbankbereich ist eine selbstrekursive Tabelle die Abbildung einer 1:n Beziehung auf eine einzige Tabelle.
Mit der Formel "funktionale Elemente" wollte ich gegen "funktionale Sprache" abgrenzen, in der Annahme, dass du keine rein funktionale Sprache, sondern lediglich Parametersubstitution implementieren willst.

Zitat von Flogo:

Im Prinzip habe ich meine Befehle ja in Tabellen, nur das ich mir durch mehrere Tabellen das Springen innerhalb dieser Tabelle(n) ersparen will.

Eine (1) Tabelle oder ein (1) Syntaxbaum. Mehrere Tabellen solltest du nur insofern haben, dass alle identifier (Konstanten, Variablen, Funktionen) und eventuell Zwischenergebnisse normalerweise in eigenen Tabellen verwaltet werden.

Zitat von Flogo:

Ich bin jetzt auf Records mit variant-Teil umgestiegen. Da ich keine Typenumwandlung und nur eine beschränkte Anzahl an möglichen Typen habe, ist dieser Record hier viel besser geeignet (und sogar nur halb so groß wie ein Variant). Außerdem kann ich hier auch noch Kontrollen durchführen , ob der richtige Typ in der Variable steckt bevor ich sie zurückgebe.

Weiter so. Viel Spaß.

marabu

[Flogo]

Zitat von marabu:

Selbstrekursive Tabellen kennst du vielleicht als Stücklisten oder bill-of-material.

Leider nicht
Aber ich glaube ich verstehe so ungefähr was du meinst. ("Eine Tabelle kann Elemente enthalten, die wieder auf eine bestimmte Stelle der gleichen Tabelle verweisen"?)

Zitat von marabu:

Mit der Formel "funktionale Elemente" wollte ich gegen "funktionale Sprache" abgrenzen, in der Annahme, dass du keine rein funktionale Sprache, sondern lediglich Parametersubstitution implementieren willst.

Ich weiß leider auch nicht was eine funktionale Sprache und Parametersubstitution ist.
Was ich vorhabe ist eine "Sprache" zu entwickeln, mit der man die Levelprogrammierung eines Spiels erledigen kann. Sie soll Befehle (wie zum Beispiel "Bewege die Figur Hanspeter zu den Koordinaten 210, 340") an die Engine weiterleiten. Da sie auf jeden Fall "Ereigniss-Gesteuert" sein soll (Wenn man Hanspeter anklickt soll der Dialog gestartet werden) brauche ich hier ja schon viele kleine Codeschnipsel (Diese werden immer zusammen mit der Figur/dem Gegenstand geladen), die ich dann auch in einzelnen Listen ablegen werde. Ob ich dann innerhalb dieser Listen nur Verweise mache oder wie bis jetzt geplant weitermache muss ich mir dann noch überlegen. Im Moment tendiere ich aber dazu mit mehreren Listen zu arbeiten, weil ich daür schon einen Ansatz (s.o.) habe.

[marabu]

Funktionale Sprachen sind z.B. Lisp, Hope, ML oder Miranda. Das mit den selbstrekursiven Tabellen hast du richtig verstanden. Das, was du implementieren willst, scheinen eher Commands zu sein. Ich halte mich jetzt etwas zurück.

marabu

[Flogo]

Ich meld mich wenn ich was zustande gebracht hab.
Vielen Dank für die Hilfe und die Motivation