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

[Kuba Ober <ober.14@osu.edu>]

On Friday 31 October 2008, Jon Harrop wrote:
> On Monday 20 October 2008 14:19:40 Kuba Ober wrote:
> > what do you guys use for your development environment?
>
> I use Emacs but I hate it.
:)

> > What would be the minimal set of functionality that would make you happy
> > for an IDE?
>
> . Written in OCaml using OCaml's own lexer and parser to save effort and
> make it possible for others to help develop it without losing their hair.

That's perhaps possible in the longer run by linking some OCaml code in.
Right now Camelia has its own parser. I could port Camelia to OCaml if someone
would first develop Qt bindings for OCaml that would allow me to do in
OCaml what I'm doing in C++ so far ;)

That's an undertaking bigger than Camelia itself. I will not develop for
gtk-anything as lost feature parity with Qt right around the time when Qt 3
came around, IIRC. Qt 4 is leaps and bounds above anything gtk provides, in
terms of integrated functionality. This is not meant as a flamebait, I believe
it to be an accurate statement of fact. I wish I could use gtk since
it's easier to bind with, but I'd end up having to either reimplement parts of
Qt, or have to deal with lots of 3rd party libraries, each from a different
author who had a different API design mindset. Qt takes care of those
integration issues internally and provides a relatively self-consistent API
-- this saves a metric crapton of time (I use the darn thing).

> . A proper GUI (where options can be set using the mouse).

Check ;)

> . Mainstream key bindings, e.g. CTRL+S for save.

Check ;)

> . Jump to definition.

Easy to do -- goes on my to-do list.

> . Graphical throwback of the type of the subexpression under the mouse
> pointer or in the current selection.

Camelia does that.

> . Graphical throwback of the documentation related to what is under the
> mouse pointer.

Easy to do -- goes on my to-do list.

> . Graphical throwback of errors and, in the case of type errors, optional
> highlighting of previous unification points.

Camelia does that.

> . Refactoring, e.g. changing the name of a definition in all occurrences.

Perhaps in version 2.2 ;)

> . Autocompletion that handles structural types in LablGTK code and
> operators, i.e. when the user types "+" present options for int "+", float
> "+.", num "+/" and any other operators that begin with "+".

Version 2.2 ;)

> . Represent an OCaml project as a tree of modules that happen to have the
> first level stored as files.

Level 1 is easy to do, but what's on the second and deeper levels in your 
idea?

> . Performant enough to handle projects with hundreds of thousands of lines
> of code.

Shouldn't be a problem, perhaps as long as you don't put all the lines in one
file ;)

In the long run I may switch to using QCodeEdit from edyuk, which is 
supposedly better performing than QPlainTextEdit. This is just hearsay, and
anyway before I can switch editors I have to refactor a lot of code to move
OCaml-specific functionality out of the editor widget itself. Since I have
to do this refactoring whether I switch editors or not, just to make the
code saner, the editor change decision can wait without undue consequences
(or so I think).

> . Parallel so seven of my cores aren't idle while I'm waiting.

Everything is done in one thread right now, but over time it can be spread
out. Implementing this properly requires refectoring of the code first:
right now Camelia is in no shape to attempt that. After 2.0 release there will
be time to attack that.

> . The ability to hide the tail of +., +/ etc. operators to make numerical
> code more readable.

Easy to do, can go in for 2.0.

> > What are killer features you dream of?
>
> Only one: an interactive top-level where output is presented via graphical
> elements (e.g. a scene graph) and is no longer limited to just ASCII text.
> This would give OCaml the graphical capabilities of Mathematica's
> awesome "notebook" front-end.

How would you like that to work? Do you think about something like ddd, or
a different approach?

Processing toplevel output is an issue nicely orthogonal to editor and
knowledgebase, so this doesn't block on the major refactoring that has
to happen on the editor end.

Cheers, Kuba