What is a future of ocaml?

What is a future of ocaml?

[Radzevich Belevich]

There were no cvs commits since 3.11 release.
It would be interesting to know something about next release. 

RE: [Caml-list] What is a future of ocaml?

[David Allsopp]

Radzevich Belevich wrote:
> There were no cvs commits since 3.11 release.
> It would be interesting to know something about next release.

The OCaml developers are also (well, mainly!) academic researchers - having
been working very hard in the last few months to release OCaml 3.11 (which
only came out 41 days ago) I expect that they've returned to other things
for now!

I imagine that there will be lots of discussion activity (if last year is
anything to go by) following the OCaml Users' Meeting 2009 in Grenoble next
month - http://wiki.cocan.org/events/europe/ocamlmeetinggrenoble2009


David

Re: [Caml-list] What is a future of ocaml?

[Richard Jones]

On Wed, Jan 14, 2009 at 12:18:31PM +0300, Radzevich Belevich wrote:
> There were no cvs commits since 3.11 release.
> It would be interesting to know something about next release. 

I'll second David's comment.  Come to Grenoble on 4th Feb, to the
OCaml users meeting,
http://wiki.cocan.org/events/europe/ocamlmeetinggrenoble2009
Cost is EUR 32.

Rich.

-- 
Richard Jones
Red Hat

Re: What is a future of ocaml?

[Sylvain Le Gall]

Hello,

On 14-01-2009, Radzevich Belevich <radzevich.belevich@gmail.com> wrote:
> There were no cvs commits since 3.11 release.
> It would be interesting to know something about next release. 
>

There will be a "little talk" by INRIA OCaml team member about different
subject around OCaml, just as last year talk of Xavier Leroy, at OCaml
Meeting 2009.

http://wiki.cocan.org/events/europe/ocamlmeetinggrenoble2009

Regards,
Sylvain Le Gall

Re: [Caml-list] What is a future of ocaml?

[Dawid Toton]

Few days ago I spent some time googling for any info in the subject and 
found nothing (except assigned feature requests in the tracer).

Would be great to know what should be expected about OCaml in a long term.
I understand that there's no manpower to push the core compiler forward 
faster. But it would be a solace to know that there are at least some 
optimistic plans with a broader horizon.

(say, following is a collection of dreams :))

Is there any hope for a grand 'OCaml 4' release that would iron out the 
last ugly spots left in the language with some breaking changes?

E.g.:
Have immutable strings for everyday use and mutable byte arrays as buffers?

Full support for revised syntax? (Error messages, documentation...)

Make modules practically first-class by devising some standard way of 
automatic module to record conversion?

Make record fields acting as projection functions?

Could anybody explain why it's impossible to have type classes in OCaml?
We have few very special operators like (=), is there any chance to make 
them less magic and work out anything that would satisfy basic needs for 
overloading?

Dawid

Re: [Caml-list] What is a future of ocaml?

[Martin Jambon]

Dawid Toton wrote:
> (say, following is a collection of dreams :))
> 
> Is there any hope for a grand 'OCaml 4' release that would iron out the
> last ugly spots left in the language with some breaking changes?
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
Hahaha.

(the rest of my reaction is censored)



Martin

-- 
http://mjambon.com/

RE: [Caml-list] What is a future of ocaml?

[David Allsopp]

Dawid Toton wrote:
> Could anybody explain why it's impossible to have type classes in OCaml?

I don't think it's impossible - but I believe that if you introduce type
classes then you "damage" Hindley-Milner type inference and you can no
longer derive a principal typing for an arbitrary ML expression without
resorting to type annotations. Whether this is a problem or not is a matter
of taste - but it does make the language harder to call "ML" if you lose one
of its central features! That said, there are of course two big features
(objects and polymorphic variants) in OCaml already which do require
annotations.


David

Re: [Caml-list] What is a future of ocaml?

[Jérémie Dimino]

Dawid Toton <d0@wp.pl> writes:

> Make record fields acting as projection functions?

This can be done with camlp4 + type-conv, i put an example here:

http://www.dimino.org/projection.tar.gz

Jérémie

Re: [Caml-list] What is a future of ocaml?

[Dario Teixeira]

Hi,

> I understand that there's no manpower to push the core
> compiler forward faster. But it would be a solace to know
> that there are at least some optimistic plans with a broader
> horizon.

Speaking of which, there's something that's been on my mind for quite
some time: what's the holdup preventing INRIA from having more manpower
dedicated to Ocaml?  The language already has a sizable community, a
fair industrial usage, and a visible presence among the academia.  I'm
sure that given the language advantages that we all know, if it had
more widespread usage there would be a positive multiplier effect on the
French economy and beyond (think of productivity losses resulting
from crappy language choices).  Should we write a letter to monsieur
le président telling him that a well-supported Ocaml language would
do a lot more "pour la gloire de la France" than supermodel wives?


