Re: [jamboost] Eureka?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-18 07:18:20

David Abrahams wrote:

> 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

I'm not sure. I would propose that we should attempt to convert DLP to the 
top-level target. The scheme below does otherwise. I don't have a strong 
opinion, and this case is not likely to be practically important.

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

Agreed.

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

Yes. I was talking about what will be selected on the way up.

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

Yes.

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

I like this.

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

I find it quite OK: something is created along the way, and there's no way to 
avoid creating it. Then it's reasonable to have that something among the list 
of final targets.

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

Exactly.

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

Me too.

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

I start to understand! We'll be in no need of comparing transformations list, 
but will look on target as is already proposed. I agree, then.

BTW, does "sticky" in this context means "disagreeable"? :-)

- Volodya