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

[Jeremy Shaw]

> 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)). 

Thanks for the detailed information, I think I now understand what you
are trying to do.

How easy will it be to cross the boundry between the DSL and scheme?
For example, in this fragment:

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

Would I be able to replace (src foo.c bar.c) with an arbitrary scheme
expression that generated (src foo.c bar.c) ? Or would I be limited
the primatives defined in the DSL ?

> 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.

I am not entirely certain that make is fundamentally broken. However,
if I fixed all the 'problems' I had with it, it is not clear that it
would still be make. It is a bit like the question, "If I replace the
brush on my broom, and then later I replace the handle, do I still
have the same broom I started with?".

Largely, I have the exact some problems with make that you addressed.

The things I specifically have issue with are:

(1) doing macro/template type stuff requires the use of a third party
    macro language (m4/cpp/etc), which has different syntax, etc.

(2) The use of whitespace seperated lists and no escaping mechanism
    makes working with filenames that contains spaces very annoying.

(3) The lack of safety features: 

    (a) very weak type system (everything is a string or list of
    strings) does not allow you to say what you mean very accurately.

    (b) no way to check for use of unitialized variables (important
    for catching typos, and other common problems).

I think that many of the problems with make can be fixed, but doing so
might break forwards and backwards compatability. This could perhaps
be dealt with to some degree by using some sort of pragmas to enable
newer features. So maybe I could add:

#pragma escaping

To enable the escaping syntax, and 

#pragma unitialized

To check for uses of uninitialized variables.

If I really wanted a better make, I think I would probably explore the
possibilty of fixing the existing make before attempting to write a
competing product.

The reason I am interested in writing a make-like program in xl is
more for the purpose of exploring the xl design space. If we can write
a 'better make' based on xl, then that is emperical data showing that
xl can be used to express useful programs. If we run into
unsurmountable obsticles, then it may mean that xl has some design
flaws that need to be addressed.

In any case, I think your DSL and xl could have a lot in common, so it
should be interesting to see the results of making different choices
along the way.

Jeremy Shaw.