murphy+2008-12-14 16:03:23--

Cool, muss ich mir unbedingt mal anschauen :-)

Cool, dann brauch ich's mir nicht anschauen! ;-)

murphy+2008-12-13 16:11:01--

moritz+2008-12-13 10:52:23--

[...]
Wie kommst du auf die Idee, dass Perl 6 kein vernünftiges Makro-System habe?

Nun, Perl6 hat zwar ein Makrosystem, bei einer Sprache mit Operatoren und komplexer Syntax ist es aber fast unmöglich, das vollständig hygienisch und nicht-intrusiv zu gestalten. Ich denke zwar, dass das neue auf Patterns basierende Makrosystem von Perl 6 gegenüber Quellcodefiltern in Perl 5 eine riesige Verbesserung darstellt, es ist aber meiner Meinung nach von hygienischen Makrosystemen wie man sie vor allem in modernen Schemeimplementationen findet, noch weit entfernt.

In welcher Hinsicht ist es davon weit entfernt?
Ich weiss nicht, was man mehr als Macros mit lexikalischem Scope, definierter precedence und der Fähigkeit, einen Syntax-Tree zurückzugeben braucht, daher frage ich.

Quote

Quote

Und hat Lisp Junctions,

In der Regel nicht eingebaut. Mit CLOS und / oder Makros ist sowas aber in wenigen Zeilen Code implementierbar. Genauso einfach, wie man bei Bedarf zwischen eager und lazy evaluation wechseln kann oder ähnliches.

Ich hätte nicht gedacht, dass man junction autothreading bei Funktionsaufrufen in wenigen Zeichen in Scheme hinbekommt, aber da habe ich mich dann wohl geirrt. Point taken.

Quote

Quote

Kontextsensitivität und

Ich bin nicht sicher, was Du hier meinst. Wenn es Dir um Konstrukte wie den "intelligenten" Matchoperator geht, so bin ich mir noch nicht so ganz sicher, ob ich den nicht eher gefährlich unberechenbar finde, solange er keine echte KI eingebaut hat ;-)

Ich meine diverse Kontexte (List-Kontext, String-Kontext, Numerischer Kontext, lvalue-Kontext etc.), wie man sie zum Teil auch schon von Perl 5 kennt.

Quote

Quote

Unicode-Support auf Grapheme-Level?

Sowas haben doch heute die meisten Programmiersprachenimplementationen, im Zweifelsfall in irgendeiner Bibliothek.

Die im Zweifelsfall zu benutzende Bibliothek ist meistens nicht besonders benutzerfreundlich, und so viel Aufwand, dass die meisten Programmierer sie gar nicht erst benutzen.

Für Perl 5 z.B. kenne ich nur zwei Implementierungen, String::Multibyte (das grauenhaft zu benutzen ist), und Perl6::Str (von mir geschrieben, ziemlich begrenzt im Funktionsumfang).

Mit Java kenne ich mich nicht so gut aus, aber wenn dafür solche Bibliotheken gibt (vermutlich wurde ICU für Java portiert), dann hat

Quote

Quote

(Meistens wenn ich Leute über Perl 6 lästern sehe, habe ich den Eindruck, dass sie ziemlich schlecht informiert sind).

Erstens habe ich nicht behauptet, besonders gut über Perl 6 Bescheid zu wissen, sondern lediglich einen allgemeinen Eindruck geschildert, der sich nichtmal ausschließlich auf Perl 6 bezog, sondern mehr meine allgemeine Verwunderung über teilweise wenig Innovation im Programmiersprachensektor zum Ausdruck brachte. Außerdem hatte ich meine Bemerkung ja mit einem Augenzwinkern versehen um kenntlich zu machen, dass ich die Kritik nicht tierisch ernst meine, sondern absichtlich überspitzt formuliert habe.

Zweitens kann ich wohl guten Gewissens umgekehrt behaupten, dass die meisten Leute die über Lisp oder Scheme lästern wohl auch noch nie eine moderne Implementation dieser Sprachen zu Gesicht bekommen haben [1]. In vielen Fällen regt man sich sogar nur über die Syntax auf, die aber meiner Meinung nach mehr eine Gewöhnungsfrage ist und bisweilen ihre Vorteile hat.

Tut mir leid, ich wollte nicht so harsch klingen. Zweitens war das auch eher allgemein gemeint, die meisten Leute, die über Perl 6 lästern, sind wirklich grottenschlecht informiert.

moritz+2008-12-14 19:49:46--

In welcher Hinsicht ist es davon weit entfernt?
Ich weiss nicht, was man mehr als Macros mit lexikalischem Scope, definierter precedence und der Fähigkeit, einen Syntax-Tree zurückzugeben braucht, daher frage ich.

ich vermute er nimmt den punkt, daß p6 macros nicht hygienisch sind, sehr wichtig. kein schlechtes feature, von dem ich in synopsen noch nichts gehört haben, könnte man mal in die diskussion einbringen.

ModEdit GwenDragon: Zitat repariert

