Re: [Pika-dev] xl, xxl, and mxl

[Jose A. Ortega Ruiz]

Jeremy Shaw <address@hidden> writes:

> I do not mean to say that make is free of those problems, just that is
> should be :) On the other hand, make does do better in those two areas
> than some other langages.
>

yes, but other languages, and scheme in particular, let you create a
DSL aimed at dependency handling and free from those problems as well
(in the same degree that make is, or even better -- more on this below).

> In make there is pretty much just one type, 'lists of strings', so,
> not much can go wrong in terms of type errors. And make tries to be
> smart about detecting non-termination.
>

on the contrary, everything can go wrong in terms of type errors and
you don't even have a warning! think for instance of a function
taking a list of integers: you have no simple way of coding this in
Make in a type-safe manner; not to mention the inability to cope with
more complex data types like records.

> [makefile examples that show how make detects circular dependencies
> skipped...]

that's nice of Make; but of course, the core of Conjure will be a
dependency resolution engine with the same capability: i'll be using
Scheme to provide a DSL (domain-specific language), which, after all,
is what Make is (although it has many limitations in this respect).

>
> Writing a non-terminating program in most languages is trivial. Indeed
> so trivial you might do it by accident. If make did not allow you to
> call out to the shell (which would also make it pretty useless), I am
> not sure that you could write a non-terminating makefile.
>

maybe. i'm not sure, either. but, as you say, pure Make is useless.
with Conjure, we'll be able to provide additional building primitives
in the form of reusable libraries that are free from similar drawbacks
to begin with (think, again, of a DSL for building C executables and
libraries, another one for creating LaTeX documents, and so on and so
forth). 

> xl has the same property, there are no built-in language features that
> will allow you to express non-terminating programs. One natural side
> effect of this is most type errors can be statically detected. Another
> natural side effect of xl's design is that it is very easy to run an
> xl program on a parallel processor or distributed system, aka, do a
> make -j4.
>

i'm not sure i fully understand the link between non-termination and
type safety. anyway, the point is again that xl alone woulb be useless
for building, say, a program. you will have to rely on external tools
(the shell?) to do the job, and all the safety goes away. with scheme,
you can provide a dependency resolution engine with the right
properties and, in addition, abstractions for doing the actual job
without leaving Scheme. of course, if you're sloppy when creating
those add-ons, problems will follow, but at least you have more
chances of doing it right. yeah, you can write shell scripts that
behave correctly too, but Scheme is a much more powerful and safe
language in every respect.

> I guess I would be interesting in seeing more information on *why* you
> think make needs to be replaced. What do you hope to achive that can
> not be done by improving the existing make (ie, in what ways is make
> fundamentally broken)? I think there are some pretty good arguments
> for why make is fundamentally broken, but seeing what you feel is
> wrong would help me understand where you hope to go with conjure.
>

well, i'm not sure if i really think that make is 'fundamentally
broken', but i want, in no particular order and among other things,:

- A cleaner, simpler syntax (no initial tabs or cryptic command
  prefixes):

   (rule target (dep0 dep1) make-target)
   (rule target0 (target dep2) (prepare make-target0))

- yet fully generalizable:

   (rule target calculate-deps make-target check-staleness)

   where CALCULATE-DEPS is a user-provided or predefined (in a
   suitable library) procedure computing TARGET's dependencies, and
   CHECK-STALENESS is a predicate checking whether TARGET needs
   update: not only timestamp based checks.

- A Conjure specification can be purely _declarative_, with the use of
  provided or third-party libraries:

    (c-library-rule libfoo (src foo.c bar.c) (flags -O3 -g))

- ... with reusability, modularity and composition :

    (with-build-dir ./build
      (c-library-rule libfoo (src foo.c bar.c) (flags -O3 -g)))

- Solving the issues raised by recursion over directories.

- (Dynamic) Type-safe procedural and data abstraction, that allows
  reusable extensions by power users.

- Direct manipulation of the dependency tree; for instance, to alter
  its traversal order according to need. in Make it's fixed. consider
  this tree:
   
                    A
                  / | \
                B   U   C
              /   \ | /   \
            D       T      E
           / \
          F   G

   When building A, i'd like to choose the order in which the leaves
   F, G, T and E are visited, and how many times T is visited (iianm,
   Make visits it only once), and so on and so forth.

- ...

in short, i want _abstraction_. and Make users need it, too. the
'solution' is automake/m4, but it relies again on shell programming,
substituion macros and cumbersome, ugly, low-level syntax/semantics,
and by no means easy to (re)use. i also want the ability of letting
the user to stay at the correct level of abstraction (i.e., most of
the time, using Conjure as a declarative DSL). other languages can
provide the extensibility, modularity, data abstraction power and
flexibility i seek, and projects like CONS (Perl) and SCONS (Python)
are somehow in the line of Conjure. what Scheme brings to the picture
is it's extremely simple and _extensible_ syntax, which makes feasible
its use by non-programmers (in much the same way you can use Ant
without programming in java, provided you can tolerate XML (i barely
can)). 

most, if not all, of the above can be accomplished with make with the
appropriate degree of kludgeness, and this i why i say i'm not sure
Make is 'fundamentally broken': i would be *very* interested in hearing
your reasons for thinking so.

thanks for your feedback,
jao
-- 
A man should never be ashamed to own he has been in the wrong, which is but
saying, in other words, that he is wiser today than he was yesterday.
-Alexander Pope, poet (1688-1744)

pgpvlkwrethjB.pgp
Description: PGP signature