Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Caml-list] What does Jane Street use/want for an IDE? What about you?

239 views
Skip to first unread message

Kuba Ober

unread,
Oct 20, 2008, 9:19:57 AM10/20/08
to caml...@inria.fr
I have questions to the kind folks at Jane Street,
and others who use OCaml for commercial/non-research
development: what do you guys use for your development
environment? What would be the minimal set of functionality
that would make you happy for an IDE? What are killer features
you dream of?

I'm trying to come up with a longer time plan for Camelia --
this so far relegated, to the dismay of my wife and daughter
-- to prolonging my morning showers, so I may as well ask
around. None of those plans/feedback would have immediate
effect, but I wouldn't mind it simmering for a bit.

The reason I got into camelia is not only OCaml, but it
seems like a small and manageable enough IDE to base
other tools that I'm working on for various embedded
architectures. In the long run, for Windows platform
I will statically link it and literally have it be
a single executable, so that it can be trivially
shared, it would also make it easier to consume
by people on locked-down computers where software
installations are disallowed. Of course OCaml is another
deal here, but you have to start with something :)

Cheers, Kuba

_______________________________________________
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

Mark Shinwell

unread,
Oct 20, 2008, 9:37:50 AM10/20/08
to Kuba Ober, caml...@inria.fr
On Mon, Oct 20, 2008 at 09:19:40AM -0400, Kuba Ober wrote:
> I have questions to the kind folks at Jane Street,
> and others who use OCaml for commercial/non-research
> development: what do you guys use for your development
> environment?

vim in an xterm for me :)

> What are killer features you dream of?

Something along the lines of Jun Furuse's ocamlspotter work, with good
editor integration, is probably highest on my list at the moment.

Mark

Thomas Gazagnaire

unread,
Oct 20, 2008, 10:05:17 AM10/20/08
to Mark Shinwell, caml...@inria.fr
> What are killer features you dream of?

Clearly, the ability to click on a function to go to the place where it is
defined is the only reason why I switched from emacs to Eclipse ... And I
would be very happy to switch to a faster IDE because Eclipse is so slow on
big project.

Thomas

Andres Varon

unread,
Oct 20, 2008, 10:33:44 AM10/20/08
to Kuba Ober, caml users

On Oct 20, 2008, at 9:37 AM, Mark Shinwell wrote:

> On Mon, Oct 20, 2008 at 09:19:40AM -0400, Kuba Ober wrote:
>> I have questions to the kind folks at Jane Street,
>> and others who use OCaml for commercial/non-research
>> development: what do you guys use for your development
>> environment?
>
> vim in an xterm for me :)
>
>> What are killer features you dream of?
>
> Something along the lines of Jun Furuse's ocamlspotter work, with good
> editor integration, is probably highest on my list at the moment.

Being a vim user myself, good editor integration is also very
important to me. My wish list has only one killer feature: smart
autocompletion, that would really increase the productivity of new
programmers and would make it easier to learn new modules.

Andres

Martin Jambon

unread,
Oct 20, 2008, 10:55:34 AM10/20/08
to Kuba Ober, caml...@inria.fr
Kuba Ober wrote:
> I have questions to the kind folks at Jane Street,
> and others who use OCaml for commercial/non-research
> development: what do you guys use for your development
> environment? What would be the minimal set of functionality
> that would make you happy for an IDE? What are killer features
> you dream of?

I'm working for wink.com (people search engine) and speaking on my own
behalf.

I use 16 (4x4) virtual Fvwm desktops with free mouse movement between
them and a small map of the desktops in the lower-right corner (+
xosview). The majority of the population finds this disturbing, I'm not
really sure why. I hate clicking or typing to switch from a window to
another so I just move my arm in order to place the mouse cursor over
the right window in the right virtual desktop as shown on the map.
That's the feature I was dreaming of until I discovered its existence,
quite a long time ago.

There are no icons or toolbar. A left-click anywhere on the background
displays a menu with the applications I commonly use, and that's enough.

Here are graphical applications I use:
* standard 80x25 xterm for filesystem navigation, commands and remote
logins.
* 80xN emacs
* wider xterm for reading log files with less, grep, etc.
* ocamlbrowser
* web browser
* IM client
* email client

Build tools:
* omake for large OCaml projects (which represents now more than 95% of
my time)
* whatever-works for small or public projects

Compilation:
* from within emacs with tuareg-mode (C-c C-c) or from an (O)Makefile
(C-x C-e)
* middle-click on the error message or warning brings me directly to the
error location (killer feature)
* compiling now always with -dtypes; C-c C-t shows the type under the
cursor (killer feature; requires caml-mode installed if I remember
correctly)

Editor:
* emacs + tuareg-mode for OCaml
* still emacs for any other text format

Testing:
* ocaml toplevel within emacs (C-x C-e to evaluate a phrase in tuareg-mode)
* or ocaml toplevel + xterm + ledit
* programs are run from an xterm
* I'm close to totally ignorant about ocamldebug. Maybe a graphical
interface would help (is there any?).


All of this is the best combination for me because I chose it myself
from the largest choice available. I must say I don't understand the
meaning or the need for the I in IDE. What I use is accessible using a
single monitor, a keyboard and a mouse + a desk + paper and pen.
Technically it is integrated on my desk, I have full control over it, it
is safe, it does what I want and never does what I don't want.

Now I hope someone will react and tell me the benefits of "Integrated"
but so far it looks to me that the close interaction between the build
system, the file system and the text editor is taken care of nicely by
emacs+tuareg-mode.


> I'm trying to come up with a longer time plan for Camelia --
> this so far relegated, to the dismay of my wife and daughter
> -- to prolonging my morning showers, so I may as well ask
> around. None of those plans/feedback would have immediate
> effect, but I wouldn't mind it simmering for a bit.
>
> The reason I got into camelia is not only OCaml, but it
> seems like a small and manageable enough IDE to base
> other tools that I'm working on for various embedded
> architectures. In the long run, for Windows platform
> I will statically link it and literally have it be
> a single executable, so that it can be trivially
> shared, it would also make it easier to consume
> by people on locked-down computers where software
> installations are disallowed. Of course OCaml is another
> deal here, but you have to start with something :)

I would already be unhappy and underproductive with KDE, so don't even
mention Windows and its single virtual desktop. (How do people manage
20+ windows without using several virtual desktops? I can't because I
need to switch between them all the time)

The great thing about an all-in-one-app solution is that it makes it
possible to get started quickly, which is great for teaching a
programming language to inexperienced students.

For a daily use it seems to me like a source of frustration and waste of
productivity.


Martin

--
http://mjambon.com/

Robert Morelli

unread,
Oct 20, 2008, 11:45:49 AM10/20/08
to Thomas Gazagnaire, caml...@inria.fr

The emacs tags system didn't work for you?

