From: Mario S. Mommer on

Juanjo <juanjose.garciaripoll(a)googlemail.com> writes:
> It may just as simple, but some people believe it should be more
> complex.
>
> 1) Dependencies should be different depending on the "action". That
> complicates things quite a bit.
> 2) Some actions trigger other actions (:compiled -> :load or :load -
>> :compile). That is even more complicated.

....right.

IMO it is better to write an ad-hoc loader with a good library to asist,
and conforming to a realistic and practical set of best practice
guidelines. The complicated cases of system definition are best handled
programatically anyway. At least it is more natural.

>
> All this complexity, which does not exist in defsystem,

Are you sure? IIRC defsystem is fully extensible.
From: Juanjo on
On Apr 15, 10:12 pm, m_mom...(a)yahoo.com (Mario S. Mommer) wrote:
> Here's something on the lines of what I have in mind:
>
> (load-module "src"
>    (load-file "file1"
>        (load-file "file 2"))
>    (load-file "file3"))
>
> where load module would append the directory "src" to some special, and
> the load-file would be implemented in a lazy fashion.

That does not look much simpler to me, specially when you look around
for the kind of dependencies that people are writing, where C, D and E
depend on A, D depends on A B and C, E depends on D an some other
module, and the graph gets rather complex. I just wonder, like you do,
to what extent this all makes sense, other than to enhance the
parallelizability of the build process -- one of the goals of XCVB and
something apparently valued at ITA.

The real problem, though is the other thing you pointed out: when some
of the operations needed to build the system depend on components of
the system itself. Say for instance that I implement a compiler and
the first three files A B and C implement a first simplified version
and the other ones are built with it, D E and F. How do you write such
a thing? We have to write rules, and that means extending ASDF in the
complicated way it provides us, and we find compilcations such as the
fact that those rules must use symbols which are defined in the files
A B and C.

From a conceptual (not yet implementation) point of view I am toying
with a declarative extension to ASDF, adding kind of makefile-type
rules. The idea would be something like what I show below. Instead of
tinkering with methods and so on, we provide some kind of pattern
matching that produces code (code is not evaluated, but concatenated)
which may rely on some macrolet forms, by which ASDF provides most of
the information: where to place files, etc.

By placing the package file in the :asdf-support we allow the rules to
depend on the rest of the system. By storing the rules as just S-expr,
not lisp code, we allow the code to work once the appropriate
dependencies have been loaded. In addition to this, rules may be
installed by other extensions (say a hypothetical cffi-asdf tiny
module) and the ASDF files remail purely declarative -- no more side
effects than package definitions.

mysystem.asd:

(defsystem :my-system
:asdf-dependency ((:file "package") (:file "mysystem.asd"))
:components ((:file "package") (:file "A") ... (:file "D" :depends-
on "D-dsl" "A" "B" "C") ...))

;;; ASDF would stop reading as soon as it reaches one defsystem form
;;; The following is loaded as part of the :asdf-dependency,
;;; since it is loaded _after_ "package" we have the package
;;; available here.

(def-asdf-rule (:my-system :file "D")
(my-system:generate-file (asdf:output-file) (first
(asdf:dependencies))))
From: Juanjo on
On Apr 15, 10:06 pm, Nathan Froyd <froy...(a)gmail.com> wrote:
> This is the big sticking point in switching to something else.  There
> are good reasons why side-effectful bits are useful in an .asd file.
> Custom component definitions and specializing operations on those components
> are what come immediately to mind

I argue that this can be done in a "declarative" manner. That would be
ok because it would also impose a stricter syntax and we can enforce
further requirements.

> > * Restrict the set of operations that ASDF supports to a few: compile,
> > load & test
>
> Please don't do this.  There are very good reasons to support more
> than three operations on a system; I've written at least two custom
> operations for my own personal use (building tar files and autogenerating
> documentation); I'm sure you can think of more.

Answer this: assume that ASDF becomes a library and can provide you
with an annotated graph with all the components of a system,
topologically sorted, each one futher annotated with the files it
produces.

Do you really need then the current system that ASDF has or wouldn't
it suffice to just traverse the list, a-la MAPC, with a function that
creates a tar file?

