RE: [Caml-list] Future of labels

RE: [Caml-list] Future of labels

[Manuel Fahndrich]

I use label in classic mode, mostly to disambiguate arguments of the
same type and a little bit for documentation.

To see if I could do with modern mode, I tried to compile my current
code base with -modern. This seems to not be too bad, except for 2
things, one being a show stopper:

1) The standard library requires ~f: labels on many function arguments.
That seems silly. I basically had to add ~f: to many places where it did
not add disambiguation (f is not a very explicit name). I can see that
for partial applications that might be useful, but still I found this a
bit annoying.

2) If some library function requires a function argument with labeled
arguments, such as Map.fold f:(key:key -> data:'a -> 'b -> 'b)
and I happen to have a function around that would do the right fold
operation, except that it is unlabeled or has different labels, then I'm
stuck. I have to write an eta conversion. Why isn't an explicit cast to
change the labels of a function sound? I tried that and it didn't work.

Other than the above, it seems that a casual user like me could move
from classic to modern, especially if there are some further benefits
like partial applications in different orders.  One thing that needs
improvement though are the error messages. Because the compiler tries to
reorder arguments etc., forgetting a label spits out really whacky
messages like, this function expects too many arguments.

-Maf
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] Future of labels

[Jacques Garrigue]

Nice, it seems that we can have a relaxed discussion this time :-)

OK, I'll first try to  correct some (potential) misunderstandings.

* I'm not sure this is a misunderstanding, but at least it may seem
  that some (Chris, Arturo) are implying that optionals argument do
  not commute in classic mode. They do commute in both classic and
  label mode, and there is no plan to change this behavior. That
  means that if you are only interested in labels on optional
  arguments, classic mode is already enough.

* The possibility to "omit labels" in classic mode, and to "omit
  optional arguments" in both modes may be confusing. These are
  completely unrelated features: the worst wording would be to say
  "labels on non-optional arguments are optional in classic mode"

* The rules in the P.S. of my previous mail describe a potential new
  version for _classic_ mode. This does not replace label mode.

* From both theory and implementation point of view, classic mode is
  not simpler than label mode. They both share optional arguments,
  which is the most complex part.

Otherwise it seems that we've got a nice array of answers, covering
everything from the die-hard non-labelist (Chris) to the die-hard
labelist (myself).
Sorry for Judicael, but I see no way to satisfy everybody with a single
mode. (You don't expect me to just drop the label mode, and be happy
with classic, no ?)

Yet, I see no strong support for the label features of classic mode:
* decorative labels in interfaces
  (I thought it could be very useful, particularly if one uses
   ocamlbrowser.)
* the ability to write labels in the code, just to increase safety

On the other hand Manuel expresses an opinion I've heard a few times:
moving to label mode might be nice, if the price to pay was not so
high.

To keep the discussion open, here is a 3rd alternative, which involves
making label mode the default mode, removing labels from the standard
library (to keep compatibility with ocaml 2, that's paramount), and
keeping a simplified classic mode for those who don't want to hear of
labels at all. 

* Label mode as default, with no labels in the standard library
  This makes moving to label mode very easy, the only needed
  modifications are when using new libraries that have labels.
  For current label mode users, some (partial) compatibility libraries
  would be provided, so that they (I?) don't have to drop all their
  dear(?) labels.
  (I'm mostly concerned with Pervasives, List, Array, String, and Unix)

* The simplified classic mode would simply prohibit writing labels on
  non-optional arguments in function application. You're free to write
  them anywhere else (abstraction or interfaces), but they are simply
  ignored, and never cause a type error.
  Basically that means that the only rule for non-optional parameters is
        (fun ~l:x -> e) v --> e[v/x]
  That makes all the theory simpler, and we recover soundess :-)
  Only problem: it is no longer possible to write everything in the
  intersection of classic and label mode. I generally try to do this
  when I write examples, but this would become impossible with some
  libraries.
  As a result this mode would have to be demoted: documentation is
  written for default mode, and no-label mode users are on their own
  to remove spurious labels.
  Even demoted, label users might still need it for some
  administrative tasks, like adding a labeled interface to a
  non-labeled library.

Would Chris (who doesn't write the labels anyway) be happy with
something like that ?
Would others enjoy moving to label mode at no cost (with libraries
compatible with 2.x) ?
That is, would they be ready to write more labels when they use
labeled libraries (like labltk) ?
Are there some real users of classic mode around (who use what I
called its "label features"), and would they fit in any of these two
categories ?
How much do label users care for having labels in the standard library?

Here are a few more answers to Manuel, whose post was closest to this
proposal:

From: "Manuel Fahndrich" <maf@microsoft.com>

> I use label in classic mode, mostly to disambiguate arguments of the
> same type and a little bit for documentation.

Nice, a real classic mode user!

> To see if I could do with modern mode, I tried to compile my current
> code base with -modern. This seems to not be too bad, except for 2
> things, one being a show stopper:
> 
> 1) The standard library requires ~f: labels on many function arguments.
> That seems silly. I basically had to add ~f: to many places where it did
> not add disambiguation (f is not a very explicit name). I can see that
> for partial applications that might be useful, but still I found this a
> bit annoying.

Not really for partial application (you rarely want to apply to a list
before the function), but rather for layout. Mostly a question of
taste, but if you like it really changes the way you use functionals.

Anyway, if we remove labels from the standard library, this would
solve the problem.
 
> 2) If some library function requires a function argument with labeled
> arguments, such as Map.fold f:(key:key -> data:'a -> 'b -> 'b)
> and I happen to have a function around that would do the right fold
> operation, except that it is unlabeled or has different labels, then I'm
> stuck. I have to write an eta conversion. Why isn't an explicit cast to
> change the labels of a function sound? I tried that and it didn't work.

The notion of soundness being with respect with an untyped reduction
semantics (cf http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/),
changing labels through a cast cannot be sound...

Is it that big a problem in practice ?
I really doubt it: I discussed it with some heavy Haskell users, and
repeatedly got the answer that they don't use fold because this
produces unreadable code. Labels and eta-expansion are just necessary
steps to make it readable.

Anyway, if we remove....
 
> Other than the above, it seems that a casual user like me could move
> from classic to modern, especially if there are some further benefits
> like partial applications in different orders.  One thing that needs
> improvement though are the error messages. Because the compiler tries to
> reorder arguments etc., forgetting a label spits out really whacky
> messages like, this function expects too many arguments.

So, you are rather a frustrated potential label mode user than a happy
classic mode user ?

Cheers,

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Markus Mottl]

