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

[Doug Evans <dje@transmeta.com>]

Jim Blandy writes:
 > 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.

I can explain why things are the way they are today.
The powers that be can of course change things however they please.

I didn't (and still don't) want (arbitrary) Scheme in .cpu files.
Maybe CGEN will be written in multiple language some day
(once one has a .cpu database reader, the choice of language
for file generators and such is less important).
I'd hate to have to rewrite all the .cpu files, or maintain multiple
versions, or etc.; or implement all of Scheme just to read the .cpu file in.
I look at .cpu files as a description of the cpu, and I don't
want the reading of that description to be excessively complicated.

Another consequence in allowing arbitrary Scheme is that .cpu files
would become harder to read and maintain.

[
One can quibble of course over whether and how much of Scheme is
already in .cpu files :-).  I think there's even some places where
I provided too much of an escape hatch in order to get something done
(e.g. .eval).  But I think one would be hardpressed to argue
that using a different language would be no harder after N years of
allowing arbitrary Scheme to appear in .cpu files.  As things stand today,
reading the database is rather simple compared with being required
to understand all of Scheme.  I can even imagine having just one database
reader in C(/C++) and then having all generators use it, regardless
of language.

Of course, if one wants to stick with just Scheme then there is
less reason for not allowing it in .cpu files.
]

Having said that, I wouldn't switch from Scheme myself.
But the point is others can for a particular file generator
once the database reader is written.
I WOULD switch from Guile to something better.
One dream I have is to have a Scheme implementation that does dynamic
compilation using a framework built from CGEN.

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

IMO (and this is just my opinion) I'd rather restrict the description
of the cpu, and make it easier to use that description.

[Hmmm,
One could have a generator that read in a .cpu with arbitrary Scheme
and spit out a copy ready for consumption by a different language,
but it feels like the wrong way to go.]