The problem is not extensibility, but that ASDF right now is so
confusing that it does not allow people to realize there are other
ways to do things than with methods. Simplifying the set of operations
would allow creating the previous graph in a simpler form: one graph
for LOAD and one graph for COMPILE, the former one being the one you
actually need because it lists what a running image needs -- compiled
files, documentation, etc.

> > * Simplify the way components are written, perhaps adding some
> > syntactic sugar.
> > * Create an API to load and traverse the set of systems and their
> > dependencies.
>
> This would be something useful standalone; coaxing a list of files out
> of ASDF can be an exercise in frustration.  Doubly so if you want
> system-relative names.

This is precisely what I meant and what jasper so clearly exposed:
ASDF is just a hidden database of dependencies. We only need to
provide a clean mean to expose those dependencies and make them as
simple and well specified as possible

> > * Replace the routine that drives ASDF, TRAVERSE, with something
> > everybody understands.
>
> Method combination would be a good start here.  TRAVERSE was written
> the way it was because of poor CLOS support from some implementations.

An even better version would not need methods at all! What makes
TRAVERSE so unpredictable is that class dependencies, method
specialization, :around, :after, and other apparent niceties can make
a developer blow everything up -- to name a few things, ASDF recently
changed the way it specializes some methods and it broke ECL's
extensions in various and really misterious ways.

OO is nice, but it is a distraction in this camp.

Juanjo
From: Jochen Schmidt on
On 2010-04-14 00:29:34 +0200, Juanjo said:

> That said, I have read XCVB's manual and I feel it introduces an
> unneeded level of complexity in it all. Parallel compilation is nice,
> but forcing the use of makefiles, permitting the developers to scatter
> the dependencies of their software over different files, and relying
> on external drivers, plus the size of the software itself -- ASDF
> could and should be so lean! --, does not really convince me.

That was also my feelings when I investigated it. I quickly came to the
conclusion "XCVB" must stand for "Xtra Complicated Variant of a
Buildsystem". Actually I think the idea behind XCVB is good, but I fear
that the majority of lisp projects do not face the complexities which
triggered it. More, I think a successor to what ASDF provides today
should really be as simple as possible. A separation of concerns would
certainly a step in the right direction.

A system in its minimal core doesn't need any inherent facilities to
build it or install it or package it - it should only be a
straightforward description which allows others to implement stuff like
building, installing and so on ON TOP of it. It should be readable by
lisp but NOT mandate a complete implementation of CL to interpret it.
It shouldn't even be mandatory to write system descriptions by hand -
there could easily be generators and IDE support to do this.

To me the most simple form of a system consists of a set of CL
components, their dependencies and the external dependencies to other
systems.

Jochen


--
Jochen Schmidt
CRISPYLOGICS
Uhlandstr. 9, 90408 Nuremberg

Fon +49 (0)911 517 999 82
Fax +49 (0)911 517 999 83

mailto:(format nil "~(~36r@~36r.~36r~)" 870180 1680085828711918828 16438)
http://www.crispylogics.com

From: o.jasper on
Note: in the linked lisp file, there are two mistakes in (def-a-
system :t..) (that is why it doesn't load)

You can do anything with dependencies with the given libs, including
calling different actions back and forth. Compiling/loading would be
something like this: http://www.ojasper.nl/src/lisp/dep/compiler.lisp
I guess one could even make a package to make loader/compilers with
this, showing the files in the correct order to some loader/compiler.

Note that my approach is from 'first principles'; being that if you
need to build something that depends on something, you need to get
what it depends on first. And that you might need to store stuff about
it during, like where you put the compiled result, whether it is
compiled, whether it is loaded.

Apply experience onto first principles. That is how physics works, the
first principles being postulates, and experiments and measurements
being 'experience'. Why? History is a cludge, but it is all the data
you have, however, first principles are simple! So find a way to
combine them. Somewhat like in the horses joke like here
http://www.silvers.org/GenEngineering.html (just a random link, those
jokes are repeated all over.)

I don't mean to imply any sort of dismissiveness of the data, Juanjo,
this really is something that needs attention, and it is good to have
a list of projects that misuse asd files. Not sure that i'd consider
two Defsystems in an asd file an error.(Well, seems like asdf doesn't
read in both, but hardly much of an issue in-principle if it would.) I
don't think regular users should be doing anything else but fill some
kind of Defsystem form, no defmethod-ing or anything like that.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: Is LISP divine?
Next: keywords & macros