Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!iuvax!purdue!bouma
From: bouma@cs.purdue.EDU (William J. Bouma)
Newsgroups: comp.lang.forth
Subject: Re: Why is Postscript not Forth?
Summary: types in forth
Message-ID: <9805@medusa.cs.purdue.edu>
Date: 21 Feb 90 22:08:20 GMT
References: <9002210136.AA20515@jade.berkeley.edu>
Organization: Department of Computer Science, Purdue University
Lines: 32

In article <9002210136.AA20515@jade.berkeley.edu> wmb@ENG.SUN.COM writes:
>PostScript already provides words to convert between types, but some
>pairs of types are not mutually convertible.  The original point was
>that Forth is inherently untyped and PostScript is inherently strongly
>typed, and that this difference is fundamental.  The above argument
>supports that claim.  In Forth, you can ultimately do anything you want
>with a stack cell, and in PostScript, you can only do "type consistent"
>things.
   
   You lost me here when you say "Forth is inherently untyped". In previous
   posts you seemed to be saying that traditionally forth is not strongly
   typed thus it is different from postscript which is. That is true. But here
   you seem to be saying the structure of is such that it cannot be typed. I
   would agree that postscript would be a mess without types, and that forth
   works without formal types. But I do think that forth can (and should) be
   typed. Forth already allows different types on the stack: integers, chars,
   addresses of arrays and variables.  But after allowing types, forth tries
   to ignore the whole issue. I am not saying type checking should be required
   everywhere, just that type information should be available when wanted.
   For the sake of speed you could have an 'f+' operation to add the top two
   floats which does not check if they are really floats. But if you want an
   operation to add a float and integer in either order, what do you do? Junk
   like '."' is stupid. Have a '.' that checks the type and prints it the
   appropriate way. Give me format statements to read and write different
   types of data. Give me the means to build new types from base primitives
   and allocate space for an instance of some type. Trash this junk that makes
   me calculate explicitely the size in bytes any time I want a block of data.
   Probably the main thing keeping a lot of people from taking forth seriously
   is the lack of a data abstraction system.
   
-- 
Bill <bouma@cs.purdue.edu>  ||  ...!purdue!bouma