parenscript-devel June 2007

parenscript-devel@common-lisp.net

10 participants
16 discussions

[parenscript-devel] Feature proposal: (defun (setf... and defsetf
by Vladimir Sedach 02 Aug '07

02 Aug '07

Another feature I'm planning to add are setf expanders for ParenScript. This should eliminate the need for explicitly name-mangling complex accessor function names like set-this and set-that, etc., which will make ParenScript code generation much easier, but at the same time generate those name mangled functions in the generated Javascript code itself, which will aid in debugging code in Javascript tools such as Firebug.

1 1

[parenscript-devel] BUG: slot value conditional.
by Vladimir Sedach 26 Jul '07

26 Jul '07

Daniel Gackle pointed this out: (js (slot-value (if yes a b) 'prop)) => "yes ? a : b.prop;" When in fact the code should be "yes ? a.prop : b.prop;"

1 1

[parenscript-devel] ParenScript tests.
by Vladimir Sedach 03 Jul '07

03 Jul '07

Henrik Hjelte mentioned the ParenScript tests, which is a subject I want to bring up since I currently can't run them. The tests are based on FiveAM, the Bese testing framework, however the asdf-install for it is broken right now (it depends on Arnesi, the Bese utility library, which isn't asdf-installable, and when I go pull it from the Bese darcs repository it still has mystery dependencies on other Bese code). Since I don't want to invest time and effort into making FiveAM easy to install, I think maybe we should consider switching test frameworks to something that Just Works? Does anyone have suggestions? Vladimir

4 5

[parenscript-devel] Proposal: Package System
by Red Daly 01 Jul '07

01 Jul '07

Dear Fellow Parenscripters, Here I detail a proposed package system for Parenscript to ease modular development. This is a feature intended to make up for the many hacks Javascript programmers use to write libraries. The proposed system takes after and integrates with the Lisp package system. Its implementation will constitute a hearty advancement of the current Parenscript compiler. The proposed system should introduce new concepts and should be robust enough to lay the foundation for a lot of future work in a coherent way. Different packages can introduce new special forms--that is, modify the language at the lowest level. With this, a "javascript2" package can introduce Parenscript forms that compile to the latest version of ECMAScript without implicating the rest of the project. The additional semantic analysis of Parenscript programs will pave the way for cropped, minified, or obfuscated scripts. In addition, a formal package specification will lead to asdf-installable script libraries with better deployment characteristics than current package systems for web development in other languages. A Parenscript package (or "script package" or simply "package," as opposed to a "Lisp package") has a few main properties: a name and list of nicknames, an primary associated Lisp package, a list of exported identifiers, and a collection of macros defined in the associated Lisp package. We must also introduce and formalize a two other concepts: Parenscript identifiers (analog of Lisp symbols), and a compilation environment. A Parenscript package is defined and exists in the context of a compilation environment. A compilation environment simply keeps track of compiler state; when any Parenscript code is compiled, a new compilation environment is created or an existing one is passed to the compiler. The environment is modified to reflect the lexical scope as forms are processed. Specifically, the compilation environment will consist of a stack of Parenscript identifiers (introduced by defun and defvar forms); a stack of macros and symbol macros; a list of defined script packages; and the current script package. An identifier in Parenscript is analogous to a Lisp symbol, but it only exists during compile time. An identifier has a string value and associated Parenscript package. Now I will run through a simple example to demonstrate these new developments: Script packages are primarily defined using a Parenscript form analogous to the Lisp defpackage: (defpackage friendly-script (:use parenscript psos) (:export hello-world) (:lisp-package friendly) (:documentation "Scripts for issuing greetings.")) This introduces a new package into the compilation environment. We enter the package system after it is defined as in Lisp: ;; enter the friendly-script package ; changes the current package in the compilation environment to :friendly-script (in-package :friendly-script) ;; define the hello-world function, which we export ; adds friendly-script::hello-world to the identifier stack in the compilation env. (defun hello-world () (alert "hello world.")) ;; enter the user package ; changes current package in compilation environment (in-package :parenscript-user) ;; call the friendly-script's hello-world function ; the compiler recognizes that friendly-script::hello-world is an e (friendly-script:hello-world) To give you an idea, this will all compile to something like the following Javascript: function friendlyScript_helloWorld() { alert("hello world."); } friendlyScript_helloWorld(); In terms of implementation, the package system will introduce a few new classes (script-package, identifier, and compilation-environment); uproot existing parsing procedures and replant them around the package system; and add a semantic analysis phase into the compilation pipeline. I will fill in details and announce problems with the implementation as it moves forward. Hopefully this is an exciting prospect for the community. The package system should empower those who want to build large programs or share Parenscript extensions/libraries. It should also preserve the javascript-in-sexps Parenscript we know and love. Anyhow, I look forward to comments on this proposal. Happy hacking! Red

5 5

[parenscript-devel] Breaking up js.lisp
by Red Daly 26 Jun '07

26 Jun '07

Parenscript is long overdue for a simple code reorganization. js.lisp is a monolithic file with nearly all the interesting components of the compiler. I propose splitting it up into three different files: source-model.lisp, js-translation.lisp, and parser.lisp: source-model.lisp: class definitions that correspond to the Javascript AST. (defjsclass forms for the most part) js-translation.lisp: functions for converting AST objects to Javascript source code parser.lisp: macro definitions and the mechanisms for processing Parenscript forms into AST objects. Let me know if there are any objections. Otherwise I will go ahead and submit a patch. Red

2 3

[parenscript-devel] Refactoring ParenScript macros.
by Vladimir Sedach 26 Jun '07

26 Jun '07

Hello, I've just submitted a patch with some refactoring done to the ParenScript macro code that has one large user-visible effect: ParenScript "compiler macros" are now called "special forms" (so the corresponding macros like define-js-compiler-macro are now called define-js-special-form). There are two reasons for this: first, those things really are special forms, and second of all compiler macros are an unrelated concept in Common Lisp that may someday be implemented in ParenScript. Please let me know if you have any objections to this or whether the patch breaks something. Also, I haven't updated the documentation yet - if anyone wants to do so, you are more than welcome (otherwise I'll delay doing it until it's time for the next tarball release). Vladimir

1 0

[parenscript-devel] Js macro names can't be used as variable names
by Daniel Gackle 26 Jun '07

26 Jun '07

Hey, Are we on? Parenscript is great and I'm hoping this list means we'll see some active development on it. Here's an issue to kick things off. Once you define a js macro in parenscript, you can't use that symbol for anything else. For example, (js (defvar blah 123)) => "var blah = 123;" ... which is good, but if you do this: (defjsmacro blah () `(some-fn)) then the first expression no longer works. That's what I would expect if blah were a symbol macro, but not a regular macro. Anyone want to take a crack at this? Dan

2 1

[parenscript-devel] BUG: &body in ParenScript macrolet doesn't work.
by Vladimir Sedach 26 Jun '07

26 Jun '07

This works: (js (macrolet ((foo (bar &rest body) `(+ ,@body))) (foo 1 2 3 4))) This doesn't: (js (macrolet ((foo (bar &body body) `(+ ,@body))) (foo 1 2 3 4))) Related to this, make ParenScript macrolet support all lambda list keywords that Lisp macrolet supports.

