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

[Bill Gunshannon]

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