parenscript-devel July 2010

parenscript-devel@common-lisp.net

4 participants
9 discussions

[parenscript-devel] Patch: added JS label/break to PS
by Daniel Gackle 07 Dec '10

07 Dec '10

I just pushed a patch (authored by Scott) to implement JS's LABEL and BREAK in PS. (Note that this patch deprecates LABELED-FOR since you can get the same effect by combining LABEL and FOR. Was anybody using LABELED-FOR?) Here's an example: (label scope (foo) (when (bar) (break scope)) (blee)) => scope: { foo(); if (bar()) { break scope; }; blee(); }; I was astonished to discover recently that JS has supported this ability all along in the form of labeled statements and labeled breaks. I'd always assumed that to get explicit returns from an arbitrary scope, you'd have to resort to the ugly hack of muscling TRY/CATCH to do it, thinking that this was the closest JS counterpart. (See http://news.ycombinator.com/item?id=793092 for a thread in which several people believe this.) But it appears we were all wrong. What's not clear yet is how far this can be taken. Can you use it inside a nested local function to return immediately from the top-level function? That is one thing I've wanted for a long time. In the ideal case, LABEL/BREAK could be used as a base for implementing a proper BLOCK and RETURN-FROM in PS, something which we'd long believed to be impossible. One challenge is that in CL, RETURN-FROM can take a value, which becomes the value of BLOCK. In other words, BLOCK in CL is an expression while LABEL in JS is not. It seems, though, that most of this challenge has already been conquered with the development of implicit return in PS. The only thing you'd need to add is detecting when BLOCK is being used as an expression, declaring a gensymed variable and assigning whatever is happening inside BLOCK to that variable (much like implicit return already does with e.g. CASE), then put the variable in the expression position that BLOCK was in. It seems like this ought to work. It would also make things like this possible in PS: (1+ (case foo (:eleven 11) (:twelve 12))) Vladimir (and everybody), is the above clear? What do you think of it? Daniel

4 11

[parenscript-devel] Fwd: Parenscript
by Nick Fitzgerald 09 Aug '10

09 Aug '10

Hey Dan, Thanks for the tip regarding the tutorial, however I'm not sure who wrote it or who is maintaining it. I am forwarding your message to the ParenScript development mailing list; I'm sure someone there will be more helpful than me. Thanks again, _Nick_ ---------- Forwarded message ---------- From: Daniel Weinreb <dlw(a)itasoftware.com> Date: Wed, Jul 28, 2010 at 2:01 PM Subject: Parenscript To: Nick Fitzgerald <fitzgen(a)gmail.com> Nick, Hi. I just got reminded of the existence of Parenscript by seeing the recent Planet Lisp blog post. This is really cool and I hope to get the time to learn all about it. I have one tiny suggestion: in this tutorial: http://common-lisp.net/project/parenscript/tutorial.html put in a reference to something that explains what Parenscript is for, what it's all about. If one stumbles onto the tutorial, one has a hard time figuring out what's going on, lacking any context. -- Dan

2 1

[parenscript-devel] TryParenScript.com!
by Nick Fitzgerald 05 Aug '10

05 Aug '10

Hey guys! I just got a quick and dirty first iteration of http://tryparenscript.com/ up and running. Emphasis on dirty. This is my first "real" piece of ParenScript, so I would love to have some feedback. All of the code is hosted at http://github.com/fitzgen/tryparenscript.com It follows in the footsteps of http://www.tryruby.org/, http://tryhaskell.org/, and http://tryclj.licenser.net/. Basically provides a REPL for ParenScript inside of your browser. I would like to add an interactive tutorial like how some of those have in the future. I couldn't get sbcl and hunchentoot running behind apache, it was a nightmare for me (though I expect I just was overlooking something), so I ended up writing the backend in ParenScript too, with Node JS. Currently there are some issues with the way that function definitions are evaled in the global scope, so (defun foo (x) (return (+ x 1))) won't create a new global foo function because it ends up being evaluated as this: window.__tryps_return = function foo(x) { return x + 1; } so what should have been a Function Declaration gets turned in to a Named Function Expression. This is on the top of my list of things to do next. Fortunately, there is a simple (while not quite "easy-to-use") fix: (setf (@ window foo) (lambda (x) (return (+ x 1)))) which will work as expected. I also expect I will need to set up some type of monitoring for the server because it is just a single process in detachtty, and if it crashes (which I suspect it might if it hit the front page of Hacker News all of a sudden, or something like that) I would have to go back in and restart the process (after I somehow found out it died). This is obviously less than optimal. If anyone has any suggestions on this front, I would love to hear them too. Most of all, I would just like to get some feedback and suggestions on the code :) Thanks in advance for all your responses! _Nick_

2 4

[parenscript-devel] Bug w/ strings and backslashes?
by Nick Fitzgerald 14 Jul '10

14 Jul '10

Hello everyone! Maybe I am misinterpreting this, but I can't seem to reproduce the following example from the reference. > Parenscript makes no effort to interpolate C-style escape strings. Rather, non-printable characters in Lisp strings are output using escape sequences: > > > #\Tab > > '\t'; > > > "\\n" > > '\\n'; This is the behavior that I get: > PS> (ps "\\n") > "'\\\\n';" > PS> (ps "\n") > "'n';" Am I doing something wrong? I'm on the HEAD of master from http://common-lisp.net/project/parenscript/git/parenscript, btw. Thanks, _Nick_

2 2

[parenscript-devel] Project announcement: cl-spidermonkey
by Red Daly 13 Jul '10

13 Jul '10

Dearest Meta Javascripters, I have written a library for interfacing Common Lisp with the Spidermonkey Javascript engine. You may find some use in this for testing Parenscript code, or ever running Parenscript code to do some important, lisp-end task. In any case, what follows is excerpted from the README. The home page for the project is http://github.com/gonzojive/cl-spidermonkey . Contributes are of course welcome. All the very best, Red # CL-SpiderMonkey: Common Lisp interface to Javascript ### A Common Lisp library for interacting with Javascript through the SpiderMonkey library ## Introduction cl-spidermonkey provides a Javascript runtime environment inside of Common Lisp by embedding a widely-used and tested Javascript engine: Mozilla's SpiderMonkey. With full access to Javascript from Common Lisp, it becomes easier to test Javascript libraries in the same breath as normal testing. It also allows a Lisp REPL to be used as a Javascript REPL, and for many other combinations of lisp and JS. ## Installation Before you do anything you need the git repostiory. git clone git://github.com/gonzojive/cl-spidermonkey.git First you need to compile Spidermonkey. It's not that bad! Just cd into the vendor directory and then run the install script: cd vendor sh install-spidermonkey.sh That will download and install SpiderMonkey, and set up all the paths properly. Now you should be able to load the library in lisp: REPL> (asdf:operate 'asdf:load-op :cl-spidermonkey) ## Usage Right now there are only two exported symbols, so things are pretty easy: REPL> (sm::with-js-context (context) (sm:evaluate-js "10 * 24;")) 240 Note that you can only get doubles, ints, strings, voids (undefined), nulls, and boolean values back from EVALUATE-JS. Any other object will come back as a pointer to a JS_Object whichs needs further attention from the bindings. If you are so inclined, lookat the src/spidermonkey-bindings.lisp file for more info on how to deal with native Spidermonkey objects.

3 4

[parenscript-devel] PS Tests - another run
by Daniel Gackle 13 Jul '10

13 Jul '10

Yes, somehow some errant ps macros made it into the test run I sent a couple days ago. Here's another. (This is from CCL.) Daniel Running reference tests: ...............f......................................................................... Did 89 checks. Pass: 88 (98%) Skip: 0 ( 0%) Fail: 1 ( 1%) Failure Details: -------------------------------- ASSIGNMENT-11 []: (NORMALIZE-JS-CODE "var _js2 = someDiv; var _js1 = 123 + 'px'; _js2.style.left = _js1;") evaluated to "var _js2 = someDiv; var _js1 = 123 + 'px'; _js2.style.left = _js1;", which is not STRING= to "left(someDiv) = 123 + 'px';".. -------------------------------- Running other tests: ....................................................................................................................................................................................................................................... Did 231 checks. Pass: 231 (100%) Skip: 0 ( 0%) Fail: 0 ( 0%) Running Package System tests: f.f..f.. Did 8 checks. Pass: 5 (62%) Skip: 0 ( 0%) Fail: 3 (37%) Failure Details: -------------------------------- NAMESPACE-AND-SPECIAL-FORMS []: (PARENSCRIPT-TEST::NORMALIZE-JS-CODE "var prefix_foo = { prefix_bar : 1, prefix_notAKeyword : prefix_something }; return !prefix_foo && prefix_foo.prefix_bar + prefix_someOtherVar;") evaluated to "var prefix_foo = { prefix_bar : 1, prefix_notAKeyword : prefix_something }; return !prefix_foo && prefix_foo.prefix_bar + prefix_someOtherVar;", which is not COMMON-LISP:STRING= to "var foo = { bar : 1, notAKeyword : something }; return !foo && foo.bar + someOtherVar;".. -------------------------------- -------------------------------- OBFUSCATION1 []: (NORMALIZE-JS-CODE "function g1(a, b, g2) { return a + my_library_libraryFunction(b, g2); };") evaluated to "function g1(a, b, g2) { return a + my_library_libraryFunction(b, g2); };", which is not STRING= to "function g1(a, b, g1) { return a + my_library_libraryFunction(b, g1); };".. -------------------------------- -------------------------------- EXPORTED-INTERFACE []: (PARENSCRIPT-TEST::NORMALIZE-JS-CODE "function interfaceFunction(prefix_baz) { return prefix_baz + g2; };") evaluated to "function interfaceFunction(prefix_baz) { return prefix_baz + g2; };", which is not COMMON-LISP:STRING= to "function interfaceFunction(baz) { return baz + g1; };".. --------------------------------

2 1

[parenscript-devel] What should PS LOOP do with null collections?
by Daniel Gackle 12 Jul '10

12 Jul '10

I don't know if anyone other than us is using PS LOOP, but we use it heavily since our application is very loop-intensive. A continual source of bugs is looping over a null collection. Say BAR is null. The following will crash: (ps (loop :for foo :in bar :do (baz foo))) ...because the code expands to include (length bar). This is particularly annoying if you're running the code in CL as well, where looping over a null collection is just fine. We've been dealing with this like so: (ps (loop :for foo :in (or bar '()) :do (baz foo))) ... but this is ugly and more importantly very brittle, since it means tracking down every crash case-by-case. My question: what does everybody think about making PS LOOP accept null collections and just do nothing in that case? Something about this bothers me. It goes against the philosophy of PS, which declines to pretend that JS arrays are Lisp lists (something I fully agree with). But I'm inclined to make an exception in this case because the strict approach is so painful. And this of course raises the analogous question for any PS versions of MAPCAR, MAPC, etc. Daniel

