[parenscript-devel] Proposal: Package System

[John Fremlin]

"Red Daly" <reddaly at 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!

[...]