"Red Daly" reddaly@gmail.com writes:
Here I detail a proposed package system for Parenscript
And in my view an excellent one!
[...]
A Parenscript package (or "script package" or simply "package," as opposed to a "Lisp package") has a few main properties: a name and list of nicknames, an primary associated Lisp package, a list of exported identifiers, and a collection of macros defined in the associated Lisp package. We must also introduce and formalize a two other concepts: Parenscript identifiers (analog of Lisp symbols), and a compilation environment.
A Parenscript package is defined and exists in the context of a compilation environment. A compilation environment simply keeps track of compiler state; when any Parenscript code is compiled, a new compilation environment is created or an existing one is passed to the compiler. The environment is modified to reflect the lexical scope as forms are processed. Specifically, the compilation environment will consist of a stack of Parenscript identifiers (introduced by defun and defvar forms); a stack of macros and symbol macros; a list of defined script packages; and the current script package.
Perhaps compiler macros (or something more powerful like SBCL's deftransform) could be included?
I'd quite like the ability to delay the emission of JavaScript code, so that definitions can be emitted only when the call tree explicitly draws in a particular function or variable. I guess the information for these delayed definitions would belong in the compilation environment. (Maybe a later version ;-)
Having macros and so on fixed to particular ParenScript packages will be a big plus for sharing code. Excellent.
[...]
;; enter the user package ; changes current package in compilation environment (in-package :parenscript-user)
As Henrik said, some people might want to consider a ParenScript package to be JavaScript object. So that here one might emit
with (parenscript-user) { ... }
(Just throwing out random ideas with complicated ramifications. Personally I prefer the prefixed name approach but some JavaScript megalibraries do stash everything in one object.)
[...]
Hopefully this is an exciting prospect for the community. The package system should empower those who want to build large programs or share Parenscript extensions/libraries. It should also preserve the javascript-in-sexps Parenscript we know and love.
It sounds great!
[...]