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

[parenscript-devel] lisp-like lambda lists (keyword, option, and rest arguments)
by Red Daly 15 Aug '07

15 Aug '07

In my local version I have added support for very Lispy lambda lists with keyword, optional, and &rest arguments. Is this a feature we should add to the language? The Javascript convention for passing named arguments is to have an options variable that functions as a hash table for keywords. I use this convention for passing keyword arguments in Parenscript. Also, when a quoted symbol (e.g. a keyword) is found in a function call, the an options object is constructed. Here are a few examples (defun name (first last &key (prefix "Ms.") (middle "")) (return (+ prefix " " first " " middle " " last))) => function name (first last options) { options.prefix = options.prefix === undefined ? "Ms." : options.prefix; options.middle = options.middle === undefined ? " " : options.middle; return prefix + " " + first " " + middle + " " + last; } (defun vote (&optional (times 1)) ...) => function vote (times) { times = times === undefined ? 1 : times; ...} (defun append (&rest lists) ...) => function append() { lists = arguments.slice(0); ...} (name "John" "Cunningham" :prefix "Mr." :middle "Appleton") => name("John", "Cunningham", { prefix : "Mr." , middle : "Appleton" }) I like having the extra lambda list features available in my own code. Should we add this to Parenscript? -Red

3 4

[parenscript-devel] Feature proposal: (defun (setf... and defsetf
by Vladimir Sedach 02 Aug '07

02 Aug '07

Another feature I'm planning to add are setf expanders for ParenScript. This should eliminate the need for explicitly name-mangling complex accessor function names like set-this and set-that, etc., which will make ParenScript code generation much easier, but at the same time generate those name mangled functions in the generated Javascript code itself, which will aid in debugging code in Javascript tools such as Firebug.

1 1

[parenscript-devel] Bug: can't call ps-to-string directly
by Daniel Gackle 01 Aug '07

01 Aug '07

I believe this used to work: (ps-to-string 'some-symbol) Now it doesn't: No methods applicable for generic function #<STANDARD-GENERIC-FUNCTION PARENSCRIPT::COMPILE-PARENSCRIPT-FORM> with args (NIL SOME-SYMBOL) of classes (NULL SYMBOL) [Condition of type PROGRAM-ERROR] ... apparently because of the lack of an implicitly expected compilation environment. Dan

3 6

[parenscript-devel] Null macro
by Daniel Gackle 31 Jul '07

31 Jul '07

Can't find anything in Parenscript to do this... should we add it? (defpsmacro null (x) `(= ,x nil)) Daniel

3 2

[parenscript-devel] *enable-package-system* and backward compatibility in general
by Attila Lendvai 31 Jul '07

31 Jul '07

hi! i've tried to update ucw to the new parenscript repo, but it turned out to be more headache then what i want to address right now. i've seen that a new naming convention is used instead of some old api functions. is there a chance of leaving the old api and keeping it backward compatible? specifically js:js* and friends should bind *enable-package-system* to false somewhere, and things like that. globally changing *enable-package-system* before loading ucw is a really bad idea, but ucw calls parenscript even at compile time, so rebinding *enable-package-system* by ucw when serving a request is also not working. i've pushed some unimportant changes in the process, though. -- attila

2 1

[parenscript-devel] Bug: renamed symbols weren't exported
by Daniel Gackle 31 Jul '07

31 Jul '07

Attached is a small patch to correct the fact that some symbols weren't renamed in package.lisp. Dan

2 1

[parenscript-devel] I like the deprecated names better
by Daniel Gackle 30 Jul '07

30 Jul '07

I agree with renaming Parenscript's package from :js to :parenscript or :ps. Indeed, just :parenscript would be fine. A library and its package should usually have the same name. However, some of the function and macro names that Parenscript now complains are deprecated, I actually prefer to their replacements. For example, the js macro is accurately named. I prefer this: (js (setf x 1)) to this: (ps (setf x 1)) ...because "js" reminds me that I'm generating Javascript (not Parenscript). To me it's closer to the meaning. What I especially don't like, though, is this: (script (setf x 1)) ... because there are at least two other scripting languages embedded in my Lisp code, and the term "script" could apply to any of them. I need to know at all times which kind of script I'm working with. In this case it's Javascript. Similarly, I much prefer "defjsmacro" to "defscriptmacro". Much clearer and more expressive. There's sort of a philosophical point here. I don't see Parenscript as a separate language. I see it as an interface to Javascript. I don't want an extra mental layer getting in the way, and I certainly don't want to forget that I'm writing Javascript. (I love using macros to build up abstractions in Parenscript - in fact that's a big reason I use PS - but to me that's a separate issue.) Bottom line, I have a moderate preference for "js" names instead of "ps" ones and a strong objection to the generic term "script". What do others think? Daniel

3 3

[parenscript-devel] Bug in latest release: js* doesn't append semicolon or accept list anymore
by Daniel Gackle 30 Jul '07

30 Jul '07

Upgrading to the latest PS in darcs broke some of my code. Specifically, (js* '(setf x 1)) => "x = 1" ... should have a semicolon but doesn't. Also, (js* '(setf x 1) '(setf y 2)) => "y = 2" ... should be "x = 1; y = 2;". Dan p.s. I see that js* has been deprecated in favor of ps*... I'll post separately about this.

2 1

[parenscript-devel] problem with princ in html
by Peter Koeleman 30 Jul '07

30 Jul '07

Hi everybody, I've been trying to run the tutorials for parenscript and installed parenscript with sbcl and aserve on a Gentoo machine. There is a problem when trying to use parenscript. The html function/macro isn't working. Somehow the common-lisp package get's out of use and princ is undefined. The error message that I get is: * 5-aserve-worker: 07/27/07 - 10:05:01 - while processing command "GET /tutorial3.js HTTP/1.1" got error The function :PRINC is undefined. Some of the warnings I get after loading some code from the tutorial: ; in: LAMBDA NIL ; JS:JS-FILE ; ==> ; (JS:HTML ; (:PRINC ; (JS:JS ; (DEFUN JS-TUTORIAL::GREETING-CALLBACK () ; (JS-TUTORIAL::ALERT "Hello World"))))) ; ; caught STYLE-WARNING: ; undefined function: HTML ; --> JS:HTML ; ==> ; (:PRINC ; (JS:JS ; (DEFUN JS-TUTORIAL::GREETING-CALLBACK () ; (JS-TUTORIAL::ALERT "Hello World")))) ; ; caught STYLE-WARNING: ; undefined function: :PRINC ; ; caught STYLE-WARNING: ; These functions are undefined: ; HTML :PRINC Is this a known problem? It seems that it all breaks out of the box. Please let me know if there is a workaround or bugfix. Peter Koeleman

2 1

[parenscript-devel] Bug: string literals don't self-evaluate in js macros
by Daniel Gackle 30 Jul '07

30 Jul '07

A js macro that evaluates to a string literal can't be used: (defjsmacro blah () "abc") (js (blah)) => "null;" This seems wrong. For one thing, other literals work fine: (defjsmacro blah () 123) (js (blah)) => "123" For another, Lisp behaves differently: (defmacro blah () "abc") (blah) => "abc" Dan p.s. Actually, I'd rather use a symbol macro but it appears there is no define-symbol-macro in Parenscript and in this case symbol-macrolet is not convenient.

3 2

[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