parenscript-devel August 2007

parenscript-devel@common-lisp.net

8 participants
18 discussions

[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

[parenscript-devel] Package system: a modest approach.
by Vladimir Sedach 04 Aug '07

04 Aug '07

Hello everybody, If you've been following the darcs repository, you may have noticed the addition of Red Daly's package system. Upon working with it for a little while, I've concluded that I don't like it very much. I think it falls outside the scope of what ParenScript is intended to do (for instance, I don't think PS needs its own implementation of the Lisp reader...), tries to provide too much functionality, and from working with the code I find that it adds significant complexity without offering a corresponding increase in value. My proposal, which I will start implementing next week, is based on the observation that there are really only two things needed for a namespace system for Javascript that will cover almost all use cases: 1. Being able to mangle identifiers for different namespaces. This can be easily implemented by associating a prefix string to a Lisp package. 2. Being able to import/use the ParenScript constructs from a different package. This can be implemented by adding some simple lookup logic to the ParenScript script-expander. The underlying idea behind ParenScript is to integrate as closely as possible with Common Lisp, which is why I think the other possible namespace features (in-package, hierarchical imports, exports, etc.) will not be necessary, and, if they ever turn out to be, should be implemented in a different way than the current system. Having made the observation above, I also think it is wrong to extend ParenScript in any way that will prevent its integration with Common Lisp (this is why the ParenScript reader in particular, and ParenScript files in general, now seem like a bad idea to me). Besides, that functionality is better implemented on a level above ParenScript (for example, I have absolutely no interest in having a function for compiling ParenScript files to Javascript files - it can be implemented trivially with the usual ParenScript forms, but why would you want to do it in the first place if Lisp lets you store the output in the web server's memory?). Having come to these conclusions, I've decided to remove the reader and the ParenScript ASDF system from the ParenScript repository. Red, if you want to continue working on them, I really think that those parts will fit better in their own projects. I am planning to start a re-implementation of the package system and a long overdue refactoring of the compiler next week. Happy hacking, Vladimir

1 0

[parenscript-devel] Bug: return by itself doesn't work
by Daniel Gackle 03 Aug '07

03 Aug '07

I would expect this to work but it doesn't for me: (js (return)) Daniel

2 1

[parenscript-devel] August 1 ParenScript release.
by Vladimir Sedach 03 Aug '07

03 Aug '07

Hello, I've put up a new tarball of ParenScript, 20070801. It is the same as 20070720, with the exception that the tutorial (and correspondingly the manual) has a corrected package definition (the AllegroServe HTML generation facilities have been moved to their own package). For the next release, I plan to go over the example code carefully and fix any issues that come. Long-term, I want to transition the example tutorial to be based on Hunchentoot, because it is the best available Free Software Common Lisp web server right now, and probably LML2 for the server-side HTML generation facilities (because that's what I like to use). Let me know if you have any suggestions about this. Thanks, Vladimir

3 4

[parenscript-devel] Bug: &optional param
by Daniel Gackle 03 Aug '07

03 Aug '07

If I define this in PS: (defun test-opt (&optional x) (return (if x "yes" "no"))) then I get the following in the browser: testOpt(123) => "no" Daniel

2 1

[parenscript-devel] Package system integration.
by Vladimir Sedach 03 Aug '07

03 Aug '07

Hello everybody, I've pushed a patch that removes the *enable-package-system* stuff and gives what I think are reasonable defaults to packages (namely, parenscript, parenscript-javascript and parenscript-user packages don't prefix their symbols - this can be customized if you want to), and automatically treats all symbols without corresponding PS packages as though they were in parenscript-user (with a flag that can enable printed warnings for this). This gives the expected results when you don't use the package system (ie - no symbols are prefixed), just like the code before the addition of the package system. I think this is a definite improvement over having what was basically two different ways of treating symbols, and it is also nice from an ease-of-use point of view. Please let me know if you have any suggestions or about any problems that come up with the new code. Vladimir

1 0

[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] Copyright holders and years
by Luca Capello 02 Aug '07

02 Aug '07

Hello, I'm finalizing a new Debian version and I need some clarifications about the copyright holders and year. ATM, the Debian copyright file contains two copyright holders: 2005-2006 Manuel Odendahl 2005-2006 Edward Marco Baringer Questions: 1) do Manuel and Marco still retain copyright for 2007? 2) Vladimir, you should be added there starting from 2007, right? 3) am I missing someone (we're talking about copyright holders, not contributors)? Once I will have solved that, I'll release a new Debian version, based on the 7-20-07 upstream release. Thx, bye, Gismo / Luca

2 3

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

parenscript-devel August 2007