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

Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
Readable-discuss mailing list

Reply via email to