In der Tiefe: Validierungskonzept

[Tessi]

@Tessi:
Ich habe noch keinen Hinweis im Handbuch gefunden, dass die Reihenfolge im Code nicht der Ausführungsreihenfolge entspricht.

Ich auch nicht - aber auch keinen Hinweis auf das Gegenteil. Sehr wohl aber immer wieder Hinweise, das man den Code eben nicht wie C-, BASIC- oder Java-Code lesen darf.

Die angesprochene parallele Ausführung enthält auch hierzu keinen Anhaltspunkt (trägt eher zur Verwirrung bei). Wenn tatsächlich umsortiert wird, muss das entsprechend beschrieben werden oder soll die von Michael gerne zitierte Blondine sich da einen Reim drauf machen müssen???

Es wurde irgendwo angedeutet, das der Parser/Compiler da irgendwie Strukturen erzeugt, die die gegenseitigen Abhängigkeiten der Daten und Aktionen beschreiben. Das legt auch den Verdacht nahe, das dabei die Reihenfolge eben nicht (nur) vom Code abhängig ist und das dabei durchaus mal etwas ganz anderes herauskommt, als bei definiert sequenzieller Abarbeitung. Ich weiß es aber nicht, weil es eben nicht beschrieben wird. So werde ich also das ein ums andere Mal überascht, wenn etwas anderes geschied, als ich mir vorgestellt hatte.

Verschachtelungen sind beim eibPC leider notwendig, den nur auf der obersten Ebene gilt der vereinfachte Syntax (das Validierungsschema = Event-getrieben). Die nächsten Ebenen sind eigentlich normale Logik, auch wenn das im Handbuch stark verkompliziert ist.

Ist das real die "programmiererverständliche" Erklärung von "alles was innerhalb eines then- oder else-Zweiges steht wird vor Ausführung des Zweiges invalid"?

(Wo findest du denn den Hinweis, dass man Verschachtelungen vermeiden soll? Ich hab da nur else in Erinnerung?).

In der aktuell angebotenen Version - HandbuchEibPC-15.odt, 2010-07-23 - steht auf Seite 46

Wir empfehlen Anfängern die Vermeidung von verschachtelten if-Anweisungen.

Dabei muß "Anfänger" wohl bezüglich EPC gesehen werden. Programmiererfahrung mit "normalen" Sprachen scheint eher verwirrend als hilfreich zu sein.

Ansonsten gebe ich dir Recht, ob ein Kommando ausgeführt wird, oder nicht definiert sich laufend neu

Das wird Enertex so wohl nicht widerspuchslos im Raum stehen lassen wollen, aber subjektiv kommt es einem schon manchmal so vor, wenn man immer wieder umlernen muß, weil das Validierungsschema vereinzelt eben nicht das macht, was man jetzt erwartet hätte und man sich das zunächst einfach nicht erklären kann.

[saft6luck]

Ist das real die "programmiererverständliche" Erklärung von "alles was innerhalb eines then- oder else-Zweiges steht wird vor Ausführung des Zweiges invalid"?

Tja, so erlebe ich das ...

[bmx]

Das einzige, wie Du das umgehen kannst, ist für jeden kritischen write eine eigene Variable anzulegen und den zu schreibenden Wert vorher dieser Variable zuzuweisen.

So geht es eben leider nicht.

Folgendes geht jedenfalls nicht:

[highlight=epc]
//Inline-Makros
:begin write_direct(GA, Value, Name)
Name^temp = Value
:return Name^temp = Value; write(GA, convert( Name^temp, Value))
:end
[/highlight]

Also ein Aufruf der Art
[highlight=epc]
a=10u08
write_direct('9/2/0'u08, a, Testwert)
a=11u08
[/highlight]

ergibt bei Dir dann 11 und nicht 10?

Gruß,
Bernd

PS: Im übrigen bin ich der Meinung das ELSE verboten werden müßte weil es Nebenwirkungen hat!

[Tessi]

PS: Im übrigen bin ich der Meinung das ELSE verboten werden müßte weil es Nebenwirkungen hat!

Welche denn?

[bmx]

Welche denn?

[highlight=epc]
a=10u08

if a==10 then a=a+1 else a=a-2 endif
[/highlight]

Beim Programmstart ergibt sich für a nach dem ersten Durchlauf das a=9 ist.

Wenn Du im Debugger dann a=10 setzt, wird a=11.
Begründung:

Der obige Code kann direkt umgeschrieben werden in:

[highlight=epc]
a=10u08

if a==10 then a=a+1 endif
if a!=10 then a=a-2 endif; /* else */
[/highlight]

