JavaScript Proposal: do-Expresssions

[1unitedpower]

Moin!

Dem JavaScript-Standardkomittee liegt ein neues Proposal vor: do-Expressions ummanteln Statements und geben den finalen Wert der Berechnung zurück. Für mich persönlich ist das eines der größten Highlights seit Anbeginn der JavaScript-Epoche.

const salutation = do {
    switch (animal) {
        case dog:
            'good boy';
            break;
        case kitty:
            'meow';
            break;
        case goose:
            'muuuuuuh';
            break;
    }
};

Der verlinkte Blog-Beitrag enthält deutlich bessere Beispiele als mein dummes Greeter-Script. Potenzielle Anwendungsfälle für do-Expressions sind Template-Literale, JSX-Templates und Alternativen zu IIFEs und zum Ternären Operator.

Wie so oft, kann man das Feature bereits heute nutzen, wenn man Babel als Precompiler einsetzt. Bis das Feature allerdings standadisiert ist, können wie immer noch Änderungen an Syntax und Semantik anfallen.

[Orlok]

Hallo 1unitedpower

Ich teile deine Begeisterung über den Vorschlag für do-Expressions größtenteils und füge mal den Link zum Proposal hinzu. Wie du schon sagtest, sind wir allerdings noch ziemlich am Anfang des Standardisierungsprozesses, und ob und wenn ja was daraus wird, muss sich erst noch zeigen. Es sind schon Vorschläge gekippt worden, die in dem Prozess bereits deutlich weiter fortgeschritten waren.

Meine Freude über den Vorschlag beruht im Übrigen auch nicht so sehr darauf, dass ich do-Expressions, insbesondere in ihrer gegenwärtigen Fassung, für der Weisheit letzten Schluss halten würde, sondern vielmehr darauf, dass durch diesen Vorschlag hoffentlich eine längst überfällige Diskussion angestoßen wird. Nämlich die über die Frage, inwieweit nicht viele Sprachkonstrukte die bislang als Statements definiert sind, in Zukunft nicht besser als Ausdrücke angesehen werden sollten.

Gewöhnliche Funktionen als Ausdrücke definieren zu können war sicher eine der besten Designentscheidungen bei der Entwicklung von JavaScript. Dem verdankt die Sprache einen großen Teil ihrer Ausdrucksstärke. Dass viele andere Konstrukte, darunter insbesondere Kontrollstrukturen wie if und switch, jedoch lediglich als Statements implementiert wurden, ist daher umso bedauerlicher.

Könnte man in JavaScript Code ähnlich diesem Elixir-Beispiel schreiben, wäre das in vielen Situationen nützlich. Einige davon sind in dem von dir verlinkten Artikel beschrieben.

# Expression for a single condition

value = if condition do
    "done this"
else
    "done that"
end


# Expression for multiple conditions

result = cond do
    number > 10 ->
        "greater than 10"    # EDIT:
                             # Gunnar hat natürlich recht,
    number > 20 ->           # das sollte in umgekehrter
        "greater than 20"    # Reihenfolge geprüft werden. ;-)

    number > 30 ->
        "greater than 30"
end

Den Trend weg von Statements hin zu Expressions verkörpert auch Rust, das syntaktisch etwas näher an JavaScript dran ist als Elixir. Auch in dieser Sprache gibt es bedingte Ausdrücke mit Anweisungsblöcken die zu einem Wert aufgelöst werden, der bei Bedarf weiterverarbeitet werden kann. Der Wert des letzten Ausdrucks wird zurückgegeben.

// Conditional expression

let value = if condition {
    "done this"
} else {
    "done that"
};

Ich würde mir wünschen, dass zunächst einmal gewissenhaft geprüft wird, inwieweit entsprechende Statements in JavaScript nicht direkt in Expressions umgewandelt werden können, ohne dabei das ganze Kartenhaus zum Einsturz zu bringen, bevor ein weiteres Syntaxelement hinzugefügt wird. Sollte man dabei wider Erwarten zu dem Ergebnis kommen, dass dies nicht möglich ist, oder aber dass do-Expressions einen zusätzlichen Nutzen bringen, würde ich die Standardisierung der Syntax auf jeden Fall begrüßen.

Gruß,

Orlok

[Gunnar Bittersmann]

@@Orlok

Könnte man in JavaScript Code ähnlich diesem Elixir-Beispiel schreiben

Kann man doch.

# Expression for a single condition

value = if condition do
    "done this"
else
    "done that"
end

value = condition ? "done this" : "done that";

# Expression for multiple conditions

result = cond do
    number > 10 ->
        "greater than 10"

    number > 20 ->
        "greater than 20"

    number > 30 ->
        "greater than 30"
end

result = number > 10 ? number > 20 ? number > 30 ? "greater than 30" : "greater than 20" : "greater than 10" : result;

Wobei da zur besseren Lesbarkeit Klammern gesetzt werden sollten.

Und die Bedingungen auch besser andersrum, dann braucht man keine Klammern:

result = number > 30 ? "greater than 30" : number > 20 ? "greater than 20" : number > 10 ? "greater than 10" : result;

Nachtrag: Oder man schreibt das mehrzeilig, dann braucht man auch keine Klammern:

result = number > 10 
	? number > 20
		? number > 30
			? "greater than 30"
			: "greater than 20"
		: "greater than 10"
	: result;

bzw.

result = number > 30
	? "greater than 30"
	: number > 20
		? "greater than 20"
		: number > 10
			? "greater than 10"
			: result;

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Könnte man in JavaScript Code ähnlich diesem Elixir-Beispiel schreiben

Kann man doch.

Deine Beispiele weiter unten zeigen, dass man genau das nicht kann 😝

LG,
CK

[pl]

Ja, schön. Ich arbeite schon lange und sehr viel damit, es ist ganz einfach zweckmäßig. U.a. auch hierbei: x = y == z ? a : do{..}; MfG

[pl]

Ja, schön. Ich arbeite schon lange und sehr viel damit, es ist ganz einfach zweckmäßig. U.a. auch hierbei: x = y == z ? a : do{..}; MfG

Wenn Ihr mir hier schon Perl draus macht, mal ein etwas ausführlicheres Beispiel zu do{}:

    if( my $keyword = $self->param('fetch') ){
        if( $keyword eq 'img' ) { 
            $self->{CONTENT} = do{
                my $fh = IO::File->new;
                $fh->open( "$ENV{DOCUMENT_ROOT}/red.gif", O_BINARY|O_RDONLY) 
                    or die "Fehler beim Lesen der Grafikdatei: $!\n";
                    
                read($fh, my $bin, -s $fh);
                $fh->close;
                $bin;
            };
        }
        else{
            # DEMO 
            die "Beim Lesen der Grafikdatei gab es einen Fehler!\n"; 
        }
    }

Oder wenn mal eben vorher noch was berechnet werden muss:

2 => do{$year--; "31.12.$year"}

MfG

[Gunnar Bittersmann]

@@pl

Wenn Ihr mir hier schon Perl draus macht

Ihr? Warst du es nicht, der die Kategorie auf Perl gesetzt hat? (Ich kann keine Änderungshistorie erkennen.)

LLAP 🖖

[pl]

Wenn Ihr mir hier schon Perl draus macht

Ihr? Warst du es nicht, der die Kategorie auf Perl gesetzt hat? (Ich kann keine Änderungshistorie erkennen.)

Nein warum sollte ich, wenn ich ein JS Beispiel poste. MfG

[Gunnar Bittersmann]

@@pl

Ihr? Warst du es nicht, der die Kategorie auf Perl gesetzt hat? (Ich kann keine Änderungshistorie erkennen.)

Nein warum sollte ich, wenn ich ein JS Beispiel poste. MfG

Ich hab das dann mal auf JavaScript zurückgesetzt. Und tatsächlich, Änderungen der Kategorie werden nicht in einer Änderungshistorie kenntlich gemacht.