I'm surprised that's the only thing you found useful in Eclipse,
considering how primitive Emacs is.

Which brings me to my suggestion ...

Part of the reason Emacs is still so limited after nearly 30 years of
development is that it is largely based on
emacs lisp, a very poorly designed lisp dialect that makes large scale
development very difficult and
unreliable. Emacs lisp has all of the flaws that make large scale,
loosely organized, collaborative development
a disaster. It's in fact rather astonishing how little progress Emacs
has made over the years and I think it's a
great case study in how dramatic an effect poor up front design choices
can have on long term development.

Unfortunately, most of the foundational "unix-think" technologies I use
suffer from the same fatal
flaw: very poor programming language design built on top of very poor
underlying architecture. That's certainly
the case with Emacs (along with bash, TeX, X, and pretty much every
other unix technology).

What Emacs lisp does wrong is virtually a checklist of bad programming
language design. On the
other hand, these are all of the things languages like OCaml do right.

So, my dream would be for someone to build a text editor with the same
basic philosophy as Emacs,
cloning a good bit of its core functionality, but built on a sound
architecture, and capable of dealing with
the demands of modern complex software systems, like IDEs. Roughly
speaking, Emacs built on top of
a "real" language like OCaml, and with the capabilities of modern gui
systems, networks, work flows,
etc. in mind.

It would of course be a total waste of time to start writing the 5000th
text editor that goes nowhere. But
I think this would be a very worthwhile project if it is built with the
goal of overcoming the failures of
Emacs through sound technology, appropriate design, and a mind to
extensibility. The goal of building a
text editor that could serve as an IDE for OCaml would be a very good
challenge to keep these goals
tested from an early stage.

David Teller

unread,
Oct 20, 2008, 11:56:57 AM10/20/08
to Robert Morelli, caml...@inria.fr
On Mon, 2008-10-20 at 09:45 -0600, Robert Morelli wrote:
> So, my dream would be for someone to build a text editor with the same
> basic philosophy as Emacs,
> cloning a good bit of its core functionality, but built on a sound
> architecture, and capable of dealing with
> the demands of modern complex software systems, like IDEs. Roughly
> speaking, Emacs built on top of
> a "real" language like OCaml, and with the capabilities of modern gui
> systems, networks, work flows,
> etc. in mind.

Just for the sake of bibliography, this reminds me of efuns [1] and
Chamo [2].

[1] http://pauillac.inria.fr/cdrom/prog/unix/efuns/eng.htm
[2] http://home.gna.org/cameleon/

Cheers,
David
--
David Teller-Rajchenbach
Security of Distributed Systems
http://www.univ-orleans.fr/lifo/Members/David.Teller
Angry researcher: French Universities need reforms, but the LRU act brings liquidations.

Yitzhak Mandelbaum

unread,
Oct 20, 2008, 1:16:43 PM10/20/08
to List caml
On Oct 20, 2008, at 11:56 AM, David Teller wrote:
>
> Just for the sake of bibliography, this reminds me of efuns [1] and
> Chamo [2].
>
> [1] http://pauillac.inria.fr/cdrom/prog/unix/efuns/eng.htm
> [2] http://home.gna.org/cameleon/
>
> Cheers,
> David

Does anyone know the status of either of these projects? Are they
still actively maintained?

Yitzhak

-----------------------------
Yitzhak Mandelbaum

Peng Zang

unread,
Oct 20, 2008, 3:54:24 PM10/20/08
to caml...@yquem.inria.fr, Andres Varon, caml users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have written smart autocompletion based on the toplevel in a mode I call
SOLID.

http://www.cc.gatech.edu/~pengzang/tools.html

I've never gotten around to announcing it because it takes time to polish up
and write good doc... time that I haven't had of late. However, I have been
using it myself for a while and a handful of random people have emailed me
about it and it works with them so, it may work for you. Now seems as good a
time as any to tell people about since I've held off for over a year saying
anything..

Peng

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFI/OHhfIRcEFL/JewRAitYAKCkwkPaD3A/uf/N6NBM3QyShyz2egCeJsna
fqAFuuuiwCmcdDdGL8ahKG0=
=T7T8
-----END PGP SIGNATURE-----

Kuba Ober

unread,
Oct 20, 2008, 4:14:32 PM10/20/08
to caml...@inria.fr
> I use 16 (4x4) virtual Fvwm desktops with free mouse movement between
> them and a small map of the desktops in the lower-right corner (+
> xosview). The majority of the population finds this disturbing, I'm not
> really sure why. I hate clicking or typing to switch from a window to
> another so I just move my arm in order to place the mouse cursor over
> the right window in the right virtual desktop as shown on the map.
> That's the feature I was dreaming of until I discovered its existence,
> quite a long time ago.
>
> There are no icons or toolbar. A left-click anywhere on the background
> displays a menu with the applications I commonly use, and that's enough.

I already thought that Camelia and similar apps should provide essentially
two UI modes: the standard, all-exposed "clutterface" typical of most
applications, and a "nakedface" where just as you say there's just the main
window (or two), even without decorations, and nothing more.

Camelia provides panes for debugger and toplevel, so those of course could be
held in a virtual space in the "nakedface" model.

Heck, as far as I can imagine it, it souldn't be that big of a deal to have
the virtual desktops implemented in Camelia itself: depending on which
direction and how fast the mouse crosses/touches the window edge from
inside, it changes the viewport to a different window.

I had similar mode in mind for a PCB editing application I'm working on, so
I do actually find your ideas appealing and worthwhile. Especially that
it's relatively trivial to implement little goodies like that. I vehemently
hate window decorations on CAD programs: that's why I liked the old
school applications like Protel for DOS, AutoCad, most of the stand-alone CAD
workstations: they displayed things full-screen since screen real estate
was really expensive, and often had single-key shortcuts to swap the screen
with a textmode interface for options, command input etc.

> Build tools:
> * omake for large OCaml projects (which represents now more than 95% of
> my time)

Will check on omake, for sure.

Thanks for the suggestions, keep them coming. I guess I have to think of
"classic" and "naked" interface modes for Camelia, then.

Kuba

Richard Jones

unread,
Oct 20, 2008, 4:15:37 PM10/20/08
to Robert Morelli, caml...@inria.fr
On Mon, Oct 20, 2008 at 09:45:34AM -0600, Robert Morelli wrote:
> What Emacs lisp does wrong is virtually a checklist of bad programming
> language design. On the
> other hand, these are all of the things languages like OCaml do right.

It'd be interesting to hear[1] what exact features of elisp are
counterproductive for large-scale collaborative programming.

I've not looked very closely at elisp, but assumed the reason that
emacs remains "unconfigurable" for most users is because it's Lisp,
not because of the particular dialect of Lisp. Most programmers look
at Lisp and run a mile, and I don't think an OCaml editor will fare
much better if that is the case.

