How much work would it be to integrate this in to PS? I don't have the time to make the patch myself, but I will help as much as I can in any other way.
We have a reference implementation of the parsing and generating the source maps which is written in JS: https://github.com/mozilla/source-map https://github.com/mozilla/source-map/blob/master/test/test-source-map-generator.js _Nick_ On Thu, Jul 28, 2011 at 1:19 PM, Daniel Gackle <[email protected]>wrote: > 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 <[email protected]>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 <[email protected]>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 <[email protected]>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 <[email protected]> >>>> 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 >>>> > [email protected] >>>> > >>>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel >>>> > >>>> >>>> _______________________________________________ >>>> parenscript-devel mailing list >>>> [email protected] >>>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel >>>> >>> >>> >>> _______________________________________________ >>> parenscript-devel mailing list >>> [email protected] >>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel >>> >>> >> >> _______________________________________________ >> parenscript-devel mailing list >> [email protected] >> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel >> >> > > _______________________________________________ > parenscript-devel mailing list > [email protected] > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > >
_______________________________________________ parenscript-devel mailing list [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