On Fri, 30 Mar 2001, Jacques Garrigue wrote:
> Would others enjoy moving to label mode at no cost (with libraries
> compatible with 2.x) ?

It might be worth trying as long as there remains a "way back". I could
have tried it earlier, of course, but as is probably true for others,
big steps (and it is a big one) are not easily taken unless somebody
pushes you...

> How much do label users care for having labels in the standard library?

If label mode really becomes the default mode, I wouldn't mind some mild
labelling in the standard library. Let's just don't become too hard-core
right from the start...

> Not really for partial application (you rarely want to apply to a list
> before the function), but rather for layout. Mostly a question of
> taste, but if you like it really changes the way you use functionals.

Being able to write the code of a functional at the end of some function
application is surely an advantage when using commuting labels.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[kahl]

Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> replied to
  "Manuel Fahndrich" <maf@microsoft.com>:

> > 1) The standard library requires ~f: labels on many function arguments.
> > That seems silly. I basically had to add ~f: to many places where it did
> > not add disambiguation (f is not a very explicit name). I can see that
> > for partial applications that might be useful, but still I found this a
> > bit annoying.
> 
> Not really for partial application (you rarely want to apply to a list
> before the function), but rather for layout. Mostly a question of
> taste, but if you like it really changes the way you use functionals.
> 
> Anyway, if we remove labels from the standard library, this would
> solve the problem.

I am a long-time label user (having started when OCaml still was
Caml Special Light) and I have therefore gone through quite a few
relabellings of the standard library.
They never really hurt me (with a 50 module 30000 line project) ---
only when labels went away, it meant trouble.
(To make it clear: I ONLY use label mode and do not intend to switch.)

Jacques' words seem to indicate that there seems to be a
complete unlabelling of the standard library in the works ---
I must confess that I do not like that at all.
(Is my interpretation right? I got the impression that
 this was the only change intended for label mode.)
Especially for the ``f'' label!
(This was ``fun'' before the OCaml/OLabl merger
 and had to be changed to accommodate the new rule that
 keywords were not allowed as labels anymore ---
 I'd rather have the keyword ``fun'' replaced by Haskell's ``\'',
 or by a real lambda in a suitable character set!)

My point with the ``f'' label is that I need it almost always:
For List.map, List.fold_right and friends I usually have
only simple list arguments, but complex functions,
and do not see the point why I should
let-define that function beforehand.
So I think it is most readable to write the following:

  let list3 = List.map list2
               ~f:(fun x -> .....
                            ... x ...
                            ..........) in
  ....

If the ``f'' label goes away,
then I need a labelled wrapper around the standard library.
If none is provided, I have to write it myself,
but I would much prefer to have a standard labelling of the standard library,
since this also provides the label-using community with useful conventions and
guidelines.

And I do find the labels in the standard library useful with OCamlBrowser --
I use that much more than my copy of the html-version of the OCaml manual!


