Moin moin.
Ich nehme mir jetzt mal Zeit um ueber compile-time-computing zu schreiben.
Welche Ideen hatte wir noch? Irgendwas neues?
1) Struct mit Feldern, operatoren +/-/etc automatisch generieren indem man mehrfach ueber die Felder interiert (so dass man keine Felder vergisst wenn man spaeter neue Operatoren macht)
2) arithmetische Formel nach anderen Variablen aufloesen (so dass der Programmier nicht die gleiche Formel mehrfach einhackt). Da war die Frage ob Maxima uns helfen kann?
3) literals. Bei ITA haben wir zum Beispiel enormen Vorteil weil die Sache wie "BOS" als string direkt in die binaere Repraesentation von TLAs uebersetzen koennen. Macht Code mehr leserlich. Gleiches gilt fuer literals wie Trees, die wir direkt in den Code packen koennen, in der bequemsten Form die wir uns vorstellen koennen.
3b) Regular Expressions sind eine gute Weise zu erklaeren warum das gut ist: - string wird zum compilierzet umgewandelt - syntaxcheck zur compilierzeit - verschiedene Frontends fuer die gleiche regex matching engine, z.B. einmal als Perl-regex-string, einmal als Unix-regex string, einmal als s-expression syntax. Alles fuer den gleichen Matcher
4) defmacro defun-inline. Das gibt es mehrere Spielchen: - kann man dynamisch zum compilierzeit dann doch nicht inlininen - wenn der Compiler kein inlining haette kann man den defun zum defmacro uebersetzen (wir hatten das bei ITA). Nichts was man machen moechte, demonstriert aber wie maechtig compile-time-computing ist
5) "refectoring tools". Die Java hacker lassen groessere Aenderungen von der IDE umschreiben. Das ist Bloedsinn weil die diffs im Versionskontrollsystem unleserlich werden.
6) reflection. Wenn man reflection statt c-t-c benutzt um ueber Felder in Strukturen zu iterieren dann werden Fehler von compilierzeit zur Laufzeit gepuscht. Erst wollen die Typen static typing, dann machen die Reflexion at runtime.
7) CLOS. Wenn man kein OO System haette, wuerden Lisp macros ausreichen um das ohne Compilermodifikationen zu machen. Oder vielleicht willst Du ein Klassenloses OO? Mach selber. Ohne am compiler rumfummeln zu muessen.
Was hatten wir denn sonst noch?
Martin
Moin!
Find ich gut!
Ich habe gerade keine Ergänzungen, aber Fragen zu Deinen Punkten:
zu 5: welche Art von Änderungen meinst Du hier? Ich bin im Allgemeinen nicht bereit, schlechteren Code hinzunehmen, nur weil der Diff zum besseren blöd aussehen könnte.
zu 1 und 3 bräuchte ich wohl konkreten Code, um zu verstehen, was Du meinst.
Gruß
Svante
On 2016-06-15 11:40:05-0400, Martin Cracauer wrote:
Moin moin.
Ich nehme mir jetzt mal Zeit um ueber compile-time-computing zu schreiben.
Welche Ideen hatte wir noch? Irgendwas neues?
- Struct mit Feldern, operatoren +/-/etc automatisch generieren indem
man mehrfach ueber die Felder interiert (so dass man keine Felder vergisst wenn man spaeter neue Operatoren macht)
- arithmetische Formel nach anderen Variablen aufloesen (so dass der
Programmier nicht die gleiche Formel mehrfach einhackt). Da war die Frage ob Maxima uns helfen kann?
- literals. Bei ITA haben wir zum Beispiel enormen Vorteil weil die
Sache wie "BOS" als string direkt in die binaere Repraesentation von TLAs uebersetzen koennen. Macht Code mehr leserlich. Gleiches gilt fuer literals wie Trees, die wir direkt in den Code packen koennen, in der bequemsten Form die wir uns vorstellen koennen.
3b) Regular Expressions sind eine gute Weise zu erklaeren warum das gut ist:
- string wird zum compilierzet umgewandelt
- syntaxcheck zur compilierzeit
- verschiedene Frontends fuer die gleiche regex matching engine, z.B. einmal als Perl-regex-string, einmal als Unix-regex string, einmal als s-expression syntax. Alles fuer den gleichen Matcher
- defmacro defun-inline. Das gibt es mehrere Spielchen:
- kann man dynamisch zum compilierzeit dann doch nicht inlininen
- wenn der Compiler kein inlining haette kann man den defun zum defmacro uebersetzen (wir hatten das bei ITA). Nichts was man machen moechte, demonstriert aber wie maechtig compile-time-computing ist
- "refectoring tools". Die Java hacker lassen groessere Aenderungen
von der IDE umschreiben. Das ist Bloedsinn weil die diffs im Versionskontrollsystem unleserlich werden.
- reflection. Wenn man reflection statt c-t-c benutzt um ueber
Felder in Strukturen zu iterieren dann werden Fehler von compilierzeit zur Laufzeit gepuscht. Erst wollen die Typen static typing, dann machen die Reflexion at runtime.
- CLOS. Wenn man kein OO System haette, wuerden Lisp macros
ausreichen um das ohne Compilermodifikationen zu machen. Oder vielleicht willst Du ein Klassenloses OO? Mach selber. Ohne am compiler rumfummeln zu muessen.
Was hatten wir denn sonst noch?
Martin
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer cracauer@cons.org http://www.cons.org/cracauer/
Zu 5: Es gibt jetzt auch Java Hacker?
Gruß Andreas
-----Ursprüngliche Nachricht----- Von: lisp-hh [mailto:lisp-hh-bounces@common-lisp.net] Im Auftrag von Svante v. Erichsen Gesendet: Donnerstag, 16. Juni 2016 00:19 An: lisp-hh@common-lisp.net Betreff: Re: Compile time computing
Moin!
Find ich gut!
Ich habe gerade keine Ergänzungen, aber Fragen zu Deinen Punkten:
zu 5: welche Art von Änderungen meinst Du hier? Ich bin im Allgemeinen nicht bereit, schlechteren Code hinzunehmen, nur weil der Diff zum besseren blöd aussehen könnte.
zu 1 und 3 bräuchte ich wohl konkreten Code, um zu verstehen, was Du meinst.
Gruß
Svante
On 2016-06-15 11:40:05-0400, Martin Cracauer wrote:
Moin moin.
Ich nehme mir jetzt mal Zeit um ueber compile-time-computing zu schreiben.
Welche Ideen hatte wir noch? Irgendwas neues?
- Struct mit Feldern, operatoren +/-/etc automatisch generieren
indem
man mehrfach ueber die Felder interiert (so dass man keine Felder vergisst wenn man spaeter neue Operatoren macht)
- arithmetische Formel nach anderen Variablen aufloesen (so dass der
Programmier nicht die gleiche Formel mehrfach einhackt). Da war die Frage ob Maxima uns helfen kann?
- literals. Bei ITA haben wir zum Beispiel enormen Vorteil weil die
Sache wie "BOS" als string direkt in die binaere Repraesentation von TLAs uebersetzen koennen. Macht Code mehr leserlich. Gleiches gilt fuer literals wie Trees, die wir direkt in den Code packen koennen,
in
der bequemsten Form die wir uns vorstellen koennen.
3b) Regular Expressions sind eine gute Weise zu erklaeren warum das gut ist:
- string wird zum compilierzet umgewandelt
- syntaxcheck zur compilierzeit
- verschiedene Frontends fuer die gleiche regex matching engine, z.B. einmal als Perl-regex-string, einmal als Unix-regex string, einmal als s-expression syntax. Alles fuer den gleichen Matcher
- defmacro defun-inline. Das gibt es mehrere Spielchen:
- kann man dynamisch zum compilierzeit dann doch nicht inlininen
- wenn der Compiler kein inlining haette kann man den defun zum defmacro uebersetzen (wir hatten das bei ITA). Nichts was man machen moechte, demonstriert aber wie maechtig compile-time-computing ist
- "refectoring tools". Die Java hacker lassen groessere Aenderungen
von der IDE umschreiben. Das ist Bloedsinn weil die diffs im Versionskontrollsystem unleserlich werden.
- reflection. Wenn man reflection statt c-t-c benutzt um ueber
Felder in Strukturen zu iterieren dann werden Fehler von
compilierzeit
zur Laufzeit gepuscht. Erst wollen die Typen static typing, dann machen die Reflexion at runtime.
- CLOS. Wenn man kein OO System haette, wuerden Lisp macros
ausreichen um das ohne Compilermodifikationen zu machen. Oder vielleicht willst Du ein Klassenloses OO? Mach selber. Ohne am compiler rumfummeln zu muessen.
Was hatten wir denn sonst noch?
Martin
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer cracauer@cons.org http://www.cons.org/cracauer/
-- Svante von Erichsen
GPG fingerprint: A78A D4FB 762F A922 A495 57E8 2649 9081 6E61 20DE
-
Andreas Thiele -
Martin Cracauer -
Svante v. Erichsen