SDV V5.04.01A - Das Entwicklungs und Diagnose Tool für Homematic CCUs

[jp112sdl]

Und da ist für mich die Logik nicht klar ablesbar.

Nicht? Ist doch

Code: Alles auswählen

(A UND B) ODER (C ODER D) UND (E UND F)

[Black]

Und da ist für mich die Logik nicht klar ablesbar.

Nicht? Ist doch

Code: Alles auswählen

(A UND B) ODER (C ODER D) UND (E UND F)

Korrekt. Strikt nach reihe

[Gerti]

Hi,

aber genau das wird der Grund sein, warum das eben nicht umgesetzt ist. Auch wenn es strikt nach der Reihenfolge geht, werden die meisten damit auf die Nase fallen.

Gruß
Gerti

[Black]

dann frag ich mich aber, wer welche pilze geraucht hat, als derjenige die Logik der Abarbeitung eines Mathematischen ausdrucks in der Skriptsprache definiert hatte.

das finde ich wesentlich fehleranfälliger...

[Gerti]

Hi,

da kannst du halt Klammern setzen, damit es korrekt ist.

Gruß
Gerti

[Black]

da musst du aber wissen, das du bei

WriteLine (2*3+5); laut dem, was du in der schule gelernt hat halt nicht 11 rausbekommst sondern 16 und man das so klammern muss

WriteLine ((2*3)+5); damit man das bekommt, was man gerne hätte.

Da kann man sich auch genauso merken, dass die logik strikt nacheinander von oben nach unten bewertet.


Das Argument sticht jetzt nicht so direkt bei mir

Black

[Baxxy]

Strikt nach reihe

Das raff ich gerade nicht...

Runtergebrochen auf Logik:

Code: Alles auswählen

true ODER true UND false =
true ODER false UND true =
false ODER true UND true =
true ODER false UND false =
false ODER true UND false =

Bitte mal vervollständigen.

[Black]

True
O true
U false
=
True
U false
= false


True
O false
U true
=
True
U true
= true


False
O true
U true
=
True
U true
=
True



True
O false
U raise
=
True
U false
=
False


False
O true
U false
=
True
U false
= false


So sollte es sich Verhalten

Black

[jmaus]

da musst du aber wissen, das du bei

WriteLine (2*3+5); laut dem, was du in der schule gelernt hat halt nicht 11 rausbekommst sondern 16 und man das so klammern muss

WriteLine ((2*3)+5); damit man das bekommt, was man gerne hätte.

Da kann man sich auch genauso merken, dass die logik strikt nacheinander von oben nach unten bewertet.

Das Argument sticht jetzt nicht so direkt bei mir

Nun, da kann ich dir vielleicht mit ein paar Interna des ReGaHss und als Erinnerungshilfe zu Compilerbau-/Parservorlesungen weiterhelfen

Der Grund ist einfach, dass es wohl für den ursprünglichen Entwickler der ReGaHss anscheinend einfacher war (oder er schlichtweg nicht wusste wie man es besser machen kann) den Parser/Lexer der Skriptsprache so umzusetzen wie das aktuell der Fall ist. Leider wurde der Parser/Lexer in ReGaHss ja komplett von Hand implementiert anstatt etablierte Tools wie "yacc" oder "bison" zu verwenden um entsprechende Parser/Lexer-Generatoren zu verwenden. Und so handelt es sich bei der ReGa-Skriptsprache eben um eine Sprache mit mehrdeutiger Grammatik bei der die Päzedenz und Assoziativität von Ausdrücken leider nicht entsprechend beachtet wird und dann der Abteilungsbaum der Syntax ohne diese Prioritäten in den verschiedenen Ausdrucksarten stringend abgearbeitet wird. Und so kommt es das "2*3+5" dann eben leider 16 ergibt und man explizit mit Klammern arbeiten muss um diese Präzedenz und Assoziativität hart herzustellen. Und da die Sprache nun leider so ist wie sie ist, kann ich da auch nicht wirklich substantiell etwas verbessern, denn nun sind diese Limitationen eben bekannt und wenn ich dies ändern würde, dann würden sicherlich einige Dinge nicht mehr korrekt ablaufen und müssten angepasst werden...

[jmaus]

Ich würd's wohl eher "Limitierung der WebUI" nennen weil die ReGa selbst das ja augenscheinlich kann.

Aber wenn wir die Stell ein der WebUI finden, die das so limitiert darstellt, könnten wir das bestimmt anpassen. Ist halt nur die Frage ob das Jens mit macht. Von meiner Korrektur des Code zur den falschen Systemvariablen-Metadaten war er ja auch nicht überzeugt.

Es ist/war einfach meines Erachtens der bessere Ansatz die Logik und Typen von Programmen unangefasst zu lassen, da ansonsten wilde Dinge passieren können. So ist/war zumindest meine Einschätzung. Und soweit ich mich erinnere war auch @jp112sdl dieser Meinung und hatte sogar vorgeschlagen das nachträgliche ändern des Datentypes einer Systemvariable gänzlich zu unterbinden. Ich sehe das nicht so strikt und würde zumindest etwas einbauen das dann den Nutzer entsprechend warnt und ihm mitteilt, das es aktuell Programme gibt in denen die besagte Systemvariable verwendet wird und deshalb ggf. das Programm von Hand angepasst werden müsste nachdem der Datentyp der Systemvariable geändert wurde. Aber das blinde/direkte Ändern von Programmen ohne das der Nutzer das wirklich mitbekommt oder ohne das es einen Weg zurück gibt halte ich weiterhin für die denkbar schlechteste Vorgehensweise.