Parameter lassen sich nicht zurückschreiben

[runxel]

Ich steh gerade vor dem Rätsel (und auf dem Schlauch), dass ich meine Parameter nicht in Abhängigkeit ändern kann.
Das sieht dann so aus (Parameterscript):

VALUES "papersize" "A3", "A2", "A1", "A0"
IF "papersize" = "A3" THEN
	PARAMETERS  A = 0.42, B = 0.297
ENDIF 
...
...

Naheliegenderweise ein Objekt, dass zum Platzieren auf dem Layout gedacht ist; über ein Dropdownfeld kann man schnell die nötige Grösse auswählen – zumindest in der Theorie.
Tatsächlich aber passiert genau nichts, A und B bleiben unverändert.
Wo sehe ich den Wald vor lauter Bäumen nicht? Danke schonmal recht herzlich!

[Anonymous]

Ich würde es ohne Anführungszeichen versuchen:
IF papersize .....

[Ma_Scht]

Och Jochen, jetzt warst Du schneller 🙂 Gruß

[runxel]

"Jochen Suehlo" wrote:
Ich würde es ohne Anführungszeichen versuchen:
IF papersize .....

Danke Jochen! EDIT: Dir auch, Mario 😉
Das war's natürlich 🙄
Dass GDL so inkonsistent mit seinen Anführungszeichen ist, geht mir so dermaßen auf den Keks.
Bei LOCK brauchts sie, bei PARAMETERS wieder nicht... 👿

[Anonymous]

Da ist gar nichts inkonsistent. Zumindest nicht an der Stelle. Mal geht es um den Inhalt und mal um den Parameter selbst.

LOCK "papersize" : Du willst ja nicht den Inhalt von Papersize sperren, sondern den Parameter
PARAMETER papersize = "A3" : Du willst ja nicht den Parameter in A3 umbenennen, sondern den Inhalt ändern.

Das sind Programmiersprachen-Syntax Basics. 😉

[runxel]

"Ove" wrote:
Da ist gar nichts inkonsistent. Zumindest nicht an der Stelle. Mal geht es um den Inhalt und mal um den Parameter selbst.

LOCK "papersize" : Du willst ja nicht den Inhalt von Papersize sperren, sondern den Parameter
PARAMETER papersize = "A3" : Du willst ja nicht den Parameter in A3 umbenennen, sondern den Inhalt ändern.

Das ist zwar eine sehr greifbare Erklärung, sie funktioniert aber auch nur genau bei den eben genannten (und selbst da eigentlich nicht, siehe unten). Bei VALUES z.B. dürften deiner Version nach keine Anführungszeichen um den Parameter sein – sind sie aber.
Davon abgesehen: Eine Grundsätzlichket für mich ist, dass "das hier stets Strings sind".

Deine Erklärung ist auch dahingehend nicht zutreffend, weil man den Inhalt einer Variablen (Parameter) grundsätzlich nicht sperren kann, es sei denn sie ist immutable. Das müsste man aber entweder bei der Erschaffung (const) angeben, oder bei manchen Sprachen umgekehrt angeben, dass die Variable mutable (mut) ist. Den Inhalt danach sperren oder entsperren geht nie. Das wäre auch Murks, weil der Status der Variable klar sein muss. Daher ist sowieso anzunehmen dass LOCK niemals den Inhalt sperrt.
Variablen umbenennen geht erst recht niemals, das wäre ja genauso tödlich.
Beides Programmiersprachenbasics. 😐

[Anonymous]

Bei VALUES z.B. dürften deiner Version nach keine Anführungszeichen um den Parameter sein – sind sie aber.

Sehr wohl. Auch hier will ich den Parameter nicht ändern, sondern eine Liste erzeugen, die für den Parameter "parameter" gilt und nicht für den Inhalt des Parameters/der Variablen parameter. Das ergibt einen ziemlichen Sinn, wenn du die Group-Befehle anschaust, wo es tatsächlich um den Inhalt der Variablen/Parameter geht.