Cheers,

Wolfram Kahl







And if the ``f'' label was to go away 
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Jacques Garrigue]

From: kahl@heraklit.informatik.unibw-muenchen.de

> I am a long-time label user (having started when OCaml still was
> Caml Special Light) and I have therefore gone through quite a few
> relabellings of the standard library.
> They never really hurt me (with a 50 module 30000 line project) ---
> only when labels went away, it meant trouble.
> (To make it clear: I ONLY use label mode and do not intend to switch.)

Indeed, when a label disappears you cannot commute anymore, and this
is a pain. I explained it in detail, but ...

> Jacques' words seem to indicate that there seems to be a
> complete unlabelling of the standard library in the works ---
> I must confess that I do not like that at all.
> (Is my interpretation right? I got the impression that
>  this was the only change intended for label mode.)
> Especially for the ``f'' label!

No, no. Nothing decided yet.
What I was thinking of was having a special module Stdlabels for
die-hard labelers like you and me, so you would just have to do
"open Stdlabels" at the top of your files, and get all the current
labels in Pervasives, List, String and Array.
There are not many labels left in other modules anyway :-(
One could say that this is still two modes, but at least the semantics
is the same.

> And I do find the labels in the standard library useful with OCamlBrowser --
> I use that much more than my copy of the html-version of the OCaml manual!

That's the most serious problem for me, and this is even why I first
devised this two-mode system a year ago, rather than using the
Stdlabels scheme. I hoped that people would enjoy ocamlbrowser like you
and me.
Surprisingly, they do not seem to use it that much... habits, lack of
advertisement ?

Cheers,

Jacques
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Benjamin C. Pierce]

Hi Jacques,

> I hoped that people would enjoy ocamlbrowser like you
> and me.
> Surprisingly, they do not seem to use it that much... habits, lack of
> advertisement ?

I've tried OCamlBrowser on a few occasions, but its default behavior
is not quite intuitive enough for me to make it easier than looking
things up in the ocaml manual.  Here are a few reasons...

* I was never able to make the search functions work (which is precisely
what would have made it REALLY useful).  

* Since it uses pop-up windows, I find that my screen quickly fills up
with dozens of windows so that pretty soon I can't find anything or see
what I'm doing.  I wonder whether it would be worth considering managing
those windows yourself (i.e., enclosing them all in some big window that
you manage) and using some kind of tiling scheme to manage the space
better (with history/focus mechanisms to help recover recently viewed
stuff).

* Adding a path to the search path does not seem to have any persistent
effect, so every time I restart I have to manually fix up the paths to
find the lablgtk libraries, for example.  (I know there must be
command-line switches to do this, but I have never become a serious
enough user to look for them.  What I'm describing here is my experiences
as a naive, occasional user.)  

Even better would be to be able to switch easily *between* sets of paths
(something like Unison's named profiles), so that I could keep the
standard OCaml libraries in one pane, the lablgtk interfaces in another,
and the Unison sources in another.  When they're mixed together, the main
interface list gets too long and it's difficult to find things.

* One feature that I'd REALLY like would be the ability to click on a use
of an identifier and be transported to its def-site.  Similarly, I'd like
to be able to click on a declaration in a .mli file and be taken to the
corresponding definition in the .ml file.  I guess doing this right 100%
of the time might be hard (at least, it might require help from the
compiler), but I'll bet a simple guess would usually be OK.

        Benjamin


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] ocamlbrowser [was labels]

[Brock]

I don't know if you've considered it before, but one idea I've toyed with
is an ocamlbrowser that looks and feels like a SmallTalk browser. The way
smalltalk browsers can be set up seems to fit Benjamin's requirements (as
well as my own).

Is there anyone else interested in a browser with a smalltalk-style
layout?

--Brock

PS
  Sorry my previous email replying about using Unix in toplevel didn't
answer the original question... someone else did so correctly though.

On Fri, 30 Mar 2001, Benjamin C. Pierce wrote:

|Hi Jacques,
|
|> I hoped that people would enjoy ocamlbrowser like you
|> and me.
|> Surprisingly, they do not seem to use it that much... habits, lack of
|> advertisement ?
....
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Re: ocamlbrowser [was labels]

[Jacques Garrigue]

Hi Benli,

Thanks for the feedback. This is what is needed to improve
ocamlbrowser :-)

> I've tried OCamlBrowser on a few occasions, but its default behavior
> is not quite intuitive enough for me to make it easier than looking
> things up in the ocaml manual.  Here are a few reasons...
> 
> * I was never able to make the search functions work (which is precisely
> what would have made it REALLY useful).  

