Re: [Caml-list] Win32 API

["Harry Chomsky" <harry@chomsky.net>]

> Then , it'll try to build the Dynamic Link Library version of Win32_c,
which
> is easier to use
> with bytecode ocaml.

I was thinking it would be nice to do this, but I haven't had a chance to
look at the new dynamic-linking features in 3.04 so I haven't tried to
implement it yet.  It would be great if you could figure out how to make
this work.

> I would also like to share your ideas about a future OCaml IDE on Win32.

I've been tossing ideas around in my head for a long time.  I'm not
interested in writing a standard IDE based on the traditional
edit/compile/run cycle.  I'm very fond of the Smalltalk style of interactive
programming, and I want to see how close I can come to it in a static
language with a traditional compilation model like OCaml.  Basically, I want
to blur the line between writing code in files and compiling it, on the one
hand, and entering expressions into the toplevel for evaluation, on the
other.

I started thinking about this when playing with Hugs, which is a cute
interactive system with the unfortunate severe limitation that you can't
bind new variables at the toplevel.  You can define a function, but you
can't give it a name and call it by that name in subsequent expressions you
enter.  The limitation actually makes a lot of sense, given the nature of
the Haskell language: it's much more declarative than OCaml, and a module is
meant to appear "all at once" rather than "one command at a time" as in
OCaml.  Just as function calls have no side effects, so also you can't enter
an expression that has the "side effect" of binding a new name.  It became
clear to me that a good Haskell IDE should have a window for each module
you're working with, with an editable display of the module's code in the
main panel, and a separate little panel at the bottom where you can enter
expressions to be evaluated in the context of the module.  That would give
you the interactivity of Hugs along with the ability to do real programming.

But I decided to focus on OCaml first, both as an implementation language
and as a target language.  It wasn't quite as clear to me how to build a
tool like this for OCaml, because things you do at the toplevel have effects
that accumulate.  I think I've finally got my ideas worked out though, with
some help from Dan Pless, whom I've cc'ed.  Again, each module should have a
window where you edit its code; then there will be a separate window (or
perhaps several) where you enter commands to execute interactively in the
context of all the modules.  This "session" window will feel like the
toplevel in some ways, but less line-oriented.  It will keep a record of the
commands you've entered and the results they've yielded, and when you change
something in one of the modules you will have the option of automatically
reexecuting all the commands in the new context.  There should also probably
be a way to capture the sequence of commands from the session into a new
module which you can then edit normally.

The Smalltalker in me insists that the code you're editing be stored on disk
in a temporary location for compilation and crash protection, but not be
accessible as a normal set of files until you decide to "save" it.  In other
words, you can make changes to your modules and try out the new code without
saving your changes, then if you like the way they work you save them all at
once.  This gives the programmer the freedom to play around with new ideas
without bothering to make backups and keep track of them.  Once the code is
saved, it looks just like a traditional program -- you can distribute it and
grep it and all that.

Looking at your message from last week, I'm not sure if what I'm going to
work on matches your goals very well.  Perhaps the ultimate IDE could have
all the Emacs-like features you're interested in as well as the
Smalltalk-like approach that I'm interested in... or perhaps my ideas are
too far outside the mainstream of most programmers' tastes.  I'm curious to
hear what you think.
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr