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

yes... I manage to make my own DLL use local_roots using a custom modified
interpreter.
But I think it will be better building a modified ocamllib including missing
globals,
then, you only need to name your lib dll[name].dll and add it in files when
building with
ocamlc / opt.

> > 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 don't know smaltalk, but I think if you have a background compiling
process running and "showing" you errors and another parsing process
which show you tips on arguments names / types , it'll be good enough.

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

yes. Having a interactive buffer to test your code in realtime is a good
feature.

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

( having a window/buffer for each separate module.... )
When you're writting module-oriented ocaml code, you're using different
files for each module. So different buffers....

About the "session" window, a background compiling process will do a great
job.

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

I think a good IDE either have to have an integrated CVS access , or
something like a custom versionning system.
Like this, even when you save and quit , you can always edit again your file
and 'undo changes you have made when you where drunk last nite :)
Borland C++ Builder IDE have for example the poor idea of erazing to undo
buffer when you're saving your file....

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

I think that both are good and can be done in the same project.

Here's my features :
1 - syntax highlightning modes
2 - multiple undo
3 - full customizable shortkeys a la Emacs (conf file written in ocaml)
4 - full buffer/point access API (needed by 3) : search/regexp
5 - indent modes
6 - typing/arguments tips ( using background compiling )
7 - integrated shell
8 - custom versionning

Here's yours (if I have understand) :
1 - "session" buffer for module testing
2 - background compiling not to have the edit/compile style
3 - file backup and versionning

With your win32 api, all theses goals seems reasonable to accomplish.
I think that most of programmers will agree to have theses features enabled,
and if not when can always disable them. The *keyword* to a good IDE is
customization !

Waiting for comments.
Bye
Warp

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