FWIW microemacs[2] used a C-like language for configuration and
extension, and this language was almost laughably incapable of doing
the most basic things. You'd think that a language designed for an
editor would, you know, be able to handle at least strings properly,
but the microemacs programming language couldn't even do that.
Nevertheless at the electronics laboratory where I started out,
electrical engineers (totally unused/untrained as programmers) wrote
huge macros and extensions in this horrible language.

Rich.

[1] Here or in a blog posting ...
[2] http://en.wikipedia.org/wiki/Microemacs

--
Richard Jones
Red Hat

Kuba Ober

unread,
Oct 20, 2008, 4:16:42 PM10/20/08
to caml...@inria.fr
On Monday 20 October 2008, you wrote:
> > What are killer features you dream of?
>
> Clearly, the ability to click on a function to go to the place where it is
> defined is the only reason why I switched from emacs to Eclipse

I think that Camelia can do that -- it already fetches type annotations from
OCaml to generate type tooltips for expressions, so probably fetching
function definition locations is either already possible, or would require
a little bit of extra work. Goes onto my feature wishlist, and I will enter
it into Sourceforge's issue tracker for this project.

Cheers, Kuba

Kuba Ober

unread,
Oct 20, 2008, 4:32:49 PM10/20/08
to caml...@yquem.inria.fr
> It'd be interesting to hear[1] what exact features of elisp are
> counterproductive for large-scale collaborative programming.
>
> I've not looked very closely at elisp, but assumed the reason that
> emacs remains "unconfigurable" for most users is because it's Lisp,
> not because of the particular dialect of Lisp. Most programmers look
> at Lisp and run a mile, and I don't think an OCaml editor will fare
> much better if that is the case.
>
> FWIW microemacs[2] used a C-like language for configuration and
> extension, and this language was almost laughably incapable of doing
> the most basic things. You'd think that a language designed for an
> editor would, you know, be able to handle at least strings properly,
> but the microemacs programming language couldn't even do that.
> Nevertheless at the electronics laboratory where I started out,
> electrical engineers (totally unused/untrained as programmers) wrote
> huge macros and extensions in this horrible language.

I can understand that: Lisp does require wrapping your head around it.

Even its library deals with things and concepts that other languages
simply don't offer. Functions that do symbol interning/generation
or say destructuring-bind will elicit blank stares from most engineering
folk -- folk that otherwise may have no problem generating your everyday
C or Matlab code without even blinking. Lisp deals with programming at
a much more abstract level, IMHO -- you can of course write C-like
code in Lisp, but it just feels unnatural to do so, and rightly so.

While it may sound weird, your regular programming experience applies
only halfway to Lisp. The other, important half, you have to acquire
with use of the language. Switching from C or C++ to say Python is
easy, going to OCaml requires perhaps a book but is quite manageable
too, even Haskell IMHO is easier than Lisp! To learn Lisp the right
way you need basically two and a half books (two by Graham, and a
half of "Practical Common Lisp"), and some midnight oil ;) That's
been the case with me.

Cheers, Kuba

Maxence Guesdon

unread,
Oct 20, 2008, 4:51:33 PM10/20/08
to caml...@yquem.inria.fr
On Mon, 20 Oct 2008 13:15:52 -0400
Yitzhak Mandelbaum <yitz...@CS.Princeton.EDU> wrote:

> On Oct 20, 2008, at 11:56 AM, David Teller wrote:
> >
> > Just for the sake of bibliography, this reminds me of efuns [1] and
> > Chamo [2].
> >
> > [1] http://pauillac.inria.fr/cdrom/prog/unix/efuns/eng.htm
> > [2] http://home.gna.org/cameleon/
> >
> > Cheers,
> > David
>
> Does anyone know the status of either of these projects? Are they
> still actively maintained?

Hello,

I maintain and develop Chamo but I miss time to do more. I use Chamo as
editor for all text files now (including ocaml code of course).

Regards,

--
Maxence Guesdon http://yquem.inria.fr/~guesdon/
Service Expérimentation et Développements https://devel.inria.fr/rocq/
INRIA Paris-Rocquencourt http://www.inria.fr/rocquencourt/

Robert Morelli

unread,
Oct 20, 2008, 7:03:04 PM10/20/08
to Richard Jones, caml...@inria.fr
Richard Jones wrote:
> On Mon, Oct 20, 2008 at 09:45:34AM -0600, Robert Morelli wrote:
>
>> What Emacs lisp does wrong is virtually a checklist of bad programming
>> language design. On the
>> other hand, these are all of the things languages like OCaml do right.
>>
>
> It'd be interesting to hear[1] what exact features of elisp are
> counterproductive for large-scale collaborative programming.
>
> I've not looked very closely at elisp, but assumed the reason that
> emacs remains "unconfigurable" for most users is because it's Lisp,
> not because of the particular dialect of Lisp. Most programmers look
> at Lisp and run a mile, and I don't think an OCaml editor will fare
> much better if that is the case.
>

Because of its poor design, I lost the heart to try to program complex
tasks in Emacs lisp quite
a while ago, so I don't have everything fresh in my mind. Perhaps Peng
Zang who posted
in this thread about more recent work can comment on his experience. Let
me point out that
Peng Zang's experience of withholding his code because it wasn't quite
finished is very typical.
Unfortunately, Emacs lisp code is never really done. It's always in this
not-sure-this-is-right
state, exactly the kind of murkiness that people who favor languages
like OCaml hate.
I have done the same thing, withholding code. Ironically, it's probably
often people with decent
programming standards who withhold their code, with the effect you can
surely predict.

As far as the problem being a dislike of lisp, no. I'm more of a static
typing kind of guy, but good
implementations of Scheme are certainly respectable languages. Emacs
lisp falls far short of that.
For instance, it has no true higher order functions, and makes an
artificial distinction between function
values and data values. For that matter, it has a somewhat wacky
smattering of types for its data values,
with a lot of redundant parallel functionality that's always getting in
the way. It uses dynamic rather
than lexical scoping. Emacs lisp has no structured datatypes like
records (only lists, arrays, and such),
nor even good conventions for how to simulate them. Scheme dialects
generally implement record types
with macros using a familiar pattern. Speaking of macros, emacs lisp
uses an unsafe kind of macro in
distinction to Scheme's hygienic macros. There's also no notion of
namespace in emacs lisp, nor any
concept of modularization, nor of object. Emacs lisp conflates 3
distinct notions into the symbol "nil":
the empty list, the false boolean, and the symbol whose name is "nil."
Emacs lisp programmers
seem to embrace this confusion with zeal, and this is one of the many
reasons why it's tedious
to translate Emacs lisp code into a higher quality lisp dialect.

