Extending a Language – Writing Powerful Macros in Scheme | Hacker News Reader

Extending a Language – Writing Powerful Macros in Scheme

mnieper.github.io

92 pointstextread5 comments

https://github.com/rogerturner/scheme-macros/blob/main/examp... shows stepwise development of a trace-let [the `(example: (fn arg) => result)` forms are tests - see check-examples library]

A few formatting changes might make this advanced example easier to understand:

    (define-syntax trace-let
      (syntax-rules ()
        [(trace-let name ([var expr] ...) body1 ... body2)
         (let f ([depth 0] [var expr] ...)
           (define name
             (lambda (var ...)
               (f (+ depth 1) var ...)))
           (indent depth)
           (display "(")
           (display 'name)
           (begin
             (display " ")
             (display var))
           ...
           (display ")")
           (newline)
           (call-with-values
               (lambda ()
                 body1 ... body2)
             (lambda val*
               (indent depth)
               (fold-left
                (lambda (sep val)
                  (display sep)
                  (display val)
                  " ")
                "" val*)
               (newline)
               (apply values val*))))]))

The biggest one is to make the rule template pattern variables all-uppercase. I also made a few other tweaks, including using indentation a little more, and naming the named-`let` variable as "loop" (I usually name it `loop` or prefix the name with `loop-` if there's more than one):

    (define-syntax trace-let
      (syntax-rules ()
        ((trace-let NAME ((VAR EXPR) ...) BODY1 ... BODY2)
         (let loop ((depth 0)
                    (VAR   EXPR) ...)
           (define NAME
             (lambda (VAR ...)
               (loop (+ depth 1) VAR ...)))
           (indent depth)
           (display "(")
           (display (quote NAME))
           (begin (display " ")
                  (display VAR)) ...
           (display ")")
           (newline)
           (call-with-values (lambda ()
                               BODY1 ... BODY2)
             (lambda val*
               (indent depth)
               (fold-left (lambda (sep val)
                            (display sep)
                            (display val)
                            " ")
                          ""
                          val*)
               (newline)
               (apply values val*)))))))

Incidentally, all-uppercase Scheme pattern variables is one of the all-time best uses of all-uppercase in any language. Second only to all-uppercase for the C preprocessor, where a preprocessor macro can introduce almost arbitrary text. Using all-uppercase for constants in some language that has constants, however, is an abomination.

(My suspicion of why Java did all-caps is that they were developing a language for embedded systems developers who were currently using C and C++, and they wanted to make it superficially look similar, even though it was an entirely different language. And then, ironically, the language ended up being used mostly by the analogue of a very different developer of the time: corporate internal information systems developers, who, as a field, didn't use anything like C. It's too late to save Java, but to all other language and API developers, please stop the insanity of all-caps constants, enum values, etc. It's not the most important thing that needs to jump out from the code above all other things.)

FWIW, all-caps makes this look much worse to me. I understand that people like things like Hungarian notation, arrows over vector names, and shouting Common Lisp symbols. I understand the argument that it can make reading easier. I just can't appreciate that benefit, and it seems to me an ugly hack which obscures the abstract and general symbolic manipulation going on.

This is all highly subjective of course, de gustibus non disputandem.

You mean aesthetically, in that interspersed all-caps makes the code visually less soothingly sensual?

I can sympathize, but let me make a non-aesthetic argument...

In large blocks of code, with all-caps, you can see at a glance where all the template substitutions are happening, and also instantly know as you're reading code what are variables and what are template substitutions?

I'm asking because one of my realizations in recent years is that not everyone reads or sees code the same way.

For example, maybe some people are stronger "visual" and some people are stronger "verbal".

For another example of a different in how people perceive and think, some people can visualize an object in their mind almost as if they're looking at it, but other people can only know and describe what it looks like without bringing a visual of it into their head.

With the benefit of the all-caps, I can glance at this and immediately see much of the structure of the template. Without all-caps, I'd have to work harder to find all the pattern variables, and the structure would be obscured.

For a bit kludgy practical matter, as I'm quickly looking at pieces of code in a template, with all-caps, I can look at a fragment of code in isolation and know what are and aren't pattern variables. Without that, I have to go read the top of the template clause (and read through any syntactic scopes of `let-syntax`) and get that in my head, until I get to the fragment of code I originally wanted to look at.

IDE support can make this unnecessary, with a hypothetical great IDE, with familiar syntax coloring. But still, if there is one thing that all-caps should be reserved for, it's something like this.

With all-caps, your code can be sensual, and the jolting all-caps bits are look out, potentially arbitrary code gets pasted into here.

Since you asked, my objection is both aesthetic and semantic, though I was really referring to the semantic part above.

I think you've hit the nail on the head with this visual vs. verbal distinction.

I can add a few clarifying details. I don't use IDEs as much as basic text editors maybe with highlighting, and I try not to rely on any fancy features. It does worry me that the allcaps use you describe is (afaik) not known to the editor or interpreter, so if you make a mistake or the symbol gets out of sync with its meaning (re: pattern variables) you may have a false signal. Finally I'll say that in the end I can't suggest a good way to treat these special variables, and so maybe I don't get it, or tastes like mine would be better served by a different formalism for macros.

Reply on news.ycombinator.com