The Excellent Schemer

Good artists copy, great ones steal...

Microsoft has always been as brazen as it is effective at this sort of thing.

The scheme in question is IronScheme. Bob wrote the office integration. Leppie wrote the rest.

The article is following the predominant formatting method for Lisp dialects. What you propose is not unheard of, even in professional code bases, but very rare.

In the predominant style, nobody worries about which specific closing parenthesis goes with which opening one. The indentation reveals the subordination structure, and the editor takes care of that.

Speaking of indentation, you have it wrong: the sqrt should be indented inside the let.

    (lambda (x y)
      (let ((xs (* x x))
            (ys (* y y)))
        (sqrt (+ xs ys))))
                      ^^^^

At the ^^^^ spot, all that matters is that we have four closing parentheses. They are all the same otherwise. Which specific one closes the let is not informative.

There are too many parentheses to be focused on them; you have to learn mostly not to see them, except within a line of code where there is no indentation. Someone who has been working with the language for a while just "sees" this:

    lambda (x y)
      let (xs (* x x))
          (ys (* y y))
        sqrt (+ xs ys)

Or maybe even this:

    lambda (x y)
      let xs (* x x)
          ys (* y y)
        sqrt (+ xs ys)

(The question of "why not make that the syntax" has been thoroughly explored; it exists out there in some forms, along with other proposals for alternative Lisp syntaxes. https://srfi.schemers.org/srfi-110/srfi-110.html )

1. Values (objects) in Scheme are tagged, carrying the type with them. And no, a variable, the identifier that names a location which stores a value isn't statically typed. From R6RS:

https://docs.racket-lang.org/r6rs/r6rs-std/r6rs-Z-H-4.html#n...

> Scheme has latent as opposed to manifest types. Types are associated with objects (also called values) rather than with variables. (Some authors refer to languages with latent types as untyped, weakly typed or dynamically typed languages.) Other languages with latent types are Python, Ruby, Smalltalk, and other dialects of Lisp. Languages with manifest types (sometimes referred to as strongly typed or statically typed languages) include Algol 60, C, C#, Java, Haskell, and ML.

The Scheme standards are very concise and readable.

2. Sometimes we Schemers will leave an orphan paren, like if we want to leave a place temporarily for new code. The primary benefit of all on the same line, IMO, is it is more compact vertically and most Lisp programmers rely on paren matching anyway. If you program in Scheme long enough, you can just "see" the level of nesting by the apparent contour of parenthesis. (If you don't understand this, that's probably a good thing.)

When trained to read Lisp, the human reader concentrates on indentation, code shape and the leading symbols. The leading symbols determine the syntax of the expression.

LAMBDA = lambda (args) body

LET = let (bindings) body

binding = (var [value]) | var

actually the syntax is quite a bit more complex, since args have a lot of options and both LET & LAMBDA allow type declarations.

Each of the symbols also determine a certain indentation style and code shape. There are built-in operators, macro operators and function calls. Especially macros provide an unbound amount of syntactic possibilities.

Trying to figure out expressions by looking at parentheses and finding pairs by parenthesis alignment is mostly not used. It's a too complex visual operation.

the overwhelming convention in Lisp (both Scheme and Common Lisp) seems to be to never have a closing paren by itself. I'm not sure why, but I also prefer it that way. Most editors like emacs and modern IDEs also highlight matching parens, so usually this is not really an issue.

If they are willing to provide good support, then the $99 is well worth it.

Thanks that looks really good. I don't use .Net platform, so I am not a potential user, but for Lispers using the .Net platform, this would be nice.

I use Common Lisp a lot in my work and my own research programming, and language interop is always a nuisance. With IronScheme, it looks like interop with all .Net languages is easy.

Both are R6RS, by the way.