> On Nov 13, 2022, at 4:41 PM, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> 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.

The thing is that “static typing” is not a “feature” that is orthogonal to other features.  When static typing is added to an otherwise dynamically typed language it “cripples” the language… some things can’t be expressed anymore because they violate the rules of the typing discipline (mind you it cripples the expressiveness but does give some nice properties in return, so it is not black and white).  For example, the Y combinator works fine in Scheme, but many static typing disciplines will not accept it.  So adding static typing puts constraints on the other features, making some of them unusable.

My understanding of your position is that you work your way around this issue by creating different “worlds” for example parts of the program that are statically typed and others that are dynamically typed.  But then isn’t that just saying that you accept the existence of different languages (i.e. these worlds) and what you are looking for is an “as seamless as possible” FFI for these languages to talk to each other, like nodes of a distributed system communicating with each other?  I think it will be hard to be seamless and this will cause users to pick a world and do their programming there, which is what is being done now.

I can’t help but make the link with my work on different FFIs between Gambit Scheme and other languages, namely JavaScript[1] and Python[2].  In those FFIs we have chosen to embed the JavaScript and Python syntax in Scheme so that it is as seamless as possible to use those languages from Scheme (note that all three are dynamically typed which simplifies things).  I reject the idea that expressing everything with parentheses is “better” even though I am a great fan of s-expressions for all the reasons we know.  Sometimes a different syntax is useful to indicate which of these worlds is running the code so that our mind doesn’t get confused.  Of course, in our work, there is a mapping from infix expressions to s-expressions that simplifies processing the foreign expressions, possibly using them in pattern matching or macros, but the programmer is not working with this directly.  A quick example:

 > '\Math.sqrt(1+`x)
 (six.infix
  (six.call
   (six.dot (six.identifier Math) (six.identifier sqrt))
   (six.x+y (six.literal 1) `x)))

Marc

[1] https://www.iro.umontreal.ca/~feeley/papers/BelangerFeeleyELS21.pdf
[2] https://andykeep.com/SchemeWorkshop2022/scheme2022-final22.pdf