Emacs lisp is closer to Common Lisp than Scheme in appearance. In my
opinion, Common Lisp is an overly
complex language, a bit like the C++ of the lisp world. The philosophy
of Scheme, which attempts to
boil down the basic language features to the most fundamental but
powerful building blocks, is a much
more satisfying approach. But while there's a lot of junk and complexity
in Common Lisp, there's
also quite a lot of powerful features to compensate. Not even that is
true of Emacs lisp.

In addition to language deficits like these, the standard libraries of
built in functions in emacs lisp
are quirky, limited, somewhat haphazardly organized, and buggy. And it
executes in a single threaded
environment, which doesn't play well with gui and network features.

Etc.

It is my opinion that Emacs is so poorly designed, and the existing base
of Emacs lisp code is of
such low quality, that continuing to build on top of this foundation is
doomed to produce the same
low quality of software at the same glacial pace as we've seen over the
past 3 decades. My hope is
that people will in fact stop writing Emacs lisp and somehow, through
some magic, a sizable community
can coalesce around a more intelligently designed editor platform. As
always, the issue is the barrier
to entry in a world that's been dominated by two text editors since
ancient times.

By the way, this message was written in Emacs, the editor I've been
using for 25 years.

PS: Almost exactly the same pattern of poor quality and glacially slow
development has plagued the TeX/LaTeX
world over the past few decades and I believe the issue is the same. If
anything, the foundations of TeX are
even worse than of Emacs. That's another place where someone with an
understanding of modern language
design could make an enormous contribution.

Peng Zang

unread,
Oct 20, 2008, 10:22:39 PM10/20/08
to caml...@yquem.inria.fr, Richard Jones, Robert Morelli
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 20 October 2008 07:02:46 pm Robert Morelli wrote:
> Because of its poor design, I lost the heart to try to program complex
> tasks in Emacs lisp quite
> a while ago, so I don't have everything fresh in my mind. Perhaps Peng
> Zang who posted
> in this thread about more recent work can comment on his experience. Let
> me point out that
> Peng Zang's experience of withholding his code because it wasn't quite
> finished is very typical.
> Unfortunately, Emacs lisp code is never really done. It's always in this
> not-sure-this-is-right
> state, exactly the kind of murkiness that people who favor languages
> like OCaml hate.
> I have done the same thing, withholding code. Ironically, it's probably
> often people with decent
> programming standards who withhold their code, with the effect you can
> surely predict.

Let me first say that I've never written anything large in elisp, so take my
views with a grain of salt.

I think for small extensions (eg. SOLID) elisp is fine. Certainly it's not
the best language, but it's better than writing C or Java, more fun than
python and more straightforward than haskell. A couple things bother me
about it which I'll explain in more detail later. The overall point is that
elisp as an editor extension language is satisfising. My reason for not
announcing my code is that I developed it to scratch my own itch. Thus, as
soon as it worked "well enough" I stopped working on it. I've always meant
to make it more robust, write down its assumptions and requirements and
document it for the benefit of the community at large; however, as perhaps
many of you have experienced, "things come up". There's always a fire to put
out, a paper deadline to meet, research to be done, etc...

As to lisp, well, I like the idea of lisp. This includes dialects from scheme
to sbcl to elisp. The main issues that have irked me about elisp are the
same ones that irk me about common lisp in general, eg. dual namespace (one
for functions and one for values). This was a stupid idea and it's
irritating. Lack of a good standard library is another complaint that I
have. But what can you do? Elisp is a CL dialect. Elisp's main
differenciating aspect is dynamic scoping. While for general programming I
think it is a bad idea, for a DSL aimed at extending an editor, I have found
it to be fantastically useful. There may be a safer way to do the things
elisp lets you do. If there is, I would love it. Unfortunately though, I
haven't found an editor that has it. In the mean time, Emacs remains the #1
most extensible, configurable, and flexible editor I know.

In summary, elisp is fine for small things... better than many in fact. I
might even go out on a limb and say for really small things, it's really
great. It's not a great language though, and it has plenty of room for
improvement.

Peng

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFI/TzdfIRcEFL/JewRAmL7AJ0Q1QkkfGaAlKh2/U6UW5m8qAackwCePLK3
neR4MfWIKfitc8xYnIeQtK4=
=9Jl2
-----END PGP SIGNATURE-----

Florian Hars

unread,
Oct 21, 2008, 8:17:49 AM10/21/08
to Robert Morelli, caml...@inria.fr
Robert Morelli schrieb:

> The emacs tags system didn't work for you?

There is no way to produce tags files for emacs that does actually work, no?
exuberant-ctags doesn't support caml, otags is still on 3.09 and ocamltags
doesn't understand files in directories...

Am I missing something?

- Florian.

Jean-Marie Gaillourdet

unread,
Oct 21, 2008, 9:04:06 AM10/21/08
to caml...@inria.fr
Hi,

and there is of course Yi[1], although it is written in Haskell.

[1] http://www.haskell.org/haskellwiki/Yi

Regards,
Jean-Marie

David Teller wrote:
> Just for the sake of bibliography, this reminds me of efuns [1] and
> Chamo [2].
>
> [1] http://pauillac.inria.fr/cdrom/prog/unix/efuns/eng.htm
> [2] http://home.gna.org/cameleon/
>
> Cheers,
> David

_______________________________________________

Dmitry Bely

unread,
Oct 21, 2008, 9:15:08 AM10/21/08
to caml...@inria.fr
On Mon, Oct 20, 2008 at 5:19 PM, Kuba Ober <obe...@osu.edu> wrote:
> I have questions to the kind folks at Jane Street,
> and others who use OCaml for commercial/non-research
> development: what do you guys use for your development
> environment? What would be the minimal set of functionality
> that would make you happy for an IDE? What are killer features
> you dream of?

I really like OcaIDE (http://ocaml.eclipse.ortsa.com:8480/ocaide/).
It's Eclipse plugin so Windows is fully supported (including graphical
debugging). IMHO it's (almost) ready for commercial development. Many
features are very convenient: hyperlink jumps, code outline, type
tooltip on mouse hoovering, completion etc. Give it a try.

- Dmitry Bely

Hugo Ferreira

unread,
Oct 21, 2008, 9:51:35 AM10/21/08
to caml...@inria.fr
Dmitry Bely wrote:
> On Mon, Oct 20, 2008 at 5:19 PM, Kuba Ober <obe...@osu.edu> wrote:
>> I have questions to the kind folks at Jane Street,
>> and others who use OCaml for commercial/non-research
>> development: what do you guys use for your development
>> environment? What would be the minimal set of functionality
>> that would make you happy for an IDE? What are killer features
>> you dream of?
>
> I really like OcaIDE (http://ocaml.eclipse.ortsa.com:8480/ocaide/).
> It's Eclipse plugin so Windows is fully supported (including graphical
> debugging). IMHO it's (almost) ready for commercial development. Many
> features are very convenient: hyperlink jumps, code outline, type
> tooltip on mouse hoovering, completion etc. Give it a try.
>

