Kurzschreibweise if-Verzweigung

  • mattik schrieb:

    zerm schrieb:


    Das liegt wahrscheinlich daran, dass Blocks keine Closures sind.

    Das ist ja mal spannend. Warum sind Blocks keine Closures? In meiner einführenden Literatur steht das nirgendwo.

    Lass mal, da ist nicht einmal __block semantisch richtig angewendet. Arg, sorry, ist doch richtig.

    Man muss sich ja nicht mit jedem unterhalten, der meint, nach 5 Minuten Wikipedia Ahnung zu haben.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Amin Negm-Awad ()

  • Soweit ich den Artikel gelesen habe, ist dieser korrekt und deckt sich mit meinem Wissen und Verständnis. Rein-Funktionale Programmierung (mit Lisp,Scheme,Prolog) ist bei mir zwar schon etwas her, aber soweit reicht es denke ich noch.

    Der erste Satzt sagt es ganz schön:
    In computer science, a closure is a first-class function with free variables that are bound in the lexical environment


    Ein Block erfüllt die Vorraussetzung, eine first-class function zu sein, aber freie Variablen ausserhalb des "Scopes" müssen nicht zwangsläufig gebunden sein. Dort in dem besagten Beispiel

    C-Quellcode

    1. typedef int (^IntBlock)();
    3. IntBlock downCounter(int start) {
    4. __block int i = start;
    5. return [[ ^int() {
    6. return i--;
    7. } copy] autorelease];
    8. }
    10. IntBlock f = downCounter(5);
    11. NSLog(@"%d", f());
    12. NSLog(@"%d", f());
    13. NSLog(@"%d", f());
    Alles anzeigen

    wird erst durch die __block int i = start und verwendung dieser aus dem Block eine Closure.
    EDIT: Würde statt "i" nur "start" verwendet, würde es auch reichen. Ohne beides ist es aber einfach nur eine first-class Funktion.

    EDIT2: Wenn es immer noch nicht klar ist, finde ich diese (wiedermal Wikipedia) Seite auch schön: en.wikipedia.org/wiki/Lambda_lifting
    Mittels Lambda Lifting versucht man (oder der Compiler) eben genau diese freien Variablen zu elimieren, damit aus der Closure wieder eine "normal" first-class Funktion wird. Ich tippe fast, dass der Compiler das bei Objective-C auch so macht, aber da kenne ich mich nicht gut genug mit aus.
    ♥C++

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von zerm ()

  • Nein, sie müssen es nicht zwangsläufig.

    Übrigens wird auch ohne __block eine Bondung erzielt.

    Halten wir fest: Es erfolgt eine Bindung, unabhängig von __block. Jeder Block bindet, sobald er sich auf $irgendwas außerhalb seines Scopes biezieht. Damit ist es ein Closure.

    Schreib doch einfach mal deine Definition in drei, vier Begriffen untereinander und sage mir, was ein Block davon nicht erfüllt. Ist doch ganz einfach, oder?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Nein, sie müssen es nicht zwangsläufig.

    Übrigens wird auch ohne __block eine Bondung erzielt.

    Halten wir fest: Es erfolgt eine Bindung, unabhängig von __block. Jeder Block bindet, sobald er sich auf $irgendwas außerhalb seines Scopes biezieht. Damit ist es ein Closure.

    Schreib doch einfach mal deine Definition in drei, vier Begriffen untereinander und sage mir, was ein Block davon nicht erfüllt. Ist doch ganz einfach, oder?

    Siehe mein Edit oben.

    Ist mir aber auch egal, Du wirst Dich nicht überzeugen lassen und ich mich genausowenig also können wir es auch dabei belassen.
    ♥C++

  • mattik schrieb:

    Genau. Außerdem: Die Menge der upvalues einer Closure kann nichtleer sein, muss sie aber nicht. Eine Closure ohne upvalues ist eine Closure ohne upvalues.

    Das meinte ich damit, dass eine leere Funktion eine Funktion bleibt.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • zerm schrieb:

    mattik schrieb:

    Genau. Außerdem: Die Menge der upvalues einer Closure kann nichtleer sein, muss sie aber nicht. Eine Closure ohne upvalues ist eine Closure ohne upvalues.

    Nein, dann ist es keine Closure mehr :P
    Oder dann ist

    C-Quellcode

    1. ;

    auch eine.

    Natürlich ist das auch eine Anweisung.

    Aber bei diesem Punkt waren wir schon. Lies einfach noch einmal.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Interessant, wie mich das aufregt und mir keine Ruhe lässt.

    Closures sind eher ein Konzept als ein konkretes Konstrukt. Wichtig für eine Closure ist, dass sie freie Variablen hat, die im selben Scope definiert wurden, in der auch die Closure definiert wurde, und nur dann hat man eine Closure. Ihr argumentiert jetzt mit dem grenzwertigen Fall, dass die Anzahl der freien Variablen auch null sein kein - aber nach meiner Auffassung ist es dann keine Closure mehr, weil man eben hier nicht mehr von dem Prozess des Abschlusses der Umgebung innerhalb einer first-class Funktion reden kann. Ich finde, das wäre so wie wenn man jede beliebige Anweisung einfach als "Schleife" bezeichnet, die halt nur ein mal durchläuft. Natürlich ist das "irgendwo" richtig, aber nicht sinnvoll die Terminologie hier zu verwenden.

    Noch ein schönes Beispiel (in Perl, liesst sich aber wirklich ganz einfach), wann aus einer first-class Funktion eine Closure wird:
    perl.com/pub/a/2002/05/29/closure.html
    ♥C++

  • Amin Negm-Awad schrieb:

    Nein, du diskutierst den grenzwertigen Fall. Du hast ihn überhaupt ins Spiel gebracht.

    Gib mir einfach eine Definition und sage mir, an welchem Merkmal es scheitert.

    Closures ergeben nur Sinn, wenn man sie in ihrem Environment betrachtet. Wenn sie freie Variablen haben, die erst ausserhalb der Funktion gebunden werden. Aus dieser Motivation heraus wurden Closures in Scheme eingeführt. Aus dieser Motivation heraus ist die Bezeichnung "Closure" entstanden. First-class Functions haben wir schon seit LISP, Closures erst mit Scheme. Willst Du mir jetzt sagen, dass mehrere hundert wissenschaftliche Arbeiten (Beschreibung des Problems, Lambda Lifting etc. um dieses Problem zu lösen) sich alle nur mit dem grenzwertigen Fall beschäftigen?

    Erkläre Du mir dann doch bitte, was Closures unterscheidet von first-class Funktionen oder Lambda-Ausdrücken?

    Willst Du es nicht verstehen, oder willst Du es nur nicht zugeben?
    ♥C++

  • Ist doch alles Käse, ääh, Wurst. Wenn ich mit Menschen rede, die ein Grundverständnis von dem Thema haben, ist die Diskussion um die Wortwahl "Blocks sind Closures" oder "Blocks ermöglichen Closures" oder "Blocks ist das Sprachkonstrukt, das das Closure-Konzept implementiert" hinfällig. Das ist insofern klar, als dass eine Closure ein Konzept ist, das mit programmiersprachlichen Mitteln realisiert wird. Darüber muss und will ich aber nicht diskutieren, weil es a) selbstverständlich, b) klar, c) albern und d) haarspalterisch ist. Ich habe nichts gegen Haarspalterei, aber dann doch bitte zu einem Thema, das des Haarespaltens wert ist. Ich hatte jedenfalls das Gefühl, dass Amin und ich über das gleiche geredet haben (und glaub' mir: das tun wir nicht immer).

    Was ich mit diesem Hintergrund nicht verstehe, ist die Aussage "Blocks sind keine Closures". Blocks setzen Closures um wie in vielen anderen Sprachen auch. Ich kenne keine Sprache, die meckert, wenn ich in einem entsprechenden Konstrukt nicht mindestens einen Upvalue verwende. Sicherlich: Eine Closure ohne Upvalues ist ein besonderer Fall, genauso wie die leere Menge eine besondere Menge ist. Oder eine leere Anweisung oder die Identitätsfunktion. Trotzdem gehören sie dazu. Und es ändert nichts an der Sache.
    Multigrad - 360°-Produktfotografie für den Mac

  • mattik schrieb:

    Ist doch alles Käse, ääh, Wurst. Wenn ich mit Menschen rede, die ein Grundverständnis von dem Thema haben, ist die Diskussion um die Wortwahl "Blocks sind Closures" oder "Blocks ermöglichen Closures" oder "Blocks ist das Sprachkonstrukt, das das Closure-Konzept implementiert" hinfällig. Das ist insofern klar, als dass eine Closure ein Konzept ist, das mit programmiersprachlichen Mitteln realisiert wird. Darüber muss und will ich aber nicht diskutieren, weil es a) selbstverständlich, b) klar, c) albern und d) haarspalterisch ist. Ich habe nichts gegen Haarspalterei, aber dann doch bitte zu einem Thema, das des Haarespaltens wert ist. Ich hatte jedenfalls das Gefühl, dass Amin und ich über das gleiche geredet haben (und glaub' mir: das tun wir nicht immer).

    Blocks sind eben keine Closures. Und das ist nicht weniger haarspalterisch, als die üblichen Hinweise die sonst etwa von Amin kommen. Ich könnte auch sagen, dass "Funktion" und "Methode" identisch sind, sogar Wikipedia verweist auf den synonymen Gebrauch. Trotzdem würdet ihr euch doch bei falscher Benutzung der Terme genauso die Haare raufen. Es wäre einfach nicht förderlich, alle Funktionen einfach als Methoden zu bezeichnen, als Spezialfall einer anonymen, leeren Klasse - Diese terminologische Unterscheidung ist eben genauso berechtigt, wie die zwischen Closures und Anonymen/First-Class Funktionen sowie Lambda-Ausdrücken.

    mattik schrieb:


    Was ich mit diesem Hintergrund nicht verstehe, ist die Aussage "Blocks sind keine Closures". Blocks setzen Closures um wie in vielen anderen Sprachen auch. Ich kenne keine Sprache, die meckert, wenn ich in einem entsprechenden Konstrukt nicht mindestens einen Upvalue verwende. Sicherlich: Eine Closure ohne Upvalues ist ein besonderer Fall, genauso wie die leere Menge eine besondere Menge ist. Oder eine leere Anweisung oder die Identitätsfunktion. Trotzdem gehören sie dazu. Und es ändert nichts an der Sache.

    Gut, wir sind uns schonmal einig, dass der Fall ohne Upvalues ein besonderer ist. Und jetzt behaupte ich weiterhin, dass das ganze Konzept der Closures ohne upvalues ohnehin hinfällig ist, denn nur dafür wurden sie geschaffen und danach sind die bezeichnet. In dem besonderen Fall bildet man eben keinen Abschluss über upvalues, daher braucht man hier auch nicht von Closures zu reden.
    Der Compiler wird sicherlich nie meckern, der denkt in dem Fall gar nicht daran, dass es eine Closure sein könnte. Muss er ja nicht. Er muss ja keine upvalues abschliessen. Und hier liegt der Haase auch im Pfeffer: KANN der Compiler mit upvalues umgehen, unterstützt er Closures. Kann er das nicht, sondern nur den Spezialfall, unterstützt er halt nur first-class Funktionen.
    Ich kann ewig mit Blocks arbeiten und nie Upvalues verwenden. Dann muss der Compiler nie einen Abschluss über diese, also Closures, bilden. Warum sollte ich jetzt trotzdem behaupten, ich würde mit Closures arbeiten? Mir würde ja nichteinmal auffallen, wenn der Compiler bzw. die Sprache gar keine Closures unterstützen würde?
    ♥C++

  • Und noch etwas:
    "Blocks sind keine Closures" ist schon darin berechtigt, dass ausnahmlos in der Literatur der funktionalen Programmierung eine Closure definiert ist als ein Tupel einer Funktion mit ihrer Umgebung. Hier bedeutet das entsprechend, dass eine Closure ein Block zusammen mit dem Scope, in dem er definiert wurde ist.
    Um das von mir vielzietierte Objective-C beispiel noch einmal zu bemühen: Die Closure ist in diesem Fall ohnehin die Funktion "downCounter" und nicht der Block darin. Meinetwegen könnte man diese Funktion auch als Closure ohne Upvalues bezeichnen, wenn es keine Upvalues darin geben würde. Aber niemals ist der Block an sich die Closure.
    ♥C++