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

[Bill Gunshannon]

On 7/13/2017 12:00 PM, Dirk Munk wrote:
> 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.

I thought the backend was the part of the compiler that generated
the code for a particular architecture? If not, just what do people
consider the backend?

bill