In other words, Dmitry's short list for Camelia is OcalIDE's feature's
list ;-)

Seriously, give it a try. It's a good way to see how things could be
done.

Hugo F.

P.S: I am curious as to the distribution regarding IDE/editor use.

Christian Stork

unread,
Oct 21, 2008, 12:57:55 PM10/21/08
to caml...@yquem.inria.fr
(I know it's off-topic, but anyway...)

You should be happy to find out about Yi, an editor written in Haskell:

http://www.haskell.org/haskellwiki/Yi

On Mon, Oct 20, 2008 at 05:02:46PM -0600, Robert Morelli wrote:
..


> PS: Almost exactly the same pattern of poor quality and glacially slow
> development has plagued the TeX/LaTeX
> world over the past few decades and I believe the issue is the same. If
> anything, the foundations of TeX are
> even worse than of Emacs. That's another place where someone with an
> understanding of modern language
> design could make an enormous contribution.

I wholeheartetly agree and think of this each time I use TeX!

--
Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F

Kuba Ober

unread,
Oct 21, 2008, 2:36:37 PM10/21/08
to caml...@yquem.inria.fr
> > I really like OcaIDE (http://ocaml.eclipse.ortsa.com:8480/ocaide/).
> > It's Eclipse plugin so Windows is fully supported (including graphical
> > debugging). IMHO it's (almost) ready for commercial development. Many
> > features are very convenient: hyperlink jumps, code outline, type
> > tooltip on mouse hoovering, completion etc. Give it a try.
>
> In other words, Dmitry's short list for Camelia is OcalIDE's feature's
> list ;-)
>
> Seriously, give it a try. It's a good way to see how things could be
> done.

I will give it a try, prepare a feature list, and ask people to vote on
priorities. I will follow Joel Spolsky's feature selection process. This
will happen no earlier than 30 days from now, as getting Camelia into shape
is my first priority, extra features will come later.

Cheers, Kuba

Till Varoquaux

unread,
Oct 21, 2008, 3:31:37 PM10/21/08
to Kuba Ober, caml...@yquem.inria.fr
I am answering as someone who works at jane street but not for jane
street (i.e. this is my personal point of view but I am a Jane street
employee).

First of all thank you for tackling the IDE problem. Anything that's
good for the Ocaml community is, by osmosis, good for companies
working with Ocaml even if it is indirectly.

There is a mix of Emacs,vim,texmate and other esoteric editors being
used here. We are all free to choose what we use but I think a lot of
us decide to cope with a steeper learning curve in order to gain more
flexibility (there's a big difference between hacking as your day job
and coding for a one term class). Dethroning emacs (or vim or ....)
might therefor be a bit of a challenge. That being said a fair amount
of advanced IDE features can be oloaded to external tools (in the
spirit of ocamlwizard). I would really love to see a user friendly IDE
interfacing with such a tool (with the heavy lifting done in an
external tool so that other editors could also benefit cheaply from
advanced features like refactoring).

We tend to work with really large code bases and cannot allow editors
we use to dictate the way we build and/or structure our tree. This
means that emacs/vim are currently closer to our needs than
eclipse/visual studio. This, however, might be very different for
student in an introduction to functional programming class. I thinks
both use cases exists and should be considered (maybe in different
IDE's) you may decide to cater to either or even both. Whatever you do
I know many of us will be following potential outcomes closely.

Till

Philippe Strauss

unread,
Oct 21, 2008, 4:26:56 PM10/21/08
to Caml List
Hello,

I'm somewhat ashamed of myself, but I must confess: I'm one of those wimps using texmate! ;-)
I like the long time spent in front of it without my eyes being too tired (mostly due
to the good mac font antialiasing), the set of color scheme, support for ocaml.

What would make me switch: a way to highlight the error when compiling, highlighting
the line, a stronger highlight for the character range reported by the compiler, taking
in consideration the tab mode used (real tab, n spaces) to interpret the value returned
by the compiler.
the error message in an infobulle and a log area.

An integrated ocamlbrowser (the standard TK tend to jiggle and hang on my computer).

An integrated small terminal window.

A mean to prevent you from the obscure error message about the very last char of the
file, that after (for a beginner) 10 minutes of nervous fight you end up discovering in
the first half of your file a missing syntax. I've been told emacs tuareg do that, maybe your
autoindent mode already do it.

Will test camelia 2.0 for sure.
Thanks.

--
Philippe Strauss
http://philou.ch

Kuba Ober

unread,
Oct 22, 2008, 8:42:30 AM10/22/08
to caml...@yquem.inria.fr
> What would make me switch: a way to highlight the error when compiling,
> highlighting the line, a stronger highlight for the character range
> reported by the compiler, taking in consideration the tab mode used (real
> tab, n spaces) to interpret the value returned by the compiler.
> the error message in an infobulle and a log area.

That's actually nearly what Camelia has right now. Right now Camelia
insists on not dealing with tabs at all -- it converts them all to
spaces. This "feature" has to go obviously, and it's a few-liner to
convert between characters (which include tabs) and columns.
The editor widget in Qt has a good text document model, and
iteration/selections are implemented via a text cursor class.
It's very easy to have multiple, even overlapping selections -- they
are all handled by the editor code, pretty much transparently.

> An integrated ocamlbrowser (the standard TK tend to jiggle and hang on my
> computer).

