[Bese-devel] Advancing Parenscript - current and future improvements

[Red Daly]

I am not an Uncommon Web user, but I have been using Parenscript heavily 
for a few months.  Hopefully this list will be interested in the 
improvements to Parenscript I have made and has suggestions to 
outstanding issues in Parenscript development.

I have a pretty stable implementation of a CLOS-like metaobject system 
in Parenscript called the Parenscript Object System.  There is currently 
support for generic functions and class inheritance.  It also has some 
cool (beta) features, like importing a CLOS class and sending instances 
of that class across the net as a JSON object.  There are also things 
that I haven't figured out how to do best, like slot definitions.  See 
http://scratchpad.wikia.com/wiki/Parenscript_Object_System for more details.

The standard Javascript function definition is fairly bland, so I also 
implemented lisp's function declaration syntax.  Keyword arguments, 
defaulting parameters, and &rest arguments all expand to proper 
Javascript function definitions.  Parenscript function definitions are 
indistinguishable from their Lisp counterparts, since the code to parse 
the paren-lambda lists is ripped from SBCL.

Now, there are a few problems that I would like to solve with the 
assistance of interested parties :).

There is still no clear solution for packaging code into modules in 
Javascript. This roughtly breaks down into two classes of problems: 
namespace problems and packaging problems.

Namespace issues
Namespace problems are those related to name conflicts in the Javascript 
environment. Currently developers work around this by introducing simple 
objects that serve as Java-esque prefixes: dojo.widgets.bloated, 
Ajax.Request, etc. Using prefixes is a good idea, but importing a 
package's "symbols" is sort of awkward. For example, a way to import 
everying from the dojo package is this:

for (var dojoSym in dojo)
   window[dojoSym] = dojo[dojoSym];

However, once those symbols are imported, they are imported into the 
global scope where they may conflict.

Does with(dojo) solve this problem at all?  I remember reading that 
with() is evil for performance and other reasons--it doesn't do what you 
think.

I would like to come up with a more elegant solution for namespacing 
Parenscript code.  Ideally there could be (defpackage) and (in-package) 
forms hide the dirty object declarations and such from a Parenscript 
user.  Ideas??

Packaging issues

Right now there is no consistent packaging strategy for Javascript code. 
In most cases, developers wishing to use the latest and greatest will 
download a project, add it to their own source tree, and then follow 
special instructions about how to actually include the scripts in their 
web sites. This works O.K. most of the time, but it is indeed not the 
smartest system.

Parenscript should probably take advantage of Lisp's Another System 
Definition Facility (ASDF) to define packages. I have not worked out the 
details of how to define Parenscript systems yet. It should be easy to 
(1) install somebody else's parenscript package (via an asdf:load-op) 
and (2) include individual Parenscript components in web pages.

Packaging issues are not as important as namespace issues to me, since a 
large packaging system doesn't matter if there are name conflicts 
everywhere.

Thanks for listening.  I hope this message reaches the right people!

Sincerely,
Red Daly