Aber wenn das JavaScript-Code sein sollte, dann hab ich doch noch eine Frage dazu. Aber an Ort und Stelle…

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Ich hab das dann mal auf JavaScript zurückgesetzt. Und tatsächlich, Änderungen der Kategorie werden nicht in einer Änderungshistorie kenntlich gemacht.

Zumindest nicht öffentlich. Für fraglichen Beitrag (m1709752) wurden bisher genau zweimal die Tags geändert. Die konkrete Änderung wird allerdings nicht protokolliert.

Bis demnächst
Matthias

[dedlfix]

Tach!

Wenn Ihr mir hier schon Perl draus macht

Ihr? Warst du es nicht, der die Kategorie auf Perl gesetzt hat? (Ich kann keine Änderungshistorie erkennen.)

Nein warum sollte ich, wenn ich ein JS Beispiel poste.

Ich hab die Kategorie geändert. Wie soll das ein Beispiel in Javascript sein, das du angeblich schon lange verwendest, wenn es grad mal in der Diskussion ist, sowas in die Sprache aufzunehmen? Deswegen nahm ich an, du beziehst sich mal wieder vom Thema abschweifend auf irgendwas in Perl.

dedlfix.

[pl]

Deswegen nahm ich an, du beziehst sich mal wieder vom Thema abschweifend auf irgendwas in Perl.

Natürlich gebe ich auch meine Erfahrungen die ich in JS mache gerne weiter. Wie DU das persönlich bewertest ist Deine Sache, aber wenn DU eine Kategorie änderst ist das nicht mehr Deine Sache. MfG

[Tabellenkalk]

Hallo,

Natürlich gebe ich auch meine Erfahrungen [...] gerne weiter.

Das ist gut so, dafür ist ja dieses Forum da. Es wäre dann aber auch hilfreich, die gestellten Fragen zu beantworten.

[Palaver]

Palaver ist dagegen so gar nicht hilfreich.

Gruß
Kalk

[Gunnar Bittersmann]

@@pl

Ja, schön. Ich arbeite schon lange und sehr viel damit, es ist ganz einfach zweckmäßig. U.a. auch hierbei: x = y == z ? a : do{..}; MfG

do-Expressions sollen doch eine Alternative zum mitunter umständlich handhabbaren ?:-Operator sein. Welchen Sinn macht es, beides gemeinsam zu verwenden?

LLAP 🖖

[pl]

Hi,

do-Expressions sollen doch eine Alternative zum mitunter umständlich handhabbaren ?:-Operator sein.

Wie kommst Du denn darauf? Das Eine hat doch mit dem Anderen nichts zu tun.

Welchen Sinn macht es, beides gemeinsam zu verwenden?

Nun, eine ternary Zuweisung macht den Code kürzer, weil die Bedingung gleich mitgegeben ist. Also entfällt auch eine vorherige Deklaration per Schlüsselwort (var, const..), weil das ebenso gleich mit der Zuweisung erledigt wird. Und in einem do{}-Block schließlich kann man weitere Codezeilen unterbringen, bspw. zur Berechnung eines bestimmten Wertes, der, damit das funktioniert, in der letzten Zeile des do{}-Block stehen muss:

var x = x === 1 ? x : do{
   var y = x * 99;
   var z = -1 * x;
   y + z >>> 0;
};

MfG

[Gunnar Bittersmann]

@@pl

do-Expressions sollen doch eine Alternative zum mitunter umständlich handhabbaren ?:-Operator sein.

Wie kommst Du denn darauf?

1. Im verlinkten Artikel unter „What is ternary hell?“. (Abschnitt lässt sich nicht verlinken. Saubere Arbeit, freeCodeCamp. Nicht.)

2. „instead of awkward nested ternaries“ im ebenfalls verlinkten Proposal

Das Eine hat doch mit dem Anderen nichts zu tun.

Ach, nein?

LLAP 🖖

[pl]

hi,

Das Eine hat doch mit dem Anderen nichts zu tun.

Ach, nein?

Nein. Man kann jedoch beides auf eine zweckmäßige Art und Weise verbinden, siehe meine Beispiele und die sind aus der Perl-Praxis. Und die sind das deswegen weil in JavaScript noch keine Erfahrungen mit do{}-Blöcken vorliegen.

Auf das Wesentliche kommt es an: do-Expressions ummanteln Statements und geben den finalen Wert der Berechnung zurück. MfG

[dedlfix]

Tach!

Dem JavaScript-Standardkomittee liegt ein neues Proposal vor: do-Expressions ummanteln Statements und geben den finalen Wert der Berechnung zurück. Für mich persönlich ist das eines der größten Highlights seit Anbeginn der JavaScript-Epoche.

