AW: Compile time computing
Andreas Thiele
andreas at atp-media.de
Wed Jun 15 22:41:04 UTC 2016
Zu 5: Es gibt jetzt auch Java Hacker?
Gruß Andreas
> -----Ursprüngliche Nachricht-----
> Von: lisp-hh [mailto:lisp-hh-bounces at common-lisp.net] Im Auftrag von
> Svante v. Erichsen
> Gesendet: Donnerstag, 16. Juni 2016 00:19
> An: lisp-hh at 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?
> >
> > 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
> > --
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > Martin Cracauer <cracauer at cons.org> http://www.cons.org/cracauer/
> >
>
> --
> Svante von Erichsen
>
> GPG fingerprint: A78A D4FB 762F A922 A495 57E8 2649 9081 6E61 20DE
More information about the lisp-hh
mailing list