1.) a wird 10 zugewiesen
2.) a ist gleich 10 und wird damit um 1 erhöht -> a=11
3.) a ist nicht 10 und damit wird a um 2 dekrementiert -> a=9

Nun manuell a=10 über Debugger zuweisen:

1.) a=10
2.) da a sich geändert hat, greift das validierungsschema und für die erste Anweisung im If-Zweig aus also a um einen erhöhen -> a=11
3.) gegenüber der vorigen Situation im Durchlauf hat sich nichts geändert, da a nun gleich 11 und damit nicht 10 ist -> a bleibt 11

Ich denke, jetzt ist klar, warum else nutzen eine schlechte Idee sein kann und warum ich der Meinung bin, das das verboten werden müßte.

Gruß,
Bernd

[pio]

ELSE hat durchaus seine Berechtigung, man muss nur im Kopf behalten, dass auch Else nur dann ausgeführt wird, wenn die Abfragebedingung sich überhaupt geändert hat. Hat sich nix geändert, wird werde then noch else ausgeführt.

Ausnahme:
Bei inneren geschachtelten ifs wird imer geprüft, sofern die äussere if-Bedingung sich geändert und damit das äussere if überhaupt durchlaufen wird.

Aber natürlich könnte man auch in inneren ifs alles mit if BLA und if ! BLA erschlagen.

[saft6luck]

Also ein Aufruf der Art
[highlight=epc]
a=10u08
write_direct('9/2/0'u08, a, Testwert)
a=11u08
[/highlight]

ergibt bei Dir dann 11 und nicht 10?

Nicht nur bei mir!

PS: Im übrigen bin ich der Meinung das ELSE verboten werden müßte weil es Nebenwirkungen hat!

Nein, es gehört IMHO nur vernünftig implementiert.

[saft6luck]

[highlight=epc]
Der obige Code kann direkt umgeschrieben werden in:

Um etwas präziser zu sein: Der Code wird direkt so umgeschrieben

Ich denke, jetzt ist klar, warum else nutzen eine schlechte Idee sein kann und warum ich der Meinung bin, das das verboten werden müßte.

Die Sache mit 'else' ist ja nun ein alter Hut. Allerdings sollte genau die Umschreibung nicht identisch mit der Funktionsweise von else sein. Wenn man es also verbieten sollte, dann weil es mit der Event-behafteten Funktion des IFs wenig Sinn macht (Hauptebene). Was soll auch ablaufen, wenn der Event nicht eintritt???

In allen Unterebenen (Verschachtelung) mach es jedoch durchaus Sinn, allerdings ist hier die zweifelhafte Umschreibung unglücklich.

Else muss ein richtiges 'entweder-oder' werden. Wer die momentane Bedeutung will, soll es auch entsprechend 'umschreiben'.

[enertegus]

[highlight=epc]
if change( Rollo_Sonnenaufgang_m_s ) then {
if ( Rollo_Sonnenaufgang_m_s < 0s08 ) then {
Rollo_Sonnenaufgang_m_s = Rollo_Sonnenaufgang_m_s + 60s08;
Rollo_Sonnenaufgang_h = sunrisehour() - 1u08;
} endif;
write('0/0/1'u08,10);
} endif
[/highlight]
So, das Ganze ist echt ein Initialisierungsproblem: Die innere If-Abfrage hat beim Systemstart ein invalid-Flag und wird daher ausgewertet. Das Umzubauen ergibt ein größeres Problem - ob und wie wir das für das nächste Release ändern, ist noch nicht abzusehen.

Ein Workaround ist wie immer die Empfehlung, die Verschachtelung zu vermeiden (ich hör Euch schon aufheulen).
[highlight=epc]
if change( Rollo_Sonnenaufgang_m_s ) and ( Rollo_Sonnenaufgang_m_s < 0s08 ) then {
Rollo_Sonnenaufgang_m_s = Rollo_Sonnenaufgang_m_s + 60s08;
Rollo_Sonnenaufgang_h = sunrisehour() - 1u08
} endif
[/highlight]

[Tessi]

Ich halte das Ganze für ein Validierungsproblem. Damit wurde uns letztlich ein Bärendienst erwiesen weil es vielen von uns offenbar nicht mehr gelingt, das Verhalten vom Code sicher vorherzusagen. Eben weil nicht mehr klar ist, zu welchem Zeitpunkt eine Änderung als solche verarbeitet wird. Bei diesem Code:
[highlight=epc]
if a==10 then a=a+1 else a=a-2 endif
[/highlight]dachte ich, wenn sich a ändert, dann wird entweder then oder else ausgeführt, aber egal was dabei passiert, garantiert nie beide zusammen.
Wird der obige Code aber umgeschrieben in:
[highlight=epc]
if a==10 then a=a+1 endif
if a!=10 then a=a-2 endif; /* else */
[/highlight]dann ändert das die Situation vom Verständnis her, denn nun kann die zweite Abfrage durchaus von der Aktion im ersten then-Zweig beeinflußt sein. Nur, sieht die zweite Abfrage das schon durch die erste Abfrage veränderte Ergebnis (das erwartet jeder "normale" Sprachen gewohnte Programmierer - im Gegensatz zum ersten Beispiel, wo er es eben nicht erwartet) oder sieht sie das erst im nächsten Durchlauf? Und wenn erst da, gilt der Wert dann als veränder oder nicht?

