Red Daly reddaly@stanford.edu writes:
John Fremlin wrote:
...
Perhaps compiler macros (or something more powerful like SBCL's deftransform) could be included?
I am not intimately familiar with either of these features, though I would appreciate an explanation.
Basically they allow you to specify optimisations to the compiler. deftransform is more flexible and has access to type inference (as far as I understand), but the basic idea is define-compiler-macro.
For a simplified example from a real world use case, in the cl-ppcre (regexp library) if you have something like
`(match "\s*[a-z]+\s" user-input)
then a compiler macro will change that into
`(match ,(create-compiled-regexp-from "\s....") user-input)
so that the regexp is compiled at compile time, massively increasing performance.
The compiler macro would be something like this (off the top of my head)
(define-compiler-macro match (&whole form regexp string &environment env) (if (constantp regexp env) `(match (load-time-value (create-compiled-regexp-from ,regexp)) ,string) form))
(if it returns the same form as it started with then it is a nop)
I am certainly interested in opening up and advancing the compilation architecture. Since I am not exactly a seasoned compiler programmer I do not know exactly how to do this effectively. I have found a few articles about the subject:
I think a lot of the stuff compilers do is quite irrelevant - I mean figuring out which registers to use is not on the agenda. Let's focus on performance problems as they come up ;-)
[...]
(in-package :parenscript-user) (slot-value thing 'property)
If identifiers are to be prefixed before compilation, then this may compile to something like:
thing.parenscriptUser_property
I think this is the correct behavior, but it is confusing. A solution is to introduce a "global" package that compiles without identifier prefixes:
Yes I think that is necessary anyway. I don't think it is confusing, as you have explicitly asked for prefixing.
However, I think that using the same syntax for CL packages as for parenscript packages is a very bad idea, as it means all the parenscript packages have to be defpackage'd in CL so the reader doesn't barf.
I don't know which syntax would be appropriate, as JavaScript already uses . (is that a problem!?) and : is taken. Maybe we could take % or = or something but I don't like either.
(in-package :parenscript-user) (slot-value thing 'global::property) ; => thing.property
Some syntax sugar might make this more manageable. For example, using keywords instead of global symbols:
I disagree! I think that symbol package lookup should occur as in CL and if you :use global and global%property exists and you haven't overridden it, then you should get "thing.property" from (slot-value thing 'property)
(in-package :parenscript-user) (slot-value thing :property) ; => thing.property
If we go the other way and have quoted identifiers serialize without prefixes, we might end up with other confusing semantics:
Yes, it would be terrible
[...]
- Determining the Parenscript package associated with a given Lisp
symbol seems difficult. This is as a result of the ability of Lisp packages to import symbols. Here is the basic functionality for determining the Script package of a Lisp symbol:
If we use the Lisp reader, I think we should use a different syntax for parenscript package designation.
An alternative would be to completely abandon the Lisp reader and use a different one (embeddable with reader macros or something). Would it look very ugly interspersed with normal Lisp?
It sounds a lot better than having stupid package!identifier names or whatever, and if you already have got it working, why not flesh out a proposal so we can see what it would look like?
(At the moment I use this bizarre superquote macro-system I concocted which rather relies on plain s-exps being fed into parenscript so I'm a little chary of the idea.)
[...]