> Is there any hope for a grand 'OCaml 4' release that would iron out
> the last ugly spots left in the language with some breaking changes?

Backwards compatibility is overrated in an open-source environment.
However, to avoid alienating users with large code bases in legacy
code, the best solution would be to keep 3.x being updated for bugfixes
for the foreseeable future (would that require all that much manpower?),
while simultaneously developing a version 4.0 not hindered by backwards
compatibility.

Cheers,
Dario Teixeira

Re: [Caml-list] What is a future of ocaml?

[Jacques Garrigue]

From: "David Allsopp" <dra-news@metastack.com>
> Dawid Toton wrote:
> > Could anybody explain why it's impossible to have type classes in OCaml?
> 
> I don't think it's impossible - but I believe that if you introduce type
> classes then you "damage" Hindley-Milner type inference and you can no
> longer derive a principal typing for an arbitrary ML expression without
> resorting to type annotations. Whether this is a problem or not is a matter
> of taste - but it does make the language harder to call "ML" if you lose one
> of its central features! That said, there are of course two big features
> (objects and polymorphic variants) in OCaml already which do require
> annotations.

The reason is mostly wrong :-)
One can have both type classes and principal types; the problem with
principal types in Haskell is more subtle thant that.
And neither polymorphic variants nor object require type anotations in
ocaml; they just make it much more painful to understand error
messages.
Principality is only broken by optional arguments and polymorphic
methods, and there is a -principal flag that recovers some form of
principality (requiring type annotations).

This said, type classes have a lot of common features with modules or
objects, so this would be yet another way to do some similar things.
More problematic, type classes depend on the nominality of the type
systems, while ocaml has a rich language of structural types. For
instance, it is not completely clear how one could select instances of
type classes for polymorphic variants, without introducing conflicts.
I'm afraid the combination of type classes with modules and functors
is not trivial either.

Jacques Garrigue

Re: [Caml-list] What is a future of ocaml?

[Benedikt Grundmann]

I would even go so far as to say that

One of the advantages of OCaml's current development model is
that it is not changing the language very quickly.

OCaml is already a big language (featurer/syntax and so on wise),
it should (IMHO) not grow a lot more at least not without giving
each change a lot of thought.

cheers,

Bene

2009/1/15 Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>:
> From: "David Allsopp" <dra-news@metastack.com>
>> Dawid Toton wrote:
>> > Could anybody explain why it's impossible to have type classes in OCaml?
>>
>> I don't think it's impossible - but I believe that if you introduce type
>> classes then you "damage" Hindley-Milner type inference and you can no
>> longer derive a principal typing for an arbitrary ML expression without
>> resorting to type annotations. Whether this is a problem or not is a matter
>> of taste - but it does make the language harder to call "ML" if you lose one
>> of its central features! That said, there are of course two big features
>> (objects and polymorphic variants) in OCaml already which do require
>> annotations.
>
> The reason is mostly wrong :-)
> One can have both type classes and principal types; the problem with
> principal types in Haskell is more subtle thant that.
> And neither polymorphic variants nor object require type anotations in
> ocaml; they just make it much more painful to understand error
> messages.
> Principality is only broken by optional arguments and polymorphic
> methods, and there is a -principal flag that recovers some form of
> principality (requiring type annotations).
>
> This said, type classes have a lot of common features with modules or
> objects, so this would be yet another way to do some similar things.
> More problematic, type classes depend on the nominality of the type
> systems, while ocaml has a rich language of structural types. For
> instance, it is not completely clear how one could select instances of
> type classes for polymorphic variants, without introducing conflicts.
> I'm afraid the combination of type classes with modules and functors
> is not trivial either.
>
> Jacques Garrigue
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>



-- 
Calvin: I try to make everyone's day a little more
surreal.

(From Calvin & Hobbes)

RE: [Caml-list] What is a future of ocaml?

[David Allsopp]

Jacques Garrigue wrote:
> The reason is mostly wrong :-)

That'll teach me to comment on type theory on this list :o)

> And neither polymorphic variants nor object require type anotations in
> ocaml; they just make it much more painful to understand error
> messages.

Though I'm confused by this - I thought that polymorphic methods in classes
(a part of the object system) do require type annotations and there are
cases with polymorphic variants where coercions (which I'd regard as a type
annotation?) must be explicitly written for a valid program to type. I
wasn't trying to say that all uses of them require type annotations, just
that there are occasions where you *have* to use them whereas for "core" ML
you never *have* to include a type annotation for *any* valid program - your
types just might be more general than you expect/want.

