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

[parenscript-devel] New ParenScript release.
by Vladimir Sedach 29 Aug '07

29 Aug '07

Hello everyone, I've just put up the tarball and documentation for the new ParenScript release. It features a rewrite of the compiler and JavaScript printer, along with many user-visible changes, the most notable being the addition of setf places (defsetf and defun setf), and Red Daly's excellent contribution of Common Lisp-like lambda lists for ParenScript functions (we now have &optional, &rest and &key). Due to the rewrite of the printer, JavaScript generation has gotten a major speed boost. As well, I've updated the tutorial and ensured it worked correctly with the latest AllegroServe (the tutorial PDF will be going away in the next release - I plan to put it up on Cliki where it can be updated in a more timely manner). Happy hacking, Vladimir

1 0

[parenscript-devel] Trial period for new ParenScript release.
by Vladimir Sedach 24 Aug '07

24 Aug '07

Hello everybody, I've just finished committing the last of my planned changes to the ParenScript documentation to reflect the new updates that have been done since the last release. I plan to make the next release available on Tuesday, August 28th. Until then, I invite everybody to go over the darcs repository version of ParenScript and report any problems that you may find. Thank you, Vladimir Sedach

1 0

[parenscript-devel] BUG: cond doesn't generate expressions.
by Vladimir Sedach 23 Aug '07

23 Aug '07

This bug comes up if you try to do something like (return (cond... A quick workaround to this problem if you're using SBCL or Allegro is to (import-macros-from-lisp 'cond), since their cond works by expanding into nested if forms (this is what we use in our ParenScript application, which is why this bug slipped through the cracks for so long). The nested-if approach is also how I'm going to fix this problem and generate cond-expressions (yeah, this is another one of those bug reports that I use as a to-do). Happy hacking, Vladimir

1 1

[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] Indentation now fixed in the printer.
by Vladimir Sedach 15 Aug '07

15 Aug '07

Hello, I've just pushed a fix that adds back correct indentation to the printer. It also has the pleasant side-effect of making the code a little simpler and a little shorter. Please feel free to pull the changes and review them. Vladimir

1 0

[parenscript-devel] Printer changes now in the darcs repository - looks like initial performance gain.
by Vladimir Sedach 15 Aug '07

15 Aug '07

Hello everybody, The changes to the printer I've promised are now in the repository. dwim-join is no more. The indentation is still wonky as I haven't gotten around to it, however now everything gets output right to a stream. Besides making the code a lot more straightforward and somewhat smaller, this also appears to have a nice performance benefit. I haven't done any profiling, but according to Firebug it now takes about 1/5 the time to fetch a generated 77KB JSON object than it used to, and that's when printing gets wrapped in a with-output-to-string first. There is now the possibility of writing Javascript directly over the socket, which should be even faster. Let me know if there are any bugs or issues with the new printer. Vladimir

1 0

[parenscript-devel] Big compiler refactoring done.
by Vladimir Sedach 14 Aug '07

14 Aug '07

Hello everybody, I just finished pushing the compiler refactoring patch that I mentioned earlier. The big change is that now the intermediate ParenScript representation is just s-expressions instead of CLOS objects, which provides several benefits: the intermediate code is now much easier to manipulate and to write code walkers for, which should make things like optimization passes easier to write, it is easily inspectable and serializable, which enables easier debugging and unit testing (I plan to add unit tests for the compiler and the printer now that they have been decoupled). The other big change that accompanies this is that the decision whether to produce expression or statement code has been pushed from the printing code to the actual compiling code, which makes the aforementioned code walkers even more practical. This has also had the effect of simplifying the printing interface considerably (from three functions down to one). The other changes I made are removing the last of the namespace functions, and the compilation environments. In the place of the namespace code is a mechanism that associates Lisp packages with a string prefix: any symbol in that package is printed with that prefix. I think that unless there are requests for further namespace functionality, that's really all that is necessary for most use cases (avoiding name clashes). The compilation environment and toplevel code I have removed because I feel that the eval-when functionality can be provided in a better way by just using Lisp code, and also to simplify the compiler interface (it's now down to one function from three) and implementation (which, although much simpler now, I think still has some room for improvement). On a more (or less?) controversial note, I have renamed all the foo-script-blah functions to be foopsblah (except for compile-script-form, which is now compile-parenscript-form). I've come to a pretty definite conclusion that it's not only clearer but also saves considerable typing. The next course of action I'm planning is to rewrite the way printing is done to simplify things, and correct the currently wonky indentation (a part of the decision for how to indent blocks was done by the compiler code previously, and of course this is currently gone). Once the rewrite is done, I'm planning to update the documentation, fix the deprecated interface, and then make a release. Happy hacking, Vladimir

3 3

[parenscript-devel] The implementation of keyword parameters
by Daniel Gackle 09 Aug '07

09 Aug '07

I like the addition of keyword params but using a json object to store the key params at runtime adds some overhead that I'm wondering if we could avoid. Could we make the compiler generate regular JS functions with ordered signatures? For example: (ps (defun f(&key a b))) would turn into: function f(a b) { } and the compiler would take care of detecting function calls and generating params in the right order. So: (ps (f :a 1 :b 2)) => f(1,2) while (ps (f :b 1 :a 2)) => f(2, 1) What do you guys think? Daniel p.s. This may sound like excessive optimization, but on our project efficiency is critical and we do a ton of profiling. We have some functions that are good candidates for &key signatures, but not if they get slower.

2 1

[parenscript-devel] Implicit RETURN for function bodies
by Red Daly 09 Aug '07

09 Aug '07

Coming from Lisp, it is tiresome inserting return statements at the end of each function. Should we change the behavior of Parenscript so that the last item in a function body is expected to be an expression and is returned? I am in favor of the change, though it may introduce incompatibility with existing code. An implementation: (defscriptmacro fn (lambda-list &body body) `(lambda ,lambda-list ,@(butlast body) (return ,(first (last body))))) Red

3 2

[parenscript-devel] compile-script toplevel compilation broken when loading compiled lisp files.
by Vladimir Sedach 07 Aug '07

07 Aug '07

Hello Red, There is a weird bug with the compiler changes you made where compiling a loading a file containing a call to compile-script works fine, but loading a fasl of that file fails (in particular, when loading the fasl things like (return something) are called by compile-to-expression, when they obviously compile to js-return, etc.). I don't understand what's broken or why, and in particular why the top-level stuff is involved in compile-script (as opposed to compile-script file). I am also really starting to hate the OO brain-damage that is the ParenScript intermediate representation. After this bug gets fixed (it is a complete PITA), I am going to start ripping that stuff out. Please see what you can do about fixing this issue. I'll be gone over the weekend, and since this is seriously starting to affect the project for which I'm using parenscript for, I'm going to start ripping out the compilation environment stuff as well if it's not fixed soon. Thanks, Vladimir

2 4