Ich finde es gut, wenn ihr euch darüber begeistern könnt. Für meinen Teil betrachte ich die Sache mit dem Nutzen im Hinterkopf, denn ich davon haben kann. Der Erfolg einer Sprache hängt nicht unbedingt davon ab, was aus akademischer Sicht die Sprache in Richtung eines bestimmten Paradigmas bewegt, sondern was man im täglichen (Berufs)leben davon hat. Typescript beispielsweise ist so erfolgreich, weil es die Sprache um Dinge erweitert, die einen großen praktischen Nutzen haben. Dabei bleibt die eigentlichen Sprache weitgehend erhalten, es kommen keine außergewöhnlichen Elemente hinzu (mit der C#-Brille auf der Nase).

const salutation = do {
    switch (animal) {
        case dog:
            'good boy';
            break;
        case kitty:
            'meow';
            break;
        case goose:
            'muuuuuuh';
            break;
    }
};

Das kann ich heutzutage auch schon als Ausdruck haben.

const animal = 'monkey';
const salutation = {
    dog: 'good boy',
    kitty: 'meow',
    goose: 'muuuuuuh'
}[animal] || 'hi';

Zumindest in der kurzen Form des Beispiels. Es geht so nicht mit falsy Werten, aber die hat man selten in solchen Anwendungsfällen. Komplexe Ausdrücke jedoch, die erst zur Laufzeit berechnet werden, gehen damit, wenn man eine Funktionsreferenz zurückgibt, die man dann aufruft.

dedlfix.

[1unitedpower]

Das kann ich heutzutage auch schon als Ausdruck haben.

const animal = 'monkey';
const salutation = {
    dog: 'good boy',
    kitty: 'meow',
    goose: 'muuuuuuh'
}[animal] || 'hi';

Stimme dir absolut zu, und dein Beispiel ist obendrauf auch noch besser lesbar. Mein Beispiel ist zugegebenermaßen recht pathologisch, deswegen auch nochmal der Hinweis auf den Blogbeitrag, der praktischere Beispiele beinhaltet, insbesondere unter der Überschrift Use in JSX wird ein Anwendungsfall geschildert, den du mit bisherigen Bordmitteln wohl nur schwierig nachbauen kannst, ohne dass die Lesbarkeit darunter leidet.

[dedlfix]

Tach!

Mein Beispiel ist zugegebenermaßen recht pathologisch, deswegen auch nochmal der Hinweis auf den Blogbeitrag, der praktischere Beispiele beinhaltet, insbesondere unter der Überschrift Use in JSX wird ein Anwendungsfall geschildert, den du mit bisherigen Bordmitteln wohl nur schwierig nachbauen kannst, ohne dass die Lesbarkeit darunter leidet.

Ich habe zwar keine Ahnung von JSX. Das Prinzip kenne ich aber von C# und dessen Razor-Syntax in ASP.NET MVC.

const View = ({ loading, error, ...otherProps }) => (
  <div>
    {do {
      if (loading) {
        <Loading />
      } else if (error) {
        <Error error={error} />
      } else {
        <MyLoadedComponent {...otherProps} />
      };
    }}
  </div>
);

Dabei verstehe ich nicht, warum man das in ein do{} kapseln muss. Wenn man diese Anweisung weglässt, hat man doch bereits, was man möchte. Vielleicht gibt das die Syntax nicht her, aber dann wäre es wohl einfacher, die Syntax dahingehend freizügiger zu gestalten, als ein neues Element einzuführen, das wenig Aussagekraft hat. "do" = "tuen", na klar tut Code immer etwas. Zumindest im Deutschen ist das "tuen" in vielen Fällen, wie beispielsweise "Ich tu mal die Pflanzen gießen", ein verzichtbarer Bestandteil, der im Gegenteil sogar stilistisch eher negativ angesehen wird. Vielleicht haben sich da die English Natives nicht so eng mit ihrem "do".

dedlfix.

[1unitedpower]

Dabei verstehe ich nicht, warum man das in ein do{} kapseln muss. Wenn man diese Anweisung weglässt, hat man doch bereits, was man möchte. Vielleicht gibt das die Syntax nicht her

So ist es, die JSX-Syntax erlaubt in den geschweiften Klammern nur JS-Ausdrücke, keine Statements.

aber dann wäre es wohl einfacher, die Syntax dahingehend freizügiger zu gestalten, als ein neues Element einzuführen, das wenig Aussagekraft hat.

Das hat @Orlok ja auch schon angemerkt, ich stimme auch zu, dass das für den Programmierer noch angenehmer wäre. Ich glaube aber auch, es würde nicht reichen die existierenden JavaScript-Statements zu Ausdrücken umzudefinieren, stattdessen müsste man wohl für jedes vorhandene Statement einen korrespondierenden Ausdruck einführen. Das wären viel tiefgreifendere Anpassungen an Syntax und Semantik. Ich kann mir daher eher vorstellen, dass man in einem nächsten Schritt if-Ausdrücke als syntaktischen Zucker über do-Expressions spezifiziert. Das würde den gleichen Komfort für den Programmierer bieten und gleichzeitig die Semantik der Sprache nicht so sehr beeinflussen.

[1unitedpower]

Ich kann mir daher eher vorstellen, dass man in einem nächsten Schritt if-Ausdrücke als syntaktischen Zucker über do-Expressions spezifiziert. Das würde den gleichen Komfort für den Programmierer bieten und gleichzeitig die Semantik der Sprache nicht so sehr beeinflussen.

Auf der Diskussionsseite des Proposals wird das auch schon in Erwägung gezogen: https://github.com/tc39/proposal-do-expressions/issues/9

[Gunnar Bittersmann]

@@dedlfix

ein verzichtbarer Bestandteil, der im Gegenteil sogar stilistisch eher negativ angesehen wird. Vielleicht haben sich da die English Natives nicht so eng mit ihrem "do".

Besonders nicht bei der Verneinung. Oder bei der Befragung. Don’t you agree?

Aber auch bei bejahenden Statements (um in der Terminologie des Threads zu bleiben) kann „do“ eingefügt werden, um dem Ganzen mehr Ausdruckskraft zu verleihen. I really do believe so.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Aber auch bei bejahenden Statements (um in der Terminologie des Threads zu bleiben) kann „do“ eingefügt werden, um dem Ganzen mehr Ausdruckskraft zu verleihen.

Spotted in the wild: “Simon does bite.” 😉

Und großartige Performance, IMHO.

LLAP 🖖

[pl]

Wenn mich eine Stimme fertigmacht dann die von Christine McVie und Camille 😉

[dedlfix]

Tach!

Aber auch bei bejahenden Statements (um in der Terminologie des Threads zu bleiben) kann „do“ eingefügt werden, um dem Ganzen mehr Ausdruckskraft zu verleihen. I really do believe so.

Ja, diese Art von Betonung gibt es. Aber ist sie logisch sinnvoll oder einfach nur ein im Grunde überflüssiges Sprachkonstrukt? Oder anders gefragt, muss ich einem Computer betonen, dass er was auszuführen hat?

dedlfix.

[Rolf B]

Hallo dedlfix,

Das kann ich heutzutage auch schon als Ausdruck haben.

const animal = 'monkey';
const salutation = {
    dog: 'good boy',
    kitty: 'meow',
    goose: 'muuuuuuh'
}[animal] || 'hi';

Deine Gänse machen mir Angst!

Das Thema hatte ich neulich schon mit PL: Das ist NICHT das gleiche wie eine do-Expression oder eine richtig gemachte Ternary-Kette. Im von Dir gezeigten Fall wird ein Objekt erzeugt, dann ein Property davon genutzt und das Objekt schließlich wieder fortgeworfen. Solange die Properties Konstanten sind, ist das nicht allzu teuer. Funktionsreferenzen sind im komplexen Fall natürlich machbar, verlangen aber trotzdem erstmal das Anlegen eines Objekts und auch die Existenz von Funktionen und eine einheitliche Schnittstelle.

In den meisten Fällen wird der dadurch entstehende Overhead ohne Bedeutung sein, aber es gibt auch in JavaScript zeitkritische Situationen, vor allem auf Servern (node.js) und wer dann ganz selbstverständlich mit diesen Temp-Objekten agiert, mag sich wundern warum seine JS-App so langsam ist bzw. warum sein Server nur 100 Requests pro Sekunde schafft statt 1000. Ok, ist übertrieben.

Sorry, wenn ich auf solchen Dingen rumreite, aber wer in den 80ern das Programmieren angefangen hat, geizt mit jedem Byte und CPU-Taktzyklus 😀

Rolf

[1unitedpower]

In den meisten Fällen wird der dadurch entstehende Overhead ohne Bedeutung sein

JavaScript-Engines sind extrem gut darin solche Dinge wegzuoptimieren. Ich habe das mal durch Prepack gejagt, einem partiellen JavaScript-Interpreter, der macht daraus den folgenden Einzeiler:

salutation = 'hi';

Die Zeit für manuelle Optimierungen ist erst gekommen, wenn es schon zu spät ist. Dann kann man gezielt nach Engpässen suchen und effektiv optimieren. Optimistisch im Voraus handanzulegen und zu hoffen, dass man am Ende effizienten Code hat, ist dagegen eher aussichtslos, wie groß ist schon die Chance, dass man auf diese Weise die wirklich großen Flaschenhälse tatsächlich erwischt? Oft schadet das einach nur der Lesbarkeit und Wartbarkeit des Codes und ist am Ende doch nur vergebliche Liebesmühe.

[Christian Kruse]

Hallo 1unitedpower,

Optimistisch im Voraus handanzulegen und zu hoffen, dass man am Ende effizienten Code hat, ist dagegen eher aussichtslos, wie groß ist schon die Chance, dass man auf diese Weise die wirklich großen Flaschenhälse tatsächlich erwischt? Oft schadet das einach nur der Lesbarkeit und Wartbarkeit des Codes und ist am Ende doch nur vergebliche Liebesmühe.

Richtig. Erstes Grundprinzip der Programmierung: „Make it correct. Make it clear. Make it concise. Make it fast. In that order.”

LG,
CK

[pl]

Das kann ich heutzutage auch schon als Ausdruck haben.

Daß man bestimmte Dinge auch anders machen kann ist hier wohl kaum die Frage weil man die ohnehin fast immer mit JA beantworten kann. Das Entscheidende beim do{}-Block ist, daß das Ergebnis der letzten Anweisung zurückgegeben wird. Und diese Erkenntnis wirkt sich unmittelbar auf den Programmierstil aus. MfG

[dedlfix]

Tach!

Das kann ich heutzutage auch schon als Ausdruck haben.

Daß man bestimmte Dinge auch anders machen kann ist hier wohl kaum die Frage weil man die ohnehin fast immer mit JA beantworten kann.

Ja, aber lassen wir mal diese konkrete Antwort auf dieses konkrete Beispiel beiseite und gehen wieder ins allgemeine zurück.

Das Entscheidende beim do{}-Block ist, daß das Ergebnis der letzten Anweisung zurückgegeben wird. Und diese Erkenntnis wirkt sich unmittelbar auf den Programmierstil aus.

Eine kleine Abschweifung vorangestellt: Es gab in Pascal die Unterschiedung zwischen Prozedur und Funktion. In anderen Sprachen ist das Äquivalent der Prozedur eine Funktion ohne oder mit void als Rückgabewert. Es braucht also kein separates Sprachkonstrukt der Prozedur, wenn man dasselbe genausogut mit einer etwas erweiterten Funktion erreichen kann. Insofern sehe ich auch keinen Grund dafür, ein do-Element in die Sprache einzufügen, wenn man stattdessen das if (und case und for usw.) so erweitern kann, dass dessen letzter Ausdruck ein Rückgabewert wird.

dedlfix.

[pl]

Moin,

Insofern sehe ich auch keinen Grund dafür, ein do-Element in die Sprache einzufügen, wenn man stattdessen das if (und case und for usw.) so erweitern kann, dass dessen letzter Ausdruck ein Rückgabewert wird.

if() hat keinen Rückgabewert sondern wertet einen Ausdruck aus. Oder gibt es sowas wie

x = if(expr){}

in einer Deiner Dir bekannten Programmiersprachen? MfG

[dedlfix]

Tach!

Insofern sehe ich auch keinen Grund dafür, ein do-Element in die Sprache einzufügen, wenn man stattdessen das if (und case und for usw.) so erweitern kann, dass dessen letzter Ausdruck ein Rückgabewert wird.

if() hat keinen Rückgabewert sondern wertet einen Ausdruck aus.

Das weiß ich. Mein Vorschlag ist ja, das Verhalten dahingehend zu ändern, dass es einen Rückgabewert bekommt, um sich die Einführung des do{} sparen zu können.

Oder gibt es sowas wie

x = if(expr){}

in einer Deiner Dir bekannten Programmiersprachen?

Es ist irrelevant, ob es so etwas bereits anderwo gibt. Das ist kein Kriterium ob das in Javascript eingeführt werden kann oder sollte.

dedlfix.

[pl]

Moin,

Oder gibt es sowas wie

x = if(expr){}

in einer Deiner Dir bekannten Programmiersprachen?

Es ist irrelevant, ob es so etwas bereits anderwo gibt. Das ist kein Kriterium ob das in Javascript eingeführt werden kann oder sollte.

Nun, wenn Du if mit do vergleichen willst, ist das schon relevant. Im Übrigen wertet do{} keinen Ausdruck aus im Gegensatz zu if(). MfG

[Tabellenkalk]

Hallo,

x = if(expr){}

sieht dann natürlich syntaktisch anders aus, aber Sprachen wie LISP u.Ä., in denen jeder Ausdruck zu einem Resultat ausgewertet wird, machen das so.

Gruß
Kalk

[pl]

Hallo,

x = if(expr){}

sieht dann natürlich syntaktisch anders aus, aber Sprachen wie LISP u.Ä., in denen jeder Ausdruck zu einem Resultat ausgewertet wird, machen das so.

Das macht im Grunde genommen jede Programmiersprache: Jede Anweisung wird als Wahr oder Falsch bewertet. D.h., daß jede Anweisung einen wahren Wert ergeben muss sonst evaluiert der Code nicht. So ist x=false; eine wahre Aussage, aber der Wert in x ist nicht wahr. x=false; Wird also bewertet obwohl es kein Ausdruck sondern eine Zuweisung ist. MfG

PS: Kurz gesagt muss in jeder Zeile was Wahres stehen.

[Schnabeltier]

Welch hanebüchener Mumpitz. Du schmeißt hier wahr und syntaktisch korrekt durcheinander.

Dir ist schon klar, dass false eine syntaktisch korrekte Zeile** in Javascript ist, die auch problemlos evaluiert, oder? Magst du bei der immer noch behaupten, sie ergäbe 'wahr', also true?

Grüße vom Schnabeltier

** Zeile und Statement schmeißt du auch durcheinander, das ist in den meisten Sprachen nicht das selbe.

[pl]

eine syntaktisch korrekte Zeile** in Javascript ist, die auch problemlos evaluiert, oder? Magst du bei der immer noch behaupten, sie ergäbe 'wahr', also true?

Es sind zwei verschiedene Dinge.

1. x=true; evaluiert zu einer wahren Aussage
2. x=false; dito
3. danach ist x false.

Das ist übrigens auch in der Shell-Programierung so, daß jede Anweisung wahr ergeben muss. Man kann auch sagen, wahr heißt syntaktisch korrekt. Und wo wir schon beim do sind, in Perl ist

do 'datei';

immer wahr, auch dann wenn es die datei gar nicht gibt. Wohingegen ein do undef; zu einem fatalen Fehler führt weil diese Anweisung niemals zu einer wahren Aussage wird.

Ich hoffe das diese, meine Ausführungen zu einem bischen mehr Verständnis deinerseits beitragen. Auch diejenigen die mir hier noch blöder als Du gekommen sind, dürfen von mir hier weiterhin stets fachlich korrekte Anworten erwarten -- nichts Anderes!

MfG

[Schnabeltier]

eine syntaktisch korrekte Zeile** in Javascript ist, die auch problemlos evaluiert, oder? Magst du bei der immer noch behaupten, sie ergäbe 'wahr', also true?

Es sind zwei verschiedene Dinge.

1. x=true; evaluiert zu einer wahren Aussage
2. x=false; dito
3. danach ist x false.

Vielleicht meinen wir sogar beide das gleiche. Aber so, wie du es formulierst, klingt es einfach völlig falsch.

Mein Beispiel war nicht x=false, sondern false. Ein Statement, das zugegebenermaßen wenig sinnvoll ist, aber syntaktisch korrekt, und natürlich zu false evaluiert …

Das ist übrigens auch in der Shell-Programierung so, daß jede Anweisung wahr ergeben muss. Man kann auch sagen, wahr heißt syntaktisch korrekt.

… weil "wahr" und "syntaktisch korrekt" eben NICHT das gleiche heißt.

Ich hoffe das diese, meine Ausführungen zu einem bischen mehr Verständnis deinerseits beitragen. Auch diejenigen die mir hier noch blöder als Du gekommen sind, dürfen von mir hier weiterhin stets fachlich korrekte Anworten erwarten -- nichts Anderes!

😂

[1unitedpower]

Es sind zwei verschiedene Dinge.

1. x=true; evaluiert zu einer wahren Aussage
2. x=false; dito

Das ist wieder nicht die Wahrheit. x = false evaluiert zu false, das ist in der EcmaScript-Spezifikation eindeutig festgelegt, ich habe die relevanten Schritte aus dem Evaluierungsalgorithmus mal für dich rausgesucht:

12.15.4 Runtime Semantics: Evaluation

LeftHandSideExpression=AssignmentExpression

3. Let rref be the result of evaluating AssignmentExpression.
4. Let rval be ? GetValue(rref).
6. Return rval.

[JürgenB]

Hallo,

1. x=true; evaluiert zu einer wahren Aussage
2. x=false; dito

Das ist wieder nicht die Wahrheit. x = false evaluiert zu false, das ist in der EcmaScript-Spezifikation eindeutig festgelegt, ich habe die relevanten Schritte aus dem Evaluierungsalgorithmus mal für dich rausgesucht:

das erkennt man auch an Zuweisungsketten:

x = y = 42;

setzt x und y auf 42, und

x = y = false;

setzt eben beide Variablen auf false.

Gruß
Jürgen

[MudGuard]

Hi,

1. x=true; evaluiert zu einer wahren Aussage
2. x=false; dito

das erkennt man auch an Zuweisungsketten:

x = y = 42;

setzt x und y auf 42, und

x = y = false;

setzt eben beide Variablen auf false.

oder auch an

if (x = getValue()) {

x enthält danach den Rückgabewert von getValue() und je nachdem, ob dieser zu true oder zu false evaluiert, wird der "then"-Block ausgeführt oder (soweit vorhanden) der "else"-Block.

Aber wir können sowas ja nicht wissen, wir sind ja alle keine richtigen Programmierer …

cu,
Andreas a/k/a MudGuard

[1unitedpower]

Oder gibt es sowas wie

x = if(expr){}

in einer Deiner Dir bekannten Programmiersprachen?

Klar, das ist weit verbreitet:

• Ruby: x = if condition then foo else bar end
• Haskell: x = if condition then foo else bar
• Rust: x = if condition { foo } else { bar }
• Python: x = foo if condition else bar
• Elm: x = if condition then foo else bar
• PureScript: x = if condition then foo else bar
• OCaml: x = if condition then foo else bar
• F#: x = if condition then foo else bar
• …

[pl]

Oder gibt es sowas wie

x = if(expr){}

in einer Deiner Dir bekannten Programmiersprachen?

Klar, das ist weit verbreitet:

• Ruby: x = if condition then foo else bar end
• Haskell: x = if condition then foo else bar
• Rust: x = if condition { foo } else { bar }
• Python: x = foo if condition else bar
• Elm: x = if condition then foo else bar
• PureScript: x = if condition then foo else bar
• OCaml: x = if condition then foo else bar
• F#: x = if condition then foo else bar
• …

Was Du hier zitierst sind bedingte Zuweisungen, aber deswegen hat if() noch lange keinen Rückgabewert. MfG

[1unitedpower]

Oder gibt es sowas wie

x = if(expr){}

in einer Deiner Dir bekannten Programmiersprachen?

Klar, das ist weit verbreitet:

• Ruby: x = if condition then foo else bar end
• Haskell: x = if condition then foo else bar
• Rust: x = if condition { foo } else { bar }
• Python: x = foo if condition else bar
• Elm: x = if condition then foo else bar
• PureScript: x = if condition then foo else bar
• OCaml: x = if condition then foo else bar
• F#: x = if condition then foo else bar
• …

Was Du hier zitierst sind bedingte Zuweisungen, aber deswegen hat if() noch lange keinen Rückgabewert.

Doch, in allen Beispielen hat if einen Rückgabewert, alle Beispiele zeigen echte if-Ausdrücke.

[pl]

Doch, in allen Beispielen hat if einen Rückgabewert, alle Beispiele zeigen echte if-Ausdrücke.

if vermittelt eine Wertzuweisung, so würde ich das eher formulieren. if selbst kann außer true oder false (sog. Boolsche Werte) keinen anderen Wert liefern aber if macht das implizit und jeder Versuch einer solchen direkten Zuweisung wird unweigerlich mit einem Syntaxfehler quittiert.

Ebensowenig prüft do einen Ausdruck. Schon der Begriff do-Expression ist irreführend, weil do keinen Ausdruck prüft, sondern lediglich das letzte im Block notierte Statement liefert -- ohne es zu prüfen.

Schönen Sonntag.

[1unitedpower]

Doch, in allen Beispielen hat if einen Rückgabewert, alle Beispiele zeigen echte if-Ausdrücke.

if vermittelt eine Wertzuweisung, so würde ich das eher formulieren. if selbst kann außer true oder false (sog. Boolsche Werte) keinen anderen Wert liefern

Das ist wieder falsch. if-Ausdrücke kriegen drei Argumente übergeben: einen boolschen Wert für die Bedingung, und jeweils einen Wert für den positiven und negativen Fall. Der Typ des Rückgabewerts ergibt sich dann aus dem jeweils eingetroffenen Fall. Der vollständige Typ des Ausdrucks besteht also aus vier Komponenten: drei für die Argumente und einen für den Rückgabewert. In Haskell Typdnotation sieht der Typ für ifs zum Beispiel so aus: forall t. (Bool, t, t) -> t. Das heißt, für jeden beliebigen Typen t übergibt man dem Ausdruck zunächst einen boolschen Wert, dann zwei Werte vom Typ t und produziert schließlich einen Rückgabewert, der ebenfalls den Typen t hat.

[pl]

Sag mal, die Seite die Du hier verlinkt hast, nimmst Du das wirklich ernst was da steht!?

Und wenn wir ohnehin schon nicht mehr bei JS sind:

$x = 123 if $exp; # poetry mode
next if $exp; #  innerhalb eines Schleifenkörpers

# mehrere Statements kapseln
$x = do{
  # more code
  local $/ = undef;
  *DATA; # hier liegt z.B. ein Template
} if $exp;

# like do, wobei eval dafür sorgt, dass Exceptions aufgefangen werden
print eval{
  # jede Menge Code
  my $buffer;
  # Code womit buffer was kriegt
  # Dateien lesen z.b.
  # dabei können Exceptions fallen
  $buffer;
} || "Eine Exception trat auf, weil: $@";


my $x = $x == 99 ? $x : do{
  # viele Zeilen Code
  'um diesen Wert für x zu kriegen';
};

Ansonsten habe ich hier auch an anderer Stelle einige weitere Beispiele gepostet um einen sinnvollen und zweckmäßigen Einsatz von do{}-Blöcken zu zeigen. In JS würde ich do{}-Blöcke sinngemäß genauso verwenden.

Was die von Dir verlinkte Seite in kleinster Weise hergibt. MfG

[Matthias Apsel]

Hallo 1unitedpower,

Doch, in allen Beispielen hat if einen Rückgabewert, alle Beispiele zeigen echte if-Ausdrücke.

Bedeutet also, hinterher hat das x entweder den Wert "foo" oder "bar"?

Bis demnächst
Matthias

[pl]

Jetzt kommt man hier mittlerweile mit mindestens 8 von JS abweichenden Programmiersprachen daher, aber laufend wird mir vorgeworfen ich würde abschweifen wenn ich auf meine in Perl gemachten Erfahrungen zurückgreife. Das ist schon mehr als seltsam.

Doch, in allen Beispielen hat if einen Rückgabewert, alle Beispiele zeigen echte if-Ausdrücke.

Bedeutet also, hinterher hat das x entweder den Wert "foo" oder "bar"?

Ja natürlich, aber es ist und bleibt eben ein Trugschluss, das if diese Werte zurückgibt. Genausowenig wie if 'foo' liefert gibt else 'bar' zurück. Auf diesen Gedanken würde kein Perl-Entwickler kommen.

Schönen Sonntag.

[Matthias Apsel]

Hallo pl,

Ja natürlich, aber es ist und bleibt eben ein Trugschluss, das if diese Werte zurückgibt.

Wer denn dann?

Bis demnächst
Matthias

[pl]

Hi,

Ja natürlich, aber es ist und bleibt eben ein Trugschluss, das if diese Werte zurückgibt.

Wer denn dann?

Der Programmierer! Er ist es der für die Zuweisung sorgt indem er eine Kontrollstruktur zweckentsprechend einsetzt.

Nicht der Schnee fegt die Straße sondern ich, wenn ich feststelle daß da zuviel davon rumliegt. MfG

[Gunnar Bittersmann]

@@pl

Ja natürlich, aber es ist und bleibt eben ein Trugschluss, das if diese Werte zurückgibt.

Wer denn dann?

Der Programmierer! Er ist es der für die Zuweisung sorgt indem er eine Kontrollstruktur zweckentsprechend einsetzt.

Der Programmier gibt Werte zurück? Das halte ich für auch einen Trugschluss.

Nicht der Schnee fegt die Straße sondern ich, wenn ich feststelle daß da zuviel davon rumliegt.

„Du kannst gleich damit anfangen.“ (Lou Caruthers zu Goldie Wilson, 1955)

LLAP 🖖

[Tabellenkalk]

Hallo,

Der Programmierer!

Der Programmier gibt Werte zurück?

Wusstest du das nicht? Z.B. beim Windows-Taschenrechner ist intern die Telefonnummer vom Programmierer hinterlegt, das Programm ruft dann mithilfe von Modem und Sprachsoftware an und fragt direkt den Programmierer: "Hey, Chef, was bitte ist die Wurzel aus PI?"…

Gruß
Kalk

[Tabellenkalk]

Hallo,

Jetzt kommt man hier mittlerweile mit mindestens 8 von JS abweichenden Programmiersprachen daher,

Jemand hat direkt nach anderen PL gefragt.

Das ist schon mehr als seltsam.

seltsam vorallem, dass du dich daran entweder nicht erinnerst, oder dich drüber wunderst.

Gruß
Kalk

[1unitedpower]

Bedeutet also, hinterher hat das x entweder den Wert "foo" oder "bar"?

Ganz genau. Das ist eigentlich nur eine schönere Syntax für den Ternären Operator. (Außer in Pyhton, die Syntax ist wirklich zum Haare raufen).

[Christian Kruse]

Hallo 1unitedpower,

• Ruby: x = if condition then foo else bar end
• Haskell: x = if condition then foo else bar
• Rust: x = if condition { foo } else { bar }
• Python: x = foo if condition else bar
• Elm: x = if condition then foo else bar
• PureScript: x = if condition then foo else bar
• OCaml: x = if condition then foo else bar
• F#: x = if condition then foo else bar
• …

Elixir treibt es hier übrigens auf die Spitze: if ist hier nur ein Makro, dass zu einer Funktion umgeschrieben wird; if cond do … end wird im AST zu if(cond, fn -> … end) (vereinfacht).

Übrigens hat @Tabellenkalk schon recht, das ist alles abgeguckt von LISP, der Mutter aller Programmiersprachen 😀 dort ist if ein special operator, der die Form (if condition then-form [else-form]) hat. Der Rückgabewert ist hier der Rückgabewert der Then-Form bzw der Else-Form, je nach Ergebnis von condition. Gibt es keine Else-Form aber die condition gibt false zurück, wird nil zurück gegeben.

LG,
CK

[JürgenB]

Hallo,

Übrigens hat @Tabellenkalk schon recht, das ist alles abgeguckt von LISP, der Mutter aller Programmiersprachen 😀 dort ist if ein special operator, der die Form (if condition then-form [else-form]) hat. Der Rückgabewert ist hier der Rückgabewert der Then-Form bzw der Else-Form, je nach Ergebnis von condition. Gibt es keine Else-Form aber die condition gibt false zurück, wird nil zurück gegeben.

ich weiß jetzt nicht, was älter ist, aber mein erster Kontakt mit do sah so aus:

      do label  var =  expr1, expr2, expr3
         statements
label continue

https://web.stanford.edu/class/me200c/tutorial_77/09_loops.html

Gruß
Jürgen

[Christian Kruse]

Hallo JürgenB,

ich weiß jetzt nicht, was älter ist, aber mein erster Kontakt mit do sah so aus:

      do label  var =  expr1, expr2, expr3
         statements
label continue

https://web.stanford.edu/class/me200c/tutorial_77/09_loops.html

Fortran ist ein Jahr älter als LISP, aber LISP hatte diese Formen-Syntax mit dem Rückgabewert früher als Fortran 😂

LG,
CK

[Tabellenkalk]

Hallo,

ich weiß jetzt nicht, was älter ist, aber mein erster Kontakt mit do sah so aus:

Fortran
[...]
https://web.stanford.edu/class/me200c/tutorial_77/09_loops.html

Und deshalb ist die Benennung auch unglücklich. Ich seh' schon die vielen Newbie-Fragen in den JS-Foren: Warum wird meine Do-Schleife nur einmal durchlaufen?

Gruß
Kalk

[JürgenB]

Hallo,

… Ich seh' schon die vielen Newbie-Fragen in den JS-Foren: Warum wird meine Do-Schleife nur einmal durchlaufen?

immer noch besser als if-Schleife 😀

Gruß
Jürgen

[Tabellenkalk]

Hallo,

immer noch besser als if-Schleife 😀

man könnte den Betreiber von if-schleife.de bitten, ein Äquivalent für die Do-Schleife einzurichten :)

Gruß
Kalk

[dedlfix]

Tach!

Ich seh' schon die vielen Newbie-Fragen in den JS-Foren: Warum wird meine Do-Schleife nur einmal durchlaufen?

Die wird natürlich solange durchlaufen, bis eine wahre Aussage entsteht - die natürlich auch false sein kann.

dedlfix.

[Tabellenkalk]

Hallo,

Die wird natürlich solange durchlaufen, bis eine wahre Aussage entsteht - die natürlich auch false sein kann.

Kunde im Blumenladen: Ist diese Blume künstlich?
Florist: Natürlich!

Gruß
Kalk

[Christian Kruse]

Hallo dedlfix,

Ich seh' schon die vielen Newbie-Fragen in den JS-Foren: Warum wird meine Do-Schleife nur einmal durchlaufen?

Die wird natürlich solange durchlaufen, bis eine wahre Aussage entsteht - die natürlich auch false sein kann.

rotfl - made my day

LG,
CK

[MudGuard]

Hi,

Übrigens hat @Tabellenkalk schon recht, das ist alles abgeguckt von LISP, der Mutter aller Programmiersprachen 😀

Lisp ist nicht die Mutter aller Programmiersprachen, Lisp ist die Mutter aller Klammern!

cu,
Andreas a/k/a MudGuard

[Christian Kruse]

Hallo MudGuard,

Übrigens hat @Tabellenkalk schon recht, das ist alles abgeguckt von LISP, der Mutter aller Programmiersprachen 😀

Lisp ist nicht die Mutter aller Programmiersprachen, Lisp ist die Mutter aller Klammern!

Die Klammern haben mich auch lange Zeit gestört. Aber irgendwann hat es klick gemacht und es ist mir wie Schuppen aus den Haaren gefallen: die Klammern machen Sinn! 😉

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Die Klammern haben mich auch lange Zeit gestört. Aber irgendwann hat es klick gemacht und es ist mir wie Schuppen aus den Haaren gefallen: die Klammern machen Sinn! 😉

Und weil sie das klammerheimlich tun, ist dir der Sinn zuerst verborgen geblieben‽

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Die Klammern haben mich auch lange Zeit gestört. Aber irgendwann hat es klick gemacht und es ist mir wie Schuppen aus den Haaren gefallen: die Klammern machen Sinn! 😉

Und weil sie das klammerheimlich tun, ist dir der Sinn zuerst verborgen geblieben‽

Hehe.

Naja, ich habe auf intellektueller Ebene schon verstanden, warum LISP auf die Klammern setzt. Ich habe es nur nicht für sinnvoll gehalten. Das hat sich erst geändert, nachdem ich ein paar tausend Zeilen LISP gelesen und geschrieben hatte. Denn wenn man sich ein wenig eingelesen hat in LISP, dann merkt man, dass die Klammern den Code nicht schwerer, sondern einfacher lesbar machen.

LG,
CK

[Christian Kruse]

Hallo dedlfix,

Es braucht also kein separates Sprachkonstrukt der Prozedur, wenn man dasselbe genausogut mit einer etwas erweiterten Funktion erreichen kann. Insofern sehe ich auch keinen Grund dafür, ein do-Element in die Sprache einzufügen, wenn man stattdessen das if (und case und for usw.) so erweitern kann, dass dessen letzter Ausdruck ein Rückgabewert wird.

Rückwärtskompatibilität.

Eine do-Expression kannst du einführen, ohne, dass du potentiell das halbe Internet kaputt machst. Wenn du jetzt anfängst, JS funktionaler zu machen und Kontrollstrukturen einen Wert zurück geben lässt, dann brichst du potentiell existierende Codebases. Die do-Expression ist also ein Kompromiss: mehr funktionales JS, aber trotzdem kein kaputter Code.

LG,
CK

[dedlfix]

Tach!

Rückwärtskompatibilität.

Eine do-Expression kannst du einführen, ohne, dass du potentiell das halbe Internet kaputt machst. Wenn du jetzt anfängst, JS funktionaler zu machen und Kontrollstrukturen einen Wert zurück geben lässt, dann brichst du potentiell existierende Codebases.

Daran habe ich auch gedacht, kann mir aber nicht vorstellen, welche syntaktisch korrekten Fälle damit kaputtgehen, wenn man eine Syntax à la var foo = if ... hinzufügt.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Rückwärtskompatibilität.

Eine do-Expression kannst du einführen, ohne, dass du potentiell das halbe Internet kaputt machst. Wenn du jetzt anfängst, JS funktionaler zu machen und Kontrollstrukturen einen Wert zurück geben lässt, dann brichst du potentiell existierende Codebases.

Daran habe ich auch gedacht, kann mir aber nicht vorstellen, welche syntaktisch korrekten Fälle damit kaputtgehen, wenn man eine Syntax à la var foo = if ... hinzufügt.

Das hast du nicht gefordert! 😉 du hast gefordert, dass if/for/etc Rückgabewerte haben. Und von da ist es nicht mehr weit, dass man versehentlich Werte zurück gibt, die man nicht zurück geben wollte.

Wenn man sich beschränkt auf Zuweisungen, erhöht man wieder die Komplexität der Sprache um einen Sonderfall. Auch nicht wünschenswert.

LG,
CK

[dedlfix]

Tach!

Rückwärtskompatibilität.

Eine do-Expression kannst du einführen, ohne, dass du potentiell das halbe Internet kaputt machst. Wenn du jetzt anfängst, JS funktionaler zu machen und Kontrollstrukturen einen Wert zurück geben lässt, dann brichst du potentiell existierende Codebases.

Daran habe ich auch gedacht, kann mir aber nicht vorstellen, welche syntaktisch korrekten Fälle damit kaputtgehen, wenn man eine Syntax à la var foo = if ... hinzufügt.

Das hast du nicht gefordert! 😉 du hast gefordert, dass if/for/etc Rückgabewerte haben. Und von da ist es nicht mehr weit, dass man versehentlich Werte zurück gibt, die man nicht zurück geben wollte.

Versteh ich nicht. Wohin zurückgeben? Welche bisher korrekte Syntax könnte denn damit ungewollt Dinge bekommen.

Wenn man sich beschränkt auf Zuweisungen, erhöht man wieder die Komplexität der Sprache um einen Sonderfall. Auch nicht wünschenswert.

Was anderes als Zuweisen oder Parameterübergaben sollte man mit Rückgabewerten wollen? Und was anderes als Zuweisungen oder Parameterübergaben sollte denn betroffen sein, wenn es Rückgabewerte gibt?

Und wie holt sich denn das do den Wert, wenn ein if oder das im Eingangsbeispiel gezeigte switch (weiterhin) nichts zurückgibt? Irgendwie muss doch diese Funktionalität auch in die bestehenden Statements eingebaut werden, oder nicht? Oder sind das dann Kopien der bisherigen Statements, die syntaktisch gleich oder zumindest ähnlich sind, aber intern anders funktionieren?

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Versteh ich nicht. Wohin zurückgeben? Welche bisher korrekte Syntax könnte denn damit ungewollt Dinge bekommen.

Keine Ahnung. Ich bin nicht Teil des Standard-Komitees und habe mir darüber kaum Gedanken gemacht. Ich habe nur geschrieben, was mir als möglicher Grund in den Sinn kam, und ich halte das Szenario nachwievor nicht für unwahrscheinlich. Dass mir kein Fall einfällt heisst ja nicht, dass keiner existiert: Software-Entwickler sind erstaunlich kreativ, wenn es um edge cases geht.

Wenn man sich beschränkt auf Zuweisungen, erhöht man wieder die Komplexität der Sprache um einen Sonderfall. Auch nicht wünschenswert.

Was anderes als Zuweisen oder Parameterübergaben sollte man mit Rückgabewerten wollen?

Auswerten. 😝 Z.B. für bedingte Verzweigungen.

Und wie holt sich denn das do den Wert, wenn ein if oder das im Eingangsbeispiel gezeigte switch (weiterhin) nichts zurückgibt? Irgendwie muss doch diese Funktionalität auch in die bestehenden Statements eingebaut werden, oder nicht? Oder sind das dann Kopien der bisherigen Statements, die syntaktisch gleich oder zumindest ähnlich sind, aber intern anders funktionieren?

Kann ich dir nicht sagen. Da musst du dich schon selber mit der Thematik beschäftigen.

LG,
CK

[dedlfix]

Tach!

Was anderes als Zuweisen oder Parameterübergaben sollte man mit Rückgabewerten wollen?

Auswerten. 😝 Z.B. für bedingte Verzweigungen.

Ja, aber auch das ist kein bisher syntaktisch gültiger Platz für ein if etc. gewesen.

Anders gefragt, kann man denn ausschließen, dass das neue do keine rückwärtigen Probleme bereitet?

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Anders gefragt, kann man denn ausschließen, dass das neue do keine rückwärtigen Probleme bereitet?

Ja. Es gibt bisher kein do-Statement (nur eine do ... while-Schleife, was aber ein anderes Konstrukt ist). Der neue Code ist also zwangsläufig nicht rückwärtskompatibel, und damit kann nichts durch eine Veränderung der VM brechen: do-Statements können nur in neuem Code auftreten. Das Testen von neuem Code obliegt der Verantwortung des Entwicklers.

Bei der Veränderung der Semantik von bestehenden Syntax-Konstrukten verändert sich halt die Semantik bestehenden Codes. Das gilt es im Sinne der Rückwärtskompatibilität unbedingt zu vermeiden.

LG,
CK

[JürgenB]

Hallo,

Ja. Es gibt bisher kein do-Statement (nur eine do ... while-Schleife, …

und wegen dieser Schleife konnte man seine Variablen (etc.) nicht do nennen.

Gruß
Jürgen

[MudGuard]

Hi,

Ja. Es gibt bisher kein do-Statement (nur eine do ... while-Schleife, was aber ein anderes Konstrukt ist).

do 
{
    if (condition1) {
       //something
    }
    else {
       //something else
    } 
}
while (condition2)
{
    let foo = 42;
    //another thing
}

Bisher ist ganz klar, daß die Schleife eine do-while-Schleife ist.

Die Klammern zur Blockbildung um //another thing sind dazu da, um foo im Scope zu begrenzen.

Mit dem neuen do-Konstrukt könnte aber auch das do mit dem } enden, das while läutet dann eine neue Schleife ein.

; am Zeilenende nach dem while ist zwar nett, aber m.W. bisher nicht erforderlich.

Und daß das do nicht einer Variable zugewiesen wird, ist ja nicht schlimm. Ein nichtgefangener Rückgabewert ist nix ungewöhnliches.

cu,
Andreas a/k/a MudGuard

[Rolf B]

Hallo MudGuard,

bösartig du bist 😀

Guck mal hier: http://www.ecma-international.org/ecma-262/5.1/#sec-12.6.1

Nach do while() ist das Semikolon syntaktisch erforderlich. Allerdings kommen hier die bad parts von JavaScript ins Spiel, die sich ein Semikolon dazudenken, wo sie eins für nötig halten, wie zum Beispiel hier zwischen return und 17+4...

    return
          17+4;

Das von Dir gezeigte Konstrukt wäre damit eindeutig: eine do-Expression, gefolgt von einer while-Schleife. Ich möchte aber nicht den Parser dafür programmieren müssen 😂

Rolf

[MudGuard]

Hi,

bösartig du bist 😀

Ich? Ich weiß gar nicht, wie bösartig sein geht. 😉

Das von Dir gezeigte Konstrukt wäre damit eindeutig: eine do-Expression, gefolgt von einer while-Schleife. Ich möchte aber nicht den Parser dafür programmieren müssen 😂

Ich wenn da was zu sagen hätte, würde - auch wenn es keine uneindeutigen Sachen erzeugt, für so ein neues Konstrukt dann doch eher zu einem jungfräulichen keyword^[1] wie "valueof" tendieren. Das ergäbe kein derartiges Problem.

Und ich finde, daß das "do" auch nicht wirklich offensichtlich sagt, was da passiert. Und bei Kenntnis der do-while-Schleife auch noch verwirrend ist, weil dasselbe keyword unterschiedliche Bedeutungen hat.

cu,
Andreas a/k/a MudGuard

---

1. ok, dann würden halt alle Variablen, die so heißen wie die Jungfrau, ungültig werden. Also auch nicht problemlos ↩︎

[Rolf B]

Hallo MudGuard,

was passiert eigentlich hier?

let q = 17;
let x = do {
   let y = { test: 1, pest: 2 };
   let z = { test: 7, pest: 8 };
   if (q == 17)
      function(i) { return z[i]; }
   else
      function(i) { return y[i]; }
};
alert(x('test'));

Hab ich da jetzt eine Closure geschnürt?

Rolf

[1unitedpower]

let q = 17;
let x = do {
   let y = { test: 1, pest: 2 };
   let z = { test: 7, pest: 8 };
   if (q == 17)
      function(i) { return z[i]; }
   else
      function(i) { return y[i]; }
};
alert(x('test'));

Hab ich da jetzt eine Closure geschnürt?

Zwei Closures sogar. Denn beide Funktionen binden Variablen aus dem umgebenden Geltungsbereich, das macht einen Closure auch schon aus. Das kennt man aus dem Matherunterricht vielleicht noch als Funktionsschar $$f_a(x) = ax$$. Hier ist das $$a$$ eine "Umgebungsvariable". In deinem Beispiel spielen z und y diese Rollen.

[1unitedpower]

Und wie holt sich denn das do den Wert, wenn ein if oder das im Eingangsbeispiel gezeigte switch (weiterhin) nichts zurückgibt? Irgendwie muss doch diese Funktionalität auch in die bestehenden Statements eingebaut werden, oder nicht?

Statements haben in JavaScript schon heute Rückgabewerte, allein die Syntax-Regeln halten uns davon ab mit diesen Rückgabenwerten weiterzurechnen: Man kann den Rückgabewert nicht in Variablen speichern, weil auf der rechten Seite von Zuweisungen unmal keine Statements erlaubt sind. Mit eval kann man das allerdings simulieren:

x = eval('if (true) 1; else 0;');
console.assert(x === 1);

Das Proposal zu do-Expression stützt sich auch auf diese Semantik.

[Christian Kruse]

Hallo 1unitedpower,

Statements haben in JavaScript schon heute Rückgabewerte, allein die Syntax-Regeln halten uns davon ab mit diesen Rückgabenwerten weiterzurechnen: Man kann den Rückgabewert nicht in Variablen speichern, weil auf der rechten Seite von Zuweisungen unmal keine Statements erlaubt sind. Mit eval kann man das allerdings simulieren:

x = eval('if (true) 1; else 0;');
console.assert(x === 1);

Das Proposal zu do-Expression stützt sich auch auf diese Semantik.

Dann muss ich Dedlfix zustimmen: das Proposal geht nicht weit genug bzw wählt den falschen Ansatz. Das Erlauben einer Zuweisung wäre hier konsequenter und IMHO auch sinnvoller.

LG,
CK

[1unitedpower]

Dann muss ich Dedlfix zustimmen: das Proposal geht nicht weit genug bzw wählt den falschen Ansatz. Das Erlauben einer Zuweisung wäre hier konsequenter und IMHO auch sinnvoller.

Fände ich auch, aber das wäre wohl nicht abwärtskompatibel. Ein Problem scheint zu sein, dass die automatische Erzeugung von Semikolons dafür sorgt, dass so eine Syntax wie dedlfix sie vorschlägt nicht eindeutig wäre. Wenn ich die Diskussion auf GitHub bisher richtig verstehe, braucht man das do nur als Krücke für den Parser. Im abstrakten Syntaxbaum wird das do schließlich eliminiert und man erhält ein Programm, das mehr oder weniger automatisch die richtige Semantik trägt. Aus Implementierungssicht muss man also nur den Parser anfassen.

[Christian Kruse]

Hallo 1unitedpower,

Wenn ich die Diskussion auf GitHub bisher richtig verstehe, braucht man das do nur als Krücke für den Parser. Im abstrakten Syntaxbaum wird das do schließlich eliminiert und man erhält ein Programm, das mehr oder weniger automatisch die richtige Semantik trägt. Aus Implementierungssicht muss man also nur den Parser anfassen.

Hm, ja, verstehe. Macht Sinn. Danke für die Erläuterungen.

LG,
CK

[pl]

Der Sinn und die Zweckmäßigkeit solcher do{}-Böcke besteht hauptsächlich darin, mehrere Anweisungen zusamenzufassen, so daß effektiv nur eine Anweisung übrigbleibt. Gerade am Beispiel des Ternären Operator wird das deutlich, d.h., man würde solche Konstrukte wohl eher weniger verwenden, wenn es den do{}-Block nicht gäbe. Mich wunderts, daß man in Deiner verlinkten Seite nun gerade darauf gar nicht weiter eingeht. Da gehts wohl eher um andere Dinge 😉

[1unitedpower]

Der Sinn und die Zweckmäßigkeit solcher do{}-Böcke besteht hauptsächlich darin, mehrere Anweisungen zusamenzufassen, so daß effektiv nur eine Anweisung übrigbleibt.

Jein, Anweisungen zu Blöcken zusammenfassen kannst du auch heute schon in JavaScript:

{
   const a = 1;
   const b = 2;
   const c = a + b;
}

Der springende Punkt ist, dass man in JavaScript bisher keine Anweisungsblöcke in Ausdrücke einbetten kann, dafür sind do-Expressions da. Kann gut sein, dass Perl das schon hat, aber einem JavaScript-Programmierer hilft das nicht sonderlich viel.

[pl]

Ja, es hilft ungemein weil es eben sehr praktisch ist. Man kann auch sagen, es ermöglicht eine flüssige Schreibweise beim Programmieren, z.b. wenn Anweisungen ternary zu notieren sind und man beim Tippen feststellen muss dass man für eine Zuweisung noch ein bischen mehr tun muss. Das geht sozusagen mit der Zeit und mit der Praxis in Fleisch und Blut über, daß man den Fluß der Tipparbeit eben nicht unterbrechen muss sondern einfach einen do{}-Block einsetzt.

Und wenn man von einer anderen PL kommt wo sowas schon immer möglich ist, ganz besonders. Natürlich mus jeder seine Erfahrungen selber machen, da haste schon recht. MfG

[Tabellenkalk]

Hallo,

do-Expressions ummanteln Statements und geben den finalen Wert der Berechnung zurück.

Kann es sein, dass das ein wenig von LISP abgeguckt ist?

Gruß
Kalk

[pl]

Hallo,

do-Expressions ummanteln Statements und geben den finalen Wert der Berechnung zurück.

Kann es sein, dass das ein wenig von LISP abgeguckt ist?

Das interessiert mich auch! Was do{}-Blöcke in Perl machen steht hier und siehe auch meine zahlreichen Beispiele hier. In JS würde ich do ganz genauso verwenden weil es sehr praktisch ist, aber das schrieb ich ja bereits.

Welche Erfahrungen hast Du mit do{} in LISP?

MfG

[Tabellenkalk]

Hallo,

Welche Erfahrungen hast Du mit do{} in LISP?

ich hab mal ein weißes Zwergkaninchen gesehen…

Gruß
Kalk