Re: Another defsystem proposal

[Marco A. <ma...@cs...>]

Hi

I browsed your specification and I do not find it contradictory with
what I and Peter wrote.

My only comments are mostly of a "political" nature.

1 - MK:DEFSYSTEM syntax (and somehow semantics) are "implementation"
    neutral for the time being.  This I believe is a plus.

2 - Much of the complication about MK:DEFSYSTEM stems from the rather
    sophisticated (or cumbersome, depending on the point of view) way
    in which the components names are built and dealt with.  This is
    a very tricky part to fix.  In the next message I will send out a
    piece of software which I believe may help in solving this
    problem.
    Apart from that, to achieve the sophistication of MK:DEFSYSTEM
    (and beyond KMP's proposal) we may need to propose a nice component
    construction protocol.
    Of course I am still convinced that it is nice to say

    (defsystem "FOO"
      :components
      ((:module "zut"
          :components ((:module "zot"
                          :components ("file1" "file2"))
                       (:file "gnao")))))

    and have the "proper pathnames" for all the components being
    automagically built.

    This means that

    (make-instance 'module
                   :name "zut"
                   :components (list (make-instance 'module :name "zot" ...)
				     (make-instance 'file :name "gnao" ...)))

    should behave like

	   (defmethod initialize-instance :after ((m module) &key components)
              (dolist (c components)
                (add-sub-components m c)))

    unfortunately this clobbers the :after method.
    Since I am against MOPping around (first you show me that all the
    CL implementations out there have a decent and compatible MOP, and
    then I will be conviced that it is worthwhile playing with it for
    something so fundamental as a defsystem), we are in a quandary.  A
    solution is to have a separate CREATE-COMPONENT method, but it is
    a little tricky to get it right.

3 - The issue of "version" numbers is IMHO very very tricky.  I have
    no problem adding a :version-id field (in substitution of the
    :version field that is there now), as long as it is structured
    and with a well defined semantics.  Morover the functionalities
    dealing with this sort of versioning should be kept orthogonal of
    the "build" functionalities of DEFSYSTEM.

4 - The COPY-SYSTEM procedure must assume that there are restrictions
    to where a system is located.  This may or may lead to problems.
    I am against hardwiring DEFSYSTEM to any specific way of locating
    a system contents.  If this can be achieved in a general way and
    with control left to the user, I am all for it. (As an aside,
    CL-CONFIGURATION does exactly this.)

Having said that, I propose to continue to work on the proposals. I
think the issues I posed are very tricky and important to get right. I
am all for building the system in a bottom-up way, as long as the
big-picture is kept in perspective.

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.