That's pretty strange. You just have to input a defined name in the
entry field and press Search. Remark that it can take a long time when
you do it for the first time, since it must load all the .cmi in the
load path.
I would suggest you first read the 2 pages in the manual describing
how ocamlbrowser works, they should answer some of your questions.
In particular it explains how to search using type patterns.

> * Since it uses pop-up windows, I find that my screen quickly fills up
> with dozens of windows so that pretty soon I can't find anything or see
> what I'm doing.  I wonder whether it would be worth considering managing
> those windows yourself (i.e., enclosing them all in some big window that
> you manage) and using some kind of tiling scheme to manage the space
> better (with history/focus mechanisms to help recover recently viewed
> stuff).

As somebody else suggests, moving to a more smalltalk style navigation
would not be difficult. The current approach is mainly due to a
historical evolution, taking for first model the original camlbrowser,
where one window pops up for every definition!
In the current system you have one window per module, but one could
easily have a single window for all modules, as long as we do not have
recursive modules including each other...
I could include this as another style of UI.

Yet, I'm not 100% sure it would be better. The way you use
ocamlbrowser is different from a smalltalk browser, in that most of
the navigation is done through types: first look for a function, then
for the definition of the type of one of its argument, then for the
definition of a type appearing inside this definition... You often
want to see several things at once, and the current approach can help
there. Once in a while you press close all to collect the garbage.

> * Adding a path to the search path does not seem to have any persistent
> effect, so every time I restart I have to manually fix up the paths to
> find the lablgtk libraries, for example.  (I know there must be
> command-line switches to do this, but I have never become a serious
> enough user to look for them.  What I'm describing here is my experiences
> as a naive, occasional user.)  

Same syntax as ocamlc: use "ocamlbrowser -I +lablgtk".
If you define aliases, you can have several paths: that's the Unix
way.
I was only too lazy to develop a preference file format. That would
really be a nice utility module to share between Caml applications,
and it would help to have a compatible syntax. Could the unison
preference format be made an independent, reusable module ?

> Even better would be to be able to switch easily *between* sets of paths
> (something like Unison's named profiles), so that I could keep the
> standard OCaml libraries in one pane, the lablgtk interfaces in another,
> and the Unison sources in another.  When they're mixed together, the main
> interface list gets too long and it's difficult to find things.

This problem of list length is real. What you really want is to use
the same path (because it is also used for type checking), but to
restrict the list (and maybe search) to the part of the path your are
interested in. This could be done.

> * One feature that I'd REALLY like would be the ability to click on a use
> of an identifier and be transported to its def-site.  Similarly, I'd like
> to be able to click on a declaration in a .mli file and be taken to the
> corresponding definition in the .ml file.  I guess doing this right 100%
> of the time might be hard (at least, it might require help from the
> compiler), but I'll bet a simple guess would usually be OK.

You can. Because of the Amazon patent, this is not single click:
first type check the file you are browsing with Alt-t, then
double click once on the identifier to get to its interface
declaration, and then press either Impl (for implementation) or Intf
(for the interface, including comments).
It should be 100% correct.

Best regards,

Jacques
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Re: ocamlbrowser [was labels]

[Benjamin C. Pierce]

> Thanks for the feedback. This is what is needed to improve
> ocamlbrowser :-)

I'm glad I asked -- I didn't realize OCamlBrowser was this cool!

[Warning: long and detailed response follows...  I almost took this
off-list, but eventually decided that others may have useful thoughts,
especially about the first couple of points.]

> I was only too lazy to develop a preference file format. That would
> really be a nice utility module to share between Caml applications,
> and it would help to have a compatible syntax. Could the unison
> preference format be made an independent, reusable module ?

We've worked pretty hard on the Unison preference handling stuff, and it
would be nice to see it packaged in a form that would be easy for others
to use.  However, it will take a little thought to figure out what is the
right way to "extract" it from Unison and make it stand on its own,
without splitting the code off into a separate version that is not the
one used by Unison.  The issue is that there are several low-level
utility functions that the preferences module gets from a standard Unison
utility module, but it probably doesn't make sense to export that module
verbatim to the whole world, since it also has quite a bit of
Unison-specific functionality in it.  Some refactoring is in order.

> As somebody else suggests, moving to a more smalltalk style navigation
> would not be difficult. The current approach is mainly due to a
> historical evolution, taking for first model the original camlbrowser,
> where one window pops up for every definition!
> In the current system you have one window per module, but one could
> easily have a single window for all modules, as long as we do not have
> recursive modules including each other...
> I could include this as another style of UI.
> 
> Yet, I'm not 100% sure it would be better. The way you use
> ocamlbrowser is different from a smalltalk browser, in that most of
> the navigation is done through types: first look for a function, then
> for the definition of the type of one of its argument, then for the
> definition of a type appearing inside this definition... You often
> want to see several things at once, and the current approach can help
> there. Once in a while you press close all to collect the garbage.

