- parenscript-devel - mailman3.common-lisp.net

[parenscript-devel] Proposal: Package System
by Red Daly 01 Jul '07

01 Jul '07

Dear Fellow Parenscripters, Here I detail a proposed package system for Parenscript to ease modular development. This is a feature intended to make up for the many hacks Javascript programmers use to write libraries. The proposed system takes after and integrates with the Lisp package system. Its implementation will constitute a hearty advancement of the current Parenscript compiler. The proposed system should introduce new concepts and should be robust enough to lay the foundation for a lot of future work in a coherent way. Different packages can introduce new special forms--that is, modify the language at the lowest level. With this, a "javascript2" package can introduce Parenscript forms that compile to the latest version of ECMAScript without implicating the rest of the project. The additional semantic analysis of Parenscript programs will pave the way for cropped, minified, or obfuscated scripts. In addition, a formal package specification will lead to asdf-installable script libraries with better deployment characteristics than current package systems for web development in other languages. A Parenscript package (or "script package" or simply "package," as opposed to a "Lisp package") has a few main properties: a name and list of nicknames, an primary associated Lisp package, a list of exported identifiers, and a collection of macros defined in the associated Lisp package. We must also introduce and formalize a two other concepts: Parenscript identifiers (analog of Lisp symbols), and a compilation environment. A Parenscript package is defined and exists in the context of a compilation environment. A compilation environment simply keeps track of compiler state; when any Parenscript code is compiled, a new compilation environment is created or an existing one is passed to the compiler. The environment is modified to reflect the lexical scope as forms are processed. Specifically, the compilation environment will consist of a stack of Parenscript identifiers (introduced by defun and defvar forms); a stack of macros and symbol macros; a list of defined script packages; and the current script package. An identifier in Parenscript is analogous to a Lisp symbol, but it only exists during compile time. An identifier has a string value and associated Parenscript package. Now I will run through a simple example to demonstrate these new developments: Script packages are primarily defined using a Parenscript form analogous to the Lisp defpackage: (defpackage friendly-script (:use parenscript psos) (:export hello-world) (:lisp-package friendly) (:documentation "Scripts for issuing greetings.")) This introduces a new package into the compilation environment. We enter the package system after it is defined as in Lisp: ;; enter the friendly-script package ; changes the current package in the compilation environment to :friendly-script (in-package :friendly-script) ;; define the hello-world function, which we export ; adds friendly-script::hello-world to the identifier stack in the compilation env. (defun hello-world () (alert "hello world.")) ;; enter the user package ; changes current package in compilation environment (in-package :parenscript-user) ;; call the friendly-script's hello-world function ; the compiler recognizes that friendly-script::hello-world is an e (friendly-script:hello-world) To give you an idea, this will all compile to something like the following Javascript: function friendlyScript_helloWorld() { alert("hello world."); } friendlyScript_helloWorld(); In terms of implementation, the package system will introduce a few new classes (script-package, identifier, and compilation-environment); uproot existing parsing procedures and replant them around the package system; and add a semantic analysis phase into the compilation pipeline. I will fill in details and announce problems with the implementation as it moves forward. Hopefully this is an exciting prospect for the community. The package system should empower those who want to build large programs or share Parenscript extensions/libraries. It should also preserve the javascript-in-sexps Parenscript we know and love. Anyhow, I look forward to comments on this proposal. Happy hacking! Red

5 5

[parenscript-devel] Breaking up js.lisp
by Red Daly 26 Jun '07

26 Jun '07

Parenscript is long overdue for a simple code reorganization. js.lisp is a monolithic file with nearly all the interesting components of the compiler. I propose splitting it up into three different files: source-model.lisp, js-translation.lisp, and parser.lisp: source-model.lisp: class definitions that correspond to the Javascript AST. (defjsclass forms for the most part) js-translation.lisp: functions for converting AST objects to Javascript source code parser.lisp: macro definitions and the mechanisms for processing Parenscript forms into AST objects. Let me know if there are any objections. Otherwise I will go ahead and submit a patch. Red

2 3

[parenscript-devel] Refactoring ParenScript macros.
by Vladimir Sedach 26 Jun '07

26 Jun '07

