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

[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