[asdf-devel] compile-with-nicknames

[Robert Goldman]

On 10/16/11 Oct 16 -8:53 PM, Gábor Balázs wrote:
> hY Fare and Robert,
> 
> I have my function, which does the described job for me too. The point
> here is to offer this functionality in public on an easy, standard way.
> Personally, I like to have a single defsystem sexp in the asd file, so I
> would prefer avoiding function definitions there. I haven't met any
> situation before when something serious had to be done around a
> compilation, but you are probably right and wrapping arbitrary functions
> is a useful functionality. However to do that nicely, asdf should be
> refactored in a way described by Robert. But I think it would be still
> nice to offer this (cheap) renaming functionality separately without
> some heavy syntax (wrapping the whole defsystem into a function seems to
> be heavy for me).
> 
> So my function walks along the whole asdf component tree and set the
> :before and :after for each (non-module) component. I had to do this way
> just because the fact you described (I guess). But I was thinking
> instead of putting this functionality around the compile-file call
> itself inside asdf. So to apply this immediately to the whole component
> tree (to each compilation unit). I think it is not a restriction with
> renaming. At least I cannot imagine a reasonable scenario when one wants
> to use different nicknames of the same package for different asdf modules.

I think the problem with doing this :before and :after of each component
and operation is that it doesn't have sensible :around semantics.  E.g.,
you can't easily use it to do something obvious like wrap a dynamic
variable binding around the entire compilation of the system and then
update that dynamic variable binding to communicate across individual
compilations.

I also worry about this nicknaming idea because it seems to rely on
assumptions about the package-to-system mapping that aren't articulated
clearly yet.

