I wonder if this would be true: https://www.theolognion.com/circular-ts-js-ts-js-transpiling-yields-impressi...

On 12 Jun 2020, at 19:44, Branimir Maksimovic wrote:

It would choke on assembler as well. Digital computer hard AI is impossible, because there is no

algorithm for making algorithms. Mathematicaly impossible...

Greets, Branimir.

On 6/12/20 7:33 PM, Gregory Guthrie wrote:

...

I think it would choke on Haskell code! Haskell has so many language extensions and pragmas, and people use many local extensions with monads to basically create DIY DSL’s – that the code becomes very dense and context specific.

Facebook's TransCoder AI Converts Code From One Programming Language Into Another VentureBeat Kyle Wiggers June 9, 2020

Facebook says its TransCoder can convert code from one high-level programming language into another. The system, which Facebook researchers describe as “a neural transcompiler,” uses an unsupervised learning approach to translate between languages like C++, Java, and Python. The researchers trained TransCoder on a public GitHub corpus featuring more than 2.8 million open source repositories. To evaluate its capabilities, the researchers extracted 852 parallel functions in C++, Java, and Python from the online GeeksforGeeks platform and developed a new computational accuracy metric that tests whether hypothesis functions generate the same outputs as a reference when given the same inputs. Wrote the researchers, “TransCoder can easily be generalized to any programming language, does not require any expert knowledge, and outperforms commercial solutions by a large margin.”

Dr. Gregory Guthrie Maharishi International University ----------------------------------------------------------------

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to:

http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Am 12.06.20 um 20:25 schrieb Branimir Maksimovic:

As long as there is math behind that it could work. There is no algorithm for creative thinking. Same way that if you put it on rng 1000 monkeys will sooner or later create Shakespeare :P

Except if you have a library that has all the monkey works, the shelf number where you can find that work will be at least as long as the work itself. You can't beat entropy...

Greets, Branimir.

On 6/12/20 8:14 PM, MigMit wrote:

...

I wonder if this would be true: https://www.theolognion.com/circular-ts-js-ts-js-transpiling-yields-impressi...

...

On 12 Jun 2020, at 19:44, Branimir Maksimovic wrote:

It would choke on assembler as well. Digital computer hard AI is impossible, because there is no

algorithm for making algorithms. Mathematicaly impossible...

Greets, Branimir.

On 6/12/20 7:33 PM, Gregory Guthrie wrote:

...

I think it would choke on Haskell code! Haskell has so many language extensions and pragmas, and people use many local extensions with monads to basically create DIY DSL’s – that the code becomes very dense and context specific. Facebook's TransCoder AI Converts Code From One Programming Language Into Another VentureBeat Kyle Wiggers June 9, 2020

Facebook says its TransCoder can convert code from one high-level programming language into another. The system, which Facebook researchers describe as “a neural transcompiler,” uses an unsupervised learning approach to translate between languages like C++, Java, and Python. The researchers trained TransCoder on a public GitHub corpus featuring more than 2.8 million open source repositories. To evaluate its capabilities, the researchers extracted 852 parallel functions in C++, Java, and Python from the online GeeksforGeeks platform and developed a new computational accuracy metric that tests whether hypothesis functions generate the same outputs as a reference when given the same inputs. Wrote the researchers, “TransCoder can easily be generalized to any programming language, does not require any expert knowledge, and outperforms commercial solutions by a large margin.”

Dr. Gregory Guthrie Maharishi International University ----------------------------------------------------------------

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to:

http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On Sun, 14 Jun 2020, Joachim Durchholz wrote:

Am 12.06.20 um 21:51 schrieb Henning Thielemann:

...

It could have its use to convert legacy code in legacy languages to shiny new Haskell code. :-)

Well, the AI would have to know what "shiny" code is.

I thought that this is the point of the AI approach and the training.

Otherwise, you'll just get a C++/VB/Cobol program written in Haskell.

This would still be helpful. Imagine we transcode LAPACK to Haskell. It would be still FORTRAN or C encoded in Haskell with the same old FORTRAN API, but we can easily generalize the code to any floating point number type that any Haskell library provides, e.g. numbers with extended precision, with decimal numbers or with interval arithmetics.

On Sun, 14 Jun 2020, Joachim Durchholz wrote:

Am 14.06.20 um 12:25 schrieb Henning Thielemann:

...

This would still be helpful. Imagine we transcode LAPACK to Haskell. It would be still FORTRAN or C encoded in Haskell with the same old FORTRAN API, but we can easily generalize the code to any floating point number type that any Haskell library provides, e.g. numbers with extended precision, with decimal numbers or with interval arithmetics.

So... I tend to be scared if somebody claims to generalize floating-point code. Either because that person knows too little, or because that person knows so much more than me that they actually know how to deal with these complications :-)

I expect that code that works for both Float and Double has already factored out precision-dependent constants. I have not claimed and do not expect that generalization can happen automatically. I just say that even a dumb conversion from FORTRAN to Haskell can be the first step to (manual) generalization in Haskell.