The simple questions ARE the good ones ... and one should certainly not stop the confusing there! If you want to define the initial object in a functional language you should write (say in Haskell): data Initial = deriving (Show) -- so we can display the elements After all clearly the initial object is the (inductive) datatype with zero constructors. Clearly you then should be able to write perfectly good programs such as the identity function and the case on this datatype. idinit:: Initial -> Initial idinit x = x init:: Initial -> a init x = case x of -- well there are no cases! There is one problem, of course: Haskell does not think this is legal as it thinks all datatypes should have at least one constructor. (BTW do any functional languages allow NO constructors? They really should.) No matter we can try to be a little cleverer and cheat the system by having a constructor which we cannot construct anyway ... data Initial = ZZ initial deriving (Show) -- so we can display the elements This has no elements ... just try to inductively construct them. So this works fine as the initial datatype ... or does it? At this stage we belatedly remember we are not quite in the world we expect as initial and final datatypes coincide so we do actually have a perfectly good element in this datatype. forever:: Initial forever = ZZ forever You do have to be patient as it does takes a bit of time to display it ... :-) OK so that did not work!! But now we have remembered that initial and final datatypes are supposed to coincide we have a blinding flash of inspiration: because ()=1 is the final type it must also be the initial object. So constant functions ARE the same as initial functions after all ....... so the student was not confused at all! Or was he? -robin Robin Cockett, Calgary