SynHighlighter erweitern

[Bjoerk]

Ich bleib' bei #2, schmeiß die KeyIndices raus.

Delphi-Quellcode:

type
  TIdentFuncTableFunc = type TtkTokenKind;

...


function TSynPHPSyn.HashKey(Str: PWideChar): integer;
var
  I: integer;
  S: AnsiString;
begin
  Result := -1;
  S:= LowerCase(AnsiString(WideCharToString(Str)));
  for I:= 0 to Length(KeyWords) - 1 do
    if AnsiString(KeyWords[I]) = S then
    begin
      Result := I;
      Break;
    end;
  // fStringLen ???
  // fToIdent ???
  // sind keine Variablen der unit ???
end;

function TSynPHPSyn.IdentKind(MayBe: PWideChar): TtkTokenKind;
var
  Key: integer;
begin
  Key := HashKey(MayBe);
  if HashKey(MayBe) > -1 then
    Result := fIdentFuncTable[Key]
  else
    Result := tkIdentifier;
end;

procedure TSynPHPSyn.InitIdent;
var
  I: Integer;
begin
  for I := Low(fIdentFuncTable) to High(fIdentFuncTable) do
    if I > High(KeyWords) then
      ...
    else
      ...
end;

...

[Codehunter]

@Bjoerk: Im Prinzip hast du recht. Ich beiß mich aber gern mal durch solche Probleme durch sonst lernt man ja nix dabei Schade dass man den ursprünglichen Erfinder des Algorithmus Martin Waldenburg nirgends mehr findet (macht anscheinend nix mehr mit Delphi).

FStringLen und FToIdent sind private-Members der Elternklasse. Ich fands schon immer merkwürdig, dass man bei der Delphi-Vererbung auf diese Weise auf Variablen der Elternklassen zugreifen kann. Aber so ist es nun mal.

Die Umwandlung in Ansistring finde ich ein wenig bedenklich. Es würde dadurch die Gefahr von False-Positives steigen denn der Hash-Algo ist ja nach wie vor der selbe. Der Verzicht auf KeyIndices bringt da meiner Meinung nach keine Vorteile.

Ich habe mich schon mit zwei Maintainern von SynEdit in Verbindung gesetzt aber anscheinend wissen sie auch nicht sehr viel über den Algorithmus. Wir vermuten aber alle, dass ein Tool verwendet wurde um die Arrays (KeyWords und KeyIndices) sowie die Konstanten im Hash-Algo zu generieren. Das einzige was mir jetzt noch einfiele, wäre die Konstanten per Bruteforce rauszufinden. Aber das ist ja auch nicht gerade die feine englische Art

[Codehunter]

Ich werd irre... Da ist doch tatsächlich ein Quellcodegenerator bei SynEdit dabei (SynGen). Man muss nur erstmal dahinter steigen, wie die Grammarfiles funktionieren die das Ding importieren will. Und der Witz an der Sache: SynGen erzeugt die Hashtable tatsächlich nach einer Art Bruteforce-Methode. Je mehr Keywords eine Sprache hat umso länger braucht das Programm.

Zwar ist der erzeugte Highlighter nicht unbedingt brauchbar weil eine Sprache ja auch aus einer Semantik besteht und nicht nur aus Keywords, Identifiern und Symbolen. Aber: Es erzeugt die Hashtables und die HashKey-Funktion. Die kann man dann einfach rüberkopieren und sich wieder auf die wesentlichen Dinge konzentrieren.

Insofern: Problem gelöst und Danke an alle die sich beteiligt haben!

[stOrM]

Das haette ich Dir sagen können Nur blick ich das Grammar nicht

[Furtbichler]

und wieso baut man nicht einfach eine Hashmap ein? Ich hab mir das Ding vor ewigen Zeiten auch mal angeschaut und den Kopf geschüttelt. Ziemlicher Blödsinn.

[Namenloser]

Zitat von Furtbichler:

und wieso baut man nicht einfach eine Hashmap ein? Ich hab mir das Ding vor ewigen Zeiten auch mal angeschaut und den Kopf geschüttelt. Ziemlicher Blödsinn.

Ich denke mal, da die Map nur ein einziges mal erzeugt wird, hat man mehr Wert auf optimale Verteilung ohne Kollisionen gelegt als auf einfache Einrichtung.

[Furtbichler]

Zitat von NamenLozer:

Zitat von Furtbichler:

und wieso baut man nicht einfach eine Hashmap ein? Ich hab mir das Ding vor ewigen Zeiten auch mal angeschaut und den Kopf geschüttelt. Ziemlicher Blödsinn.

Ich denke mal, da die Map nur ein einziges mal erzeugt wird, hat man mehr Wert auf optimale Verteilung ohne Kollisionen gelegt als auf einfache Einrichtung.

Is klar, aber es geht nicht um die Anzahl der Kollisionen, sondern um die Performance. Jede Hashmap ist gegen Kollisionen immun. Wichtig ist der Load-Factor und jede halbwegs anständige Hashmap-Implementierung wächst automatisch mit.

Bei der Implementierung würde ich persönlich auch eher Wert auf Erweiterbarkeit nehmen, und die Zeit, die ich in die Entwicklung des Codegenerators gesteckt hätte, an anderer Stelle sinnvoller investiert wäre.

Kann man da nichts nachträglich einbauen bzw. ersetzen?

[Bjoerk]

Zitat von Furtbichler:

und wieso baut man nicht einfach eine Hashmap ein? Ich hab mir das Ding vor ewigen Zeiten auch mal angeschaut und den Kopf geschüttelt. Ziemlicher Blödsinn.

Und auch, wer soll das Programm überhaupt verstehen? Es gibt ein 0..136 Array, in denen aber nur 56 Werte drinstehen können, da es nur 56 KeyWörter gibt???

[nahpets]

Zitat von Bjoerk:

[Und auch, wer soll das Programm überhaupt verstehen? Es gibt ein 0..136 Array, in denen aber nur 56 Werte drinstehen können, da es nur 56 KeyWörter gibt???

Vielleicht, weil man die gleiche Logik auch für andere Highlighter mit mehr (oder weniger) als 56 KeyWörtern verwenden möchte? Man muss ja nicht unbedingt für die Hashmap pro Highlighter eine eigene Logik entwickeln, die auf die konkrete Anzahl von Schlüsselwörten der Sprache ausgelegt ist.