Compile time computing

[Svante v. Erichsen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://mailman.common-lisp.net/pipermail/lisp-hh/attachments/20160616/92be36b0/attachment.sig>