Hi Red,
It appears that I had an old version. I was using the darcs repo instead of the git repo. There must have been a lot of changes as of August! (ps:ps :foo) used to output a variable reference to foo.
Yes! All of them should be for the better, but if you see something that looks wrong, do let us know.
Nonetheless, here is a bug with the current implementation:
CL-USER> (setf (ps:PS-PACKAGE-PREFIX :cl-user) "CL_USER_") CL-USER> (ps:ps (let* ((some-prop 'foo-sym) (my-object (ps:create 'foo-sym "value!"))) (slot-value my-object 'foo-sym)))
"var CL_USER_someProp = 'foo-sym'; var CL_USER_myObject = { 'foo-sym' : 'value!' }; CL_USER_myObject.CL_USER_fooSym;"
The expected behavior would be for the (create ...) form to reference the same value as the (slot-value ...) form.
Just pushed a patch for that, which makes quoted symbol handling uniform.
If there were any sort of Parenscript runtime, it would be easy to make a data structure for symbols. For example, the above code could translate to something like...
function Symbol(string, prefix) { this.string = string; this.prefix = prefix; // .. add to symbol table, etc. } Symbol.prototype.toString = function() { if (this.prefix) return this.prefix
- "::" + this.string; else return this.string; }
var someProp_symbol = new Symbol("someProp", "CL_USER");
var CL_USER_someProp = someProp_symbol; var CL_USER_myObject = { someProp_symbol : 'value!' }; CL_USER_myObject[someProp_symbol];
This would differentiate symbols and strings, and it would result in pointer comparisons between symbols, just as in lisp.
I understand the current approach is to avoid any runtime, but the runtime solution does seem like less of a hack in the end.
I think there should be a runtime system that PS users would have the option of using for their applications, which would have more run-time CL features like first-class symbols. That way we can make Parenscript self-hosting, among other cool things.
I see the latest implementation now processes keyword arguments differently, eliminating the old hash table approach. This seems like an okay solution, but I suspect it adds a a little overhead for each call to a function with keyword arguments.
This approach adds overhead that is linear in the number of keyword arguments defined, while the previous approach added overhead that was linear in the number of times the keyword arguments were referenced (because it did a slot reference on each occurrence of the variable). I suspect a larger loss will result from the fact that the new approach uses the arguments array, which might prevent the JS compiler from making some kinds of optimizations, but without benchmarks all of this is just speculation.
I also noticed a bug that resulted in improper handling of the following case: (ps:ps (defun hello-world (&key ((my-name-key my-name))) (print "hello, " + my-name)) (hello-world 'my-name-key "fred"))
"function CL_USER_helloWorld() { var CL_USER_myName; var _js54 = arguments.length; for (var n52 = 0; n52 < _js54; n52 += 2) { switch (arguments[n52]) { case CL_USER_myNameKey:
{ CL_USER_myName = arguments[n52 + 1];
};
};
}; if (CL_USER_myName === undefined) { CL_USER_myName = null;
}; print('hello, ', plus, CL_USER_myName); }; CL_USER_helloWorld('my-name-key', 'fred');"
the javascript should really use the following case: case 'myNameKey' instead of case CL_USER_myNameKey. a patch is attached
Pushed. Thanks a lot for the patch!
Vladimir
All the best, Red
Thanks, Vladimir
In general, symbols occupy a strange place in Parenscript. Javascript has no analogue of Lisp symbols, so there is no sensible translation of symbols that works for everyone. Nonetheless, quoted symbols are used in many Parenscript macros to fake having real symbols in javascript. We could build in the ability to translate symbols to some javascript form, e.g.
(ps:ps (make-instance 'animal)) => makeInstance( symbolTable["ANIMAL"] )
The latter part of this post is just food for thought. I will go ahead and commit the patch for the former part of this post unless someone objects.
Red
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