Am Fr., 29. Mai 2020 um 19:59 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> However, there's a minor pitfall in assuming that there can be a clean
> separation between data that cannot be ignored, and metadata that can.

There is at least one clear separation. If you have a documented file
format and want to add extra information that has no place in the file
format as documented, it has to be meta-information in the sense
above. For example, given whatever data format in s-expressions, you
can't simply insert new s-expressions and hope that the data format
would still work. You would have to create a new data format first.
The same goes for Scheme source files. Think of the C preprocessor
directives "#file" and "#line". You may want to add such information
to a Scheme program but on the level of individual Scheme datums. You
cannot do this by adding macros that are "no-op"s because macros
cannot be placed everywhere. What you can do is placing the
information in comments, and in any case, we are talking about
metadata here.

> That's why I would advocate having just one layer of data and coining
> new macros. The macros can be no-ops at first so the data is ignored. If
> it turns out later that parts of it shouldn't be ignored by Scheme, then
> the macro definition can adapt.

In general, I would call this macro misuse. But even if you want to go
this route, you cannot place macros everywhere. For example, in
library definitions, there is generally no place for macros. Every
data file, which is not a Scheme program, does not even have the
concept of macro.