2 2

[parenscript-devel] A macro for integrating PS with Slime
by Daniel Gackle 11 Jul '10

11 Jul '10

Below is a DEFUN-JS macro for defining PS functions at the Lisp top-level. It creates a Lisp stub with the same signature whose body simply throws an error telling you that you tried to call a PS function from Lisp. Why is that useful? Because now your PS functions are fully integrated with Slime. You can jump around with M-., get arglist info in the minibuffer, and so on. After a week of using this, I can't believe how much of a difference it makes. In PS, DEFUN-JS translates trivially to DEFUN. Of course you still need a way to collect the JS emitted by all these forms, but PS is agnostic on how that should be done. A side note: we also converted nearly all our ps macros to DEFMACRO+PS forms at the toplevel. This has the neat property that you can now look at expansions using the highly convenient Slime macroexpand. I doubt that this is a perfect solution (no doubt you can trip yourself up on differences between the CL and PS macro environments), but it's sure handier than calling PS::PS-MACROEXPAND from the REPL. Daniel p.s. The following has been stripped of a couple of functions specific to our project. I tested it a bit, but if I missed anything, let me know. (defmacro defun-js (name lambda-list &body body) (declare (ignore body)) (labels ((sym% (argspec) (if (symbolp argspec) argspec (car argspec)))) (multiple-value-bind (required optionals restp rest keyp keys allowp auxp aux morep more-context more-count beyond-requireds? key-object) (ps::parse-lambda-list lambda-list) (declare (ignore restp keyp allowp auxp aux morep more-context more-count beyond-requireds? key-object)) ;; get rid of init forms, which can't be evaluated in Lisp. (setf optionals (mapcar #'sym% optionals) keys (mapcar #'sym% keys)) `(defun ,name (,@required ,@(when optionals `(&optional ,@optionals)) ,@(when rest `(&rest ,rest)) ,@(when keys `(&key ,@keys))) (declare (ignore ,@required ,@optionals ,@(when rest (list rest)) ,@keys)) (error "The ~s function is js-only and cannot be called from Lisp." ',name))))) (defpsmacro defun-js (name lambda-list &body body) `(defun ,name ,lambda-list ,@body))

3 3

[parenscript-devel] Another way to run JavaScript in CL
by Vladimir Sedach 09 Jul '10

09 Jul '10

Just came across this: http://github.com/akapav/js It looks like a full-fledged JS runtime written in CL. Vladimir

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

parenscript-devel July 2010