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

[parenscript-devel] Package system, new reader, compilation interface changes, and more refactoring
by Red Daly 30 Jul '07

30 Jul '07

Dear Parenscripters, I have made some significant changes to the source code. The impetus for most of my changes was the creation of a package system for Parenscript. This is a brief, rambling explanation of my changes to the code base and is by no means a full documentation of new features. The compilation interface is now contained in 'compilation-interface.lisp'. The main functions for compiling Parenscript to Javascript are COMPILE-SCRIPT, COMPILE-SCRIPT-FILE, and the macro SCRIPT. The package system is very similar to Lisp's package system because it works on the symbol level. A script package has an associated lisp package that it uses to intern all of that script package's symbols. This way, the parenscript package of any (lisp) symbol can be determined by looking at the lisp package of any lisp symbol. The Parenscript compiler mandates that every symbol have an associated script package. As a result, the compiler now assigns semantic meaning to both a symbol's name and package--before only the string name of a symbol had any bearing on the resultant code. There are a few packages that come standard issue (see builtin-packages.lisp). The macros provided by the Parenscript language are split into two package: PARENSCRIPT and JAVASCRIPT. JAVASCRIPT contains special forms that are eventually translated directly to Javascript (e.g. defvar, lambda, with). The PARENSCRIPT package is the package most users will use and contains the rest of the special forms/macros described in the documentation (e.g. macrolet, let, html). There is now a Parenscript reader thanks to the BSD-licensed Sacla project[SACLA]. Parenscript can use either the Lisp reader or the Parenscript reader to read objects from source text. Generally, Parenscript embedded in Lisp will use the Lisp reader, and Parenscript in Parenscript files (*.paren) will use the Parenscript reader. (Though perhaps in the future the Parenscript reader will be preferred.) It is possible to use the Lisp reader within the Parenscript reader with the reader macro #L(lisp-form), which may be useful for some reason. Parenscript does not currently interfere with the Lisp reader by introducing reader macros. There are only a few differences between the readers: # The Parenscript reader will not obey defined reader macros from the Lisp reader # The Parenscript reader understands Parenscript package names as package prefixes and does NOT understand Lisp package names as package prefixes. # The Lisp reader does not understand Parenscript package names but does understand Lisp package names as symbol prefixes. I broke up source-model.lisp into js-source-model.lisp and ps-source-model.lisp to correspond to the underlying Javascript and Parenscript special forms. I broke up parser.lisp into parser.lisp, js-macrology, and ps-macrology: the macrology files define macros for javascript and parenscript; parser.lisp contains the functionality for parsing S-expressions into the objects defined in the source-model files. I moved js-html and js-css to the lib/ subdirectory; eventually these should probably be members of other packages. All tests currently pass and I am adding more tests. More on the package system later, after I have made use of it myself. Happy hacking, Red Daly [SACLA] http://homepage1.nifty.com/bmonkey/lisp/sacla/index-en.html

3 3

[parenscript-devel] ASDF compatibility for Parenscript
by Red Daly 27 Jul '07

27 Jul '07

Good evening, You can now include Parenscript files in ASDF systems. Parenscript will compile a whole slough of .paren files (with due respect for dependencies) into a single output stream. This and the package system should allow people to share legitimately modularized Parenscripts. In a short while, with some semantic analysis and optimization, it will be extremely easy and efficient to share Parenscript code. See src/paren-asdf.lisp and src/compilation-interface.lisp for implementation details, and docs/internal/asdf.lisp & [1] for asdf reference. Here is some syntax: (defpackage paren-ajax-system (:use :cl :asdf)) (in-package :paren-ajax-system) (defsystem :paren-ajax :name "paren-ajax" :author "Red Daly <reddaly(a)gmail.com.>" :version "0.0.1" :license "MIT" :description "Basic Parenscript functions for AJAX." :components ((:static-file "paren-ajax.asd") (:file "package") (:parenscript-file "util" :depends-on ("package")) (:parenscript-file "core-ajax" :depends-on ("package"))) :depends-on (:parenscript)) The following will produce a string with all the Parenscript files in :paren-ajax and its dependencies compiled to javascript: (with-output-to-string (stream) (parenscript:compile-script-system :paren-ajax :output-stream stream))) => "function util_lispyMap(util_fun, util_thing) { return util_thing.map(util_fun); }; var parenAjax_hellobang = 'hi there'; " There are two ways to compile Parenscript systems via ASDF: 1. Parenscript files will be compiled when the system is compiled (via asdf:compile-op), giving warnings and errors alongside lisp warnings and errors. This will produce a bunch of .js files that ride in tandem with your .paren files 2. Use the method described above. This outputs Javascript code to a single stream. 2 works with whole ASDF systems, not individual components. I would like to get it working for individual components, however. Suggestions are welcome for how to do this. See docs/internal/asdf.lisp for the entirety of ASDF source code. This is what I used as a reference to implement the extension. Enjoy, Red [1] http://constantly.at/lisp/asdf/index.html#Top

