Email list hosting service & mailing list manager

Type strategy for Scheme Lassi Kortela (09 Nov 2022 22:54 UTC)
Re: Type strategy for Scheme Marc Nieper-Wißkirchen (10 Nov 2022 07:07 UTC)
Re: Type strategy for Scheme Marc Nieper-Wißkirchen (10 Nov 2022 07:42 UTC)
Re: Type strategy for Scheme Peter Bex (10 Nov 2022 08:05 UTC)
Re: Type strategy for Scheme Philip McGrath (10 Nov 2022 08:54 UTC)
Re: Type strategy for Scheme Lassi Kortela (10 Nov 2022 09:49 UTC)
Re: Type strategy for Scheme Lassi Kortela (10 Nov 2022 09:08 UTC)
Re: Type strategy for Scheme Marc Feeley (10 Nov 2022 23:34 UTC)
Re: Type strategy for Scheme Lassi Kortela (11 Nov 2022 19:17 UTC)
Re: Type strategy for Scheme Marc Feeley (11 Nov 2022 21:34 UTC)
Re: Type strategy for Scheme Lassi Kortela (12 Nov 2022 21:58 UTC)
Re: Type strategy for Scheme Marc Nieper-Wißkirchen (12 Nov 2022 22:52 UTC)
Re: Type strategy for Scheme Lassi Kortela (12 Nov 2022 23:14 UTC)
Re: Type strategy for Scheme Marc Nieper-Wißkirchen (13 Nov 2022 09:41 UTC)
Re: Type strategy for Scheme Lassi Kortela (13 Nov 2022 11:59 UTC)
Re: Type strategy for Scheme John Cowan (13 Nov 2022 19:52 UTC)
Re: Type strategy for Scheme Lassi Kortela (13 Nov 2022 20:22 UTC)
Re: Type strategy for Scheme Marc Nieper-Wißkirchen (13 Nov 2022 20:35 UTC)
Re: Type strategy for Scheme Lassi Kortela (13 Nov 2022 21:41 UTC)
Re: Type strategy for Scheme Marc Feeley (14 Nov 2022 00:03 UTC)
Re: Type strategy for Scheme Lassi Kortela (14 Nov 2022 09:36 UTC)
Re: Type strategy for Scheme Marc Feeley (14 Nov 2022 16:27 UTC)
Re: Type strategy for Scheme Lassi Kortela (14 Nov 2022 19:58 UTC)
Re: Type strategy for Scheme John Cowan (13 Nov 2022 20:40 UTC)
Re: Type strategy for Scheme Marc Nieper-Wißkirchen (13 Nov 2022 20:42 UTC)
Re: Type strategy for Scheme Panicz Maciej Godek (20 Nov 2022 21:59 UTC)
Re: Type strategy for Scheme Per Bothner (20 Nov 2022 22:58 UTC)

Re: Type strategy for Scheme Lassi Kortela 13 Nov 2022 21:41 UTC

Marc:
> I think the point is that you already get a mess with programming
> languages even when you only throw together closely related languages.
> For example, take Scheme and add all the things people like about CL
> and that are perceived not to be in Scheme.  You'll end up with
> something I would call a mess.  When you try to clean up the mess,
> chances are that you end up with either Scheme or CL.
>
> Don´t get me wrong; I like the idea of a statically typed language
> that is interoperable with Scheme.  I can't imagine the idea of a
> catch-all language.  Actually, I think it is good if language
> differences are not blurred.  This helps select the correct language
> for the job (and for one's preferences) and makes it easier to
> understand a particular language's model and scope.

John:
>     For some reason people tend to start thinking from the language and say,
>     "what kinds of problems can this solve?" Try starting from the problems
>     and asking "what language features does this problem need?"
>
> That's how you get to PL/I, Algol 68, or (most especially) C++.  It is the very inverse of Scheme.

I can't understand why people don't see what I'm saying.

You're still thinking in terms of separate languages. The point is to
think of individual features and how they fit together. There should be
one unified semantic model into which all the features fit.

Features are, broadly speaking:

- execution model / control flow
- data types
- libraries
- syntax
- nomenclature

There's tons of orthogonality both between and within these sets.

Not every feature fits with every other (semantically) but generally
features can coexist. The result may not be aesthetically pretty but
that's a concern on a different level. The aesthetics should be done by
a different group of people than the semantics (or same people wearing
different hat).

A multi-language virtual machine, for example, would be based on the
features in the model. A "Java virtual machine" doesn't make sense,
conceptually. Why put so much effort into something that only runs one
language? It does now run many languages, of course. But it's all an
inelegant and inefficient mess due to lack of a common semantic model.
GraalVM is now a "universal" VM for which they implement languages using
Java. That has to be an elaborate practical joke.

Machine translation of computer code is intractable without the model, etc.