OK, I'm adding this to my feature list. I didn't even know ocamlbrowser
existed (never quite made it through the manual, I'm afraid).

> An integrated small terminal window.

It's there.

> A mean to prevent you from the obscure error message about the very last
> char of the file, that after (for a beginner) 10 minutes of nervous fight
> you end up discovering in the first half of your file a missing syntax.
> I've been told emacs tuareg do that, maybe your autoindent mode already do
> it.

I presume you're talking about missing closing elements (parentheses etc.).
Yes, they can be automatically highlighted.

> Will test camelia 2.0 for sure.

I will first release 1.90, which will be an alpha, then a few releases later
we'll have a beta, and then 2.0 ;)

I know for sure now that 1.90 release will be a single executable that can
be run from anywhere, which will make it more convenient to test.

Cheers, Kuba

David Teller

unread,
Oct 22, 2008, 5:56:29 PM10/22/08
to Kuba Ober, caml...@yquem.inria.fr
On Wed, 2008-10-22 at 08:42 -0400, Kuba Ober wrote:
> > An integrated ocamlbrowser (the standard TK tend to jiggle and hang on my
> > computer).
>
> OK, I'm adding this to my feature list. I didn't even know ocamlbrowser
> existed (never quite made it through the manual, I'm afraid).

For information, we have the beginning of a ocamlbrowser replacement in
Batteries.

Cheers,
David

--
David Teller-Rajchenbach
Security of Distributed Systems
http://www.univ-orleans.fr/lifo/Members/David.Teller
Angry researcher: French Universities need reforms, but the LRU act brings liquidations.

_______________________________________________

David Teller

unread,
Oct 22, 2008, 6:39:39 PM10/22/08
to Caml
Le me be more specific: we're not working on a ocamlbrowser replacement.
We're just working on a on-line help system. In turn, this help system
could be useful for someone wishing to write a ocamlbrowser replacement.

Cheers,
David

Peng Zang

unread,
Oct 22, 2008, 8:22:19 PM10/22/08
to caml...@yquem.inria.fr
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 21 October 2008 03:31:26 pm Till Varoquaux wrote:
> There is a mix of Emacs,vim,texmate and other esoteric editors being
> used here. We are all free to choose what we use but I think a lot of
> us decide to cope with a steeper learning curve in order to gain more
> flexibility (there's a big difference between hacking as your day job
> and coding for a one term class). Dethroning emacs (or vim or ....)
> might therefor be a bit of a challenge. That being said a fair amount
> of advanced IDE features can be oloaded to external tools (in the
> spirit of ocamlwizard). I would really love to see a user friendly IDE
> interfacing with such a tool (with the heavy lifting done in an
> external tool so that other editors could also benefit cheaply from
> advanced features like refactoring).
>
> We tend to work with really large code bases and cannot allow editors
> we use to dictate the way we build and/or structure our tree. This
> means that emacs/vim are currently closer to our needs than
> eclipse/visual studio. This, however, might be very different for

I agree. There are many different use cases, different types of developers
with different goals and styles. Putting most of the heavy lifting into
external tools so that can be integrated into any editor would be a great
boon across the board.

Actually, how did ocamlwizard go? I seemed to have missed the OSC results.
The proposal looked promising..

Peng


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFI/8OvfIRcEFL/JewRAnFeAJsFLZs4EfEsW4o7VoFY0g1oNQijHgCbBK/Y
BOy2qu3Nomzng5bpJqT27is=
=3Cmt
-----END PGP SIGNATURE-----

Hugo Ferreira

unread,
Oct 23, 2008, 3:47:40 AM10/23/08
to Kuba Ober, caml...@yquem.inria.fr
Hello,

Kuba Ober wrote:
>> What would make me switch: a way to highlight the error when compiling,
>> highlighting the line, a stronger highlight for the character range
>> reported by the compiler, taking in consideration the tab mode used (real
>> tab, n spaces) to interpret the value returned by the compiler.
>> the error message in an infobulle and a log area.
>
> That's actually nearly what Camelia has right now. Right now Camelia
> insists on not dealing with tabs at all -- it converts them all to
> spaces. This "feature" has to go obviously, and it's a few-liner to
> convert between characters (which include tabs) and columns.

What do you mean with this? Reason I ask is that in OcalIDE an option to
save files with spaces only, was added because it allows one to
simultaneously edit files in various editors, each with its own tab
"length". If not, indenting is not maintained. I myself think that
avoiding tabs altogether is a good solution.

Regards,
Hugo F.

Romain Bardou

unread,
Oct 23, 2008, 4:27:11 AM10/23/08
to caml-list caml-list
>> That's actually nearly what Camelia has right now. Right now Camelia
>> insists on not dealing with tabs at all -- it converts them all to
>> spaces. This "feature" has to go obviously, and it's a few-liner to
>> convert between characters (which include tabs) and columns.
>
> What do you mean with this? Reason I ask is that in OcalIDE an option to
> save files with spaces only, was added because it allows one to
> simultaneously edit files in various editors, each with its own tab
> "length". If not, indenting is not maintained. I myself think that
> avoiding tabs altogether is a good solution.

I agree.

Even without changing your editor, you can change the tab length.

Moreover, if the editor uses tabs and counts them as more than one
character (default behavior of emacs) it won't be able to locate errors
correctly.

Finally, when you use backspace to delete one space and suddenly it
deletes eight of them because it was actually a tab, it's annoying
because it's unpredictable.

Altogether, this means that if you edit a file and put tabs in it, it
may work for you, but it may annoy the people you give your file to :p

--
Romain Bardou

Thomas Gazagnaire

unread,
Oct 23, 2008, 6:13:45 AM10/23/08
to Romain Bardou, caml-list caml-list
I would prefer to not have an editor which modify completely the file I am
working on (ie. automatically replace tab by spaces). When working on big
project, you cannot assume that everybody use spaces-based editor, and you
still want to minimize the diff size of your patches.

Thomas

2008/10/23 Romain Bardou <Romain...@lri.fr>

Hugo Ferreira

unread,
Oct 23, 2008, 7:01:52 AM10/23/08
to Thomas Gazagnaire, caml-list caml-list, Romain Bardou
Thomas Gazagnaire wrote:
> I would prefer to not have an editor which modify completely the file I
> am working on (ie. automatically replace tab by spaces). When working on
> big project, you cannot assume that everybody use spaces-based editor,
> and you still want to minimize the diff size of your patches.
>

That is the whole issue. If you work in a big project wherein everyone
can you use their own "tab length", maintaining consistent indentation
is difficult (if not impossible). As Romain Bardou pointed out, you
can even use the same editors with differing "tab length". Real messy.
And the bigger the project and the longer it needs maintenance the worse
it gets.

BTW, I believe all editors are "space based" :-)

HF.

> Thomas
>
> 2008/10/23 Romain Bardou <Romain...@lri.fr

> <mailto:Romain...@lri.fr>>

> ------------------------------------------------------------------------

Baudet David

unread,
Oct 23, 2008, 9:53:33 AM10/23/08
to caml...@yquem.inria.fr
> I agree. There are many different use cases, different types of developers
> with different goals and styles. Putting most of the heavy lifting into
> external tools so that can be integrated into any editor would be a great
> boon across the board.
>
> Actually, how did ocamlwizard go? I seemed to have missed the OSC results.
> The proposal looked promising..
>


Ocamlwizard is available here from Osp Meeting: http://ocamlwizard.lri.fr/
The OSP result is here : http://ocaml.janestreet.com/?q=node/38

Me and Mohammed were very busy this last month (from the osp meeting), but
Mohamed have updated the website and the Newer will be online in few days, I
think...

Me, I try to finish the "developper documentation" this next week to help
some best implementation of this tools in emacs and other IDE... and to
explain our implementation, I prepare too a short video to show "how
install" and "use" ocamlwizard.

We try to finish some part of ocamlwizard, but we can't promise when... for
this time.

We didn't answer at all question on ocamlwizard, but I have read it (and I
am sure, Mohamed too) and I wil continue every weeks to read caml list...
and I hope this developper documentation answer for me.

..Sorry for my english...


| Ocamlwizard Team
| ------------------
| Baudet David
| M2 Programmation and Developpment, Gamagora
| ------------------
| http://dafide.free.fr/
| (En construction)
| -------------------

