[parenscript-devel] parenscript on parenscript?

[Daniel Gackle]

This is great to hear! It's a feature I have wanted for a long time.

On Thu, Jul 28, 2011 at 12:50 PM, Nick Fitzgerald <fitzgen at gmail.com> wrote:

> I've been meaning to drop a line here for a while, but this seems as
> opportune as any other time. I'm currently interning at Mozilla and my
> project should make targeting JS easier whether from PS or eventually from
> CL. It requires some buy-in on the side of the compiler, but I think it is
> worth it.
>
> https://wiki.mozilla.org/DevTools/Features/SourceMap
>
> _Nick_
>
>
>
>
> On Wed, Jul 27, 2011 at 1:47 PM, Daniel Gackle <danielgackle at gmail.com>wrote:
>
>> < It would also be nice to have the full-featured JS environments (V8,
>> Rhino, SpiderMonkey) as another target for CL deployment. >
>>
>> I think this is going to become increasingly important as the JS
>> implementations improve. The recent release of Clojurescript is an
>> indicator.
>>
>> We've actually switched Skysheet to using PS server-side as well as
>> client-side so we can deploy to V8 on the server. There are three
>> reasons for this:
>>
>> 1) it eliminates the impedance mismatch between our CL code and our PS
>> code, which was a drag on development (example: JS's hash objects
>> don't have a very good counterpart in CL; neither CL hashtables nor
>> plists/alists are a great substitute);
>>
>> 2) we get better performance from V8 than we do from SBCL. (That's for
>> unoptimized CL. Optimized CL would do much better of course, but that
>> would worsen the impedance mismatch described above;
>>
>> 3) interoperability with JS gives some desired conveniences, like V8's
>> fast JSON support and Node.js for non-blocking i/o.
>>
>> A full CL-in-JS would open the door to an all-CL system rather than an
>> all-JS one. Either would be better than straddling the two. Would we
>> switch? Hard to say.
>>
>>
>> On Wed, Jul 27, 2011 at 1:56 PM, Vladimir Sedach <vsedach at gmail.com>wrote:
>>
>>> Currently Parenscript uses some things from Common Lisp that aren't in
>>> Parenscript. The three approaches to make PS self-hosting are:
>>>
>>> 1. Rewrite PS code in a DSL that can be compiled with Parenscript. For
>>> example, replace car/cdr/etc. with destructuring and templating macros
>>> that translate to car/cdr for CL and array access in JS. Then on the
>>> JS side you'd construct your code from arrays instead of conses. The
>>> only problematic thing is symbol representation.
>>>
>>> 2. Implement the missing CL features as a run-time library (add a cons
>>> prototype with car/cdr methods).
>>>
>>> 3. Make a Common Lisp implementation that runs in JavaScript.
>>>
>>> I think the last option is the most overall useful, and the most fun
>>> to do. Parenscript then would (along with an existing CL
>>> implementation) act as a "syslisp"/bootstrapping dialect and
>>> cross-compiler. Red Daly already has large parts of the needed CL
>>> runtime implemented in his PSOS project
>>> (https://github.com/gonzojive/paren-psos).
>>>
>>> How useful would Parenscript be in the browser? My guess is not very.
>>> After all, it will just be a macro pre-processor over JavaScript's
>>> eval, and anything you can do with that you're better off doing with
>>> closures.
>>>
>>> OTOH having a full Common Lisp on the browser (*with* a working ASDF)
>>> would be pretty sweet. It would also be nice to have the full-featured
>>> JS environments (V8, Rhino, SpiderMonkey) as another target for CL
>>> deployment.
>>>
>>> Vladimir
>>>
>>> On Wed, Jul 27, 2011 at 7:24 AM, Anton Vodonosov <avodonosov at yandex.ru>
>>> wrote:
>>> > Hello.
>>> >
>>> > I am new in parenscript and only glanced through the documentation on
>>> the project page.
>>> >
>>> > As I understand parenscript source is compiled to javascript using a CL
>>> implemented compiler.
>>> >
>>> > It's interesting, how difficult it is to have the same compiler
>>> implemented on javascript (i.e. on parenscript itself).
>>> >
>>> > As parenscript is a subset of CL, in theory it mitght be not difficult.
>>> >
>>> > The goal - is to have a browser only Lisp implementation, that can work
>>> without hunchentoot. To include parenscript
>>> > scripts onto browser directly, redefine functions interactively and so
>>> on.
>>> >
>>> > What do you think?
>>> >
>>> > Best regards,
>>> > - Anton
>>> >
>>> > _______________________________________________
>>> > parenscript-devel mailing list
>>> > parenscript-devel at common-lisp.net
>>> >
>>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>>> >
>>>
>>> _______________________________________________
>>> parenscript-devel mailing list
>>> parenscript-devel at common-lisp.net
>>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>>>
>>
>>
>> _______________________________________________
>> parenscript-devel mailing list
>> parenscript-devel at common-lisp.net
>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>>
>>
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://lists.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/20110728/ab524dde/attachment.html>