Newsgroups: comp.lang.prolog
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!news.alpha.net!uwm.edu!cs.utexas.edu!howland.reston.ans.net!pipex!uknet!festival!hwcee!andrew
From: andrew@cee.hw.ac.uk (Andrew Dinn)
Subject: Re: meta-programming, strong typing, and monads
Message-ID: <D02rG7.E28@cee.hw.ac.uk>
Sender: news@cee.hw.ac.uk (News Administrator)
Organization: Dept of Computing and Electrical Engineering, Heriot-Watt University
X-Newsreader: TIN [version 1.2 PL2]
References: <CztzuC.H1w@info.bris.ac.uk> <3bck5l$ph9@hitchcock.dfki.uni-sb.de> <D0155o.HvA@info.bris.ac.uk>
Date: Wed, 30 Nov 1994 09:52:54 GMT
Lines: 55

John Lloyd (jwl@miki.cs.bris.ac.uk) wrote:

: Can someone provide some concrete cases where a strong type system in a 
: language such as Goedel gets in the way to a significant degree for this 
: kind of task? 

I don't know enough about Goedel to answer the specific question but
I do have an example of a `hard' problem for many strictly typed
languages. The problem is to implement a menu handling library where
menus are created parameterised by a list of menu entries. A menu
entry is a record containing three fields, a string for use as the
menu label, a callback routine to handle a menu selection and a
callback argument which contains data specific to the particular menu
entry. Generally the callback data belong to a heterogeneous
collection of types.

In a strictly typed language the type of supplied callback data must
be conformant to the type for the data field in the menu entry which
requires the latter to be implemented as a union type. But the range
of possible types in the union cannot be predefined so the package
cannot be implemented as a standalone library - it must `know' about
the menu client types.

Ok, I'll come clean. If you have type parameterisation then the menu
entry data field can be typed using a type parameter which is
instantiated with a union type supplied by the application (a common
parent type in a hierarchical type system would do the same trick -
i.e. make your heterogeneous types homogeneous). Still this kind of
example is a pain in the neck to code because it requires not just
adding the union type but also including case checking in the callback
routines to ensure that the appropriate union field is received and
handled. And this has to be done every time you define a new menu
i.e. it happens once *per menu* rather than once per application (it's
a rare case that all (any?) of an application's menus have the same
types of entries).

An alternative for OO languages which avoids the case checking is to
use a common parent type for the parameterised type and replace the
routine stored in the menu entry with a method selector (sort of like
what is done in Smalltalk except that the selector must be defined at
compile time rather than evaluated at runtime in order to be type
safe). This avoids the need for case checking in the callback
routines. The menu code sends the message to the stored object and the
implementation appropriate to the object is selected by the message
dispatching process. To be type safe, this requires not just type
parameters but also the ability to check that a parameter type
supports the required interface. However, it still implies definition
of the common parent type and the implementation of selector methods
for each callback data type to be done *per menu*.



Andrew Dinn
-----------
there is no map / and a compass / wouldn't help at all
