[Caml-list] Why isn't there a common platform for functional language interaction ?

[Caml-list] Why isn't there a common platform for functional language interaction ?

[Diego Olivier Fernandez Pons]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

    Caml-list,

Given that other people are raising trolls, here is mine...

I have to admit I appreciate F# transparent interaction with C# libraries
which allows me to use large amounts of code that I would have had to
poorly rewrite otherwise (GUI, database, web stuff, etc). Same happens with
SML, Caml, Haskell and F#, some pieces of code are just way better in one
language than in the others, and you end partially porting these libraries
to Caml which is a waste of time and you don't benefit from the updates of
the original code and nobody but you can maintain your quick-and-dirty port.

Why isn't there a core functional languages to which everyone could
compile, on which the compiler research could be done (certification,
optimisation, garbage collection) and that would allow full interaction of
the different dialects at run-time ?

At some point I thought that C-- (http://www.cminusminus.org/index.html)
and that type of work would converge to that but it never happened.

        Diego Olivier

[-- Attachment #2: Type: text/html, Size: 1113 bytes --]

Re: [Caml-list] Why isn't there a common platform for functional language interaction ?

[Stéphane Glondu]

Le 10/12/2011 11:36, Diego Olivier Fernandez Pons a écrit :
> At some point I thought that C-- (http://www.cminusminus.org/index.html)
> and that type of work would converge to that but it never happened.

Interesting... but it doesn't seem to have evolved since 2007.

LLVM and Parrot advertised the same goals, and are uncontroversial
technologies in my opinion. I think that to achieve better
interoperability and "hype", one of those would be a better fit than the
current native and bytecode compilers. I know, either is probably not
the best fit w.r.t. performances (actually, I've got some concern about
Parrot's design, but that's not the point), but, come on... do people
really chose to write in OCaml because of performances? Much more people
write in Perl, Python, etc. for reasons that could be applied to OCaml
(if there were only the toplevel).

By the way, as far as OCaml is concerned, there was also the OCamlIL
project [1], but it looks dead now (and .NET is not a technology I would
call uncontroversial).

[1] http://www.pps.jussieu.fr/~montela/ocamil/


Cheers,

-- 
Stéphane

Re: [Caml-list] Why isn't there a common platform for functional language interaction ?

[rixed]

> I think that to achieve better
> interoperability and "hype", one of those would be a better fit than the
> current native and bytecode compilers.

Next year is going to be exciting with so many people commiting themselves
to develop all these additions to the compiler ! :-)

Re: [Caml-list] Why isn't there a common platform for functional language interaction ?

[Gabriel Scherer]

There already exist such a common denominator language. For
performance reasons, it is architecture-dependent (I mean there are
several dialects to better use hardware peculiarities; the virtual
machine it runs on is not exactly virtual). Unfortunately, most
languages have concentrated on compiling to it in an efficient manner,
rather than considering how to interact with the other ones.

For maintainability reasons, we tend to develop N wrappers to a
historic common bridge language also compiled to that common
denominator (you may have heard of it before as it can also barely be
used for programming, it's called C), rather than N*N wrappers, one
for each pair of languages. The common denominator language also
doesn't provide runtime facilities (how could F#, SML, OCaml and
Haskell agree on a common runtime anyway?), and it is very hard to
make the various runtimes interact gracefully (eg. you basically can't
share data except raw numbers, only transfer ownership from one
runtime to another).

There have been plans to move to a better common denominator, or at
least a better bridge language (C--, LLVM, ...), but it is very hard
to move from the historical choice, despite the attracting technical
improvements of newer candidates. Moreover, it is basically impossible
to move up the abstraction ladder (eg. provide common runtime
components) without sacrificing universality or efficiency.

On Sat, Dec 10, 2011 at 11:36 AM, Diego Olivier Fernandez Pons
<dofp.ocaml@gmail.com> wrote:
>     Caml-list,
>
> Given that other people are raising trolls, here is mine...
>
> I have to admit I appreciate F# transparent interaction with C# libraries
> which allows me to use large amounts of code that I would have had to poorly
> rewrite otherwise (GUI, database, web stuff, etc). Same happens with SML,
> Caml, Haskell and F#, some pieces of code are just way better in one
> language than in the others, and you end partially porting these libraries
> to Caml which is a waste of time and you don't benefit from the updates of
> the original code and nobody but you can maintain your quick-and-dirty port.
>
> Why isn't there a core functional languages to which everyone could compile,
> on which the compiler research could be done (certification, optimisation,
> garbage collection) and that would allow full interaction of the different
> dialects at run-time ?
>
> At some point I thought that C-- (http://www.cminusminus.org/index.html) and
> that type of work would converge to that but it never happened.
>
>         Diego Olivier

Re: [Caml-list] Why isn't there a common platform for functional language interaction ?

[oliver]

On Sat, Dec 10, 2011 at 01:38:53PM +0100, rixed@happyleptic.org wrote:
> > I think that to achieve better
> > interoperability and "hype", one of those would be a better fit than the
> > current native and bytecode compilers.
> 
> Next year is going to be exciting with so many people commiting themselves
> to develop all these additions to the compiler ! :-)
[...]

A lot of people think, next year (2012) will be the end of the world.

But there is no proof for this so far.
Not even a reason. Only the maya calendar's value overflow.

But maybe you have found the explanation for it, so we all will be doomed. ;-)


Ciao,
   Oliver

RE: [Caml-list] Why isn't there a common platform for functional language interaction ?

[Jon Harrop]

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

Most projects are either academic research or industrial products. In
academia, reinventing a common language run-time won't get funding because
it is not novel enough. In industry, products that aren't economically
viable in the mid-term (years) or sooner won't get funding. So the common
solutions don't work here.

 

There are at least two alternatives. One is to join forces with a massive
company like Microsoft who are willing to risk comparatively huge lead
times, as they did with .NET, but the result will be proprietary. The other
is to earn millions yourself and invest in the R&D that you think will be
most beneficial, as Stephen Wolfram did.

 

Perhaps another alternative would be to adopt Microsoft's CLR and focus on
creating an open source implementation that has a working garbage collector
and decent performance.

 

Also, interoperability is not the only benefit of a common language
run-time. Another major benefit is maturity: because you have multiple
languages sitting on top of the same run-time all of the programs in all of
those languages are testing your run-time.

 

Cheers,

Jon.

 

From: Diego Olivier Fernandez Pons [mailto:dofp.ocaml@gmail.com] 
Sent: 10 December 2011 10:36
To: caml-list
Subject: [Caml-list] Why isn't there a common platform for functional
language interaction ?

 

    Caml-list,

Given that other people are raising trolls, here is mine...

I have to admit I appreciate F# transparent interaction with C# libraries
which allows me to use large amounts of code that I would have had to poorly
rewrite otherwise (GUI, database, web stuff, etc). Same happens with SML,
Caml, Haskell and F#, some pieces of code are just way better in one
language than in the others, and you end partially porting these libraries
to Caml which is a waste of time and you don't benefit from the updates of
the original code and nobody but you can maintain your quick-and-dirty port.

Why isn't there a core functional languages to which everyone could compile,
on which the compiler research could be done (certification, optimisation,
garbage collection) and that would allow full interaction of the different
dialects at run-time ?

At some point I thought that C-- (http://www.cminusminus.org/index.html) and
that type of work would converge to that but it never happened.

        Diego Olivier


[-- Attachment #2: Type: text/html, Size: 5936 bytes --]

Re: [Caml-list] Why isn't there a common platform for functional language interaction ?

[Florian Hars]

Am 10.12.2011 13:58, schrieb Gabriel Scherer:
> Moreover, it is basically impossible
> to move up the abstraction ladder (eg. provide common runtime
> components) without sacrificing universality or efficiency.

This might be relevant to the topic at hand:
http://lists.gnu.org/archive/html/dotgnu-general/2002-06/msg00197.html

- Florian.

Re: [Caml-list] Why isn't there a common platform for functional language interaction ?

[Diego Olivier Fernandez Pons]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

    Caml-list

On 10 December 2011 13:58, Gabriel Scherer <gabriel.scherer@gmail.com>wrote:


> There already exist such a common denominator language. For
> performance reasons, it is architecture-dependent

[...]
>
There have been plans to move to a better common denominator, or at
> least a better bridge language (C--, LLVM, ...)
>

Why should that be a low-level language ? Why not core-ML ?

What I see as the very first issue is the spread of the efforts between
similar yet incompatible ML dialects leading to 4 weak communities (SML,
OCaml, F#, Haskell) instead of a really strong one and all the related
problems that come with it (fewer books, risk for industrials, work
duplication, inefficient funding, lack of visibility, etc).

Example : there is an excellent whole source code optimiser ... for SML.
And an award winning SMT solver ... in Caml developed in a company that
invests heavily in information-centric web applications ... in F# (
http://research.microsoft.com/en-us/um/redmond/projects/z3/ if you don't
know Nikolaj Bjorner's Z3). Now say you want to do an application that
delivers optimal electricity production plans. What language do you choose ?

Just being able to reuse the source-code between string ML dialects even
after recompilation (X -> CoreML -> specific platform) would be an
improvement.

        Diego Olivier

[-- Attachment #2: Type: text/html, Size: 2116 bytes --]

Re: [Caml-list] Why isn't there a common platform for functional language interaction ?

[Philippe Strauss]

On Sat, Dec 10, 2011 at 09:44:01PM +0100, Diego Olivier Fernandez Pons wrote:
> 
> What I see as the very first issue is the spread of the efforts between
> similar yet incompatible ML dialects leading to 4 weak communities (SML,
> OCaml, F#, Haskell) instead of a really strong one and all the related
> problems that come with it (fewer books, risk for industrials, work
> duplication, inefficient funding, lack of visibility, etc).
> 
> Example : there is an excellent whole source code optimiser ... for SML.
> And an award winning SMT solver ... in Caml developed in a company that
> invests heavily in information-centric web applications ... in F# (
> http://research.microsoft.com/en-us/um/redmond/projects/z3/ if you don't
> know Nikolaj Bjorner's Z3). Now say you want to do an application that
> delivers optimal electricity production plans. What language do you choose ?

Sure but is there any effort not based on free will limitation which would works ?
Marketing, an attractive website, an packaging/oasis-db like thing, good introductory tutorials (I've appreciated
the chapter1 of jon harrop, btw), a distro maybe based on batteries or ... argh.

Each piece of software, libraries, exist becaus of a reserch project, someone choosing ocaml as
the tool of choice, or spare-time and leisure. This diversity is the consequence of free will.
sometimes it's waste of resources, but try to join each resources by email and convince
them to unify their efforts. Or give them compensation for it.

Joining together jane-street core and batteries, you can already forget about it, so joining
ML/Haskell/OCaml/F# efforts together...

And people getting away from for example c-- or llvm based lower level stuff, there's always an explanation
of lower "energy" like barrier to get a thing done, writing your own stuff rather than diving and get drown in a monster, etc...

that's open source devel.

> Just being able to reuse the source-code between string ML dialects even
> after recompilation (X -> CoreML -> specific platform) would be an
> improvement.

-- 
Philippe Strauss
av. de Beaulieu 25
1004 Lausanne
http://www.philou.ch

RE: [Caml-list] Why isn't there a common platform for functional language interaction ?

[Jon Harrop]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

Agreed! Being able to share FFI bindings would be even more useful.

 

Cheers,

Jon.

 

From: Diego Olivier Fernandez Pons [mailto:dofp.ocaml@gmail.com] 
Sent: 10 December 2011 20:44
To: Gabriel Scherer
Cc: caml-list
Subject: Re: [Caml-list] Why isn't there a common platform for functional
language interaction ?

 

    Caml-list

On 10 December 2011 13:58, Gabriel Scherer <gabriel.scherer@gmail.com>
wrote:

 

There already exist such a common denominator language. For
performance reasons, it is architecture-dependent 

[...] 

There have been plans to move to a better common denominator, or at
least a better bridge language (C--, LLVM, ...)


Why should that be a low-level language ? Why not core-ML ?

What I see as the very first issue is the spread of the efforts between
similar yet incompatible ML dialects leading to 4 weak communities (SML,
OCaml, F#, Haskell) instead of a really strong one and all the related
problems that come with it (fewer books, risk for industrials, work
duplication, inefficient funding, lack of visibility, etc).

Example : there is an excellent whole source code optimiser ... for SML. And
an award winning SMT solver ... in Caml developed in a company that invests
heavily in information-centric web applications ... in F#
(http://research.microsoft.com/en-us/um/redmond/projects/z3/ if you don't
know Nikolaj Bjorner's Z3). Now say you want to do an application that
delivers optimal electricity production plans. What language do you choose ?

Just being able to reuse the source-code between string ML dialects even
after recompilation (X -> CoreML -> specific platform) would be an
improvement.

        Diego Olivier


[-- Attachment #2: Type: text/html, Size: 5255 bytes --]