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