Re: Text substitution macros and multi-file archives Lassi Kortela 28 Jun 2021 08:38 UTC
> I think you are missing the point. There is no universal s-expression > format. A priori, you just have text, which you have to interpret. > Different Scheme implementations use different formats (e.g. for > bytevector literals in R6RS and R7RS; other Schemes may have more > complex reader macros, etc.). Of course. The key is to decide what level of compatibility to go for, and then write the code in the common subset of those standards / implementations. Increasing portability usually adds some pain. cond-expand adds pain, and a lexical-syntax-cond-expand would add even more pain. If the latter is desired, it would be better to standardize in the language than in a bundle file format, but I think it's overengineering. > There is a distinction to be made between the representation and the > actual structure. > > The crucial principle is that a program should never try to parse > another program's representation for data. This principle is much more > important than any aesthetic considerations. It forbids that a script > consists *solely* of s-expressions. I find the aesthetic consideration much more important. Aesthetic mistakes cannot be rectified later; it puts the "ecosystem" on a downward spiral of getting more and more messy over the years. In the case of embedding (declare-file ...) in Scheme or Lisp syntax, we don't parse another program's representation; instead, the script writer promises to use a syntax (in the relevant part of the file) that is compatible with both the target Lisp standards/implementations, as well as the (declare-file ...) spec which specifies its own lenient version of S-expressions. Note that you need to do the same with magic comments and the like. You could specify that the launcher always rewrites the file, removing the (declare-file ...), but that adds the complexity of temp files, messes up line numbers in stack traces, etc. Nothing is gained.