[parenscript-devel] Package system, new reader, compilation interface changes, and more refactoring
Dear Parenscripters,
I have made some significant changes to the source code. The impetus for most of my changes was the creation of a package system for Parenscript. This is a brief, rambling explanation of my changes to the code base and is by no means a full documentation of new features.
The compilation interface is now contained in 'compilation-interface.lisp'. The main functions for compiling Parenscript to Javascript are COMPILE-SCRIPT, COMPILE-SCRIPT-FILE, and the macro SCRIPT.
The package system is very similar to Lisp's package system because it works on the symbol level. A script package has an associated lisp package that it uses to intern all of that script package's symbols. This way, the parenscript package of any (lisp) symbol can be determined by looking at the lisp package of any lisp symbol. The Parenscript compiler mandates that every symbol have an associated script package. As a result, the compiler now assigns semantic meaning to both a symbol's name and package--before only the string name of a symbol had any bearing on the resultant code.
There are a few packages that come standard issue (see builtin-packages.lisp). The macros provided by the Parenscript language are split into two package: PARENSCRIPT and JAVASCRIPT. JAVASCRIPT contains special forms that are eventually translated directly to Javascript (e.g. defvar, lambda, with). The PARENSCRIPT package is the package most users will use and contains the rest of the special forms/macros described in the documentation (e.g. macrolet, let, html).
There is now a Parenscript reader thanks to the BSD-licensed Sacla project[SACLA]. Parenscript can use either the Lisp reader or the Parenscript reader to read objects from source text. Generally, Parenscript embedded in Lisp will use the Lisp reader, and Parenscript in Parenscript files (*.paren) will use the Parenscript reader. (Though perhaps in the future the Parenscript reader will be preferred.) It is possible to use the Lisp reader within the Parenscript reader with the reader macro #L(lisp-form), which may be useful for some reason. Parenscript does not currently interfere with the Lisp reader by introducing reader macros. There are only a few differences between the readers: # The Parenscript reader will not obey defined reader macros from the Lisp reader # The Parenscript reader understands Parenscript package names as package prefixes and does NOT understand Lisp package names as package prefixes. # The Lisp reader does not understand Parenscript package names but does understand Lisp package names as symbol prefixes.
I broke up source-model.lisp into js-source-model.lisp and ps-source-model.lisp to correspond to the underlying Javascript and Parenscript special forms. I broke up parser.lisp into parser.lisp, js-macrology, and ps-macrology: the macrology files define macros for javascript and parenscript; parser.lisp contains the functionality for parsing S-expressions into the objects defined in the source-model files. I moved js-html and js-css to the lib/ subdirectory; eventually these should probably be members of other packages.
All tests currently pass and I am adding more tests. More on the package system later, after I have made use of it myself.
Happy hacking, Red Daly
[SACLA] http://homepage1.nifty.com/bmonkey/lisp/sacla/index-en.html
I finally got around to looking at the changes today. Neat! I pushed some patches that cleaned up a few of the deprecated bits, and restored the Lisp/ParenScript macro defining stuff (I'm surprised you haven't made use of them - that stuff is IMO one of the best features of PS).
Vladimir
On 7/25/07, Red Daly reddaly@gmail.com wrote:
Dear Parenscripters,
I have made some significant changes to the source code. The impetus for most of my changes was the creation of a package system for Parenscript. This is a brief, rambling explanation of my changes to the code base and is by no means a full documentation of new features.
The compilation interface is now contained in 'compilation-interface.lisp'. The main functions for compiling Parenscript to Javascript are COMPILE-SCRIPT, COMPILE-SCRIPT-FILE, and the macro SCRIPT.
The package system is very similar to Lisp's package system because it works on the symbol level. A script package has an associated lisp package that it uses to intern all of that script package's symbols. This way, the parenscript package of any (lisp) symbol can be determined by looking at the lisp package of any lisp symbol. The Parenscript compiler mandates that every symbol have an associated script package. As a result, the compiler now assigns semantic meaning to both a symbol's name and package--before only the string name of a symbol had any bearing on the resultant code.
There are a few packages that come standard issue (see builtin-packages.lisp). The macros provided by the Parenscript language are split into two package: PARENSCRIPT and JAVASCRIPT. JAVASCRIPT contains special forms that are eventually translated directly to Javascript ( e.g. defvar, lambda, with). The PARENSCRIPT package is the package most users will use and contains the rest of the special forms/macros described in the documentation (e.g. macrolet, let, html).
There is now a Parenscript reader thanks to the BSD-licensed Sacla project[SACLA]. Parenscript can use either the Lisp reader or the Parenscript reader to read objects from source text. Generally, Parenscript embedded in Lisp will use the Lisp reader, and Parenscript in Parenscript files (*.paren) will use the Parenscript reader. (Though perhaps in the future the Parenscript reader will be preferred.) It is possible to use the Lisp reader within the Parenscript reader with the reader macro #L(lisp-form), which may be useful for some reason. Parenscript does not currently interfere with the Lisp reader by introducing reader macros. There are only a few differences between the readers: # The Parenscript reader will not obey defined reader macros from the Lisp reader # The Parenscript reader understands Parenscript package names as package prefixes and does NOT understand Lisp package names as package prefixes. # The Lisp reader does not understand Parenscript package names but does understand Lisp package names as symbol prefixes.
I broke up source-model.lisp into js-source-model.lisp and ps-source-model.lisp to correspond to the underlying Javascript and Parenscript special forms. I broke up parser.lisp into parser.lisp, js-macrology, and ps-macrology: the macrology files define macros for javascript and parenscript; parser.lisp contains the functionality for parsing S-expressions into the objects defined in the source-model files. I moved js-html and js-css to the lib/ subdirectory; eventually these should probably be members of other packages.
All tests currently pass and I am adding more tests. More on the package system later, after I have made use of it myself.
Happy hacking, Red Daly
[SACLA] http://homepage1.nifty.com/bmonkey/lisp/sacla/index-en.html
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Sorry for clobbering features during the code overhaul. I'm glad you spotted what I wiped out. Maybe you can give me some examples of dual Lisp/ParenScript macro definitions. I am wary to make them, though I have not tried it out.
Red
Vladimir Sedach wrote:
I finally got around to looking at the changes today. Neat! I pushed some patches that cleaned up a few of the deprecated bits, and restored the Lisp/ParenScript macro defining stuff (I'm surprised you haven't made use of them - that stuff is IMO one of the best features of PS).
Vladimir
On 7/25/07, Red Daly reddaly@gmail.com wrote:
Dear Parenscripters,
I have made some significant changes to the source code. The impetus for most of my changes was the creation of a package system for Parenscript. This is a brief, rambling explanation of my changes to the code base and is by no means a full documentation of new features.
The compilation interface is now contained in 'compilation-interface.lisp'. The main functions for compiling Parenscript to Javascript are COMPILE-SCRIPT, COMPILE-SCRIPT-FILE, and the macro SCRIPT.
The package system is very similar to Lisp's package system because it works on the symbol level. A script package has an associated lisp package that it uses to intern all of that script package's symbols. This way, the parenscript package of any (lisp) symbol can be determined by looking at the lisp package of any lisp symbol. The Parenscript compiler mandates that every symbol have an associated script package. As a result, the compiler now assigns semantic meaning to both a symbol's name and package--before only the string name of a symbol had any bearing on the resultant code.
There are a few packages that come standard issue (see builtin-packages.lisp). The macros provided by the Parenscript language are split into two package: PARENSCRIPT and JAVASCRIPT. JAVASCRIPT contains special forms that are eventually translated directly to Javascript ( e.g. defvar, lambda, with). The PARENSCRIPT package is the package most users will use and contains the rest of the special forms/macros described in the documentation (e.g. macrolet, let, html).
There is now a Parenscript reader thanks to the BSD-licensed Sacla project[SACLA]. Parenscript can use either the Lisp reader or the Parenscript reader to read objects from source text. Generally, Parenscript embedded in Lisp will use the Lisp reader, and Parenscript in Parenscript files (*.paren) will use the Parenscript reader. (Though perhaps in the future the Parenscript reader will be preferred.) It is possible to use the Lisp reader within the Parenscript reader with the reader macro #L(lisp-form), which may be useful for some reason. Parenscript does not currently interfere with the Lisp reader by introducing reader macros. There are only a few differences between the readers: # The Parenscript reader will not obey defined reader macros from the Lisp reader # The Parenscript reader understands Parenscript package names as package prefixes and does NOT understand Lisp package names as package prefixes. # The Lisp reader does not understand Parenscript package names but does understand Lisp package names as symbol prefixes.
I broke up source-model.lisp into js-source-model.lisp and ps-source-model.lisp to correspond to the underlying Javascript and Parenscript special forms. I broke up parser.lisp into parser.lisp, js-macrology, and ps-macrology: the macrology files define macros for javascript and parenscript; parser.lisp contains the functionality for parsing S-expressions into the objects defined in the source-model files. I moved js-html and js-css to the lib/ subdirectory; eventually these should probably be members of other packages.
All tests currently pass and I am adding more tests. More on the package system later, after I have made use of it myself.
Happy hacking, Red Daly
[SACLA] http://homepage1.nifty.com/bmonkey/lisp/sacla/index-en.html
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Well, one thing that immediately comes to mind is:
(defmacro+ps out-of-bounds (var start end) `(or (< ,var ,start) (> ,var ,end)))
The code above is expanded into the following by SBCL:
(LET ((#:G1728 (< X 1))) (IF #:G1728 #:G1728 (OR (> X 2))))
Which can is valid PS (but it may not be for other CL implementations), but it isn't compiled into an expression by PS. The import-macros-from-lisp is useful when you already have some macros defined in library/3rd party code where it isn't appropriate to use the defmacro+/ps forms.
Vladimir
On 7/26/07, Red Daly reddaly@stanford.edu wrote:
Sorry for clobbering features during the code overhaul. I'm glad you spotted what I wiped out. Maybe you can give me some examples of dual Lisp/ParenScript macro definitions. I am wary to make them, though I have not tried it out.
Red
Vladimir Sedach wrote:
I finally got around to looking at the changes today. Neat! I pushed some patches that cleaned up a few of the deprecated bits, and restored the Lisp/ParenScript macro defining stuff (I'm surprised you haven't made use of them - that stuff is IMO one of the best features of PS).
Vladimir
On 7/25/07, Red Daly reddaly@gmail.com wrote:
Dear Parenscripters,
I have made some significant changes to the source code. The impetus for most of my changes was the creation of a package system for Parenscript. This is a brief, rambling explanation of my changes to the code base and is by no means a full documentation of new features.
The compilation interface is now contained in 'compilation-interface.lisp'. The main functions for compiling Parenscript to Javascript are COMPILE-SCRIPT, COMPILE-SCRIPT-FILE, and the macro SCRIPT.
The package system is very similar to Lisp's package system because it works on the symbol level. A script package has an associated lisp package that it uses to intern all of that script package's symbols. This way, the parenscript package of any (lisp) symbol can be determined by looking at the lisp package of any lisp symbol. The Parenscript compiler mandates that every symbol have an associated script package. As a result, the compiler now assigns semantic meaning to both a symbol's name and package--before only the string name of a symbol had any bearing on the resultant code.
There are a few packages that come standard issue (see builtin-packages.lisp). The macros provided by the Parenscript language are split into two package: PARENSCRIPT and JAVASCRIPT. JAVASCRIPT contains special forms that are eventually translated directly to Javascript ( e.g. defvar, lambda, with). The PARENSCRIPT package is the package most users will use and contains the rest of the special forms/macros described in the documentation (e.g. macrolet, let, html).
There is now a Parenscript reader thanks to the BSD-licensed Sacla project[SACLA]. Parenscript can use either the Lisp reader or the Parenscript reader to read objects from source text. Generally, Parenscript embedded in Lisp will use the Lisp reader, and Parenscript in Parenscript files (*.paren) will use the Parenscript reader. (Though perhaps in the future the Parenscript reader will be preferred.) It is possible to use the Lisp reader within the Parenscript reader with the reader macro #L(lisp-form), which may be useful for some reason. Parenscript does not currently interfere with the Lisp reader by introducing reader macros. There are only a few differences between the readers: # The Parenscript reader will not obey defined reader macros from the Lisp reader # The Parenscript reader understands Parenscript package names as package prefixes and does NOT understand Lisp package names as package prefixes. # The Lisp reader does not understand Parenscript package names but does understand Lisp package names as symbol prefixes.
I broke up source-model.lisp into js-source-model.lisp and ps-source-model.lisp to correspond to the underlying Javascript and Parenscript special forms. I broke up parser.lisp into parser.lisp, js-macrology, and ps-macrology: the macrology files define macros for javascript and parenscript; parser.lisp contains the functionality for parsing S-expressions into the objects defined in the source-model files. I moved js-html and js-css to the lib/ subdirectory; eventually these should probably be members of other packages.
All tests currently pass and I am adding more tests. More on the package system later, after I have made use of it myself.
Happy hacking, Red Daly
[SACLA] http://homepage1.nifty.com/bmonkey/lisp/sacla/index-en.html
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel@common-lisp.net
-
Red Daly -
Red Daly -
Vladimir Sedach