Toplevel wishlist

Toplevel wishlist

[Andrej Bauer]

Thank you for suggestions on how to tweak custom toplevels.

For a while now I have been thinking that there should be a fancy
alternative to the current toplevel. If I had the time, I would actually
go ahead and try to write one. But what would be a good feature list?

I can think of several improvements:

1) First, provide not only a toplevel but also a library that others
could use to make toplevel-like interfaces to ocaml bytecode engine.

2) Do not hardcode stdin/stdout communication into toplevel. Instead,
have a toplevel that communicates with the outside in a more abstract
way. Thus it should be relatively easy to create toplevels that are
equipped with line editing, that communicate through a graphical user
interface (in a natural way), that talk via Texmacs, etc.

3) Equip toplevel with pretty printers that can manage polymorphic
types, and essentially make it possible to pretty print _everything_. It
should be possible to create a toplevel linked to a graphical user
interface that shows pictures and typeset text as results.

4) Provide reasonable configuration options that allow one to customize
the toplevel in a sensible way (such as pre-installed pretty printers
and pre-open modules). Reading stuff _only_ from .ocamlinit is not fancy
enough.

What else can we put on the wishlist?

If only someone else did it :-)

Andrej

Re: [Caml-list] Toplevel wishlist

[Jonathan Roewen]

> 1) First, provide not only a toplevel but also a library that others
> could use to make toplevel-like interfaces to ocaml bytecode engine.

You mean toplevellib.cma for bytecode? ;-)

> 2) Do not hardcode stdin/stdout communication into toplevel. Instead,
> have a toplevel that communicates with the outside in a more abstract
> way. Thus it should be relatively easy to create toplevels that are
> equipped with line editing, that communicate through a graphical user
> interface (in a natural way), that talk via Texmacs, etc.

Using toplevellib.cma, you can create your own loop that reads/writes
from anything (though, for some reason, it appears the error printing
interface is not in the library dirs--why is that?).

> 4) Provide reasonable configuration options that allow one to customize
> the toplevel in a sensible way (such as pre-installed pretty printers
> and pre-open modules). Reading stuff _only_ from .ocamlinit is not fancy
> enough.

I made my own change to compiler/toplevel to specify modules to open
automatically. Look in mantis for it (it's not a proper patch, but
should be easy enough to apply yourself).

Jonathan

Re: [Caml-list] Toplevel wishlist

[David Teller]

Le jeudi 19 janvier 2006 à 21:13 +0100, Andrej Bauer a écrit :
> 2) Do not hardcode stdin/stdout communication into toplevel. Instead,
> have a toplevel that communicates with the outside in a more abstract
> way. Thus it should be relatively easy to create toplevels that are
> equipped with line editing, that communicate through a graphical user
> interface (in a natural way), that talk via Texmacs, etc.

TeXmacs ? Talk about *extremely* pretty-printing :)

More seriously, do you have any application in mind ? I wonder what kind
of "abstract" information should be communicated. 

> 3) Equip toplevel with pretty printers that can manage polymorphic
> types, and essentially make it possible to pretty print _everything_. It
> should be possible to create a toplevel linked to a graphical user
> interface that shows pictures and typeset text as results.

Nice idea, too. It reminds me of a Microsoft video I saw some time ago
about how The Next Big Thing In Programming Languages (tm) would be
getting rid of syntax.


Cheers,
 David
-- 
Read, Write, and Publish Standard eBooks
  Free, Open Software, Open Standards and multi-platform
    The OpenBerg project http://www.openberg.org

Re: [Caml-list] Toplevel wishlist

[Daniel Bünzli]

Le 19 janv. 06 à 21:13, Andrej Bauer a écrit :

> What else can we put on the wishlist?
A toplevel directive to list value and type specifications defined at  
toplevel or in a given module.
A toplevel directive to profile an execution in space and time, this  
can be implemented by yourself but it would be nice to have it by  
default.

Best,

Daniel