How much work would it be to integrate this in to PS? I don&#39;t have the time to make the patch myself, but I will help as much as I can in any other way.<br><br>We have a reference implementation of the parsing and generating the source maps which is written in JS:<br>
<br><a href="https://github.com/mozilla/source-map">https://github.com/mozilla/source-map</a><br clear="all"><a href="https://github.com/mozilla/source-map/blob/master/test/test-source-map-generator.js">https://github.com/mozilla/source-map/blob/master/test/test-source-map-generator.js</a><br>
<br>_Nick_<br><br>
<br><br><div class="gmail_quote">On Thu, Jul 28, 2011 at 1:19 PM, Daniel Gackle <span dir="ltr">&lt;<a href="mailto:danielgackle@gmail.com">danielgackle@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This is great to hear! It&#39;s a feature I have wanted for a long time.<div><div></div><div class="h5"><div><br><div class="gmail_quote">On Thu, Jul 28, 2011 at 12:50 PM, Nick Fitzgerald <span dir="ltr">&lt;<a href="mailto:fitzgen@gmail.com" target="_blank">fitzgen@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;ve been meaning to drop a line here for a while, but this seems as opportune as any other time. I&#39;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.<br>



<br><a href="https://wiki.mozilla.org/DevTools/Features/SourceMap" target="_blank">https://wiki.mozilla.org/DevTools/Features/SourceMap</a><br clear="all"><font color="#888888"><br>_Nick_</font><div><div></div><div>

<br><br>
<br><br><div class="gmail_quote">On Wed, Jul 27, 2011 at 1:47 PM, Daniel Gackle <span dir="ltr">&lt;<a href="mailto:danielgackle@gmail.com" target="_blank">danielgackle@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div><font face="arial, sans-serif"><div><div><span style="border-collapse:collapse">&lt; It would also be nice to have the full-featured JS environments (V8,</span></div><div>

<span style="border-collapse:collapse">Rhino, SpiderMonkey) as another target for CL deployment. &gt;</span></div><div><span style="border-collapse:collapse"><br></span></div>

</div><div><span style="border-collapse:collapse">I think this is going to become increasingly important as the JS</span></div><div><span style="border-collapse:collapse">implementations improve. The recent release of Clojurescript is an</span></div>





<div><span style="border-collapse:collapse">indicator.</span></div><div><span style="border-collapse:collapse"><br></span></div><div><span style="border-collapse:collapse">We&#39;ve actually switched Skysheet to using PS server-side as well as</span></div>





<div><span style="border-collapse:collapse">client-side so we can deploy to V8 on the server. There are three</span></div><div><span style="border-collapse:collapse">reasons for this:</span></div>

<div><span style="border-collapse:collapse"><br></span></div><div><span style="border-collapse:collapse">1) it eliminates the impedance mismatch between our CL code and our PS</span></div>

<div><span style="border-collapse:collapse">code, which was a drag on development (example: JS&#39;s hash objects</span></div><div><span style="border-collapse:collapse">don&#39;t have a very good counterpart in CL; neither CL hashtables nor</span></div>





<div><span style="border-collapse:collapse">plists/alists are a great substitute);</span></div><div><span style="border-collapse:collapse"><br></span></div><div><span style="border-collapse:collapse">2) we get better performance from V8 than we do from SBCL. (That&#39;s for</span></div>





<div><span style="border-collapse:collapse">unoptimized CL. Optimized CL would do much better of course, but that</span></div><div><span style="border-collapse:collapse">would worsen the impedance mismatch described above;</span></div>





<div><span style="border-collapse:collapse"><br></span></div><div><span style="border-collapse:collapse">3) interoperability with JS gives some desired conveniences, like V8&#39;s</span></div>

<div><span style="border-collapse:collapse">fast JSON support and Node.js for non-blocking i/o.</span></div><div><span style="border-collapse:collapse"><br></span></div>

<div><span style="border-collapse:collapse">A full CL-in-JS would open the door to an all-CL system rather than an</span></div><div><span style="border-collapse:collapse">all-JS one. Either would be better than straddling the two. Would we</span></div>





