|
From: Jörg F. W. <Joe...@so...> - 2013-11-27 10:21:26
|
Am 27.11.2013 02:28, schrieb David A. Wheeler: > I said: >>> At the least, I could put things in different files, and then use "cat" >>> to create files usable to different systems. > On Tue, 26 Nov 2013 14:47:36 +0100, "Jörg F. Wittenberger": >> Not too bad and idea. While it might not scale to whole programs, it's >> certainly a valid way to get things done for something the size of a >> srfi's implementation. > Right. This thing is small. > > I don't see anything good for trivial preprocessing: > * "scmxlate" appears too complex to get going. Probably. A few bullet point about my take on this. 1) Whatever we do here, it's not necessarily going to be used "for real" but merely to show how things would have to be processed in users build. 2) From (1) I conclude: the least amount of commonly available tools is the best. 3) When pre-processing LISP code, the best language for the job is actually LISP, since it has easily access to the structure of the code to be rewritten. Other languages are forced to go through axillary properties of the code. cpp, as you said, is a disaster for LISP and m4 is a disaster in itself. 4) Point (3) is mostly incompatible with (2). The only exception might be recent GNUmake. I did not yet have the time to check it out, but I read it would support guile. Maybe one could trick it into running a guile pre-process. 5) Coming back once more to my desire to have a Scheme reader which would allow to deliver a modified AST including comment nodes: such a beast could be used to write back-and-forth (round-trip-safe) code to code transformations. One could work with any flavor when porting to new implementations and easily roll the result back into the "generic" form. All this should need would be the generic base and a guile-as-in-gnumake specialized version. Let me add: I'm not entirely sold to (5) but I'd like to see how this would work in reality before I judge. > * "cpp" is a disaster for Lisp (it wants to parse '...' as character constants) > * "m4" is easy to get wrong, and has too much functionality. > > I think I could create a simple "#ifdef ... #elifdef... #else... #endif" > preprocessor in awk (which is in the POSIX standard) > that would do the job. If I dug deep enough into the code I ever wrote, I guess I could come back with at least two such things in K&R C. ;-) I'm not sure it's worth to write a special tool just for this special case. > Then the whole thing could be in one file, > and generate variations for different purposes. For those Schemes with > cond-expand, we could put them in one file, so we wouldn't have to > generate too many files. > > Since the single-file approach would still require some pre-processing, let me suggest yet another single file approach: "shar". A shell archive including several files a little sh-script to glue the pieces together. Still one file. ;-) Irony aside: any tool will do. Simplicity for the end user should be the trumping argument. |