[highlight=epc]
a=0u08
if a>=10 then a=a+1 endif
[/highlight]Endloszähler oder nicht? Wenn ja warum, wenn nein, warum nicht?
Ich würde jetzt einen in jedem Durchlauf inkrementierten Zähler erwarten...
[highlight=epc]
a=a+1u08
[/highlight]Endloszähler oder nicht? Wenn ja warum, wenn nein, warum nicht?
Hier meine ich mich daran erinnern zu können, das mal gesagt wurde, das dieses Statement nur einmal ausgeführt wird. Aber warum führt die Änderung von a im nächsten Durchlauf nicht zur erneuten Ausführung?

Warum werden die Statements in Code wie diesem dann aber doch mehrfach ausgeführt
[highlight=epc]
a=0u08
if xxx then a=a+1
b=a+1
c=b+1
d=c+1
[/highlight]Oder ändern sich b, c und d gar nicht mehr?

Irgendwie habe ich trotz (oder vielleicht gerade wegen?) aller Ausführungen keine klare Vorstellung (mehr) davon, wann eine Bedingung überhaupt geprüft wird und wann scheinbar unbedingte Statements wie
[highlight=epc]
b=a+1
[/highlight]überhaupt ausgeführt werden.

[enertegus]

[highlight=epc]
if a==10 then a=a+1 else a=a-2 endif
[/highlight]dachte ich, wenn sich a ändert, dann wird entweder then oder else ausgeführt, aber egal was dabei passiert, garantiert nie beide zusammen.

Tun sie auch nicht. EDIT: Im Beispiel kann das aber schon passieren, da ja im then/else-Zweig direkt die Variable verändert wird.

[highlight=epc]
a=0u08
if a>=10 then a=a+1 endif
[/highlight]Endloszähler oder nicht? Wenn ja warum, wenn nein, warum nicht?

Nein, a ist kleiner 10?

[highlight=epc]
a=a+1u08
[/highlight]Endloszähler oder nicht? Wenn ja warum, wenn nein, warum nicht?

Weil es vom Eibparser nicht akzeptiert wird.

[Tessi]

[highlight=epc]
a=10u08
if a==10 then a=a+1 else a=a-2 endif
[/highlight]Im ersten Zyklus wird also a=11. Damit hat sich a geändert, ist ungleich 10 und so wird im nächsten Zyklus a=9. Damit hat sich a wieder geändert, ist ungleich 10 und so wird im folgenden Zyklus a=7. Und so weiter? Da a auch nach Unterlauf immer ungerade bleiben wird, hätte ich so eine Art Endlosschleife gebaut - hier nicht sonderlich tragisch, aber falls gesendet werden würde...
Ich meine irgendwo gelesen zu haben, das genau das nicht passiert, aber warum sollte das so sein?

Wird der obige Code aber intern umgesetzt in:
[highlight=epc]
if a==10 then a=a+1 endif
if a!=10 then a=a-2 endif; /* else */
[/highlight]dann ändert das die Situation vom Verständnis her, dann frage ich mich, ob die zweite Abfrage den schon veränderten Wert gleich sieht, oder erst im nächsten Durchlauf, oder erst einmal gar nicht und a muß "von außen" erneut verändert werden, damit die beiden Abfragen überhaupt erneut ausgewertet werden...

Das letzte Beispiel:
[highlight=epc]
a=0u08
if a>=10 then a=a+1 endif
[/highlight]enthält leider einen Copy&paste-Fehler. Es sollte so aussehen:
[highlight=epc]
a=0u08
if a>=0 then a=a+1 endif
[/highlight]Vergleichbar dem ersten Beispiel: Ist es jetzt ein Endloszähler oder nicht? Wenn ja warum, wenn nein, warum nicht?

Wie sieht es mit diesem Code aus:
[highlight=epc]
a=0u08
if xxx then a=a+1
b=a+1u08
c=b+1u08
d=c+1u08
[/highlight] Ist der OK und werden b, c und d angepasst wenn a sich ändert? Wenn ja, schon im gleichen Zyklus oder erst im jeweils folgenden, wenn nicht, warum nicht? Oder wird
[highlight=epc]
b=a+1u08
[/highlight]ebensowenig vom Parser akzeptiert wie
[highlight=epc]
a=a+1u08
[/highlight]
?

