[parenscript-devel] Re: Proposal: Package System

[John Fremlin]

Red Daly <reddaly at 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

[...]

> 2.  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.)

[...]