caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Pierre Weis <Pierre.Weis@inria.fr>
To: dave@kal.com (Dave Berry)
Cc: caml-list@inria.fr
Subject: Re: CamlTk and LablTk
Date: Sat, 3 Jun 2000 10:16:05 +0200 (MET DST)	[thread overview]
Message-ID: <200006030816.KAA20425@pauillac.inria.fr> (raw)
In-Reply-To: <3145774E67D8D111BE6E00C0DF418B6623BCEE@nt.kal.com> from Dave Berry at "Jun 1, 100 05:44:37 pm"

> (I hope you don't mind me replying to a fairly old message).
> 
> This was a very interesting question, and the examples that Pierre included
> were illuminating.  Would it be possible to elucidate a little further?  In
> particular, I'd appreciate it if someone could give the types of the
> relevant functions in each library.  (At some point one has to look at the
> documentation for all the details, but this seems like a reasonably
> educational example to take a little further).
> 
> Let's compare the two calls to create_oval.  First the Caml/TK:
>       Canvas.create_oval c
>         (Pixels (cx - wx)) (Pixels (cy - wy))
>         (Pixels (cx + wx)) (Pixels (cy + wy))
>         [Outline (NamedColor "black"); Width (Pixels 7);
>          FillColor (NamedColor "white")]
> Second the Labl/TK:
>     Canvas.create_oval
>         ~x1:(cx - wx) ~y1:(cy - wy)
>         ~x2:(cx + wx) ~y2:(cy + wy) 
>         ~outline: `Black ~width: 7
>         ~fill: `White
> 
> It seems that Labl/TK is using labels in two ways.  First, to have named
> arguments, so that you can see which position is x1, which is y1, etc.
> Second, to handle optional arguments.  Where Caml/TK takes a list of
> attributes, Labl/TK takes extra parameters.  I assume that this is where
> Labl/TK has better type checking.  Does the type of each function list the
> optional parameters that it may take?  : Doesn't this lead to large types
> for each function? (I don't know O'Labl at all well).
> 
> Dave.

You are perfectly right. As an example, we can compare the types of
Canvas.create in both libraries;

In Caml/Tk:
-----------

val create : widget -> options list -> widget
             (* [create p options] creates a new widget with parent p.
                Options are restricted to the widget class subset,
                and checked dynamically. *)

simple, but as mentioned in the documentation, options are restricted
to the widget class and this is not checked statically.

In Labl/Tk:
-----------

val create :
  ?name:string ->
  ?background:color ->
  ?borderwidth:int ->
  ?closeenough:float ->
  ?confine:bool ->
  ?cursor:cursor ->
  ?height:int ->
  ?highlightbackground:color ->
  ?highlightcolor:color ->
  ?highlightthickness:int ->
  ?insertbackground:color ->
  ?insertborderwidth:int ->
  ?insertofftime:int ->
  ?insertontime:int ->
  ?insertwidth:int ->
  ?relief:relief ->
  ?scrollregion:(int * int * int * int) ->
  ?selectbackground:color ->
  ?selectborderwidth:int ->
  ?selectforeground:color ->
  ?takefocus:bool ->
  ?width:int ->
  ?xscrollcommand:(first:float -> last:float -> unit) ->
  ?xscrollincrement:int ->
  ?yscrollcommand:(first:float -> last:float -> unit) ->
  ?yscrollincrement:int ->
  ?yscrollincrement:int ->
  'a widget -> canvas widget
             (* [create p options ?name] creates a new widget with
                parent p and new patch component name.
                Options are restricted to the widget class subset,
                and checked dynamically. *)

Extremely precise typing, informative and useful to know which options
you can use to create a canvas. Note also that ``widget'' is no more a
constant type constructor: it takes an 'a parameter to carry and
reflect its kind. So that options can be (and are) checked statically.

Note also, that we will continue to maintain Caml/Tk because we still
use programs that use it (and text book, and courses that give
examples using Caml/Tk). Moreover, being written in the core language,
it could be simpler to start with when teaching GUI to beginners, and
last but not least, it is also the only GUI for Caml light that we
still support for thousands of students.

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/





  reply	other threads:[~2000-06-03  8:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-01 16:44 Dave Berry
2000-06-03  8:16 ` Pierre Weis [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-05-18 17:37 Georges MARIANO
2000-05-22 14:57 ` Pierre Weis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200006030816.KAA20425@pauillac.inria.fr \
    --to=pierre.weis@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=dave@kal.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).