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)
|
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.