lichtkind+2008-12-14 20:26:10--

moritz+2008-12-14 19:49:46--

In welcher Hinsicht ist es davon weit entfernt?
Ich weiss nicht, was man mehr als Macros mit lexikalischem Scope, definierter precedence und der Fa:higkeit, einen Syntax-Tree zuru:ckzugeben braucht, daher frage ich.

ich vermute er nimmt den punkt das p6 macros nicht hygienisch sind sehr wichtig. kein schelchtes feature von dem ich in synopsen noch nichts geho:rt haben, ko:nnte man mal in die diskussion einbringen.

Ja, ich finde hygienische Makros einfach sinnvoll. Aber eigentlich ist der Vorwurf, Perl 6 habe "kein vernuenftiges" Makrosystem wohl ein wenig ueberzogen. Das was da ist, ist immer noch deutlich besser als Quellcodefilter oder Praeprozessoren wie CPP oder M4. Und es sollte auch maechtig genug sein, um mit einigem Programmieraufwand hygienische Makros als Makrobibliothek zu implementieren. Wenn man so etwas programmieren wollte, koennte man wahrscheinlich bei Schemebibliotheken wie alexpander oder psyntax Ideen klauen...


ModEdit GwenDragon: Zitat repariert

lichtkind+2008-12-14 20:26:10--

ich vermute er nimmt den punkt, daß p6 macros nicht hygienisch sind, sehr wichtig.

Sind sie das denn wirklich nicht? Ich habe mir mal den wiki-Eintrag durchgelesen, und was ich dem entnehme ist, dass ein Makro dann hygienisch ist, wenn die darin verwendeten privaten Symbole nicht von aussen redefiniert werden koennen.

Bei Perl 6 ist es so, dass die Symbole verwendet werden, die im lexikalischen Scope gelten, in dem das Makro definiert wird. Ist es damit hygenisch?

ich dachte eher das wären macros die keine exisierenden überschreiben können. sont hätte icha uch gesagt das p6 macros hygienisch sind.

moritz+2008-12-15 13:55:55--

[...]
Bei Perl 6 ist es so, dass die Symbole verwendet werden, die im lexikalischen Scope gelten, in dem das Makro definiert wird. Ist es damit hygenisch?

Das ist zumindest notwendig fuer die Hygiene, aber nicht hinreichend. Zusaetzlich muss es moeglich sein, in den lexikalischen Geltungsbereich an der Stelle, wo das Makro benutzt wird, neue Symbole einzufuehren, die fuer jeden Aufruf des Makros eindeutig, von ausserhalb des Makros unsichtbar und syntaktisch nicht von normalen lexikalischen Variablen zu unterscheiden sind.

Das ist zum Beispiel wichtig, wenn man ein Makro schreibt, das eine temporaere Variable anlegen und im Geltungsbereich dieser Variable an das Makro uebergebenen Code einbetten muss. Es sollte dann moeglich sein, die Variablendeklaration einfach hinzuschreiben, aber trotzdem sicher zu sein, dass sie nur innerhalb des vom Makro generierten Codes nicht aber im eigebetteten Code sichtbar ist.

murphy+2008-12-15 17:27:19--

Das ist zum Beispiel wichtig, wenn man ein Makro schreibt, das eine temporaere Variable anlegen und im Geltungsbereich dieser Variable an das Makro uebergebenen Code einbetten muss. Es sollte dann moeglich sein, die Variablendeklaration einfach hinzuschreiben, aber trotzdem sicher zu sein, dass sie nur innerhalb des vom Makro generierten Codes nicht aber im eigebetteten Code sichtbar ist.

?!? ... ein Beispiel wäre nett! : )

@LanX: Ich gebe mal ein relativ sinnfreies Beispiel, das aber verdeutlicht, welches Problem man zu loesen versucht: Angenommen, wir wollen ein Makro haben, das von

in

expandiert.

Ohne Hygiene ist es nun so, dass bei jedem Aufruf dieses Makros der eingebettete Benutzercode die Variable $tmp sieht, die ihn aber nichts angeht. Insbesondere schreibt eventuell ein ahnungsloser Programmierer, der den Quellcode des Makros nicht kennt, mal so etwas hin:

und wundert sich dann, warum er auf seine eigene lexikalische Variable $tmp nicht mehr zugreifen kann.

Man sieht also, dass das Problem, das durch lokale Variablen geloest wird, in Anwesenheit von Makros komplizierter wird, da Makros ja effektiv Code in andere Geltungsbereiche injizieren. Ein hygienisches Makrosystem wuerde mir nun aber erlauben, mein Makro foo ganz natuerlich hinzuschreiben, in Phantasiesyntax zum Beispiel als

und die lokale Variable $tmp automatisch so umbenennen oder markieren, dass sie in der Expansion von <block> nicht sichtbar waere.

NACHTRAG: Zum Thema REPL hab ich mal die Mönche gefragt und u.a. sepia für emacs empfohlen bekommen.

@*emacser: (insbesondere Murphy) schauts euch an, es funzt sehr schön!