Vincent Hanquez

unread,
Oct 23, 2008, 10:10:36 AM10/23/08
to Hugo Ferreira, Romain Bardou, caml-list caml-list
On Thu, Oct 23, 2008 at 12:01:00PM +0100, Hugo Ferreira wrote:
> Thomas Gazagnaire wrote:
>> I would prefer to not have an editor which modify completely the file I
>> am working on (ie. automatically replace tab by spaces). When working
>> on big project, you cannot assume that everybody use spaces-based
>> editor, and you still want to minimize the diff size of your patches.
>>
>
> That is the whole issue. If you work in a big project wherein everyone
> can you use their own "tab length", maintaining consistent indentation
> is difficult (if not impossible). As Romain Bardou pointed out, you
> can even use the same editors with differing "tab length". Real messy.

tab has no length. projects tab-indented (not talking about alignment here),
is the only consistant choice that permit everyone in this same project
to use any *representation* they want for their indentation (8 spaces, 2
spaces, 4 spaces, 11 spaces, ...) without making a mess.

--
Vincent

Romain Bardou

unread,
Oct 23, 2008, 10:43:20 AM10/23/08
to Vincent Hanquez, Hugo Ferreira, Romain Bardou, caml-list caml-list
> tab has no length. projects tab-indented (not talking about alignment here),
> is the only consistant choice that permit everyone in this same project
> to use any *representation* they want for their indentation (8 spaces, 2
> spaces, 4 spaces, 11 spaces, ...) without making a mess.

Sure, this would work if you could force everyone to follow this
convention AND that your indentations are always a multiple of the same
number of spaces. Unfortunately, the later does not seem to hold for
OCaml programs. For instance:

let x = List.map (fun z ->
very_long_stuff_blablablablablablablabla)

IMO this is ugly and I try to avoid this indentation style, but it is
not always easy and it is the behavior of the Tuareg mode (OCaml mode
for emacs), and I think the vim OCaml mode too.

--
Romain Bardou

Dave Benjamin

unread,
Oct 23, 2008, 11:24:37 AM10/23/08
to Romain Bardou, Hugo Ferreira, caml-list caml-list
Romain Bardou wrote:
> let x = List.map (fun z ->
> very_long_stuff_blablablablablablablabla)

I tend to write this sort of thing as:

let x =
List.map
(fun z ->
very_long_stuff_blablablablablablablabla)

...

which, as you may notice, still can't be done with tabs alone due to the
extra space after the opening parenthesis. I'm curious what you all
think of this coding style, which seems on one hand to be excessively...
um, vertical? but it does seem to strike a balance between Tuareg's
indentation rules and the problem of "running into the margin" too quickly.

BTW, If you keep the function on the first line, it's a bit more
compact, but the indentation no longer tells the truth about the real
hierarchy:

let x = List.map
(fun z ->
very_long_stuff_blablablablablablablabla)

...

This is why I tend to put the function on a line of its own as soon as
things start to wrap.

Dave

Kuba Ober

unread,
Oct 23, 2008, 1:13:58 PM10/23/08
to caml...@inria.fr
On Wednesday 22 October 2008, you wrote:
> Thanks, I tried it and I love the simplicity vis-a-vis eclipse's
> baroqueness. But am I missing something?
> When I type in a line of caml followed by a CR the cursor lines up all
> the way to the left rather than indenting
> on the next line. Once I'm doing I can hit the indent button and all
> is well but I'm wondering if there is a way to
> get it to indent for me as I go along. (Otherwise the code looks funky
> as I write it.)

This is perhaps a bug in the code. I don't have time nor incentive
to fix the 1.2 code line, which uses Qt3 (and Qt3 portability classes in Qt4),
but it's there in the SVN repository and the world is free to send me patches
;).

I am aware of most of these problems and my primary goal is to eliminate
silliness and follow the principle of least astonishment.

Cheers, Kuba

Kuba Ober

unread,
Oct 23, 2008, 1:17:59 PM10/23/08
to caml...@inria.fr
> >> What would make me switch: a way to highlight the error when compiling,
> >> highlighting the line, a stronger highlight for the character range
> >> reported by the compiler, taking in consideration the tab mode used
> >> (real tab, n spaces) to interpret the value returned by the compiler.
> >> the error message in an infobulle and a log area.
> >
> > That's actually nearly what Camelia has right now. Right now Camelia
> > insists on not dealing with tabs at all -- it converts them all to
> > spaces. This "feature" has to go obviously, and it's a few-liner to
> > convert between characters (which include tabs) and columns.
>
> What do you mean with this? Reason I ask is that in OcalIDE an option to
> save files with spaces only, was added because it allows one to
> simultaneously edit files in various editors, each with its own tab
> "length". If not, indenting is not maintained. I myself think that
> avoiding tabs altogether is a good solution.

This is likely to erupt into a flamewar ;) I will leave it to the user to
choose. I have no preference personally, and this is a matter of taste
and people get religious about it: so no point arguing either way.

I will support space-only mode, mixed space-tab mode, and also different
indent styles between expressions/statements and within them. Basically
whatever emacs/vi does, I will do as well, leaving it to the user to choose.

Depending on time constraints, the full gamut of choices may be relegated
to 2.1, but I have it all on my mind.

Cheers, Kuba

Kuba Ober

unread,
Oct 23, 2008, 1:20:40 PM10/23/08
to caml...@yquem.inria.fr
On Thursday 23 October 2008, Vincent Hanquez wrote:
> On Thu, Oct 23, 2008 at 12:01:00PM +0100, Hugo Ferreira wrote:
> > Thomas Gazagnaire wrote:
> >> I would prefer to not have an editor which modify completely the file I
> >> am working on (ie. automatically replace tab by spaces). When working
> >> on big project, you cannot assume that everybody use spaces-based
> >> editor, and you still want to minimize the diff size of your patches.
> >
> > That is the whole issue. If you work in a big project wherein everyone
> > can you use their own "tab length", maintaining consistent indentation
> > is difficult (if not impossible). As Romain Bardou pointed out, you
> > can even use the same editors with differing "tab length". Real messy.
>
> tab has no length. projects tab-indented (not talking about alignment
> here), is the only consistant choice that permit everyone in this same
> project to use any *representation* they want for their indentation (8
> spaces, 2 spaces, 4 spaces, 11 spaces, ...) without making a mess.

Exactly, and that's why indentation in-between statements/expressions
can use tabs with arbitrary length, but indentation within statements/
expressions (split between lines) has to copy previous line's indentation
up to the starting column, and then use solely spaces. Same goes for
indentation of comments that follow a non-blank line (can only use spaces).
There are several orthogonal issues here, all are well known, so please let's
not prolong this thread ;)

Cheers, Kuba