Or am I still barking up the wrong tree?


David

Re: [Caml-list] What is a future of ocaml?

[Richard Jones]

On Wed, Jan 14, 2009 at 01:44:40PM +0000, Dawid Toton wrote:
> Is there any hope for a grand 'OCaml 4' release that would iron out the 
> last ugly spots left in the language with some breaking changes?

No no no, this is a really bad idea for a few reasons.

(1) Perl 6 and Python 3.  Python 3 is even very conservative (compared
to the ongoing complete rewrite that is Perl 6), but even there just
about no one is going to move to Python 3 in the immediate future
because it requires maintaining two incompatible versions of all your
code.  The OCaml community has far fewer resources available than the
Perl and Python communities, and doesn't need extra make-work.

(2) Everyone would need to agree on what the new language would look
like, what features it would and wouldn't have.  Good luck with that.

(3) The language is fine as it is, and many syntactic changes can be
made using camlp4 anyway and don't require any changes to the
compiler.

It's the slow, boring, steady work that's going to pay off.

Make the tools better.  Write more documentation and tutorials.  Fix
the website[*].  Mirror much more content on mirror.ocamlcore.org
and/or set up a CPAN-like repository of tarballs.  Make the mega-
releases for package-challenged beginners (what's happening to
Batteries?)  Make GODI work really well on Windows.  Package more
stuff in MacPorts ...

Rich.

[*] INRIA: Are you interested in handling control of http://ocaml.org
to OcamlCore?  I think we (Red Hat) can kick in some money to pay a
graphic designer and a user interface specialist to work on a good
looking site that appeals to beginners and directs people to the
necessary resources.

-- 
Richard Jones
Red Hat

Re: [Caml-list] What is a future of ocaml?

[Richard Jones]

On Wed, Jan 14, 2009 at 09:28:59AM -0800, Dario Teixeira wrote:
> Speaking of which, there's something that's been on my mind for quite
> some time: what's the holdup preventing INRIA from having more manpower
> dedicated to Ocaml?

Honestly I don't think we need to fixate on the core compiler.  If the
compiler had a new release once a year it really wouldn't matter.
Perl 5.x releases new versions less often than once a year, and that
wasn't what killed Perl take-up (it was the Osborne Effect around Perl
6 which did that, combined with O'Reilly dropping financial support).

What's needed is activity in all the other areas around the compiler -
I listed a few in my other response.

Rich.

-- 
Richard Jones
Red Hat

Re: What is a future of ocaml?

[Stefan Monnier]

> I'm afraid the combination of type classes with modules and functors
> is not trivial either.

Actually, in "Modular Type Classes", Derek Dreyer et al. argue fairly
convincingly that they can be combined in a natural way.

Of course, there's still the question of whether it all works out when
you add objects, polymorphic variants, ...


        Stefan

Re: [Caml-list] What is a future of ocaml?

[Oliver Bandel]

Hi,

Zitat von Benedikt Grundmann <benedikt.grundmann@googlemail.com>:

> I would even go so far as to say that
>
> One of the advantages of OCaml's current development model is
> that it is not changing the language very quickly.
>
> OCaml is already a big language (featurer/syntax and so on wise),
> it should (IMHO) not grow a lot more at least not without giving
> each change a lot of thought.
[...]


Yes, I agree fullheartedly!

So many other languages evolve a lot, and there is enough
busy-ness / daily business, that needs attention.
Always changing the API or other properties of the language would
be a factor of annoyance.

Such permanent changes and "add-ons" is/are necessary, when there
is a language that is quite weak, so that it is necessary to be enhanced
permanently.

But OCaml is such a good language, that it can compete with it's
language features without that kind of ADH-disorder, that many other
environments offer.  Such ADHD is provided as an advantage, but it
shows me, that there is not only room for enhancement... there also is
a necessity for enhancement of such languages!

And I don't say, OCaml is perfect or any way of making it better should
be deined. But it's strong with it's features.

And with it's it-does-not-change-every-week it is a good base for
long-term developments, IMHO.

Many languages, which will be changed permanently,
also incorporate functional features. I have heard that C++ now has
lambda terms... but it lacks many other things...