Can you explain the use case more clearly so we understand why this is
generally useful?
> 
> So as I see this renaming functionality has the following properties:
> 
>   * it is fairly easy to implement into the current mainstream asdf version
>   * it is easy to use, so CL library developers could easily eliminate
>     the :nicknames options from the package definitions and use this
>     instead (they should basically change only a few lines of code in
>     the .asd and package.lisp files)
>   * unfortunately, it is not the most general solution, so the arbitrary
>     function wrapping would not be provided this way
> 
> I feel the 2nd point very valuable, so I think it would worth doing...
> 
> `bg`
> 
> 
> On Sun, Oct 16, 2011 at 4:11 PM, Robert Goldman <rpgoldman at sift.info
> <mailto:rpgoldman at sift.info>> wrote:
> 
>     On 10/16/11 Oct 16 -4:52 PM, Faré wrote:
>     > 2011/10/16 Gábor Balázs <gabalz at gmail.com <mailto:gabalz at gmail.com>>:
>     >> But there would be a nicer way, and this is the proposal. What
>     about a new
>     >> asdf option (eg :compile-with-nicknames), which could look like
>     something
>     >> this?
>     >>
>     >> (defsystem my-system
>     >>   :depends-on ("package-1" "package-2" "package-3" ...)
>     >>   :compile-with-nicknames (("package-1" "pckg-1")
>     >>                            ("package-3" "pckg-3"))
>     >>   :components (...))
>     >>
>     >> I think this approach nicely works in a "clear" environment for
>     non-parallel
>     >> compilation when there are no insane nickname requests.
>     >> The "clear" environment assumption can be relaxed to say that the
>     user
>     >> hasn't defined any nicknames which causes collisions for any
>     necessary
>     >> compilations.
>     >>
>     >> Or if you know a better way to handle this problem, I would be
>     happy to hear
>     >> about that...
> 
>     I think there is a better way to solve this problem, but it is an
>     ASDF3 method.
>     The basic idea is as follows:
> 
>     1.  ASDF currently works by developing a LINEAR plan for performing an
>     operation.  Here's an example:
> 
>     CL-USER> (asdf:operate 'asdf:load-op :murphy-ltk-demo)
>     #<ASDF:LOAD-OP NIL @ #x1000d42f82>
>     ((#<ASDF:LOAD-OP NIL @ #x1000d57312>
>      . #<ASDF:CL-SOURCE-FILE "ltk" "ltk">)
>      (#<ASDF:LOAD-OP NIL @ #x1000d57312> . #<ASDF:SYSTEM "ltk">)
>      (#<ASDF:LOAD-OP NIL @ #x1000d62f32>
>      . #<ASDF:CL-SOURCE-FILE "murphy-ltk-demo" "package">)
>      (#<ASDF:COMPILE-OP NIL @ #x1000d62f52>
>      . #<ASDF:CL-SOURCE-FILE "murphy-ltk-demo" "ltk-demo">)
>      (#<ASDF:COMPILE-OP NIL @ #x1000d62f52>
>      . #<ASDF:SYSTEM "murphy-ltk-demo">)
>      (#<ASDF:LOAD-OP NIL @ #x1000d42f82>
>      . #<ASDF:CL-SOURCE-FILE "murphy-ltk-demo" "ltk-demo">)
>      (#<ASDF:LOAD-OP NIL @ #x1000d42f82>
>      . #<ASDF:SYSTEM "murphy-ltk-demo">))
> 
>     Inspecting this plan reveals the problem: the operation COMPILE-OP on
>     #<ASDF:SYSTEM "murphy-ltk-demo"> is not done AROUND the compilation
>     operations
>     on the component files, but AFTER them.
> 
>     2.  A possible solution would be to restructure the plans so that
>     they are
>     TREE-SHAPED, instead of linear.  So that there would be an operation
>     that
>     CONTAINS the compile-ops of the individual systems.
> 
>     Then, instead of the "plan interpreter" component of ASDF just being
>     a MAP, it
>     would be a tree-mapper.
> 
>     I think that this is in some sense The Right Thing.  The only
>     problem is that
>     the LOAD-OP is not "convex" in some sense.  Instead, there is
>     loading of files
>     done *during* the compilation.  So if we were to do this, wrapping
>     something
>     around the LOAD-OP might have counterintuitive results.
> 
>     Note also that I believe that we would have to keep the original,
>     odd semantics
>     of the operations on systems, and add a new operation, for backwards
>     compatibility.  So we might have COMPILE-COMPONENT-OP or something.
> 
>     Cheers,
>     r
> 
>     >>
>     > Dear Gábor,
>     >
>     > you describe a common problem and a shared frustration of many CL
>     developers.
>     > However, the problem is not limited to package nicknames, and instead
>     > I would prefer something more general:
>     > the ability to wrap something around compilation,
>     > essentially an advice around compile-file*.
>     > I recently added this feature to xcvb, so that it may compile
>     ironclad,
>     > that uses such a wrapper (an :around method on perform)
>     > to bind the *readtable* and muffle some warnings around compilation.
>     >
>     > And so, I propose something more like:
>     >
>     > (defun call-with-my-nicknames (thunk)
>     >   (with-package-nicknames
>     >     (("package-1" "pckg-1")
>     >      ("package-3" "pckg-3"))
>     >     (funcall thunk)))
>     >
>     > (defsystem my-system
>     >   :depends-on ("system-1" "system-2" "system-3" ...)
>     >   :around-compile call-with-my-nicknames
>     >   :components (...))
>     >
>     > What do you think?
>     >
>     > Of course, you'd have to use ASDF 2.018 or later for that.
>     > Or maybe it's time to call it ASDF 2.18 instead?
>     >
>     > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
>     http://fare.tunes.org
>     >
>     > _______________________________________________
>     > asdf-devel mailing list
>     > asdf-devel at common-lisp.net <mailto:asdf-devel at common-lisp.net>
>     > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
> 
> 
>     _______________________________________________
>     asdf-devel mailing list
>     asdf-devel at common-lisp.net <mailto:asdf-devel at common-lisp.net>
>     http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
> 
>