I think no single, simple mechanism is going to be right all the time.  

  * When I'm following a thread to get somewhere else, I want to reuse
    the same window that I'm looking at now.

  * When I'm looking at a piece of code and want to check something that
    it refers to, I want to pop that up in a different window that I can
    close when I'm done without disturbing the main one.  

  * Moreover, I may sometimes want to look at several modules together,
    and for this it would be useful to somehow attach them together so
    that they do not obscure each other, so that they can be moved and
    closed (and perhaps later re-opened?) together, etc.  This kind of
    "tiling" organization can sometimes also use screen space more
    efficiently.

Reaching a design that uses screen space optimally in all these
situations (and the ones I didn't think of) seems pretty hard, but
at least we could probably get a little closer.

Here's one possible design (I'm sure it can be improved).
   * Every navigation command comes in three forms:
       1) open a *new* window for the new information
       2) re-use *this* window to display the new information
   * Style (1) is the default.  Pressing SHIFT while clicking gets you
     style (2).  
   * A netscape-style "back" command can be used to restore the contents
     of the current (or temp) window to its previous state, or to close
     a window that you just created.  
   * Perhaps there chould be some way to make the SHIFT and CONTROL
     modifiers sticky.

A possible refinement: 
   * One window on the screen is designated the "temp window" (initially,
     there is no temp window; one is created the first time it is needed,
     and the same window is used thereafter).
   * Add a navigation style:
       3) use the *temp* window 
   * Pressing CONTROL when clicking gets you style (3).   
(I'm not sure whether this refinement is worth the trouble -- just having
mode (1) plus a "back" keystroke to close the new window when done might
be enough.)   

Neither of these ideas addresses the last point above, about sometimes
wanting to "tile" parts of the screen.  I have the impression that good
tiling schemes are hard to find.

A more minor comment: the window that pops up when you click a module
name is usually too short to show all of the things defined in that
module, which means there's almost always some scrolling involved in
finding what you want.  What about making these windows initially tall
enough to show everything (within reason), and providing a Minimize
button to save space if needed?

> This problem of list length is real. What you really want is to use
> the same path (because it is also used for type checking), but to
> restrict the list (and maybe search) to the part of the path your are
> interested in. This could be done.

What I'd *really* like is to be able to have several module listing
windows -- one for the standard OCaml libraries, one for the LablGtk
interfaces, one for the application program I'm browsing, etc.  

> > * One feature that I'd REALLY like would be the ability to click on a use
> > of an identifier and be transported to its def-site.  Similarly, I'd like
> > to be able to click on a declaration in a .mli file and be taken to the
> > corresponding definition in the .ml file.  I guess doing this right 100%
> > of the time might be hard (at least, it might require help from the
> > compiler), but I'll bet a simple guess would usually be OK.
> 
> You can. Because of the Amazon patent, this is not single click:
> first type check the file you are browsing with Alt-t, then
> double click once on the identifier to get to its interface
> declaration, and then press either Impl (for implementation) or Intf
> (for the interface, including comments).
> It should be 100% correct.

Wonderful!!

Wouldn't it be possible to make the typechecking step automatic -- do it
the first time someone clicks on an identifier?

> > * I was never able to make the search functions work (which is precisely
> > what would have made it REALLY useful).  
> 
> That's pretty strange. You just have to input a defined name in the
> entry field and press Search. Remark that it can take a long time when
> you do it for the first time, since it must load all the .cmi in the
> load path.

I don't remember what I was having trouble with before, but it does seem
to work fine now.

> I would suggest you first read the 2 pages in the manual describing
> how ocamlbrowser works, they should answer some of your questions.
> In particular it explains how to search using type patterns.

It would be nice if this information were somehow available from the
program itself.  (In Unison we do this by simply dumping the HTML
documentation into a text file using Lynx, cutting it up into sections
using some not-too-ugly hacks, and build a menu from these.  The result
is not as pretty as it might be, but it seems to get the job done.)
Another alternative is something like tool-tips.


Two last items for the wish list: 

  * It would sometimes be really helpful to be able to see a module
    dependency graph beginning from the present module, to get a sense of
    how things fit together. 

  * Some kind of outline mode for implementations would be nice.

Whew -- that should keep somebody busy for a while.

      Benjamin

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Re: ocamlbrowser [was labels]

[Francisco Valverde Albacete]

"Benjamin C. Pierce" wrote:

> Two last items for the wish list:
>
>   * It would sometimes be really helpful to be able to see a module
>     dependency graph beginning from the present module, to get a sense of
>     how things fit together.

Yes! Any graph! This is something I so much miss in Ocamlbrowser that I've almost
started putting it in several times already. Fortunately, I respect too much J.
Garrigue's work to mess with his code (or theory) and I have abandoned the project.