<div><span style="border-collapse:collapse">switch? Hard to say.</span></div><div style="border-collapse:collapse"><br></div></font><div><div></div><div><br><div class="gmail_quote">On Wed, Jul 27, 2011 at 1:56 PM, Vladimir Sedach <span dir="ltr">&lt;<a href="mailto:vsedach@gmail.com" target="_blank">vsedach@gmail.com</a>&gt;</span> wrote:<br>





<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Currently Parenscript uses some things from Common Lisp that aren&#39;t in<br>
Parenscript. The three approaches to make PS self-hosting are:<br>
<br>
1. Rewrite PS code in a DSL that can be compiled with Parenscript. For<br>
example, replace car/cdr/etc. with destructuring and templating macros<br>
that translate to car/cdr for CL and array access in JS. Then on the<br>
JS side you&#39;d construct your code from arrays instead of conses. The<br>
only problematic thing is symbol representation.<br>
<br>
2. Implement the missing CL features as a run-time library (add a cons<br>
prototype with car/cdr methods).<br>
<br>
3. Make a Common Lisp implementation that runs in JavaScript.<br>
<br>
I think the last option is the most overall useful, and the most fun<br>
to do. Parenscript then would (along with an existing CL<br>
implementation) act as a &quot;syslisp&quot;/bootstrapping dialect and<br>
cross-compiler. Red Daly already has large parts of the needed CL<br>
runtime implemented in his PSOS project<br>
(<a href="https://github.com/gonzojive/paren-psos" target="_blank">https://github.com/gonzojive/paren-psos</a>).<br>
<br>
How useful would Parenscript be in the browser? My guess is not very.<br>
After all, it will just be a macro pre-processor over JavaScript&#39;s<br>
eval, and anything you can do with that you&#39;re better off doing with<br>
closures.<br>
<br>
OTOH having a full Common Lisp on the browser (*with* a working ASDF)<br>
would be pretty sweet. It would also be nice to have the full-featured<br>
JS environments (V8, Rhino, SpiderMonkey) as another target for CL<br>
deployment.<br>
<font color="#888888"><br>
Vladimir<br>
</font><div><br>
On Wed, Jul 27, 2011 at 7:24 AM, Anton Vodonosov &lt;<a href="mailto:avodonosov@yandex.ru" target="_blank">avodonosov@yandex.ru</a>&gt; wrote:<br>
</div><div><div></div><div>&gt; Hello.<br>
&gt;<br>
&gt; I am new in parenscript and only glanced through the documentation on the project page.<br>
&gt;<br>
&gt; As I understand parenscript source is compiled to javascript using a CL implemented compiler.<br>
&gt;<br>
&gt; It&#39;s interesting, how difficult it is to have the same compiler implemented on javascript (i.e. on parenscript itself).<br>
&gt;<br>
&gt; As parenscript is a subset of CL, in theory it mitght be not difficult.<br>
&gt;<br>
&gt; The goal - is to have a browser only Lisp implementation, that can work without hunchentoot. To include parenscript<br>
&gt; scripts onto browser directly, redefine functions interactively and so on.<br>
&gt;<br>
&gt; What do you think?<br>
&gt;<br>
&gt; Best regards,<br>
&gt; - Anton<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; parenscript-devel mailing list<br>
&gt; <a href="mailto:parenscript-devel@common-lisp.net" target="_blank">parenscript-devel@common-lisp.net</a><br>
&gt; <a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
&gt;<br>
<br>
_______________________________________________<br>
parenscript-devel mailing list<br>
<a href="mailto:parenscript-devel@common-lisp.net" target="_blank">parenscript-devel@common-lisp.net</a><br>
<a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
</div></div></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
parenscript-devel mailing list<br>
<a href="mailto:parenscript-devel@common-lisp.net" target="_blank">parenscript-devel@common-lisp.net</a><br>
<a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
<br></blockquote></div><br>
</div></div><br>_______________________________________________<br>
parenscript-devel mailing list<br>
<a href="mailto:parenscript-devel@common-lisp.net" target="_blank">parenscript-devel@common-lisp.net</a><br>
<a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
parenscript-devel mailing list<br>
<a href="mailto:parenscript-devel@common-lisp.net">parenscript-devel@common-lisp.net</a><br>
<a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
<br></blockquote></div><br>