[parenscript-devel] Bug: can't call ps-to-string directly

[Daniel Gackle]

Ah, ps::symbol-to-js was what I wanted. Thanks.

On 7/31/07, Red Daly <reddaly at gmail.com> wrote:
>
> Hi Dan,
>
> In what context are you trying to translate a symbol?  In general, you
> should now use COMPILE-SCRIPT to get Javascript output from Parenscript
> forms.  It ensures a bound compilation environment.
>
> (compile-script 'some-symbol)
>
> Sorry to break your code, but since the last release we have been making
> some changes to the Parenscript interface.  compile-script,
> compile-script-file, compile-script-system are the preferred functions for
> compilation.  More documentation is coming up.
>
> Some additional information about symbol translation:  If you want the
> camel-cased version of a Parenscript symbol you might want to call
> "ps::symbol-to-js."  However, this ignores anything about the current
> compilation environment, which may have some bearing on how a symbol is
> translated when the package system is enabled.  During compilation,
> js-translate-symbol right now provides a correct Javascript serialization of
> the symbol.
>
> On 7/31/07, Vladimir Sedach <vsedach at gmail.com> wrote:
> >
> > Fixed. *default-compilation-environment* is now initialized with a
> > basic compilation environment (via make-basic-compilation-environment)
> > when its declared.
>
>
> This might cause some unexpected behavior since it creates a lingering,
> universal compilation environment.  Package definitions will persist across
> all compilations, for example.
>
> The revised compilation interface will ensure that
> *compilation-environment* is bound to a compilation environment before
> compiling (see compilation-interface.lisp and "non-nil-comp-env").  I
> think the functions provided in compilation-interface are sufficient for all
> compilation/translation needs.  We might want to unexport some other
> functions.
>
> A compilation environment is generally supposed to be initialized before
> and die after a logical compilation process.  For example, consider an HTML
> page with a inlined script in a <script> tag, some external script in a
> <script src="...">, and script function calls embedded in onMouseClick
> attributes in the HTML page.  The compilation environment will be created.
> The compiler will then be invoked on the inline script, the script files,
> and the script embedded in HTML.  After all this, the compilation
> environment can be thrown away, along with all the Parenscript package
> definitions and other local compilation rules.
>
> This intended use requires the user to manage a compilation environment to
> some degree.  Before long we should figure out the public interface for
> dealing with a compilation environment.  I also have no problem writing up
> the documentation.  Before I do this, however, I would like to use the
> package system extensively for a real application so I can see how it is
> best used in practice.
>
> Vladimir
>
> > Dan
> > >
>
>
>
> Red
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20070801/eb446e12/attachment.html>