Hello, I've just submitted a patch with some refactoring done to the ParenScript macro code that has one large user-visible effect: ParenScript "compiler macros" are now called "special forms" (so the corresponding macros like define-js-compiler-macro are now called define-js-special-form). There are two reasons for this: first, those things really are special forms, and second of all compiler macros are an unrelated concept in Common Lisp that may someday be implemented in ParenScript. Please let me know if you have any objections to this or whether the patch breaks something. Also, I haven't updated the documentation yet - if anyone wants to do so, you are more than welcome (otherwise I'll delay doing it until it's time for the next tarball release). Vladimir

1 0

[parenscript-devel] Js macro names can't be used as variable names
by Daniel Gackle 26 Jun '07

26 Jun '07

Hey, Are we on? Parenscript is great and I'm hoping this list means we'll see some active development on it. Here's an issue to kick things off. Once you define a js macro in parenscript, you can't use that symbol for anything else. For example, (js (defvar blah 123)) => "var blah = 123;" ... which is good, but if you do this: (defjsmacro blah () `(some-fn)) then the first expression no longer works. That's what I would expect if blah were a symbol macro, but not a regular macro. Anyone want to take a crack at this? Dan

2 1

[parenscript-devel] BUG: &body in ParenScript macrolet doesn't work.
by Vladimir Sedach 26 Jun '07

26 Jun '07

This works: (js (macrolet ((foo (bar &rest body) `(+ ,@body))) (foo 1 2 3 4))) This doesn't: (js (macrolet ((foo (bar &body body) `(+ ,@body))) (foo 1 2 3 4))) Related to this, make ParenScript macrolet support all lambda list keywords that Lisp macrolet supports.

1 1

[parenscript-devel] Parlez-vous ActionScript?
by John Pallister 26 Jun '07

26 Jun '07

Hello list, While people are discussing future directions for ParenScript, I thought I'd add my two cents. I am developing systems based around XHTML, X3D and Adobe Flex; in all three cases we have an XML-syntax language with an embedded JavaScript language. Except that X3D uses ECMAScript 2 (which AFAIK is "standard" XHTML JavaScript 1.x) while Flex (i.e. Flash 9) uses ActionScript 3.0, which is an implementation of ECMAScript 262 Revision 4 [1], a.k.a. JavaScript 2.0 [2]. The point is, ECMAScript 4 has a variety of new features (optional static typing, classes, interfaces, packages, generators, list comprehensions etc. - there's a nice overview at [3]) which aren't currently supported by ParenScript. Given that the adoption of ECMAScript 4/JavaScript 2 is a case of when rather than if [4], it would be great if any overhaul of ParenScript could be done with an eye to incorporating some or all of these features in the near future (hopefully by other interested parties such as myself). The "add a compiler" POV vs. the "keep it simple" perspective echoes the two sides of the JavaScript 2 debate. Since these new language features will be added (and I'm already using them in ActionScript 3), it would be great if they could be added to ParenScript without causing too much inconvenience to those who like it the way it is now. I would like to help out with this task; I might have some time to spend on it later in the year. Cheers, John :^P [1] http://www.ecmascript-lang.org/ - includes reference impl. in Standard ML [2] "ActionScript 3: The Language of Flex. A Conversation with James Ward, Part I", http://www.artima.com/lejava/articles/actionscript.html [3] http://developer.mozilla.org/presentations/xtech2006/javascript/ [4] http://www.mozilla.org/projects/tamarin/ -- John Pallister john(a)synchromesh.com Wellington, New Zealand

4 3

[parenscript-devel] Feature request: prefixed names
by John Fremlin 25 Jun '07

25 Jun '07

Nowadays many things seem to want to include their JavaScript in your webpages. Aside from the fact that this is annoying, dangerous and wrong, we have to accept that it is quite prevalent: from Google AdWords to ReCaptcha. If I might add a feature request, it would be to be able to make sure that the identifiers generated by parenscript don't clash with anything else.

6 12

[parenscript-devel] Miscellaneous utils I use
by John Fremlin 21 Jun '07

21 Jun '07