1 0

[parenscript-devel] BUG: slot value conditional.
by Vladimir Sedach 26 Jul '07

26 Jul '07

Daniel Gackle pointed this out: (js (slot-value (if yes a b) 'prop)) => "yes ? a : b.prop;" When in fact the code should be "yes ? a.prop : b.prop;"

1 1

[parenscript-devel] Feature request: Slime navigation shortcuts
by Daniel Gackle 26 Jul '07

26 Jul '07

I'd like to be able to use M-. and M-, to navigate around Parenscript function definitions using Slime. I know this is a Slime enhancement and not a Parenscript one, but since Vladimir has already implemented a great feature of this kind (C-c j to view Parenscript-generated JS code), I figure this is the place to request another. Dan

1 0

[parenscript-devel] New ParenScript release.
by Vladimir Sedach 20 Jul '07

20 Jul '07

I've just put up the tarball of a new ParenScript release. Have fun! Vladimir

1 0

[parenscript-devel] Test period for new release.
by Vladimir Sedach 20 Jul '07

20 Jul '07

Hello everyone, I've added a description of the new ParenScript functionality to the documentation, and last Friday improved the whitespace-reducing code in the tests so that now everything that's supposed to pass passes. I think there's been enough changes now that a new release is due. I'm going to make a tarball and put it online this Friday. If there are any problems with what's in the darcs repository or you want something to go into this release, let me know. Vladimir

2 1

[parenscript-devel] Warning about usage of reserved words as variable names
by Viktor Leis 12 Jul '07

12 Jul '07

Hi, here is a piece of code that warns when a reserved keyword is used as a variable name. This is nice time saver for me, since IE refuses to run such code. Perhaps it could be included in a nicer way. Bye Viktor (defmethod initialize-instance :after ((var js-variable) &rest initargs) (declare (ignore initargs)) (when (find (slot-value var 'value) '(abstract else instanceof switch boolean enum int synchronized break export interface this byte extends long throw case native throws catch final new transient char finally float package try const for private typeof continue function protected var debugger goto public void default if return volatile delete implements short while do import static with double in super class) :test #'string-equal) (warn "~a is a reserved word and should not be used as a variable" (slot-value var 'value))))

2 1

[parenscript-devel] [PATCH] Split tests from t/test.lisp
by Luca Capello 03 Jul '07

03 Jul '07

Hello, I think that t/test.lisp is eligible for a refactoring, i.e. IMHO it's better to split out all the tests and leaving there only stuff needed to run the tests. The attached darcs patch implement this idea. Thx, bye, Gismo / Luca

2 1

[parenscript-devel] ParenScript tests.
by Vladimir Sedach 03 Jul '07

03 Jul '07

Henrik Hjelte mentioned the ParenScript tests, which is a subject I want to bring up since I currently can't run them. The tests are based on FiveAM, the Bese testing framework, however the asdf-install for it is broken right now (it depends on Arnesi, the Bese utility library, which isn't asdf-installable, and when I go pull it from the Bese darcs repository it still has mystery dependencies on other Bese code). Since I don't want to invest time and effort into making FiveAM easy to install, I think maybe we should consider switching test frameworks to something that Just Works? Does anyone have suggestions? Vladimir

4 5

[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