Warum dürfen Variablen nicht mit Zahlen beginnen?

Ich denke, das hat etwas mit dem Parser/Compiler zu tun. Die Token, die er bekommt, sind entweder Elemente der Programmiersprache oder deren Inhalte, wie z.B. Strings. Deshalb werden Strings ja auch immer(?) in Hochkommata oder Anführungszeichen gesetzt. Würde man Zahlen als Variablen zulassen, müssten "echte" Zahlen auch irgendwie gekennzeichnet werden und da ist die bestehende Regelung einfach praktischer. Das ist mal meine Vermutung ..

mar05
 
Ich stimme Mar zu. Zudem denke ich, dass es mehr ein Relikt aus alten Zeiten ist. Heute koennte man das bestimmt anders machen. Nur damals war der Compiler einfacher gestrickt und Speicher war knapp.
 
Was heißt hier Relikt aus alten Zeiten? Wie sollten denn Variablen von Zahlen unterschieden werden, wenn beide dieselbe Syntax hätten?
 
Mal ein konkretes Beispiel:

Variable: abc String: "abc"
Variable: 123 Zahl: 123 -> Das kann der Parser nicht so ohne weiteres auseinanderhalten. Also müssten Zahlen anders behandelt werden, z.B. »123«. Das ist aber eindeutig umständlicher, als reine Zahlen als Variablen auszuschließen.

Da eine Unterscheidung, ob eine Zahl oder Variable vorliegt, zumindest vom Parser nicht gemacht werden kann (denke ich), würde es die Erstellung eines Syntaxbaumes enorm erschweren.

mar05

ps: Da meine Theoretische Informatik schon lange zurückliegt, bin ich mir nicht ganz sicher, aber es erscheint doch einleuchtend, oder? ;)

edit: Die eigentliche Fragestellung war ja, warum Variablen nicht mit Zahlen beginnen dürfen. Das ist wahrscheinlich wirklich nur eine Konvention, zudem verhindert es, dass man 'aus Versehen' nur Ziffern benutzt.
 
Zuletzt bearbeitet:
Da eine Unterscheidung, ob eine Zahl oder Variable vorliegt, zumindest vom Parser nicht gemacht werden kann (denke ich), würde es die Erstellung eines Syntaxbaumes enorm erschweren.
Das sollte wohl weniger das Problem sein. Der PHP-Parser erkennt ja auch undefinierte Konstanten und behandelt diese als String. So koennte das dann auch mit Zahlen laufen.
Die Frage waere eben nur wie man an die Zahl 7 kommt wenn man eine Variable namens 7 belegt. ;)
 
..
Die Frage waere eben nur wie man an die Zahl 7 kommt wenn man eine Variable namens 7 belegt. ;)
Genau das ist das Problem. Wenn die Sprache typsicher ist, geht es noch solange nicht so etwas da steht:
Code:
// Pseudocode
int 7 = 0;
int i = 6 + 1;
int j = 7 + 1; // Compiler Fehler: mehrdeutig
Man muesste zumindest verbieten, dass eine Ziffernvariable den Typ int hat. Das waere die einzige Einschraenkung, die mir gerade einfaellt.

EDIT: Mit Relikt meinte ich die Typsicherheit. Die war naemlich nicht immer gegeben :D.
 
Zuletzt bearbeitet:
Wisst ihr eigentlich, wie schwierig es ist, die Syntax einer Sprache so zu bestimmen, dass sie zwar einerseits einfach zu schreiben und zu verstehen ist aber andererseits auch idiotensicher ist, so dass es also keine syntaktischen oder semantischen Mehrdeutigkeiten gibt, die zu Fehlinterpretationen führen könnten? Dazu kommt dann noch der ständige Ruf nach Geschwindigkeit und Effektivität, die ebenfalls in der Syntax berücksichtigt werden muss. Denn je komplexer eine Sprache ist, desto komplexer ist auch die Interpretation dieser Sprache, was wiederum mit dem Ressourcenverbrauch (Zeitaufwand, Speicherverbrauch) eng in Verbindung steht.

Je strikter die Sprache syntaktisch definiert ist, je weniger „Auswahlmöglichkeiten“ es also gibt, desto effektiver ist auch ihre Interpretation. Denn der Interpreter muss nicht erst prüfen, ob semantisch nicht A oder B oder doch vielleicht C gemeint ist, wenn syntaktisch definitiv nur A erlaubt ist.

Dies ist aber nicht nur auf Programmier- oder Skriptsprachen bezogen sondern auf alle Sprachen allgemein. Wer beispielsweise den Unterschied zwischen HTML und XHTML wirklich kennt, der weiß was ich damit meine.
 
Hallo,


double d = 123e45; ist beispielsweise gültiger Javacode. In anderen Sprachen wird es ähnlich aussehen. Man muss aber nicht mal soweit gehen, um unlösbare Doppeldeutigkeiten zu erzeugen. Was ist beispielweise mit dem Token 7? Ist das jetzt eine Zahlenkonstante oder ein Bezeichner?

Grüße,
Matthias

Oh nein, darauf hätte ich tatsächlich selber kommen müssen. Gut, bin ich aber nicht :-(

Nachdem das zu 100% geklärt ist, kann ich heute Nacht bestimmt gut schlafen. ;-)

Daniel
 
Zurück