My own style of coding relies too much in piecewise construction of signatures and
modules and I would like to navigate the graph enormously... I can't help with
coding it, but I promise to make a thorough test of it if anybody obliges!

BTW I use ocamlbrowser very much indeed. Thanks Mr. Garrigue.

Regards,

        Francisco Valverde
        Univ. Carlos III de Madrid


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] Re: ocamlbrowser [was labels]

[Michael Hicks]

Perhaps the browser could be merged with ocamldot?

http://www.research.att.com/~trevor/ocamldot/index.html

Mike

> -----Original Message-----
> From: owner-caml-list@pauillac.inria.fr
> [mailto:owner-caml-list@pauillac.inria.fr]On Behalf Of Francisco
> Valverde Albacete
> Sent: Tuesday, April 03, 2001 1:44 PM
> To: bcpierce@cis.upenn.edu
> Cc: Jacques Garrigue; caml-list@inria.fr
> Subject: Re: [Caml-list] Re: ocamlbrowser [was labels]
>
>
> "Benjamin C. Pierce" wrote:
>
> > Two last items for the wish list:
> >
> >   * It would sometimes be really helpful to be able to see a module
> >     dependency graph beginning from the present module, to get
> a sense of
> >     how things fit together.
>
> Yes! Any graph! This is something I so much miss in Ocamlbrowser
> that I've almost
> started putting it in several times already. Fortunately, I
> respect too much J.
> Garrigue's work to mess with his code (or theory) and I have
> abandoned the project.
>
> My own style of coding relies too much in piecewise construction
> of signatures and
> modules and I would like to navigate the graph enormously... I
> can't help with
> coding it, but I promise to make a thorough test of it if anybody obliges!
>
> BTW I use ocamlbrowser very much indeed. Thanks Mr. Garrigue.
>
> Regards,
>
>         Francisco Valverde
>         Univ. Carlos III de Madrid
>
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr.  Archives:
http://caml.inria.fr

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Re: ocamlbrowser [was labels]

[John Max Skaller]

"Benjamin C. Pierce" wrote:
 
> Here's one possible design (I'm sure it can be improved).
>    * Every navigation command comes in three forms:
>        1) open a *new* window for the new information
>        2) re-use *this* window to display the new information
>    * Style (1) is the default.  Pressing SHIFT while clicking gets you
>      style (2).

	No. Left button is 'same window'. Right button is popup menu.
It is the standard used in MS-Windows (eg in Windows Explorer).
Using this technique means only ONE mouse click for both cases,
in the second case the default is 'new' window, and requires no
mouse movement. Other options require movement. Neither option
requires any keyboard.

	Holding mouse still over active element pops up tooltip help
with extra information.

>    * A netscape-style "back" command can be used to restore the contents
>      of the current (or temp) window to its previous state, 

	Yes.

>  or to close a window that you just created.

	No: examine your browser. Back does nothing at the root.

>    * Perhaps there chould be some way to make the SHIFT and CONTROL
>      modifiers sticky.

	Modifiers should be avoided at all costs. They should only
be used for 'expert', 'dangerous' and 'user defined' functions. More
generally,
navigation should be possible with the mouse alone. The keyboard should
provide alternatives, but only be required for data entry and dangerous
functions. For example, by default 'search' should use the word the
cursor is on in an edit file and NOT require typing anything.
If an entry box is use, the default should support history by a drop
down list, 
again allowing no-keyboard operation in many cases. Again, see browsers.
 
> A possible refinement:
>    * One window on the screen is designated the "temp window" (initially,
>      there is no temp window; one is created the first time it is needed,
>      and the same window is used thereafter).
>    * Add a navigation style:
>        3) use the *temp* window
>    * Pressing CONTROL when clicking gets you style (3).
> (I'm not sure whether this refinement is worth the trouble -- just having
> mode (1) plus a "back" keystroke to close the new window when done might
> be enough.)

	No. This kind of refinement is definitely worth the trouble.

********************************************************************
  
	Here is a general comment. It is a serious bug of all current
GUI design that to make a functional GUI, one must take the basic
functionality like Ocamlbrowser today, and add more and more features
to control layout/style -- which have nothing at all to do with the
underlying functionality.

	A system for managing this complex problem independently
of the application is needed. Such systems exist, they're called
window managers on X systems, and they're quite archaic and
close to useless.

	I have designed and implemented an approach to a partial
solution (lots of qualifiers here!). It is called HWM, or
Heirarchical Window Manager. HWM uses a tree widget to represent
'containment' of application and sub-application level windows.

	Some of the windows used are containers: for example:
	a) multi-paned window (vertical, horizontal etc)
	b) notebook
	c) display

