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

[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