Auch bei LOCK ist es logisch, weil du nicht wirklich den Inhalt sperrst, sondern für das UI die Zugänglichkeit des Eingabefeldes.

Also ich habe da syntaktisch keinerlei Probleme. 😉 Für mich ist das sowas von logisch. 🙂

[Anonymous]

const und immutable gibt es bei GDL nicht. Du kannst keine Konstanten deklarieren. Noch nicht mal Typen. DAS ist eine Inkonsistenz, das Variablen während des Skriptdurchlaufes durchaus mal ihren Typ ändern können. (Oder zumindest in früheren Versionen als 21 konnten.)

[runxel]

Na gut, Ove, wenn du keine Probleme damit hast, ist das schön.
Lass ich mal gelten. 😉
(Finde ich wirklich immer wieder interessant, wie die "Herkunft" einen unterschiedliche Sichtweisen einnehmen lassen kann. Daher großes Danke für dein Input, Ove! Gerade weil wir ganz unterschiedliche Philosophien haben)

Liegt vielleicht an meinem Alter, dass ich das als unlogisch empfinde, weil ich mit vernünftigen Sprachen aufwachsen durfte, und nicht mit prähistorischen Krüppeln (*hust*GOTO*hust*). 😄

"Ove" wrote:
const und immutable gibt es bei GDL nicht.

Ist mir bewusst. Ich hab das nur benutzt, um zu zeigen, dass dein Argument nicht stichhaltig ist.

"Ove" wrote:

Bei VALUES z.B. dürften deiner Version nach keine Anführungszeichen um den Parameter sein – sind sie aber.

Sehr wohl. Auch hier will ich den Parameter nicht ändern, sondern eine Liste erzeugen, die für den Parameter "parameter" gilt und nicht für den Inhalt des Parameters/der Variablen parameter.

Okay, ist ne Grauzone. Es sind erstmal nur mögliche Werte, aber zugleich wird ja einer der Werte als default gesetzt, und damit der Parameter tatsächlich geändert; er erhält einen Wert.

"Ove" wrote:
Das ergibt einen ziemlichen Sinn, wenn du die Group-Befehle anschaust, wo es tatsächlich um den Inhalt der Variablen/Parameter geht.

Die GROUP Befehle sind das schlechteste Beispiel überhaupt. Noch schlimmer kann man eine Sprache nicht gestalten.
PLACEGROUP braucht entweder Anführungszeichen oder nicht, je nach dem ob die Gruppe einfach nur eine Gruppe oder das Resultat aus einer Operation ist. Bei beidem wird Geometrie ausgegeben, die Herkunft sollte unerheblich sein.

"Ove" wrote:

Auch bei LOCK ist es logisch, weil du nicht wirklich den Inhalt sperrst, sondern für das UI die Zugänglichkeit des Eingabefeldes.

Das ist natürlich eine Besonderheit bei GDL. Nur wie ich bereits vorhin gesagt habe: weil man den Inhalt von Variablen eh nicht sperren kann, ist es erst recht nicht logisch.

"Ove" wrote:
Noch nicht mal Typen. DAS ist eine Inkonsistenz, das Variablen während des Skriptdurchlaufes durchaus mal ihren Typ ändern können.

Das sieht selfgdl anders.
Was genau meinst du?

[Anonymous]

Das sieht selfgdl anders.
Was genau meinst du?

Dass es in GDL unterschiedliche Typen gibt und auch geben muss ist klar, aber du kannst sie nicht deklarieren.

name = 1

Könnte ein Typ boolean, integer oder real sein.

Schreibst Du:

name = 1
IF name = 1 THEN block 1,2,3
name = 2.7
IF name = 1 THEN block 3,4,5

Gibt es eine Typenwarnung. Aber erst beim zweiten IF. Weil kurz davor der Typ von integer auf real gewechselt hat. Das ist inkonsequent und schwer zu vermitteln! 😉