Maxence Guesdon

unread,
Oct 24, 2008, 3:18:05 AM10/24/08
to caml...@yquem.inria.fr
On Thu, 23 Oct 2008 15:53:19 +0200
"Baudet David" <dafi...@gmail.com> wrote:

> > I agree. There are many different use cases, different types of developers
> > with different goals and styles. Putting most of the heavy lifting into
> > external tools so that can be integrated into any editor would be a great
> > boon across the board.
> >
> > Actually, how did ocamlwizard go? I seemed to have missed the OSC results.
> > The proposal looked promising..
> >
>
>
> Ocamlwizard is available here from Osp Meeting: http://ocamlwizard.lri.fr/
> The OSP result is here : http://ocaml.janestreet.com/?q=node/38
>
> Me and Mohammed were very busy this last month (from the osp meeting), but
> Mohamed have updated the website and the Newer will be online in few days, I
> think...
>
> Me, I try to finish the "developper documentation" this next week to help
> some best implementation of this tools in emacs and other IDE... and to
> explain our implementation, I prepare too a short video to show "how
> install" and "use" ocamlwizard.
>
> We try to finish some part of ocamlwizard, but we can't promise when... for
> this time.
>
> We didn't answer at all question on ocamlwizard, but I have read it (and I
> am sure, Mohamed too) and I wil continue every weeks to read caml list...
> and I hope this developper documentation answer for me.

Talking about ocamlwizard, why does it embed a part of ocaml sources
rather than use a configure option to find the compiled sources of ocaml ?
This would allow to compile ocamlwizard with any (compatible) version of
ocaml (even a cvs version). For example, how to use it with ocaml 3.11 beta1
without modifying the copied parts of ocaml present in ocamlwizard ?

That's how topcameleon is compiled, asking the user where the compiled
sources of ocaml are located.

Having the compiled sources of ocaml is not a problem for an ocaml
developer, and the ocamlwizard users are ocaml developers, aren't they ?

For users of pre-compiled packages (debian, etc.), this is not a problem
for the packagers to have ocamlwizard compiled using the sources of ocaml
used for the ocaml package.

Regards,


--
Maxence Guesdon http://yquem.inria.fr/~guesdon/
Service Expérimentation et Développements https://devel.inria.fr/rocq/
INRIA Paris-Rocquencourt http://www.inria.fr/rocquencourt/

Sylvain Le Gall

unread,
Oct 24, 2008, 4:03:06 AM10/24/08
to caml...@inria.fr
On 24-10-2008, Maxence Guesdon <maxence...@inria.fr> wrote:
> On Thu, 23 Oct 2008 15:53:19 +0200
> "Baudet David" <dafi...@gmail.com> wrote:
>
>> We didn't answer at all question on ocamlwizard, but I have read it (and I
>> am sure, Mohamed too) and I wil continue every weeks to read caml list...
>> and I hope this developper documentation answer for me.
>
> That's how topcameleon is compiled, asking the user where the compiled
> sources of ocaml are located.
>
> Having the compiled sources of ocaml is not a problem for an ocaml
> developer, and the ocamlwizard users are ocaml developers, aren't they ?
>
> For users of pre-compiled packages (debian, etc.), this is not a problem
> for the packagers to have ocamlwizard compiled using the sources of ocaml
> used for the ocaml package.
>

I don't agree, people should take care of the license of the file they
use from OCaml source. You cannot link with everything inside the
source, except if you acknowledge in some way the license of this
source.

A lot of code from the compiler is Q Public license. People should be
aware of this point.

To be short, people using GPL for their code should include the
following term:

As a special exception, you have permission to link this program
with the FOO library and distribute executables, as long as you
follow the requirements of the GNU GPL in regard to all of the
software in the executable aside from FOO.

(when using module FOO).

See http://en.wikipedia.org/wiki/QPL

However, I agree that embeding source of ocaml inside another project is
the worse thing you can do.

Regards,
Sylvain Le Gall

mohamed iguernelala

unread,
Oct 24, 2008, 7:45:19 AM10/24/08
to maxence...@inria.fr, caml...@yquem.inria.fr
> Talking about ocamlwizard, why does it embed a part of ocaml sources
> rather than use a configure option to find the compiled sources of ocaml ?
> This would allow to compile ocamlwizard with any (compatible) version of
> ocaml (even a cvs version). For example, how to use it with ocaml 3.11 beta1
> without modifying the copied parts of ocaml present in ocamlwizard ?

> That's how topcameleon is compiled, asking the user where the compiled


> sources of ocaml are located.

> Having the compiled sources of ocaml is not a problem for an ocaml
> developer, and the ocamlwizard users are ocaml developers, aren't they ?

> For users of pre-compiled packages (debian, etc.), this is not a problem
> for the packagers to have ocamlwizard compiled using the sources of ocaml
> used for the ocaml package.

> Regards,


 
> --
> Maxence Guesdon                           http://yquem.inria.fr/~guesdon/
> Service Expérimentation et Développements https://devel.inria.fr/rocq/
> INRIA Paris-Rocquencourt                  http://www.inria.fr/rocquencourt/

Unfortunately, Its's not possible (for now) to have ocamlwizard compatible with both ocaml-3.10 and ocaml-3.11 for several reasons :
 
Ocamlwizard uses a patched ocaml-3.10 parser to be used on incomplete source files. But I think it is easy to patch an ocaml-3.11 parser to do so.
 
During the first month (during June), we used cvs version of ocaml (3.11). We have patched an ocaml-3.11 parser, we parsed the annot file to get expression's type and read cmi files to get more information and to extract proposals ...
 
But, We've released by the beginning of July that types in .annot (3.10.2) are not always qualified enough. And to give the right qualification we have to perfom a scope analysis. We also need to scope analysis for nagivation in soure code and refactoring.
 
We know its better to use ocaml compiler as a blackbox to increase portability. and we considered this approach as much as possible, but (unfortunately) important information are missing. Performing our own scope analysis it not realistic. The solution we have choose is to embed and ocaml type checker (3.10) and to patch it to have localizations in cmi files (.cmi + localizations = .owz files). I suppose typecheckers in ocaml-3.10 and in ocaml-3.11 are differents.
 
So, we have embed ocaml source files in ocamlwizard (parser + typechecker ) because we have to patch some files to get the information we need. Thus, to be used with ocaml-3.11, one have to patch ocaml-3.11 parser and typechecker.
 
Regards,
 
Mohamed.


DooMeeR

unread,
Oct 25, 2008, 6:14:43 AM10/25/08
to Dave Benjamin, caml-list caml-list, Romain Bardou
Another possibility is:

let x = List.map begin fun z ->
very_blabla
end my_list in

It's quite compact, doesn't run into the margin, is consistent with
tuareg, but might be less readable.

--
Romain Bardou

Dave Benjamin a écrit :