Re: [Caml-list] OCaml popularity

[Max Kirillov <max630@mail.ru>]

On Wed, Mar 12, 2003 at 11:32:09AM +0900, Nicolas Cannasse wrote:
> This had been in my mind (and also in the mind of several other people of
> this list I think) since I started with OCaml. Right now, as one of the few
> ocaml-windows developpers, I'm editing and compiling Ocaml under Visual
> Studio 6. The language is not fully integrated since VC6 does not enable it
> ( while .Net can do it, but is far more expensive and more difficult to
> deploy for a single basic user ). There is the workspace, syntax
> highlightning, automatic compilation, one-key compilation start and
> compilation-error-jump-to-file+line. So it is right now quite convenient to
> work with.
> 
> An IDE will require a far more level of integration such as the possibility
> to "debug" types visualy when having an error ( e.g. just put your mouse /
> cursor on a variable to see its type ) , perhaps an integrated debugger ,
> and of course a multiplatform (unix+windows) GUI since doing it from
> unix-only won't help people from the industry and doing it for windows only
> won't help the large part of the ocaml community.
> 
> The problem here is that such kind of editor is more or less a personnal
> choice, and if you want the current OCaml+Emacs users to switch to such an
> IDE, you'll have to make it fully customizable and add key features that
> will make the difference. Quite a challenge.
> 
> Nicolas Cannasse

There is ocamlbrowser in the distribution. It can typecheck and then be
the type browser as you mention it. I dont know how much of it works on
Windows (I surely have seen it started), but the functionality you want
should not be very os-depended. It is based on analysis of typed tree
after successful typecheck.

As a first step, one writing the VS (or whatever) plugin could just
start from here and take some code from ocamlbrowser.

To go further, there are 2 points.

First, there would be nice to dump a typed tree just like the parsetree
by -dparsetree option. It should be easy to do. Then, you can read the
output and do whatever you want with it.  (though, it is doubtful
parsing the output to use it in VS-ish ides is easier than adding a
IDE-specific reporter to the compiler)

Then, this all OK when there are no errors. But, when there are some
(and this it what is mostly wanted for IDE), typechecking is aborted and
no information if returned. So, it would be great to have possibility to
freeze the typechecking (or even force it further), getting as much
information as possible.  Then, one could see the inferred types and
easily locate the point where they goes wrong. Currently, locating a
typing error it an iterative process -- I insert explicit type
constraint here and there, then compile, then just stare at output and
think, then again. If I could look at typedtree at the moment the typing
error was detected, I suppose this will be much faster.

-- 
Max

P.S. btw, is the "typecheck at error" done for the other languages. I
know there are alot of languages support for the VS. How many of them
cat acquire information from a wrong source?

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners