October 2009 - parenscript-devel - mailman3.common-lisp.net

[parenscript-devel] Bug: function call doesn't work with symbol macros
by Daniel Gackle 01 Nov '09

01 Nov '09

(ps (symbol-macrolet ((fake real)) (fake 123))) => "fake(123);"

2 3

Re: [parenscript-devel] Does @ Work?
by Curtis Schlak 30 Oct '09

30 Oct '09

Wow. Do I feel stupid. Duh. Sorry, Vladimir. I *really* should have known. I guess that, after writing ALGOL-inspired code during the day and CL-WHO forms at night, I forgot about the package name. :curtis 2009/10/28 Vladimir Sedach <vsedach(a)gmail.com>: > Hi Curtis, > > Are you sure you've got the right package? Parenscript treats symbols > like Common Lisp: > > (ps:ps (ps:@ document get-element-by-id)) > => "document.getElementById;" > > Vladimir >

1 0

[parenscript-devel] Does @ Work?
by Curtis Schlak 29 Oct '09

29 Oct '09

I downloaded the latest stable and then checked out the source from the git repository at http://common-lisp.net/project/parenscript/git/parenscript. Irrespective of the code that I use, when I write (@ document get-element-by-id) it renders as at(document, getElementById) Am I doing something incorrectly? The tutorial shows that it should.... :curtis

2 1

[parenscript-devel] Tweaks to the NOT and RETURN special forms
by Daniel Gackle 28 Oct '09

28 Oct '09

I pushed another fix for PS LOOP, this time to make :WHILE and :UNTIL clauses play well with :FOR clauses. Working on this, I noticed the generated code was getting lots of expressions like "!!x". So I tweaked the NOT special form to eliminate double negatives (this wasn't a big deal because the NOT special form was already doing some operand reduction): (ps (not (not x))) now => "x;" formerly => "!!x" Also, we sometimes get syntactically illegal double RETURNs in our generated JS (things like "return return x;"). Although this only happens when we make a mistake and use the wrong macro, it can be hard to track down the problem. Since "return return" is never legal JS, I added an error check to the RETURN special form to signal when PS is given such a bad expression to compile. (The above pertains to commit 7c417818 and its two predecessors.) Daniel

1 0

[parenscript-devel] Vector literals
by Daniel Gackle 27 Oct '09

27 Oct '09

I pushed a small patch so PS can handle vector literals. These obviously map to the same thing as lists (namely, JS arrays). (ps #(1 2 3)) => "[1, 2, 3];" (ps #(1 2 #(a b) 3)) => "[1, 2, ['a', 'b'], 3];" It's helpful to have this notation for anyone who's trying to maintain common code across CL and Parenscript (as we are). In principle, I feel that extensions to PS that exist purely to support this goal should probably not be in the core library. But the above change requires hacking the compiler, so I went ahead and put it in. If there are objections, we can remove it. Daniel

1 0

[parenscript-devel] Enhancements to PS LOOP
by Daniel Gackle 27 Oct '09

27 Oct '09

I have added support for :WITH and :APPEND clauses to PS LOOP, and fixed some bugs with :INITIALLY and :FINALLY clauses. I also removed support for some non-standard clauses (:index, :first-time, and :last-time) that to my knowledge were unused. These date back to the experimental origins of this code and conflict with the design goal of implementing a subset of CL LOOP. Daniel

1 0

[parenscript-devel] CREATE: incorrect translation of argument names
by Leslie P. Polzer 24 Oct '09

24 Oct '09

Not sure if this is intended behavior with the next-generation Parenscript, but: (ps:ps ((create :foo-bar 1))) => "({ 'foo-bar' : 1 })();" This used to be converted properly to 'fooBar'. Now I have to specify a string instead which is not really lispy. Leslie -- http://www.linkedin.com/in/polzer

2 1

[parenscript-devel] Bug: lexical renames wrongly extended to CREATE special form
by Daniel Gackle 15 Oct '09

15 Oct '09

In this example, the CREATE form is being expanded incorrectly, because the symbol A passed to it is not a reference to either of the lexical variables in scope. (ps (let ((a 99)) (let ((a 22)) (create a 33)))) => "var a = 99; var a666 = 22; { a666 : 33 };"

3 8

[parenscript-devel] New Parenscript release.
by Vladimir Sedach 10 Oct '09

10 Oct '09

Hello, A new version of Parenscript has been released. This release comes with partial support for LOOP and DESTRUCTURING-BIND Common Lisp facilities (thanks to the efforts of Daniel Gackle and Scott Bell), much faster compilation speed, many bugfixes, real and efficient lexical scoping for all special forms that introduce bindings, as well as the ability to direct compiler output directly to a stream. One thing that has been removed is support for the dot symbol notation (ie - 'object.property' would be special cased into (slot-value object 'property) by the compiler) - this has been done to allow Parenscript code to be a useful target for code walkers designed for regular Lisp code. The consequence is that any code that relies on the dot notation will need to be changed to use non-opaque object slot access. Thank you, Vladimir

7 19

[parenscript-devel] Reimplementing (.method object ...) syntax
by Clinton Ebadi 07 Oct '09

07 Oct '09

Greetings, I recently upgraded parenscript after a few months and was disheartened to see that (.method ...) syntax was removed (and to a lesser extent foo.bar and foo[bar] syntax). I read the mailing list threads pertaining to the new lexical let implementation and compiler improvements, but after skimming the source code I don't see why (.method ...) could not be supported. As such I have started a symbol-syntax branch at [0]. In particular I have done a first stab at reimplementing the (.method ...) syntax in the patch viewable at [1]. I do not yet have a grasp of the subtleties in the new compiler, but I think the patch looks basically correct. I figured you guys could tell me if I missed anything. Are there any objections to the patch? I've found that (funcall (@ foo bar) ...) and (chain foo bar (baz ...)) syntax to be fairly unwieldy for something as common as a method call, and don't see why (.method ...) should not be considered a fundamental syntax of parenscript (parenscript is parenscript and not lisp; enforcing consistency with lisp syntax at the expense of conciseness is not desirable in my opinion). I'll probably reimplement foo.bar.baz syntax properly (by splitting the symbol apart and translating to nested (js:slot-value ...) nodes?). I'm not convinced that it is worth having foo[bar] syntax however (but drewc disagrees so I may reimplement it anyway for our use in ucw/lisp-on-lines). Is there anything fundamentally preventing this from working properly (in the face of symbol renaming and such)? [0] git://git.hcoop.net/git/clinton/parenscript.git [1] http://git.hcoop.net/?p=clinton/parenscript.git;a=commitdiff;h=18eb19984154… -- Jessie: but today i was a nerd Jessie: i even read slashdot.

2 2