Am So., 13. Nov. 2022 um 00:14 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > So are you looking for some ML dialect with parentheses? This is a
> > serious question. I wonder how much such a Scheme would differ from
> > ML.
>
> Yes, I'd like to make one (unless someone beats me to it). Specifically,
> I'm interested in something that can be translated easily into the
> existing ML family languages, to make use of their toolchains. (There
> are non-trivial differences in the type systems between ML family
> members too, so it's not clear how comprehensively this can be done.)

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.

> I expect other people to want other things; schemers will never agree on
> the right kind of type system (no pun intended). And implementations
> like Kawa and IronScheme are probably constrained (in practice, if not
> in theory) by their host platform.
>
> Racket is years ahead of us on all this stuff, and Typed Racket should
> probably be considered one valid type system for Scheme. But it's not
> clear to me that their answer is optimal; there are tradeoffs. Matthew
> Flatt implemented Plait (https://github.com/mflatt/plait), which is a ML
> style design for teaching. That's a pretty obvious starting point.
>
> I'm also trying to understand Koka's
> (https://koka-lang.github.io/koka/doc/book.html) combined type and
> effect system, which is noted for its uniformity and powers of
> inference. I bet we'd learn a lot if we tried to write Koka signatures
> for standard Scheme procedures.

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?

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.

> One obvious question is whether macros should be statically or
> dynamically typed. I don't find this very interesting, as I expect
> either approach to work well. PreScheme uses dynamic Scheme for macros.

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