Diskussion:Scheme
Scheme - Lisp
BearbeitenIch hab' einige Halbwahrheiten aus dem Artikel entfernt. Der Artikel im englischen Wikipedia ist ausgezeichnet und könnte eine solide Grundlage für einen deutschen Artikel werden. Gruesse, MH 20:25, 15. Mär 2004 (CET)
Umstrukturierung
BearbeitenIch habe den Artikel etwas umstrukturiert, für meinen Geschmack war in der Vorgängerversion eine zu starke Trennung zwischen Prozeduren und anderen Daten. Ich hoffe ich hab niemanden damit verärgert. Anregungen willkommen. --84.160.232.235 13:22, 1. Sep 2005 (CEST)
Hygienische Makros
Bearbeiten"Drittens sind Makros in Scheme im Gegensatz zu LISP hygienisch." was heißt das denn bitte? --84.63.3.179 02:10, 6. Feb 2006 (CET)
Ich glaube der Satz stimmt so nicht, war mir schon immer ein Dorn im Auga, da Scheme (R5RS) keine Macros kennt, aber dazu müsste ich mal meinen Ausdruck von R5RS rauskramen. Diese Form von Macros wird von den einzelnen Implementierungen geboten. Das hygienisch bedeutet in dem Fall, dass die Macros nicht so leicht außer Kontrolle geraten können.--Rbb 06:53, 6. Feb 2006 (CET)
- Die syntax transformers aus R5RS werden meiner Kenntnis nach durchaus üblicherweise als Makros angesehen. Makros heißen hygienisch, wenn ihre Verwendung nicht die lexikalische Struktur der die Verwendung enthaltenden Ausdrücke verletzt, so dass einerseits die innerhalb eines Makros möglicherweise eingeführten Bindungen von Bezeichnern niemals die bereits in der lexikalischen Umgebung der Makroverwendung definierten Bindungen dieser Bezeichner überdecken und andererseits die innerhalb eines Makros verwendeten freien Bezeichner immer in der lexikalischen Umgebung der Makrodefinition aufgelöst werden statt in der lexikalischen Umgebung der Makroverwendung. — Tobias Bergemann 14:26, 4. Aug 2006 (CEST)
Deklarationen vs Bindungen
BearbeitenZum Abschnitt "Deklaration": Hier waere es sinnvoll Deklarationen (also define, global) und Bindungen (lokal mit lambda) zu unterscheiden. Das Bindungen nur ueber ein lambda moeglich ist, kommt dann auch klarer raus. Besonders, wenn man darauf hinweist, dass let, let* und letrec nur syntaktischer Zucker ist. --Uknela 11:56, 1. Mär 2006 (CET)
- Man könnte hierbei auch auf die unterschiedliche Semantik von globalem und lokalem
define
hinweisen (siehe R5RS: 5.2 Definitions). — Tobias Bergemann 14:05, 4. Aug 2006 (CEST)
Die Aussage, das ein Merkmal von "define" sei, dass es global wirke, während "lambda" lokal sei, ist meines Wissens falsch. Man kann mit "define" auch lokale Definitionen machen und insbesondere ist es nicht möglich mit "define" innerhalb eines lokalen Gültigkeitsbereichs eine Definition außerhalb des lokalen Gültigkeitsbereichs zu machen, was die obige Aussage suggerieren würde. Beispiel mit Guile:
(define outer (lambda ()
(define inner 3.14)
inner))
(outer) ;; -> 3.14
inner ;; -> error: unbound variable
Hierbei handelt es sich um eine "globale" Definition unter Verwendung von "lambda" und eine lokale Definition mit "define". Es ist offensichtlich, dass es keinen Zusammenhang zwischen "define" und einem globalen Geltungsbereich gibt. Die maßgebliche Leistung von "define" besteht darin, anonyme Referenzen, wie sie z.B. von "lambda" erzeugt werden, zu benennen damit sie danach nicht mehr anonym sind. Ich musste gerade feststellen, dass der Irrglaube, dass define global sei, sich durch den ganzen Artikel durchzieht. --Ceving 15:20, 3. Mai 2010 (CEST)
Kommentare
BearbeitenIch habe dem Artikel gestern die Möglichkeit für Mehrzeilige Kommentare hinzugefügt. Falls bei diversen Interpretern die Kommentierung mit ( #| ) ( |# ) nicht funktionieren sollte, möge er das angeben. Ansonsten ist es eine SEHR praktische Funktion. In meinen Kreisen wusste bisher kaum jemand davon, dass es die Möglichkeit mehrzeiliger Kommentare überhaupt gibt.
Gruß Robbster 23:10, 3. Mär 2006 (CET)
- Afaik ist das nicht R5RS, also tendiere ich eher dazu das rauszzustreichen.--Rbb 13:08, 5. Mär 2006 (CET)
- Wahrscheinlich bietet jede konkrete Scheme-Implementierung deutlich mehr Funktionalität als von R5RS gefordert. Ich denke, der Artikel sollte sich nicht scheuen, derartige Erweiterungen zu beschreiben, vorausgesetzt, sie sind so gängig, dass sie von mehreren weitverbreiteten Implementierungen unterstützt werden. — Tobias Bergemann 14:09, 4. Aug 2006 (CEST)
- Da magst du recht haben, aber ich denke es ist wichtiger einen guten Überblick darüber zu geben wie Scheme funktioniert als solche syntaktischen nebensächlichkeiten genauer auszuführen. --Rbb 00:49, 23. Sep 2006 (CEST)
- Ich dachte auch nicht, dass man mehr als einen oder zwei Sätze zu mehrspaltigen Kommentaren schreiben sollte. Andererseits denke ich nicht, dass sich der Artikel auf eine Beschreibung von R5RS beschränken kann, ohne ein verzerrtes Bild der Sprache und ihrer Einsatzmöglichkeiten zu geben. Außerdem sind mehrzeile Kommentare durch einen weithin akzeptierten Scheme Request For Implementation abgedeckt (SRFI 30) und Teil des Entwurfs für R6RS. — Tobias Bergemann 09:10, 23. Sep 2006 (CEST)
- Da magst du recht haben, aber ich denke es ist wichtiger einen guten Überblick darüber zu geben wie Scheme funktioniert als solche syntaktischen nebensächlichkeiten genauer auszuführen. --Rbb 00:49, 23. Sep 2006 (CEST)
- Wahrscheinlich bietet jede konkrete Scheme-Implementierung deutlich mehr Funktionalität als von R5RS gefordert. Ich denke, der Artikel sollte sich nicht scheuen, derartige Erweiterungen zu beschreiben, vorausgesetzt, sie sind so gängig, dass sie von mehreren weitverbreiteten Implementierungen unterstützt werden. — Tobias Bergemann 14:09, 4. Aug 2006 (CEST)
Syntaktischer Zucker
BearbeitenWas um alles in der Welt soll der Ausdruck "Syntaktischer Zucker" denn eigentlich bedeuten? Könnten die ganzen Programmierer hier bitte von ihrem geek-talk runterkommen und bestenfalls von "Bequemlichkeit" reden? Nur weil die englische Literatur ständig diesen Ausdruck verwendet, ist er noch lange kein vernünftiger deutscher Begriff. Danke. --Cstim 14:20, 21. Sep 2006 (CEST)
- "Syntaktischer Zucker" bezeichnet eine syntaktische Form, die, wenn man sie aus der Sprache entfernte, die Ausdrucksfähigkeit der Sprache nicht beschneiden würden. Also LET ist z. B. syntaktischer Zucker für die Bindung von Variablen über ein LAMBDA und einen Funktionsaufruf. Der Begriff taucht schon in der im Artikel zitierten deutschen Literatur auf. Insofern gehört der Begriff schon im Artikel erwähnt.
- Ich denke Syntaktischer Zucker kann schon im Artikel vorkommen, allerdings nicht so wie es der Fall war. Also ist es imho besser die Bedeutung von Syntaktischen Zucker im Text zu umschreiben, aber in einem eigenen Abschnitt zu erklären was »Syntactic Sugar« im Bezug auf Scheme bedeutet. Noch eine Bitte: Signiert eure Diskussionsbeiträge.--Rbb 11:33, 25. Sep 2006 (CEST)
Ach du Schreck, es existiert tatsächlich ein Artikel Syntaktischer Zucker. Na denn. Aber ich hab (zwar nicht im Hauptfach, aber teilweise doch) auch einiges an Informatik studiert und mir ist der Begriff im Deutschen nie begegnet. Ist das nicht halt so ein englischer Begriff, von dessen Übersetzung man aber großzügig Abstand nehmen könnte? Also mit anderen Worten: Das ist dann aber schlimmster Fach-Jargon und der sollte in diesem beschreibenden Artikel dann bitte vermieden werden, soweit möglich. An den Stellen wo ich's geändert habe war es offensichtlich sehr leicht möglich. --Cstim 16:30, 25. Sep 2006 (CEST)
- In unserer Scheme-Vorlesung war auch von Syntaktischem Zucker die Rede, ich fand den Ausdruck eigentlich recht intuitiv zu erfassen. – 84.130.34.70 06:07, 5. Okt 2006 (CEST)
Eckige Klammern
BearbeitenDie Möglichkeit eckige anstatt runder Klammern zu verwenden wird nur von einigen Implementierung (z. B. PLT Scheme) geboten. Der aktuelle R5RS-Standard sieht nur die runden Klammern vor. Von daher sollte der Artikel auf die Verwendung von eckigen Klammern verzichten. -- 84.160.23.159 10:54, 19. Nov. 2006 (CET)
- Ich glaube nicht, dass das überhaupt erwähnt werden sollte, es lenkt nur von den wirklichen Eigenschaften der Syntax ab. Der Artikel muss ja nicht die kompletten zukünftigen Sprachreferenzen umfassen (R6RS ist noch nicht durch) und jede eigenheit der Verschiedenen Interpreter aufzählen. Viel wichtiger wäre es vielleicht Anwendungsgebiete von Scheme zu zeigen. --Rbb 23:02, 19. Nov. 2006 (CET)
Sch...
BearbeitenIst es erwähnenswert dass das Sch in Scheme dem im englischen üblichen sh gegenübersteht und relative eindeutig auf School hinweist, weil er ja eigentlich nur akademische Absichten dahinterstanden? --Kockmeyer 19:15, 9. Apr. 2007 (CEST)
- "scheme" ist ein selbstständiges, englisches Wort mit mehreren Bedeutungen ([1]). Ein Bezug zu "school" wäre ohne Quellen bloße Spekulation und sollte als solche nicht in den Artikel. Wenn du Quellen hierfür hast könnte man drüber reden. --Rbb 00:18, 10. Apr. 2007 (CEST)
- Zu den Ursprüngen der Sprache scheme http://www.brics.dk/~hosc/local/HOSC-11-4-pp399-404.pdf ... ansonsten wäre es begrüßenswert, wenn demnächst vor dem Editieren recherchiert würde. Wenn ich die Zeit finde korrigiere ich demnächst mal ein paar Fehler im Artikel.
Schleifen in Scheme?
BearbeitenHier im Artikel steht, dass es in Scheme keine Schleifen-Konstrukte gäbe. Ich habe jedoch eine Quelle gefunden, die anderes behauptet und diese Behauptung auch erfolgreich getestet. In Scheme gibt es das Konstrukt do, die ähnlich wie eine for-Schleifen in Java und anderen Sprachen aufgebaut ist. Quelle:http://www.debacher.de/pdf/scheme-hansa-2007.pdf (Seite 6)
Kann das bitte ein erfahrener Wikipedianer in den Artikel einpflegen?
Grüße -- 141.58.50.214 10:27, 4. Aug. 2009 (CEST)
do wird in der Regel als Makro implementiert, welches die Schleife mit letrec implementiert. Siehe R6RS: http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-6.html#node_chap_5 --92.74.174.38 21:32, 8. Aug. 2010 (CEST)
Scheme - Lisp
BearbeitenScheme unterscheidet sich von Lisp in der Weise, dass es sich bei Scheme um eine Programmiersprache handelt und bei Lisp um eine Sprachfamilie. Der dritte Absatz der Einleitung ergibt damit wenig Sinn, da Scheme selbst zu dieser Sprachfamilie gehört. Vielleicht ist mit "Lisp" an dieser Stelle "Common Lisp" oder "Lisp 1.5" oder auch "Lisp Machine Lisp" gemeint. -- 79.237.48.95 18:25, 8. Nov. 2009 (CET)
/* Implementierungen und Entwicklungswerkzeuge */ überarbeiten
Bearbeitender Absatz enthält eine Reihe Weblinks im Fließtext. Derartige Weblinks sind unzulässig. Vielleicht vermag Fachmann/Fachfrau dies zu korrigieren. --Ottomanisch 13:17, 6. Jul. 2010 (CEST)
Endlosschleife
BearbeitenEigentlich ist der rekursive Aufruf von loop (wie im Artikel) keine Endlosschleife! Wenn der Arbeitsspeicher (Stack) voll ist, terminiert das Programm (nicht signierter Beitrag von 84.168.58.140 (Diskussion) 21:37, 14. Dez. 2011 (CET))
- Nö. Tail Call Elimination ist von der Sprachspezifikation vorgeschrieben. --Daniel5Ko 22:15, 14. Dez. 2011 (CET)
Schreibweise DrScheme
BearbeitenIch bin mir nicht ganz sicher, aber war "DrScheme" nicht "DRScheme", da Produkt von Digital Research ? Meine Erinnerung daran ist jedoch lückenhaft... --arilou 00:14, 19. Dez. 2011 (CET)
Literal oder Variable?
BearbeitenAbschnitt "Syntax": "Der Operator kann wieder eine zusammengesetzte Form, ein Schlüsselwort oder eine einfache Form, also z. B. ein Literal oder ein Variablenname sein."
Ähm, hä? Ein Operand kann ein Literal, eine zusammengesetzte Form oder eine Variable sein, aber der Operator doch nicht.
- Als "zusammengesetzte Form" muss diese dann zwingend zu einer "Funktion"/"Operator" auswerten.
- Und als Variable muss diese dann vom Typ "Funktion"/"Operator" sein. (Und selbst dann, ist da nicht ein
(eval myVariable)
o.ä. notwendig?) - Aber bestimmt kein Literal. (Geht gar nicht.)
--arilou (Diskussion) 10:33, 13. Nov. 2012 (CET)
- Ohne vorab definierte Nomenklatur kann man sich den Text natürlich so auslegen, wie man will. Möglicherweise ist mit "Literal" eine "Literal expression" [2] gemeint, also eigentlich eher ein "wörtlicher Ausdruck". Aber auch dann kann ein Literal kein Operator sein.
- Zur zusammengesetzten Form: Das ist richtig, ((+ 2 2) 2 2) ist nicht zulässig. Aber der Text behauptet das auch nicht, er macht aber auch nicht darauf aufmerksam.
- Zu Variablen: In (define (y x) (x 2 2)) ist x in (x 2 2) eine Variable, die eine Funktion erhält. (y +) bindet x dann an +. Das geht ohne eval.
- --Zahnradzacken (Diskussion) 19:53, 18. Nov. 2012 (CET)
- "... wie man will" ~ nuja, es gibt den Artikel Literal#Literale in Programmiersprachen. Ein Leser wird wohl den zugehörigen WP-Artikel als Bezugsrahmen erwarten. Und dann ist die Aussage im hießigen Artikel schlichtweg falsch.
- Und daher ändere ich das jetzt entsprechend. --arilou (Diskussion) 11:49, 20. Nov. 2012 (CET)
- Sehe ich auch so. Ich habe jetzt nicht überprüft, ob derjenige, der im Artikel auf Literal verlinkt hat, auch der Autor des Abschnitt ist. Wenn ja, war das schlicht falsch. Wenn nein, war der Link verwirrend und die fehlende Definition das Versäumnis des Abschnitts-Autors.
- Deine Änderungen habe ich aber auch nochmal überarbeitet. Der Abschnitt heißt zwar "Syntax", aber ohne Semantik hat die Syntax-Beschreibung keinen Zweck – dennoch finde ich eine Trennung sinnvoll. Dass bei (f x) das f zu einer Funktion auswerten muss, ist Teil der Semantik. Nebenbei habe ich falsche und missverständliche Sätze gestrichen (mit Konstanten gibt es eben gerade auch nicht zusammengesetzte Ausdrücke, Klammern setzt man nicht nur um zusammengesetzte Ausdrücke). Aber es fehlt noch viel, zum Beispiel die zentrale Bedeutung von Funktionen. Also noch ein Versäumnis, das sich aber gerade nicht vermeiden lässt. --Zahnradzacken (Diskussion) 22:09, 20. Nov. 2012 (CET)
a) Danke! Ist jetzt imo ok.
b) somit:
M.M. nach fehlt im Vergleichsabschnitt Scheme<-> LISP die ganz zentrale Aussage, daß Scheme lexically scoped ist, LISP aber per default dynamically scoped. Das ist eine der grundlegenden Designüberlegungen von Scheme, deswegen sollte sie in die Vergleichsliste mit rein. RAc (nicht signierter Beitrag von 217.243.170.68 (Diskussion) 10:42, 28. Feb. 2012 (CET))
- Beitrag nach unten verschoben --arilou (Diskussion) 10:40, 13. Nov. 2012 (CET)
WP:OMA
BearbeitenDen "Vergleich Scheme/Lisp" versteh' ich auch nur nach dreimal lesen so halb. Da müsste mal jemand mit dem Fremdwortbesen durchwischen. --Tuxman (Diskussion) 14:24, 1. Sep. 2016 (CEST)
- Kann ich nicht ganz nachvollziehen. Im Prinzip besteht doch der ganze Abschnitt aus Erläuterungen eben dieser Fachausdrücke, ohne die sich sowas eben schlecht beschreiben lässt. Nix Neues. Dazu ist einiges verlinkt, wobei manche dieser Artikel sogar Scheme-Beispiele anführen, also quasi direkt anknüpfen, d.h. soweit WP das halt hergibt. Richtig wild ist es dazu nun nicht, jedenfalls bestimmt nicht in dem Sinne, dass sich jmd., der schon mal irgendwie von funkt. Prog. hörte, davon erschlagen sähe. Blöder find ich, dass das Wichtigste glatt fehlt (siehe etwa Abs. hier drüber) und man sowas ohne Codebeispiel(e) generell witzlos finden kann. So isses nämlich in der Tat auch für Programmierer erst mal Blahblah und ein (guter) Blog-Eintrag hätte sie, eben deshalb. Das hat dann nur nix mehr mit Allg.-Verst. zu tun. An die erste Stelle gehört das aber sicher nicht, ich werd's mal verschieben. -ZT (Diskussion) 22:19, 1. Sep. 2016 (CEST)
- Nja ~ ich kann Tuxmans Kritik teilweise verstehen: "Continuation" sollte mit einem Halbsatz kurz grob-erklärt werden.
- Hingegen gibt es Makros, Rekursion, Variablen-Gültigkeitsbereiche und -Überdeckung auch in den meisten anderen Programmiersprachen, und die Probleme und Besonderheiten Schemes diesbezüglich werden ja gerade erklärt in dem Abschnitt.
- Aber über die "Continuation" bin ich auch gestolpert.
- --arilou (Diskussion) 08:44, 2. Sep. 2016 (CEST)
- Also am Anfang hab ich bei dem Absatz noch gedacht, so schlimm ist es doch gar nicht, aber bei diesem "Satz" musste ich schon lachen:
- Drittens sind Makros in Scheme im Gegensatz zu LISP „hygienisch“, was bedeutet, dass ihre Verwendung nicht die lexikalische Struktur der die Verwendung enthaltenden Ausdrücke verletzt, so dass einerseits die innerhalb eines Makros möglicherweise eingeführten Bindungen von Bezeichnern niemals die bereits in der lexikalischen Umgebung der Makroverwendung definierten Bindungen dieser Bezeichner überdecken und andererseits die innerhalb eines Makros verwendeten freien Bezeichner immer in der lexikalischen Umgebung der Makrodefinition aufgelöst werden statt in der lexikalischen Umgebung der Makroverwendung.
- Das kann man gar nicht verstehen, ohne sich zu konzentrieren.--Entinator (Diskussion) 20:31, 29. Okt. 2016 (CEST)
- Ich fühle mich (teil-)schuldig. Der Wortlaut ist von mir, ich hatte das 2006 (noch unter meinem alten Namen) hier auf dieser Diskussionsseite geschrieben (Diff, siehe #Hygienische Makros). Immerhin habe ich den Text aber nicht selbst in den Artikel eingefügt, und schon als dieser Text 2007 von AchimP eingefügt wurde (Diff), war die Änderung mit einem entsprechenden Kommentar versehen: "von Diskussionsseite geklaut, vielleicht geht's auch etwas verständlicher?" Vielleicht reicht es ja schon, das in drei bis vier Sätze aufzuteilen? Tea2min (Diskussion) 07:50, 30. Okt. 2016 (CET)
- Ich habe mal versucht, das in mehr Sätze zu zerlegen (bisher ohne Bindewörter) Sieht das verständlicher aus?
- Drittens sind Makros in Scheme im Gegensatz zu LISP „hygienisch“. Das bedeutet, dass sie nicht die lexikalische Struktur der Ausdrücke verletzen, in denen sie verwendet werden. Falls innerhalb eines Makros Bindungen von Bezeichnern eingeführt werden, überdecken sie keine Bindungen, die bereits in der lexikalischen Umgebung der Makroverwendung definiert sind. Die innerhalb eines Makros verwendeten freien Bezeichner werden immer in der lexikalischen Umgebung der Makrodefinition aufgelöst, statt in der lexikalischen Umgebung der Makroverwendung.
- Ich stelle mir vor, dass es dem Absatz helfen würde, wenn man statt einem Text die Unterschiede einzeln auflistet. Dann ist es auch einfacher, die weiteren Unterschiede reinzuwurschteln, die oben erwähnt werden --Entinator (Diskussion) 10:55, 30. Okt. 2016 (CET)
Ich verstehe auch in der aufgelösten Satzstruktur nicht, was "eine Verletzung der lexikalischen Struktur" sein soll. Anscheinend ist kein Syntaxfehler gemeint, oder? Und dann frage ich mich noch, ob dafür der Begriff "hygienisch" etabliert ist, oder doch nur TF? --AchimP (Diskussion) 12:16, 30. Okt. 2016 (CET)
- Na ja, eine Verletzung der lexikalischen Struktur ist eben, wenn innerhalb der Verwendung eines Makros Bezeichner gebunden werden, die in der lexikalischen Umgebung der Verwendung des Makros schon gebunden waren. Und der Begriff "hygienisch" ist allerdings etabliert, er wird ja beispielsweise in R5RS selbst verwendet, stammt aber wohl ursprünglich von Barendregt. Siehe Kohlhaber, Friedman, Felleisen & Duba, "Hygienic Macro Expansion" von 1986. Tea2min (Diskussion) 18:29, 30. Okt. 2016 (CET)
- Gut, jetzt hab ich's verstanden. Und Danke für den Link. . Lax würde ich formulieren: "Makros in Scheme können lexikalisch keine lokalen Variablen überschreiben." Aber das ist vielleicht zu unpräzise. --AchimP (Diskussion) 18:49, 30. Okt. 2016 (CET)
- So kann man sich vielleicht eher was vorstellen, aber was die Präzision betrifft... Ich fände es besser, wenn wir einfach alles, was unklar ist, und noch nicht erklärt wird, auch erklären. Für mich sind z.B. "lexikalische Struktur" oder "lexikalische Umgebung" und "freie Bezeichner" Begriffe, die man noch erklären könnte. Was ist eine lexikalische Umgebung im Gegensatz zu einer Umgebung? Ich kann mir zwar etwas vorstellen, aber ich bin nicht sicher... --Entinator (Diskussion) 10:32, 31. Okt. 2016 (CET)
- Das mit der "lexikalischen Struktur" kann man einfach weglassen. Dann liest es sich ungefähr so:
- Drittens sind Makros in Scheme im Gegensatz zu LISP „hygienisch“: Falls innerhalb eines Makros Bindungen von Bezeichnern eingeführt werden, überdecken sie keine Bindungen, die bereits in der lexikalischen Umgebung der Makroverwendung definiert sind, und umgekehrt werden innerhalb eines Makros verwendete freie Bezeichner immer in der lexikalischen Umgebung der Makrodefinition aufgelöst, statt in der lexikalischen Umgebung der Makroverwendung.
- Zum Begriff "lexikalische Umgebung" (englisch: "lexical Environment", oft auch einfach nur "environment"). Kurz gesagt besteht die lexikalische Umgebung aus den sichtbaren lexikalischen Bindungen, d.h. die vielleicht vorhandenen dynamischen Bindungen sind nicht Teil der lexikalischen Umgebung. (Aber dynamische Bindungen spielen in Scheme sowieso keine Rolle.)
- Das wird in der Definition von ECMAScript so formuliert:[3]
- A Lexical Environment is a specification type used to define the association of Identifiers to specific variables and functions based upon the lexical nesting structure of ECMAScript code. A Lexical Environment consists of an Environment Record and a possibly null reference to an outer Lexical Environment. Usually a Lexical Environment is associated with some specific syntactic structure of ECMAScript code such as a FunctionDeclaration, a BlockStatement, or a Catch clause of a TryStatement and a new Lexical Environment is created each time such code is evaluated.
- In der "Common Lisp HyperSpec" heißt es:[4]
- lexical environment n. that part of the environment that contains bindings whose names have lexical scope. A lexical environment contains, among other things: ordinary bindings of variable names to values, lexically established bindings of function names to functions, macros, symbol macros, blocks, tags, and local declarations.
- Und freie Bezeichner sind unter Freie Variable und gebundene Variable beschrieben. – Tea2min (Diskussion) 12:41, 31. Okt. 2016 (CET)
- Danke für die Info! Nach dieser Definition könnte man doch auch auf den Artikel Wortschatz (dahin wird von Lexikalisch weitergeleitet) verlinken? Also wäre die Lexikalische Umgebung der "Wortschatz". Verstehe ich etwas falsch? Und viel wichtiger: Würde das zu mehr Klahrheit führen? --Entinator (Diskussion) 13:13, 31. Okt. 2016 (CET)
- Das mit der "lexikalischen Struktur" kann man einfach weglassen. Dann liest es sich ungefähr so:
- PS ich würde den einen Satz nochmal unterteilen: "...definiert sind[. U]mgekehrt..." Dann weiß man, dass man kurz eine Denkpause machen kann ;) --Entinator (Diskussion) 13:13, 31. Okt. 2016 (CET)
- Offenbar hat die deutschsprachige Wikipedia eine lexikalische Lücke in Bezug auf Begriffe wie Lexikalische Bindung und Lexikalische Umgebung... Aber ernsthaft: Ich halte einen Verweis auf Wortschatz in diesem Kontext für wenig hilfreich, einfach weil wir hier ja über Programmiersprachen sprechen und nicht über natürliche Sprachen. Es geht hier um die Sichtbarkeit von Namen/Bezeichnern und insbesondere ihre Bindung zu Variablen. Siehe Variable (Programmierung)#Sichtbarkeitsbereich von Variablen (Scope). Dort wird der Begriff "lexikalische Bindung" erklärt. Vielleicht sollte man gelegentlich eine Weiterleitung von Lexikalische Bindung dahin anlegen. – Tea2min (Diskussion) 15:02, 31. Okt. 2016 (CET)
- Fänd ich gut. --Entinator (Diskussion) 20:02, 31. Okt. 2016 (CET)
- Offenbar hat die deutschsprachige Wikipedia eine lexikalische Lücke in Bezug auf Begriffe wie Lexikalische Bindung und Lexikalische Umgebung... Aber ernsthaft: Ich halte einen Verweis auf Wortschatz in diesem Kontext für wenig hilfreich, einfach weil wir hier ja über Programmiersprachen sprechen und nicht über natürliche Sprachen. Es geht hier um die Sichtbarkeit von Namen/Bezeichnern und insbesondere ihre Bindung zu Variablen. Siehe Variable (Programmierung)#Sichtbarkeitsbereich von Variablen (Scope). Dort wird der Begriff "lexikalische Bindung" erklärt. Vielleicht sollte man gelegentlich eine Weiterleitung von Lexikalische Bindung dahin anlegen. – Tea2min (Diskussion) 15:02, 31. Okt. 2016 (CET)
- Ich kenn das unter Scope (so lautet ja auch die Abschnitts-Überschrift) und den Eintrag gibt's. Eine WL schadet sicher nicht, auch wenn ich nicht glaube, dass jemand gezielt nach "Lexikalische Bindung" sucht. --AchimP (Diskussion) 10:43, 1. Nov. 2016 (CET)
- Kann sein. Ich glaube, wir haben noch zu viele Nominalisierungen drin (Makrodefinition und Makroverwendung z.B.). Es könnte sein, dass man ein paar Sätze mehr braucht, um den Text allgemeinverständlich zu machen. Das kann ich nicht mehr so gut beurteilen, weil ich ihn inzwischen verstehe xD. Laut einem Online-Textanalyse-Werkzeug ist der Text inzwischen OK, deswegen übertrage ich mal die bisherigen Änderungen, wobei ich noch ein Paar Sätze zerstückele. (Ich finde den Text mit Unterteilungen schöner zu lesen. Deswegen würde ich Umbrüche oder Aufzählungspunkte verwenden) Was sagt ihr, bzw. eure Oma?
Drei wesentliche Merkmale unterscheiden Scheme von LISP:
- In Scheme gibt es die Funktion call-with-current-continuation. Sie erlaubt, die gegenwärtige Continuation anzusprechen oder an eine Variable zu binden, also eine Repräsentation des aktuellen Zustands des laufenden Programms. Damit ist es möglich, durch Aufrufen der in jener Variablen gespeicherten Continuation, später im Programm an die Stelle dieser Continuation zurück zu springen.
- Der Scheme-Standard schreibt proper tail recursion vor. Das bedeutet, dass Prozeduraufrufe, die in einer endrekursiven Position stattfinden, keinen Speicherplatz auf dem Stack verbrauchen dürfen.
- Im Gegensatz zu LISP sind Makros in Scheme „hygienisch“: Falls innerhalb eines Makros Bindungen von Bezeichnern eingeführt werden, überdecken sie keine Bindungen, die bereits in der lexikalischen Umgebung der Makroverwendung definiert sind. Umgekehrt werden innerhalb eines Makros verwendete freie Bezeichner immer in der lexikalischen Umgebung der Makrodefinition aufgelöst, statt in der lexikalischen Umgebung der Makroverwendung.
Ich würde den gewünschten Nebensatz zu Continuation noch überarbeiten (auch die Position!), denn ich finde ihn nicht gerade erklärend :/ Dann bleiben noch inhaltliche Überlegungen. --Entinator (Diskussion) 19:21, 1. Nov. 2016 (CET)
Aus meiner Sicht hiermit erledigt. --Lpd-Lbr (d) 16:33, 8. Okt. 2019 (CEST)
- Besser, danke. --Tuxman (Diskussion) 00:05, 10. Okt. 2019 (CEST)
Link zum aktuellen Standard fehlerhaft
BearbeitenKorrekt ist: https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/R7RSHomePage.md?fileviewer=file-view-default
- Und warum schreibst du den hier rein und nicht in den Artikel? --Tuxman (Diskussion) 15:52, 17. Apr. 2020 (CEST)