1 1

[parenscript-devel] Parlez-vous ActionScript?
by John Pallister 26 Jun '07

26 Jun '07

Hello list, While people are discussing future directions for ParenScript, I thought I'd add my two cents. I am developing systems based around XHTML, X3D and Adobe Flex; in all three cases we have an XML-syntax language with an embedded JavaScript language. Except that X3D uses ECMAScript 2 (which AFAIK is "standard" XHTML JavaScript 1.x) while Flex (i.e. Flash 9) uses ActionScript 3.0, which is an implementation of ECMAScript 262 Revision 4 [1], a.k.a. JavaScript 2.0 [2]. The point is, ECMAScript 4 has a variety of new features (optional static typing, classes, interfaces, packages, generators, list comprehensions etc. - there's a nice overview at [3]) which aren't currently supported by ParenScript. Given that the adoption of ECMAScript 4/JavaScript 2 is a case of when rather than if [4], it would be great if any overhaul of ParenScript could be done with an eye to incorporating some or all of these features in the near future (hopefully by other interested parties such as myself). The "add a compiler" POV vs. the "keep it simple" perspective echoes the two sides of the JavaScript 2 debate. Since these new language features will be added (and I'm already using them in ActionScript 3), it would be great if they could be added to ParenScript without causing too much inconvenience to those who like it the way it is now. I would like to help out with this task; I might have some time to spend on it later in the year. Cheers, John :^P [1] http://www.ecmascript-lang.org/ - includes reference impl. in Standard ML [2] "ActionScript 3: The Language of Flex. A Conversation with James Ward, Part I", http://www.artima.com/lejava/articles/actionscript.html [3] http://developer.mozilla.org/presentations/xtech2006/javascript/ [4] http://www.mozilla.org/projects/tamarin/ -- John Pallister john(a)synchromesh.com Wellington, New Zealand

4 3

[parenscript-devel] Feature request: prefixed names
by John Fremlin 25 Jun '07

25 Jun '07

Nowadays many things seem to want to include their JavaScript in your webpages. Aside from the fact that this is annoying, dangerous and wrong, we have to accept that it is quite prevalent: from Google AdWords to ReCaptcha. If I might add a feature request, it would be to be able to make sure that the identifiers generated by parenscript don't clash with anything else.

6 12

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

parenscript-devel June 2007