and some of the windows are application windows. These windows
are also containers by delegation to their parent.

	Using the tree widget, it is possible to move, iconise,
or destroy whole subtrees of windows. For example consider


	display
	  ocamlbrowser-toplevel
	    module data
	      symbol list
              text
	    module data
	      symbol list
	      text

Here, 'module data' is a horizontally paned window, display is your X
windows
display. Ocamlbrowser-toplevel is a single non-container window, so we
have three top level windows at this point. I HATE that! So I (and NOT
ocamlbrowser) simply create a notebook:


	display
	  mybook
	  ocamlbrowser-toplevel
	    module data
	      symbol list
              text
	    module data
	      symbol list
	      text

and then move the two module panes into it with drag and drop:


	display
	  mybook
	    module data
	      symbol list
              text
	    module data
	      symbol list
	      text
	  ocamlbrowser-toplevel

and now there are only two top level windows. Now, I want to see
both module data at the same time. So I right click on the 'mybook'
entry and select 'metamorphise/vertical paned window' and the notebook
is changed into a vertical paned window. I want to edit the text
of one module, so I just drag it out to 'display' to change it
to a top level window. Indeed, I have TWO displays, and at the flick
of a mouse, I can move the display to the second screen.

I designed HWM because I had a system much more complex than Ocaml
to browse: the complete text and code for a literate programmed
book. I needed the system to manage multiple ways of organising
information, which required a lot of kinds of 'summary' windows
at different levels of modularity.

So I have an interesting suggestion here. Instead of enhancing
Ocamlbrowser, REMOVE most of the window management (there isn't
much anyhow), and replace it with calls to a new HWM API.

Then build HWM. This will give the USER extensive control over layout
and window management, and that system will work for ANY compliant
application (not just Ocamlbrowser).

I have implemented HWM in iTCL and in Python, both using Tcl/Tk with Tix
for the GUI. (Tix is mandatory for the tree widget, which Tk lacks).
Tk has some problems reparenting a window to another display.
Ocaml has some problems with dynamic loading (required so HWM
can manage independent applications).

An Ocaml based  HWM implementation would be an interesting use of
classes. At the most abstract level, one writes only a management
system for a tree data structure. Subclasses are used to add
the tree widget modelling. Further subclassing is used to add
actual containers. Dynamic loading is used to add a menu of
applications.

HWM runs first, and can be used to create new containers and
launch user applications. The current design handles 
'add child to parent' but does not provide any control over ordering.
However, it is possible to change the state of the containment
tree by manipulating the other windows (and tricky to get the
synchronisation right). It is also possible to reorganise the tree
under program control (just by manipulating the abstract tree,
everything else works by method polymorphism).

Is anyone interested? Can a Tix binding be created easily?

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Judicael Courant]

Jacques Garrigue a écrit :

> Sorry for Judicael, but I see no way to satisfy everybody with a single
> mode. (You don't expect me to just drop the label mode, and be happy
> with classic, no ?)
> 

No I can't. But I did neither expect you to remove labels from the
standard library: this would be just another way to drop labels, would
not it? :-)

> On the other hand Manuel expresses an opinion I've heard a few times:
> moving to label mode might be nice, if the price to pay was not so
> high.

I agree with this statement and that's why I would have prefered a
single mode: my problem is that with two modes I cannot say "ok, I am
just giving a try to the modern  style within this function/this file"
mostly because I have to choose classic vs modern for a whole file and
even for a whole project (as I do not want my Makefile to become a
nightmare because of labels).

Unfortunately it appears there is no mode that is "better" than both the
current classic *and* modern ones. So we need two modes.
Then, I am not opposed to have labels as the default mode (classic being
kept only for backward compatibility). However I wish there would be a
way to switch to this classic mode with a pragma (not only with a
command-line switch) so that it is easier to mix files in classic mode
and in modern mode in a given project (and if it is even possible, to
mix functions written in classic modes and in modern mode within a given
file). That would help moving eventually to modern mode. IMHO "There's
More Than One Way To Do It" is not necessarily a good slogan...

If I switch to labels, I would prefer changes to happen once. If you
remove labels from the standard library and leave them in third parties
libraries, either people won't use third-parties libraries (which would
be a pity) or they will come back later saying "labels are great! why
does the standard library lacks labels?". I would prefer the standard
library to have labels at the right places. IMHO there are still
possible improvements with respect to this issue. For instance in Map
you can find

val add : key:key -> data:'a -> 'a t -> 'a t
val find : key -> 'a t -> 'a
val remove : key -> 'a t -> 'a t

which is not really uniform (moreover, I never remember whether 
it is find : key -> 'a t -> 'a or find : 'a t -> key -> 'a so I would
like to have find : key:key -> 'a t -> 'a)

