Re: [jamboost] Eureka?

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-17 11:37:50

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

> The top-level operation we've been discussing is "given a certain target
type
> and a list of sources, compute a sequence of transformations". This is
what I
> mean by "tries to match". In other words, when WD->WHL,DLP transformation
has
> been selected by seach from WHL, we suddenly realize that there's DLP file
> and have no better option that to treat that file as if it were yet
another
> source.

So, exactly what happens? Since there may be several recursive searches
active, how do you know which search to serve?

IOW (unrealistic example):

EXE
/|\
/ | \
OBJ<OBJ>LIB
...: / \
: / \
: <OBJ> OBJ
?: :? |
:...: CPP
: |
DLP WHL
\ /
\ /
WD

> > Also, does it handle the case where WHL->LEX->CPP and DLP->CPP?
> Yes. After arriving at CPP type, there are two alternatives:
> 1. LEX->CPP is selected, WHL->LEX is selected, WD->{WHL,DLP} is selected
and
> DLP file appears, then OBJ->CPP, DLP->CPP transformations are added.

I suppose you mean CPP->OBJ. Maybe we should always use left-pointing arrows
as long as we're traversing top-down. Since we have left-to-right writing it
will be less confusing:

OBJ<-CPP, CPP<-DLP, {WHL,DLP}<-WD

> 2. DLP->CPP is selected, WD->{WHL,DLP} is selected and WHL file appears,

I think at this stage, on the way down, we're exploring. We only select
transformations on the way up. Right?

> the OBJ->CPP, LEX->CPP, WHL->LEX transformation are added.
>
> Since the list of transformations is the same in both cases, we'll know
> there's no ambiguity. (Acually, we'd need to gather the list of
> (transformation, source files) pairs, but that's the same).

That still sounds complicated, but let me try to get my head around it.
You are suggesting that, whenever a search is performed and two generators
hand back an equal number of intermediate targets, we check to see if it's
really the same path. If so, we just pick one of them?

Let me propose a modification: When returning its list of targets, a
generator distinguishes the intermediate from final targets somehow. When an
intemediate generator produces multiple targets, its parent transforms the
targets it can cope with, and passes back any others to its parent as final
targets. A multi-source generator like EXE<-{OBJ,LIB} will add any final
targets that it can't cope with to its sources at that point in its list of
sources.

[Questionable idea: If it can't generate a transformation sequence, they are
passed up the chain as final targets again]

In the case of EXE<-OBJ*, OBJ<-CPP, CPP<-LEX, LEX<-WHL, {WHL,DLP}<-WD,
when we arrive here----------------------------------^
as we're unwinding, we find that the generator can't cope with DLP, so with
final targets enclosed in {}:

EXE<-OBJ*, OBJ<-CPP, CPP<-LEX, {LEX,DLP}<-WHL
EXE<-OBJ*, OBJ<-CPP, {CPP,DLP}<-LEX,
EXE<-OBJ*, {OBJ,DLP}<-CPP

Now find that OBJ* doesn't match DLP, so we search for DLP just like a
source.

> > Finally, does it force the products of wd to be handled as a unit?
>
> I don't think so. If something like
>
> generate a_lexer.lex : a.wd ;
>
> is given (meaning create the target of type determined by extension from
> source), then after selecting WD->{WHL,DLP} transformation, there will be
no
> transformation sequence using the other generated file, so DLP file will
be
> generated, but will remain unused.

...which fits with my proposed modification. This tells me that it should
not be an error to for generators to produce unrequested target types
(obviously).

I like this.

> > > Selection rules are almost the same as you've proposed, and the only
> > > non-trivial thing is finding equivalent alternatives, which is quite
easy
> > > once the list of all intermidiate transformation is collected.
> >
> > What do you mean by "finding equivalent alternatives"? Please spell it
out
> > for me.
>
> This is the case when at some point you can run either of two generators,
but
> each one, if selected, will result in the same list of transformations.

I hope that my proposal gets us out of having to explore two paths and
determine equivalence. That sounds sticky to me.

> > > And then... hope we'll start writing something!
> >
> > HERE HERE!
>
> Okay, would you mind my experimenting with project declaration syntax?
I've
> made some attempts in that direction already and there unlikely to be any
> major problems.

Not at all; please go ahead.

-Dave