{"id":89,"date":"2005-02-25T12:15:17","date_gmt":"2005-02-25T10:15:17","guid":{"rendered":"http:\/\/blogs.bl0rg.net\/netzstaub\/?p=89"},"modified":"2005-02-25T12:15:17","modified_gmt":"2005-02-25T10:15:17","slug":"javascriptcompiler-expressions","status":"publish","type":"post","link":"https:\/\/blogs.bl0rg.net\/netzstaub\/2005\/02\/25\/javascriptcompiler-expressions\/","title":{"rendered":"Javascriptcompiler: Expressions"},"content":{"rendered":"

\nEine Funktionalität des Javascript Compilers (über den ich hier<\/a> und hier<\/a> schon gebloggt habe) war recht interessant. Und zwar geht es darum, die vollgeklammerten und in Prefix-Syntax geschriebenen arithmetischen Ausdrücke aus dem Lisp-Javascript-Dialekt zu lesbaren Javascript-Ausdrücken umzuformen. Also z.B.\n<\/p>\n

\n(+ (* 3 4) 9 (- 10 5)) => (3 * 4) + 9 + (10 – 5) bzw. 3 * 4 + 9 + 10 – 5\n<\/p>\n

\nMit einem Trivialansatz, bei dem alles geklammert wird, um die korrekte Auswertung zu gewährleisten, sieht das Ergebnis richtig unlesbar aus:\n<\/p>\n

\n((3) * (4)) + (9) + ((10) – (5))\n<\/p>\n

\nDer bessere Ansatz ist eher, so wenig Klammern wie möglich einzusetzen, und dazu müssen wir die Operatorpräzedenzen berücksichtigen. Im Javascriptstandard steht jetzt keine klare Tabelle mit der Reihenfolge der Operatoren drin, sondern nur eine BNF-Syntax, aus der man sich das Ganze extrahieren muss. Zum Glück gibt es im Netz eine Tabelle<\/a> die man verwenden kann. Anstatt die jetzt doof abzutippen werden wir uns dort nur die Reihenfolge der Operatoren abgucken, und diese in Lisp giessen:\n<\/p>\n

(defparameter *op-precedences*\n  '((aref)\n    (* \/ %)\n    (+ -)\n    (<< >>)\n    (>>>)\n    (< > <= >=)\n    (in)\n    (eql == !=)\n    (=== !==)\n    (&)\n    (^)\n    (\\|)\n    (\\&\\& and)\n    (\\|\\| or)\n    (setf)))\n<\/pre>\n
\nDiese Liste hat die Operatoren in Reihenfolge abnehmender Präzedenz. Wie bei den Specialforms werden wir diese Liste verarbeiten und die einzelnen Operatoren in eine Hashtabelle speichern. Das wollen wir natürlich zur Ladezeit machen, also verwenden wir eine EVAL-WHEN Form:\n<\/p>\n
(defvar *op-precedence-hash* (make-hash-table))\n(eval-when (:compile-toplevel :load-toplevel :execute)\n  (let ((precedence 1))\n    (dolist (ops *op-precedences*)\n      (dolist (op ops)\n        (setf (gethash op *op-precedence-hash*) precedence))\n      (incf precedence))))\n<\/pre>\n
\nJetzt sind in der Hashtabelle *OP-PRECEDENCE-HASH* die Präzedenzen der Operatoren gespeichert. Z.B.:\n<\/p>\n
CL-USER> (gethash '< *op-precedence-hash*)\n6\n<\/pre>\n
\n< hat also die Präzedenz 6. Anhand der Tabelle können wir auch bestimmen ob ein Ausdruck eine Expression ist (die Funktion OP-FORM-P ist uns gestern schon begegnet):\n<\/p>\n
(defun op-form-p (form)\n  (and (listp form)\n       (not (null (gethash (first form) *op-precedence-hash*)))))\n<\/pre>\n
\nLetztendlich wollen wir die Präzedenz von einer Expression bestimmen. Da müssen wir die Spezialfälle von Funktionsaufrufen und atomaren Expressions (Strings, Variablen oder Nummern) berücksichtigen). Das macht die Funktion OP-FORM-PRECEDENCE, die im bekannten Stil wieder ein grosses COND einsetzt:\n<\/p>\n
(defun op-form-precedence (form)\n  (cond ((op-form-p form)\n         (gethash (first form) *op-precedence-hash*))\n        ((or (atom form)\n             (js-funcall-p form))\n         0)\n        (t (error \"~A is not an expression\" form))))\n<\/pre>\n
\nAtomare Expressions (Funktionsaufrufe, Strings, Variablen oder Nummern) haben die niedrigste Präzendenz, und binden so am “Stärksten”, d.h. man braucht da nie Klammern herum zu packen. Anhand dieser Werkzeugsfunktionen können wir jetzt den Expression-Compiler angehen, der in Form einer Funktion namens JS-EXPRESSION implementiert ist:\n<\/p>\n
(defun js-expression (form)\n  (if (or (atom form)\n          (js-funcall-p form))\n      (js-compile-single form)\n      (let ((args (cdr form))\n            (name (js-op-name (car form)))\n            (precedence (op-form-precedence form)))\n        (string-join (mapcar #'(lambda (x) (let ((prec (op-form-precedence x)))\n                                             (if (> prec precedence)\n                                                 (klammer (js-expression x))\n                                                 (js-expression x))))\n                             args)\n                     (format nil \" ~A \"  name)))))\n<\/pre>\n
\nWenn die Expression “atomar” ist, brauchen wir nicht zu klammern, und rufen den “normalen” Compiler auf. Wenn aber FORM eine komplexere Expression ist, also eine Expression wo Operatoren zum Einsatz kommen, müssen wir die Präzedenz des Ausdrucks ermitteln. Das Ergebnis von (OP-FORM-PRECEDENCE FORM) wird an PRECEDENCE gebunden. Wenn jetzt ein Argument der Expression von höherer Präzedenz ist (also loser bindet), müssen Klammern eingesetzt werden. Sonst kann der Ausdruck so eingesetzt werden. Für die Argument einer Expression, die selber wieder Expressions sein müssen, wird JS-EXPRESSION rekursiv aufgerufen. Einen kleinen Trick gibt es hier noch, und zwar wird die Funktion JS-OP-NAME eingesetzt um “Lisp-typische”-Namen zu übersetzen, also z.B. EQL nach ==. Zum Schluss noch ein kleines Beispiel:\n<\/p>\n
CL-USER> (js-expression '(+ (* 3 4) 9 (- 10 5)))\n\"3 * 4 + 9 + 10 - 5\"\nCL-USER> (js-expression '(+ (setf a (blorg 2)) (* 4 5 2)))\n\"(a = blorg(2)) + 4 * 5 * 2\"\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
Eine Funktionalität des Javascript Compilers (über den ich hier und hier schon gebloggt habe) war recht interessant. Und zwar geht es darum, die vollgeklammerten und in Prefix-Syntax geschriebenen arithmetischen Ausdrücke aus dem Lisp-Javascript-Dialekt zu lesbaren Javascript-Ausdrücken umzuformen. Also z.B. (+ … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-89","post","type-post","status-publish","format-standard","hentry","category-lispstaub"],"_links":{"self":[{"href":"https:\/\/blogs.bl0rg.net\/netzstaub\/wp-json\/wp\/v2\/posts\/89","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.bl0rg.net\/netzstaub\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.bl0rg.net\/netzstaub\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.bl0rg.net\/netzstaub\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.bl0rg.net\/netzstaub\/wp-json\/wp\/v2\/comments?post=89"}],"version-history":[{"count":0,"href":"https:\/\/blogs.bl0rg.net\/netzstaub\/wp-json\/wp\/v2\/posts\/89\/revisions"}],"wp:attachment":[{"href":"https:\/\/blogs.bl0rg.net\/netzstaub\/wp-json\/wp\/v2\/media?parent=89"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.bl0rg.net\/netzstaub\/wp-json\/wp\/v2\/categories?post=89"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.bl0rg.net\/netzstaub\/wp-json\/wp\/v2\/tags?post=89"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}