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

[Jon Harrop <jon@ffconsultancy.com>]

On Monday 03 November 2008 14:15:38 Kuba Ober wrote:
> On Friday 31 October 2008, Jon Harrop wrote:
> > . 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.

You reimplemented the whole OCaml parser in C++? Does it handle Camlp4 syntax 
extensions?

> 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 may already be possible if you go via more mainstream dynamic languages 
like Python. However, python-qt4-dev has fewer installs on Debian and Ubuntu 
than OCaml does, so you may well find that the Python bindings are inadequate 
as well.

> 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.

I can well believe that. Another option is to create a new GUI toolkit from 
scratch in OCaml.

> 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.

And WPF is leaps and bounds above anything Qt 4 provides, in terms of 
functionality, integration and performance. Combined with the fact that using 
Qt4 from a decent language is very hard and basically completely pointless by 
design anyway, I think there is a strong argument for starting from scratch.

> 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).

Swings and roundabouts. The metric crapton of time you save with Qt4's 
functionality is paid by having to use an awful language.

> > . Graphical throwback of the documentation related to what is under the
> > mouse pointer.
>
> Easy to do -- goes on my to-do list.

How would you implement it?

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

Cool. AFAIK, OCaml does not export information about unification points. So 
how do you get hold of that data in Camelia?

> > . Refactoring, e.g. changing the name of a definition in all occurrences.
>
> Perhaps in version 2.2 ;)

Fair enough. That is not essential.

> > . 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 ;)

I believe that kind of IDE support would allow a language like OCaml (i.e. 
without overloading) to handle arithmetic over many types gracefully.

> > . 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?

The first level is defined by the filename and all subsequent levels are 
defined as nested modules within a file. I would not mind if the IDE 
abstracted away the concept of files completely: they have no place in modern 
programming IMHO.

> > . 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.

Until you get a significant user base I wouldn't worry about it.

> > . 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.

It is trivial if you can pull the sources of the OCaml compiler into your IDE 
and if OCaml has a parallel GC. ;-)

> > . The ability to hide the tail of +., +/ etc. operators to make numerical
> > code more readable.
>
> Easy to do, can go in for 2.0.

You need type throwback on operators as well, of course.

> > > 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?

It is a logical progression from building your own GUI toolkit. You represent 
graphics using scene graphs. Everything in an interactive session is 
converted into scene graphs for rendering.

So:

  val pretty_printer : Expr.t -> string

becomes:

  val pretty_printer : Expr.t -> Scene.t

and the resulting Scene.t is fed through a renderer like Smoke.

> Do you think about something like ddd, or a different approach?

Look at Mathematica (and not ddd) for inspiration.

> 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.

Yes and no. I assume your editor is completely hard-wired from the ground up 
for editing plain text and maybe even unicode but is completely incapable of 
rendering arbitrary vector graphics. If so, it will need to be completely 
gutted.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e