So, as Richard Jones mentioned it: it would be much better in enhancing
documentation (Tuorials and HowTO's and so on) and many of the tools...
especially easy installing of packages.

Let me mention R for example... I've never seen a better package-update
system. You can update installed, or install new packages very easy.
It's interactive like Perl's CPAN-module, but you don't need to be
superuser. If you want to install your stuff locally, R supports you
with this! You can have more than one library directory, and you can
select the right directory during the installation process.

Also better consitency of Code and Docs is worth looking at in OCaml.


If there will be enhancements in the distribution (Compiler and
library), I will be happy to appreciate it. I don't want to stop
enhancement. But as you, Benedikt, mentioned, a lot of thought should
be invested, before doing it. I think the INRIA team with it's superior
programmers will do this. There is necessity for the Bazaar as welll as
the Cathedral. We need both, and IMHO the Ocaml-cathedral makes sense.

The Bazaar can offer a lot of tools, tutorials and other things...
...as Richard Jones already mentioned.


Best wishes,
         Oliver Bandel

Re: [Caml-list] What is a future of ocaml?

[Kuba Ober]

On Jan 15, 2009, at 5:20 PM, Oliver Bandel wrote:

> Hi,
>
> Zitat von Benedikt Grundmann <benedikt.grundmann@googlemail.com>:
>
>> I would even go so far as to say that
>>
>> One of the advantages of OCaml's current development model is
>> that it is not changing the language very quickly.
>>
>> OCaml is already a big language (featurer/syntax and so on wise),
>> it should (IMHO) not grow a lot more at least not without giving
>> each change a lot of thought.
> [...]
>
>
> Yes, I agree fullheartedly!
>
> So many other languages evolve a lot, and there is enough
> busy-ness / daily business, that needs attention.
> Always changing the API or other properties of the language would
> be a factor of annoyance.
>
> Such permanent changes and "add-ons" is/are necessary, when there
> is a language that is quite weak, so that it is necessary to be  
> enhanced
> permanently.
>
> But OCaml is such a good language, that it can compete with it's
> language features without that kind of ADH-disorder, that many other
> environments offer.  Such ADHD is provided as an advantage, but it
> shows me, that there is not only room for enhancement... there also is
> a necessity for enhancement of such languages!
>
> And I don't say, OCaml is perfect or any way of making it better  
> should
> be deined. But it's strong with it's features.
>
> And with it's it-does-not-change-every-week it is a good base for
> long-term developments, IMHO.
>
> Many languages, which will be changed permanently,
> also incorporate functional features. I have heard that C++ now has
> lambda terms... but it lacks many other things...

OCaml-based Prolog can be as fast as SWI Prolog in principle since all  
SWI
Prolog does is compile to bytecode and run a bytecode virtual machine  
written in C.
What you were doing, most likely, is interpreting instead of  
compiling. I.e. you were
perhaps walking the parsed representation of predicates? Writing a  
Prolog
implementation in OCaml can be a bit less work than doing it in C,  
since your
VM can reuse OCaml's garbage collector, and of course it can use  
features
of a real high-level programming language. It should be entirely doable
to write a Prolog-to-OCaml cross-compiler. The result should be faster  
than
SWI Prolog, methinks.

Rant: C++ has had a pure functional metaprogramming language built in
for half a decade now (or is it longer?). This is something that  
unfortunately
even OCaml doesn't have. Of course LISP and Scheme's macro system blows
that out of the water, but there is a whole class of problems that are  
quite hard
to cleanly solve without compile-time execution of some sort. Of course,
metaprogramming is an art, that's why there are whole books about it
(Graham's "On Lisp" and Abrahams/Gurtovoy's "C++ Template  
Metaprogramming").
It's true, of course, that C++'s metaprogramming language feels like  
writing
for the Turing machine, but it's there, and it does find applications.
camlp4 has to be an external pass on the source code because there's no
way to get OCaml's compiler to execute code ;)

Cheers, Kuba

Re: [Caml-list] What is a future of ocaml?

[Xavier Leroy]

> [*] INRIA: Are you interested in handling control of http://ocaml.org
> to OcamlCore?  I think we (Red Hat) can kick in some money to pay a
> graphic designer and a user interface specialist to work on a good
> looking site that appeals to beginners and directs people to the
> necessary resources.

That sounds like an interesting offer indeed.  We'd have to discuss
actual contents of the site, but, yes, this is an area where outside
help would be welcome.

- Xavier Leroy

Re: [Caml-list] What is a future of ocaml?

[Richard Jones]

On Sun, Jan 18, 2009 at 05:34:14PM +0100, Xavier Leroy wrote:
> > [*] INRIA: Are you interested in handling control of http://ocaml.org
> > to OcamlCore?  I think we (Red Hat) can kick in some money to pay a
> > graphic designer and a user interface specialist to work on a good
> > looking site that appeals to beginners and directs people to the
> > necessary resources.
> 
> That sounds like an interesting offer indeed.  We'd have to discuss
> actual contents of the site, but, yes, this is an area where outside
> help would be welcome.

This is something it's probably best to discuss at the conference in
2.5 weeks time.

Rich.

-- 
Richard Jones
Red Hat