Ist es richtig, das alles, was innerhalb eines then- oder else-Zweiges steht wird vor Ausführung des Zweiges invalid wird und somit alle inneren Statements sich so verhalten, wie man das als Programmierer von anderen Sprachen gewohnt ist - also immer ausgewertet werden, egal ob sich ein Parameter geändert hat - also quasi das Validierungsschema hier nicht zur Anwendung kommt? Unterliegt - vereinfacht ausgedrückt - also nur die äußerste Bedingung einer verschachtelten Struktur dem Validierungsschema, die inneren dann nicht mehr?

[enertegus]

Ist es richtig, das alles, was innerhalb eines then- oder else-Zweiges steht wird vor Ausführung des Zweiges invalid wird und somit alle inneren Statements sich so verhalten, wie man das als Programmierer von anderen Sprachen gewohnt ist - also immer ausgewertet werden, egal ob sich ein Parameter geändert hat - also quasi das Validierungsschema hier nicht zur Anwendung kommt? Unterliegt - vereinfacht ausgedrückt - also nur die äußerste Bedingung einer verschachtelten Struktur dem Validierungsschema, die inneren dann nicht mehr?

Schau doch noch mal in Ruhe das PDF dieses Threads durch. Da ist das genau mit Beispielen erläutertet.
Die If-Abfrage invaldiert "ihren" then Zweig, so dass dieser im Falle einer wahren Bedingung auch ausgeführt wird. Somit hängt der then Zweig natürlich nicht mehr unmittelbar von der Validierung der Variablen im then-Zweig ab, sondern von der Validierung der if-Abfrage.

[saft6luck]

Die If-Abfrage invaldiert "ihren" then Zweig, so dass dieser im Falle einer wahren Bedingung auch ausgeführt wird. Somit hängt der then Zweig natürlich nicht mehr unmittelbar von der Validierung der Variablen im then-Zweig ab, sondern von der Validierung der if-Abfrage.

Ist das jetzt ein 'ja' oder 'nein' oder 'ja, aber mit ein paar Ausnahmen' oder 'nein, denn ... '?

Für mich persönlich ist deine Aussage wenig hilfreich, genauso wie das ewige "invlaidieren" etc. wenn man überhaupt nicht sagen kann, wer wann und wie ausgeführt wird und man diese Flags auch nirgends sehen oder beeinfussen, geschweige denn debuggen kann.

Was soll den eine Aussage wie: "Tun sie auch nicht, sondern eben von einem auf den nächsten Zyklus." wenn die ganze Zeit klar ist/war (siehe auch dein Beispiel in deinem angeführten Dokument), dass der else-Zweig sofort zusätzlich ausgeführt werden kann?

Soll ich jetzt auch noch bedenken, dass im nächsten Zyklus der else-Zweig abgearbeitet werden kann und sich die entsprechende Bedingung schon längst geändert haben kann? Ist das deine Art von Determinismus?

Für mich steht ein Neuanfang an, so oder so!

[Tessi]

Schau doch noch mal in Ruhe das PDF dieses Threads durch. Da ist das genau mit Beispielen erläutertet.

Die Crux mit Beispielen ist, das diese immer nur einen begrenzten Teil darstellen können. Daher gelingt es auch nicht, daraus die zugrunde liegende Logik eindeutig zu rekonstruieren und somit Rückschlüsse auf mein jeweiliges Problem ziehen zu können. Aber das sollte auch gar nicht nötig sein, denn den jeweiligen Entwicklern muß die Logik doch vollständig bekannt sein. Da sollte es nicht all zu schwer sein, sie auch komplett formal zu beschreiben.

Die If-Abfrage invaldiert "ihren" then Zweig, so dass dieser im Falle einer wahren Bedingung auch ausgeführt wird. Somit hängt der then Zweig natürlich nicht mehr unmittelbar von der Validierung der Variablen im then-Zweig ab, sondern von der Validierung der if-Abfrage.

Diese "Antwort" wiederholt doch die Passage, die ich hinterfragt habe, das hilft mir nicht weiter...

Ist das jetzt ein 'ja' oder 'nein' oder 'ja, aber mit ein paar Ausnahmen' oder 'nein, denn ... '?

Das war und ist auch immer noch auch meine Frage...


Ich verstehe ja auch, wenn Fragen mit beantwortet werden.
Aber dazu muß die Dokumentation auch tatsächlich alles vollständig abdecken. Das ist aus meiner Sicht bei der EPC-Doku noch nicht der Fall.