(defjsmacro max (a b) `(*Math.max ,a ,b)) ; might be nice to be able to have more than two arguments (defjsmacro ceil (expr) `(*Math.ceil ,expr)) (define-js-compiler-macro timeout (form timeout) (js-compile `(set-timeout (lambda() ,form) ,timeout))) (defjsmacro make-xml-http-request () `(if (slot-value window '*X-M-L-Http-Request ) (new *X-M-L-Http-Request) (new (*Active-X-Object "Microsoft.XMLHTTP"))))

2 5

[parenscript-devel] Feature request: speed (generating function)
by John Fremlin 19 Jun '07

19 Jun '07

In my dynamically generated webpages I regularly compile lots of very simple parenscript like `(append-markup ,element-id ,markup) where element-id and markup are Lisp strings. Parenscript takes a lot of time to do this in comparison to everything else. Ideally, I guess would be something that would generate a function like (defun js-append-markup (element-id markup) (output "appendMarkup(\"") (output (escape element-id)) (output "\",\"") (output (escape markup)) (output "\");"))

1 0

[parenscript-devel] Re:Js macro names can't be used as variable names
by Red Daly 17 Jun '07

17 Jun '07

I am away from a lispy computer, but here are the problem areas in js.lisp: (defun js-expand-form (expr) "Expand a javascript form." (cond ((atom expr) (multiple-value-bind (js-macro macro-env) (lookup-macro expr) (if js-macro (js-expand-form (let ((*js-macro-env* macro-env)) (funcall js-macro))) expr))) ;;; macros (define-js-compiler-macro macrolet (macros &rest body) (let* ((macro-env (make-hash-table :test 'equal)) (*js-macro-env* (cons macro-env *js-macro-env*))) (dolist (macro macros) (destructuring-bind (name arglist &rest body) macro (setf (gethash (symbol-name name) macro-env) (compile nil `(lambda ,arglist ,@body))))) (js-compile `(progn ,@body)))) (defjsmacro symbol-macrolet (macros &rest body) `(macrolet ,(mapcar #'(lambda (macro) `(,(first macro) () ,@(rest macro))) macros) ,@body)) The problem is that symbol-macrolets use the same machinery as regular macrolets. A solution is to maintain parallel symbol and regular macro environments... ;; new variables (eval-when (:compile-toplevel :load-toplevel :execute) (defvar *js-symbol-macro-toplevel* (make-hash-table :test 'equal) "Toplevel of symbol macro expansion, holds all the toplevel javascript macros.") (defvar *js-symbol-macro-env* (list js-symbol-macro-toplevel*) "Current symbol macro environment.")) ;; amend (lookup-macro ..) to take a :type argument. (defun lookup-macro (name &keyword (type :lambda)) "Lookup the macro NAME in the current macro expansion environment. Returns the macro and the parent macro environment of this macro." (unless (symbolp name) (return-from lookup-macro nil)) (do ((env (case type (:lambda *js-macro-env*) (:symbol *js-symbol-macro-env*) (t (error "Invalid macro type ~A" type))) (cdr env))) ((null env) nil) (let ((val (gethash (symbol-name name) (car env)))) (when val (return-from lookup-macro (values val (or (cdr env) (list (case type (:lambda *js-macro-toplevel*) (:symbol *js-symbol-macro-toplevel*) (t (error "Invalid macro type ~A" type)))))))))) ;; get rid of (defjsmacro symbol-macrolet ...) and replace it with ;; a compiler macro: (define-js-compiler-macro symbol-macrolet (macros &rest body) (let* ((macro-env (make-hash-table :test 'equal)) (*js-symbol-macro-env* (cons macro-env *js-symbol-macro-env*))) (dolist (macro macros) (setf (gethash (symbol-name (first macro)) macro-env) (compile nil `(lambda () ,@(rest macro))))) (js-compile `(progn ,@body)))) ;; change expand-form (defun js-expand-form (expr) "Expand a javascript form." (cond ((atom expr) (multiple-value-bind (js-macro macro-env) (lookup-macro expr :type :symbol) (if js-macro (js-expand-form (let ((*js-symbol-macro-env* macro-env)) (funcall js-macro))) expr))) ((js-compiler-macro-form-p expr) expr) ((equal (first expr) 'quote) expr) (t (let ((js-macro (lookup-macro (car expr)))) (if js-macro (js-expand-form (apply js-macro (cdr expr))) expr))))) This should at least give an idea of the relevant areas of code. -Red

1 0