parenscript-devel January 2011

parenscript-devel@common-lisp.net

7 participants
8 discussions

[parenscript-devel] An operator precedence error
by Daniel Gackle 30 Jan '11

30 Jan '11

(unless (equal (= 3 3) (= 3 4)) (foo)) generates this, which is wrong, since FOO should be called: if (3 === 3 != 3 === 4) { foo(); }; I think more parentheses are needed. Daniel

2 1

[parenscript-devel] Syntax error assigning compound expression in object literal
by Daniel Gackle 30 Jan '11

30 Jan '11

The generated JS is invalid here, somewhat unexpectedly (I suppose parentheses are required): (defun foo (obj) (create :abc (let ((x (gethash "blah" obj))) (if x 123 456)))) => function foo(obj) { var x; return { 'abc' : x = obj['blah'], x ? 123 : 456 }; };

2 1

[parenscript-devel] Why is there a WITH clause in my loop?
by Daniel Gackle 30 Jan '11

30 Jan '11

Here's a really strange one. We have a form like the following. I've stripped it down for brevity, so it looks weird: (loop :for time :from time1 :below time2 :do (when (foo (λ () (bar (λ () (blah)) time)) time) (break))) It used to generate this: for (var time = time1; time < time2; time += 1) { if (foo(function () { return barr(function () { return blah(); }, time); }, time)) { break; }; }; But now it generates this: for (var time = time1; time < time2; time += 1) { with ({ time : time }) { if (foo(function () { return bar(function () { return blah(); }, time); }, time)) { break; }; }; }; That is one weird WITH clause in there! No doubt it has something to do with lexical scoping magic going on under the hood. But I definitely don't want it in a performance-critical loop. Daniel

5 8

[parenscript-devel] FLET, LABELS, and MULTIPLE-VALUE-BIND are broken
by Daniel Gackle 30 Jan '11

30 Jan '11

I've attempted to upgrade again to the latest PS. It looks like the issues we discussed last month are fixed (thank you), but there are some serious new breakages: 1. FLET and LABELS no longer accept &OPTIONAL, &REST, or &KEY arguments 2. MULTIPLE-VALUE-BIND doesn't work: in the JS for (PS (MULTIPLE-VALUE-BIND (A B) (BLAH) (+ A B))), the function BLAH doesn't appear. I'll post if I notice anything else.

2 3

[parenscript-devel] PS warning being treated as error by ASDF+SBCL
by Daniel Gackle 26 Jan '11

26 Jan '11

PS does the following to warn you about redefining built-in operators: (warn "Redefining Parenscript operator/macro ~A" name) As it happens, we redefine DEFMACRO and IN-PACKAGE to expand to nothing and @ to expand to something a bit different than what PS does. The purpose of these redefinitions is to support cross-compiling a number of files to both CL and JS. Unfortunately, that warning turns into an error preventing ASDF from loading the system in SBCL: ; compilation unit aborted ; caught 1 fatal ERROR condition ; caught 3 WARNING conditions I don't see what the ERROR is, since only the above three warnings are written to the REPL. It goes away, however, when I comment out the WARN form above. I have an ugly workaround for this (reach in to PS::*PS-DEFINED-OPERATORS* and rip out these three symbols before attempting to redefine them), but that seems like a horrible thing to do. Resorting to SBCL's condition-muffling mechanism seems even worse. Just to be clear, I don't object to PS issuing the warning, just to the fact that it turns into a fatal error along the way. So I guess my question is: what's the intended way to redefine a PS operator/macro, on the rare occasion when one really does need to do that? Daniel

3 4

[parenscript-devel] CASE is still broken with RETURN
by Daniel Gackle 17 Jan '11

17 Jan '11

This generates an incorrect fall-through when A is "a" and FOO returns NIL: (defun blah (a) (case a ("a" (when (foo) (return-from blah 111))) ("b" t))) Note that if you replace WHEN with IF, it works.

2 1

[parenscript-devel] Evaluation of default values for keyword args
by Daniel Gackle 11 Jan '11

11 Jan '11

I'm glad to see the tighter code being generated for keyword arguments, but I'm afraid there's a problem. If a default value is provided, it is now being evaluated whether it's needed or not: (defun blah (&key (param (long-running-computation))) (foo param)) => function blah() { var param = longRunningComputation(); var _js10 = arguments.length; // ... return foo(param); }; Compare this to: (defun blah (&optional (param (long-running-computation))) (foo param)) => function blah(param) { if (param === undefined) { param = longRunningComputation(); }; return foo(param); }; I think the above keyword behavior is incorrect and the optionals have it right. Yet I like the fact that all the sludge of the "if variable remains undefined after sucking out the optional arguments then set it to null" sort has been removed. Is there a compromise? For example, could we do it the simpler way where the default value is a constant? Daniel

2 3

[parenscript-devel] best practice for developing a JS-only HTML5 webapp?
by Jon Rosebaugh 11 Jan '11

11 Jan '11

As I said in the subject, I'm working on a JS-only (no server-side code) HTML5 webapp in Parenscript with jQuery. I have extensive JS experience, but I'm really new to Common Lisp. I wanted a setup where I could edit a Parenscript file, hit save, then hit refresh in my browser and immediately see the new code, just as if I were working in Javascript. I built a little server using Hunchentoot and cl-who that runs ps-compile-file on my parenscript source file as needed. This works fairly well, but maybe is not the best way to accomplish this. However, there's a problem; I wanted to use parenscript functions without the namespace, so I defined a package in serve.lisp that uses parenscript, then put (in-package :innkeeper) at the top of my parenscript file. This doesn't work properly in the 2.2 release of Parenscript (which is what Quicklisp provides). It _does_ work in the git repo version (as of commit 0e01e555f404a7dcb8befb7587288c38abf526c2), but it's annoying to not be able to use Quicklisp for everything. Once I have a release version I'll want to come up with some lisp program that compiles the parenscript to javascript, minifies it, and sticks it in an also-minified html file from cl-who, so the whole thing is compiled down to a single file. I'd appreciate any best-practice tips on that too. Just in case my description was unclear, here's what I think are the relevant bits. If needed, I can provide the entire files off-list. ; relevant bits of serve.lisp (defpackage "INNKEEPER" (:use "COMMON-LISP" "HUNCHENTOOT" "CL-WHO" "PARENSCRIPT") (:export :start-innserver :stop-innserver)) (in-package :innkeeper) (define-easy-handler (jsgen :uri "/innkeeper.js") () (setf (content-type*) "application/javascript") (ps-compile-file "/Users/jon/code/innkeeper/innkeeper.lisp")) ; beginning (and a few representative lines) of innkeeper.lisp (in-package :innkeeper) (defmacro immediate (&body body) `((lambda () ,@body))) (var *inn* (create setup (lambda () ((@ ($ "#top-tabs") tabs))))) (j-query #'(@ *inn* setup))

5 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

parenscript-devel January 2011