Re: [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input

["Jim Blandy" <jimb@red-bean.com>]

On 5/11/06, Dave Brolley <brolley@redhat.com> wrote:
> Thien-Thi Nguyen wrote:
>
> >why not allow computed `include' instead?  (perhaps that is already
> >supported?)  something like:
> >
> >(include EXPR)
> >
> >then EXPR can be all manner of `if', `cond' or whatever.  e.g.:
> >
> >(include (if (application-is? SID-SIMULATOR)
> >             "sid-macros.cpu"
> >             "sim-macros.cpu"))
> >
> >(include (cond ((application-is? SID-SIMULATOR)
> >                "sid-macros.cpu")
> >               (else "sim-macros.cpu")))
> >
> >(include (case (application->symbol APPLICATION-OBJECT)
> >           ((SIMULATOR) "sid-macros.cpu")
> >           (else "sid-macros.cpu")))
> >
> >
> >
> The point isn't really the (include "..."). That's just what I happened
> to use the 'if' capability for. The true and false expressions could
> theoretically be any valid top level CGEN construct. Implementing
> conditional capability for them all seems like a lot more work for no
> gain and may not even make sense in some cases. Also 'cond' or 'case'
> could easily be added as top level tests if necessary.

The larger question is, why aren't CGEN machine description files just
arbitrary Scheme code that happens to call some functions to register
machine description pieces?  Then you'd have the full Scheme language
at your disposal, not just pmacros.

None of this would complicate the interesting parts of CGEN --- the
code for producing encoders, decoders, and simulators.  They would
operate on the same data structures they do now.  You'd just have a
lot more flexibility in how those structures are produced.