Judicaël.
-- 
Judicael.Courant@lri.fr, http://www.lri.fr/~jcourant/
(+33) (0)1 69 15 64 85
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Jacques Garrigue]

Hello Judicael,

> Then, I am not opposed to have labels as the default mode (classic being
> kept only for backward compatibility). However I wish there would be a
> way to switch to this classic mode with a pragma (not only with a
> command-line switch) so that it is easier to mix files in classic mode
> and in modern mode in a given project (and if it is even possible, to
> mix functions written in classic modes and in modern mode within a given
> file). That would help moving eventually to modern mode. 

I asked for this pragma one year ago, but was refused it :-)
This should come from the users, they said.

> If I switch to labels, I would prefer changes to happen once. If you
> remove labels from the standard library and leave them in third parties
> libraries, either people won't use third-parties libraries (which would
> be a pity) or they will come back later saying "labels are great! why
> does the standard library lacks labels?". I would prefer the standard
> library to have labels at the right places. IMHO there are still
> possible improvements with respect to this issue. For instance in Map
> you can find
> 
> val add : key:key -> data:'a -> 'a t -> 'a t
> val find : key -> 'a t -> 'a
> val remove : key -> 'a t -> 'a t
> 
> which is not really uniform (moreover, I never remember whether 
> it is find : key -> 'a t -> 'a or find : 'a t -> key -> 'a so I would
> like to have find : key:key -> 'a t -> 'a)

So bad you didn't say it one year ago :-(
In ocaml-2.99, this was the case, but I had to remove labels on find
and remove against my will :-)

Remark that this might suggest yet another evolution:
keep classic and label mode as they are now, but add more labels in
the standard library (revert back to the old labels ?)

Jacques

P.S. It's friday night here, so I'll join back the discussion on
monday.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Francois Pottier]

Jacques,

> To keep the discussion open, here is a 3rd alternative, which involves
> making label mode the default mode, removing labels from the standard
> library (to keep compatibility with ocaml 2, that's paramount), and
> keeping a simplified classic mode for those who don't want to hear of
> labels at all.

> Would others enjoy moving to label mode at no cost (with libraries
> compatible with 2.x) ?  That is, would they be ready to write more labels
> when they use labeled libraries (like labltk) ?

This proposal sounds reasonable to me. But I'd support Judicaël and vote
in favor of a single mode. If the designer of a particular library chose
to include labels in its API, why should the user not comply? Who are the
people who `don't want to hear of labels at all'?

-- 
François Pottier
Francois.Pottier@inria.fr
http://pauillac.inria.fr/~fpottier/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Benjamin C. Pierce]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

> This proposal sounds reasonable to me. But I'd support Judicaël and vote
> in favor of a single mode. If the designer of a particular library chose
> to include labels in its API, why should the user not comply? Who are the
> people who `don't want to hear of labels at all'?

I don't really have an opinion about whether classic mode, label mode, or
something else is best, but I'd like to add my strong support for having
just *one* mode that everybody uses.  

One thing to be careful of, though, is making the language a lot more
difficult to use for newcomers.  The present language design has the
advantage that people do not have to start out understanding labels to do
anything at all in OCaml -- they can learn about them much later, when
they start doing fancy GUI programming or whatever.

This property makes OCaml at the moment a much better language for
*teaching* than, say, Java, where there are about a dozen fairly deep
concepts that you have to understand before you can write even the
smallest program.  We use OCaml at Penn for teaching intro programming to
hundreds of undergraduates, and the main attraction is that you can write
significant programs in a tiny subset of the language.

     Benjamin
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Jean-Marc Alliot]

"Benjamin C. Pierce" wrote:

> One thing to be careful of, though, is making the language a lot more
> difficult to use for newcomers.  The present language design has the
> advantage that people do not have to start out understanding labels to do
> anything at all in OCaml -- they can learn about them much later, when
> they start doing fancy GUI programming or whatever.
>
> This property makes OCaml at the moment a much better language for
> *teaching* than, say, Java, where there are about a dozen fairly deep
> concepts that you have to understand before you can write even the
> smallest program.  We use OCaml at Penn for teaching intro programming to
> hundreds of undergraduates, and the main attraction is that you can write
> significant programs in a tiny subset of the language.
>

I completely support Benjamin opinion. We have exactly the same kind of problems
with our students and it would be a real pain if they had to learn labels from the
start.

So, my only strong wish is to still be able to use OCAML without having to know
anything about labels.

Note : I still find labels useful, especially in GUI bindings. And this comment is
in noway a criticism of Jacques Garrigue excellent work.


--
|             Jean-Marc Alliot          |
|  http://www.recherche.enac.fr/~alliot |
|         alliot@recherche.enac.fr      |



-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr