[asdf-devel] compile-with-nicknames

Mon Oct 17 01:53:23 UTC 2011

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.

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> wrote:

> On 10/16/11 Oct 16 -4:52 PM, Faré wrote:
> > 2011/10/16 Gábor Balázs <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
> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
>
>
> _______________________________________________
> asdf-devel mailing list
> asdf-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20111016/17d4f060/attachment.html>