[Info-vax] The Kotlin language, something for VMS as well?

[Dirk Munk]

Bill Gunshannon wrote:
> On 7/13/2017 8:38 AM, Dirk Munk wrote:
>> Jan-Erik Soderholm wrote:
>>> Den 2017-07-13 kl. 14:02, skrev Arne Vajhøj:
>>>> On 7/13/2017 4:37 AM, Dirk Munk wrote:
>>>>> Arne Vajhøj wrote:
>>>>>> On 7/12/2017 4:13 PM, Brett Cameron wrote:
>>>>>>> Just FYI, I had a bit of a play around with Kotlin a few weeks back
>>>>>>> and pretty much all the JVM stuff seems to work okay on OpenVMS 
>>>>>>> with
>>>>>>> Java 8 (the interactive shell has a couple of minor issues, but
>>>>>>> that’s about all I’ve hit so far)...
>>>>>>
>>>>>> Most JVM languges should be easy to get working:
>>>>>>
>>>>>> Kotlin
>>>>>> Scala
>>>>>> Groovy
>>>>>> Jython (Python) [I am rather interested in that one]
>>>>>> JRuby (Ruby)
>>>>>> Clojure (Lisp derivative)
>>>>>> JGnat (Ada)
>>>>>> Rembulan (Lua)
>>>>>> Rhino or Nashorn (JavaScript) [comes with Java out the box and 
>>>>>> works]
>>>>>> Renjin (R)
>>>>>>
>>>>
>>>>> Thank you very much Arne, this is very interesting information. I 
>>>>> wasn't aware of these developments.
>>>>>
>>>>> Let's take Jython as an example. If I'm going to use an 
>>>>> application written in Python now, then it will come with all the 
>>>>> clutter of a Python runtime system in its directories. Another 
>>>>> application written in Python will have the same clutter, 
>>>>> preferably with another (sub)version of Python.
>>>>>
>>>>> With Jython you would only have the application in .jar files in 
>>>>> its directories, perhaps a kind of Jython library as well, and run 
>>>>> the whole thing with the standard JVM that you already have 
>>>>> installed. No more clutter.
>>>>>
>>>>> It also means you don't need Jython (Python!) versions for every 
>>>>> OS, only for desktop operating systems. Those would be Windows, 
>>>>> Linux and Mac OS.
>>>>>
>>>>> If I understand John Reagon's contribution correctly, the Python 
>>>>> developers could also build a LLVM compiler kit, add some VMS 
>>>>> specific code, and build a LLVM Python compiler on VMS. With that 
>>>>> you can produce Python executables. Don't know if that would be 
>>>>> useful, but that's not the point for this discussion.
>>>>>
>>>>> So my conclusion is that if you want to add a new language to VMS, 
>>>>> makes sure it runs with the JVM, and/or produce a LLVM kit, adapt 
>>>>> it somewhat for the VMS specifics, and build a LLVM compiler to 
>>>>> produce executables for the new language. (The LLVM stuff is on 
>>>>> x86-VMS of course!!)
>>>>>
>>>>> Am I correct?
>>>>
>>>> I don't think there is any silver bullet, but I do see some advantages
>>>> of the JVM model.
>>>>
>>>> Native languages will typical be:
>>>>
>>>> language A
>>>>     large runtime for A
>>>>     database drivers etc. for A
>>>> language B
>>>>     large runtime for B
>>>>     database drivers etc. for B
>>>> language C
>>>>     large runtime for C
>>>>     database drivers etc. for C
>>>>
>>>> JVM languages will typical be:
>>>>
>>>> Java
>>>>     huge Java runtime
>>>>     database drivers etc. for Java
>>>> language A
>>>>     small runtime for A
>>>> language B
>>>>     small runtime for B
>>>> language C
>>>>     small runtime for C
>>>>
>>>> I don't know much about how LLVM works. But I thought it was
>>>> more of a compiler backend meaning that it would make it much
>>>> easier to produce a native language for a platform, but that
>>>> it would not really change the deployment model. But I may
>>>> be wrong.
>>>>
>>>> Arne
>>>>
>>>
>>> I also thought that you need a language specific frontend to LLVM,
>>> much as you need for GEM. Maybe LLVM can produce code runable
>>> in the JVM, no idea...
>>>
>>
>> Yes, of course you need a language specific frond-end. However the 
>> source for this frond-end seems to be the same for every OS, with the 
>> exception of a few OS specific parts. In other words, it is rather 
>> simple to build a LLVM compiler for any OS, since every supported OS 
>> has a LLVM package that will allow you to build such compilers. At 
>> least that is my understanding.
>>
>> LLVM certainly is not meant to produce code for the JVM.
>>
>
> No reason why it couldn't.  Bytecode for the JVM is no different than
> the binary for any other architecture.  Someone just needs to create
> that backend.
>
> bill
>

I'm sure you could use the same idea to set up compilers that produce 
code for the JVM, but I doubt if that could or should be done by 
building a new back-end.