From: Donald Syme
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <334599F3.1079@cl.cam.ac.uk>
Chris Bitmead wrote:
>
> ····@adi.COM (Franklin Chen) writes:
>
> >To see the advantages of a typeless language, consider the following
> >Tcl command:
> >
> >button .b -text Hello! -font {Times 16} -command {puts hello}
> >
> >This command creates a new button control that displays a text string
> >in a 16-point Times font and prints a short message when the user
> >clicks on the control. It mixes six different types of things in a
> >single statement: a command name (button), a button control (.b),
> >property names (-text, -foreground, and -command), simple strings
> >(Hello! and hello), a font name (Times 16) that includes a typeface
> >name (Times) and a size in points (16), and a Tcl script (puts
> >hello). Tcl represents all of these things uniformly with strings. In
> >the button example the properties may be specified in any order and
> >unspecified properties are given default values; more than 20
> >properties were left unspecified in the example.
> >
> >The button example requires about 25 lines of code in three procedures
> >when implemented in C++ with Microsoft Foundation Classes. Just
> >setting the font requires 7 lines of code:
> >
> >LOGFONT lf;
> >
> >memset(&lf, 0, sizeof(lf));
> >
> >lf.lfHeight = -16;
> >
> >strcpy(lf.lfFaceName, "Times New Roman");
> >
> >CFont *fontPtr = new CFont();
> >
> >fontPtr->CreateFontIndirect(&lf);
> >
> >buttonPtr->SetFont(fontPtr);
>
> Come on! All this shows is the inconveniece of using the MFC
> classes. An interface exactly the same as the Tcl one could easily be
> written in C++.
>
Trash. Show me C++ which is as succinct and I may believe you.
For example the O'Caml crowd (who I think are wonderful)
have to bend over backward to create O'Labl (again wonderful)
to achieve anything like the succinctness Ousterhout achieves
in Tcl/Tk, precisely because of the ML type system. Ousterhout
is right on this point at least: strong, static typing
does often mean cutting back on nifty syntactic tricks that
are played with untyped languages (like specifying a font
with just "Times 16", or allowing config parameters in any order).
At least until the language designers
add some features (like labelled optional arguments) to their
language.
Don
P.S. I think I must be the only person in the world who
is a Tk/Tcl fan *and* an ML/Scheme/Java fan. Different
horses for different courses!
-----------------------------------------------------------------------------
At the lab: At home:
The Computer Laboratory Trinity Hall
New Museums Site CB2 1TJ
University of Cambridge Cambridge, UK
CB2 3QG, Cambridge, UK
Ph: +44 (0) 1223 334688 Ph: +44 (0) 1223
505863
http://www.cl.cam.ac.uk/users/drs1004/
email: ·······@cl.cam.ac.uk
-----------------------------------------------------------------------------
Don writes:
| ... Ousterhout
| is right on this point at least: strong, static typing
| does often mean cutting back on nifty syntactic tricks that
| are played with untyped languages
I don't think it is the strong typing that does it, it is just the lack of
abstraction. Strong typing, if rich enough, can even _help_ you making
better abstractions in a language.
Ousterhout is absolutely right: we need languages that provide better glue
than the languages he calls `system languages'. But that doesn't mean that
we have to give up strong typing!
| ... At least until the language designers
| add some features (like labelled optional arguments) to their
| language.
What do you think of type classes? The system `TkGofer' uses these, to do
a pretty good job combining the conciseness of Tcl with the strong typing
and expressiveness of functional languages (in this case Gofer).
An example of an expression in TkGofer is:
b <- button [ text "A button", command (puts "hello") ] w
This would create a button in window w with the specified options and puts
the result in the variable b. (This is a disadvantage of Tcl -- explicit
naming of widgets).
Strong typing is for example _used_ for configurations. A widget that has
no command, can't get a `command' configuration. For example:
l <- label [ text "A label", command foo ] w
Will give a _static_ type error:
Type checking.....
ERROR (line 7):
*** Required instance : HasCommand Label
Because labels don't have commands. But _both_ widgets can get the `text'
configuration, because they both have text. TkGofer use type classes to do
this.
My experience with TkGofer is that it is even more concise than Tcl, _due_
to the expressiveness of strong typing, type classes, and functional
programming in general.
TkGofer is one of the many examples that show how we can use strongly
typed (functional) languages as glue to provide interfaces to untyped
libraries.
References:
* Vullinghs, T., `TkGofer homepage', URL:
http://www.informatik.uni-ulm.de/abt/pm/ftp/tkgofer.html
* Claessen, K., Vullinghs, T. and Meijer, E., `Structuring Graphical
Paradigms in TkGofer', to appear at the ICFP '97, URL:
http://www.cse.ogi.edu/~kcclaess/Articles/tkgofer.ps
Regards,
Koen.
--
| Koen Claessen, ····@cse.ogi.edu. |
| http://www.cse.ogi.edu/~kcclaess/ |
|------------------------------------------------------|
| Visiting student at OGI, Portland, Oregon, USA. |
From: Graham Matthews
Subject: Re: Ousterhout is partially right (was: Re: Ousterhout lost the plot)
Date:
Message-ID: <334870F3.3046@maths.anu.edu.au>
Koen Claessen wrote:
> What do you think of type classes?
> ...
>
> My experience with TkGofer is that it is even more concise than Tcl, _due_
> to the expressiveness of strong typing, type classes, and functional
> programming in general.
I'll second this opinion. I wrote a GUI using TkGofer and it was most
concise and reliable. Far more so than similar things I have written in
Tcl and in Python. The type checking proved very useful -- I had no
problems with TkGofer's strong static typing (ie. it never got in the
way). It's just a pity that TkGofer is hooked up to Tk (I can't stand
the eventloop model of GUIs -- give me threaded GUIs any day!).
graham
--
I would gladly die for a man who was looking for the
truth, but would just as gladly kill a man who thought
he had actually found it -- Voltaire