Thanks for sharing! It's been a while since I thought about this, but my conclusion a few years ago was that homoiconicity was an ill-posed idea. A language only really needs two properties to make macros convenient:
* I like symbols. Having symbols and strings in a Lisp doesn't seem any more weird than having variables and string literals in Algol or Java. Even if I _could_ use one in place of the other, it seems useful to separate symbols as part of the program from strings as part of the environment/domain/data model. You could implement one with the other, sure, but I wouldn't question anyone who chose not to. After all, every attempt I've seen to support spaces in symbols has been quite ugly.
* Your other points seem to be in the context of building tools like code formatters where the output will be seen by humans. That's not really the context for Lisp macros. I haven't really thought much about how useful they would be. Since I believe in macros, I can probably be persuaded. So that might be an interesting post to write. Why do you care about emitting exactly the code that was parsed? What new apps does it enable?
Are you aware of any languages that perfectly reproduce input layout? Even Go supports gofmt only by tightly constraining how programs "should" be indented, and only outputting that layout.
> Why do you care about emitting exactly the code that was parsed? What new apps does it enable?
Got a `gofmt` addiction, can't go back. Auto-formatting should ship with every language.
Briefly skimmed the Go implementation, and you seem to be right: it seems to lose whitespace and enforce its own formatting.
> Are you aware of any languages that perfectly reproduce input layout?
For now just my own.  The language isn't real yet, and might never be realized, but it has a base data notation (very Lisp-like), a parser, and I just started writing a formatter. Because the AST for the data notation preserves whitespace and comments, the formatter can print the code _exactly_ as is. This has interesting repercussions.
For a fully-implemented formatter for a fully-defined language, you wouldn't need whitespace; see Go. However, being able to print everything back means your formatter is usable from the start. It can support one or two simple rules, making only minor modifications, but you can use it on real code right away. Furthermore, this means we'll _always_ be able to choose which rules to enable or disable, which can be handy if the family of languages described in terms of this notation has different formatting preferences. I actually want the formatter shipped with the language, like `gofmt`, to be non-configurable, but this still seems like a useful quality.
Should clarify something (follow-up to previous reply, see below or above).
Most macros don't want to deal with whitespace and comments. We also might want to _not let_ them, otherwise people will start using comments as code, like in Ruby. Macros just want expressions. So, we would define a second level of the AST and perform a second pass.
For the same base notation, there may be multiple languages defined in terms of it. If such a language has any form of prefix or infix, or uses the `outside_parens()` calling convention, the second pass would have to group nodes into expressions, in ways specific to that language. Furthermore, it should be addled with metadata about packages, types, and so on. The resulting AST is compiled, fed to macros, etc.
Is it that you're trying to reduce stack juggling? That's hard to understand from simple examples (that you need to have to grok the syntax). Maybe compare something like finding the hypotenuse of a right triangle given the two other sides. Without naming arguments, you'd have to do something like:
hypot = dup * swap dup * + sqrt
But with named arguments:
hypot x y = x x * y y * + sqrt
That seems a little easier to read, but even the original isn't so complicated. Is there an example that makes it more obvious why it's better? Even your `square` example is more tokens than with stack juggling (without arguments, `square = dup *` is just four tokens, compared to six with named arguments). I'd say the with-arguments one is easier to read, but I've far less familiar with stack-based postfix programming.
Yeah, some other polynomial might be a better example. The Pythagorean formula has a clean separation when it comes to which args each term uses. How about the roots of a quadratic equation when you start out with a, b and c on the stack?
You're right that in general any such example can be refactored to reduce stack operations. That's even a fun game for many Forth programmers to play. (We lispers have our own equivalents.) But it usually makes the code less comprehensible, in my experience.
I spend all my time with Arc working on the forum, so JSON is more important to me than it might be to someone else who primarily focuses on the language.
I was working on the data export feature, which before just dumped a user's posts and comments as a printed statement, but I wanted it to export JSON because that's more portable. Racket has a really nice JSON parser, unfortunately all the forum data is templated, so I can't just pass it to Racket because it doesn't understand the type. There may be a way to get it to work at that level but I don't know what it is.
So I had to get an old JSON parser for Arc and rewrite a bit of it to be able to generate JSON from forum data. I think it was zck's parser but I'm not entirely sure ATM. It works, but it's an awkward workaround. Any data coming from the forum has to go through one parser, and any other data, such as from a remote API would be going through another (Racket's.)
>Is making it work just a matter of calling the Racket primitive on `rep.template` instead of `template`?
Yes, I had to hunt around to even know that existed, because it's not in the docs.
You can get to it from the "Type operations" link in the table of contents. Of course, you might've been drawn to the "Templates" page instead.
And unfortunately, that documentation describes Anarki's stable branch. Making documentation of similar quality for Anarki's master branch might be quite a bit more work. So even if you were familiar with tagged types already, the knowledge that template instances were a tagged type on Anarki master might be hard to discover.
I suppose a more ideal form of the documentation would describe on the "Templates" page that template instances were a tagged type with a certain representation. It could describe the direct implications of that, but it would also have a link to the "Type operations" page for more background.
>I suppose a more ideal form of the documentation would describe on the "Templates" page that template instances were a tagged type with a certain representation. It could describe the direct implications of that, but it would also have a link to the "Type operations" page for more background.
That would have been tremendously helpful, can we do that? Who actually maintains the documentation, can it be updated?
Perhaps we should maintain the docs only in plain-text and only within the repo, just because of the operational overheads of managing multiple branches. At least that way they won't seem to lie to a newcomer. I'm curious to hear what others think.