> What would be the advantage of such a Scheme vs. ML? One could ask why
> to take the trouble to invent a Scheme with HM-static typing when one
> could use ML instead.

Macros, and S-expressions generally.

The topic deserves an essay titled "Taking S-expressions seriously". But
writing it now would be more shouting into the void.

The most urgent problem concerning the field of programming languages as
a whole is that people "could use" a wide range of languages, so they
do. There is a huge number of language pairings, and it's rare for any
pair to have good interop. Code sharing between pairings is almost
non-existent, for no reason at all.

A language, as we now know it, is an agglomeration of features, many of
them orthogonal. In the future - if our field has any sense in it -
"languages" won't exist, except as conventions. We'll have a universal
language-building toolkit -  a big web of precisely defined features
whose interactions are fully mapped out with the same precision. Subsets
of this toolkit are supported by each compiler and VM (the bigger ones
supporting a bigger subset) and the conventions now known as "languages"
are built from the toolkit like themes, or like buildings made out of
pre-fabricated elements.

The most productive way we can spend our time in Scheme is to do our
part to push the field toward this inevitability, which baffles people
now, will arouse contempt and sneering while it's being built, but will
be taken for granted once it arrives.

The way to kick things off is to look for neighboring languages - those
that are most like Scheme. That's the Lisp and ML families. We should
eventually create a spec, that has precision similar to RnRS and the SML
spec, containing all substantial features of every language in the Lisp
and ML families. Then create definitions of the existing languages (or
something close enough to be easily compatible with existing practical
codebases) by expressing them in terms of the big spec.

> When we talked about the "Steme" project, we discussed Koka-like
> semantics and type systems (and I implemented some bits and pieces).
> So are we basically back to the Steme endeavor?

You're thinking in terms of specific artifacts. What matters to me is
the general direction. People should do whatever projects they are
interested in, going in this direction, and whenever there is common
ground between two projects it should be extracted. Once you extract
enough things, you get the big spec. The precise path we take there
doesn't matter. I stopped caring about individual languages years ago,
and only work on them as vehicles for going toward this vision. As
explained in the opening post of this email thread, Scheme is the best
vehicle, so I mostly work on it.

> As others said before, a type system with automatic type inference is
> necessarily not rich enough to represent the actual types used in
> ordinary Scheme, especially the standard procedures.  So either you
> have to limit what is expressible with "static Scheme" or your type
> signatures will only be very rough approximations to the actual types.

I think the useful properties of static typing come from restrictions. I
expect most ML and Haskell programmers to agree, and most lispers to
disagree.

> Do you mean you want the macro transformer procedures to be written in
> dynamic Scheme? Why this split?

Because we already have dynamic Scheme, it could be used as-is.

Ultimately the big toolkit will have both static and dynamic macro
systems - it's inevitable that people will show up who want one or the
other. I don't care which step on the way there will have which kind of
system.