Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!willett!dwp
From: dwp@willett.UUCP (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: Non-Forth systems/languages.
Message-ID: <468.UUL1.3#5129@willett.UUCP>
Date: 14 Feb 90 02:20:33 GMT
References: <461.UUL1.3#5129@willett.UUCP>
Organization: Latest link in the ForthNet chain.  (Pgh, PA)
Lines: 29

In article <461.UUL1.3#5129@willett.UUCP>, ZAFAR ESSAK writes:
>  LB>  C is built on the "streams concept", making all input and output, 
>  LB>  regardless of origin, look like a file. 
>  LB>  That is both a blessing and a curse. 
> 
>  Could you please elaborate on how the Stream approach is a curse. 
>  Having used Forth for many years without Streams I was surprised at the 
>  ease with which a number of problems could be solved once stream I/O 
>  was added to Forth.  This was especially true of data translation from 
>  one format to another.  I am inclined to think that stream I/O should 
>  be made a fundamental component of Forth, after all doesn't the 
>  interpreter view input as a "stream" coming either from the keyboard or 
>  mass storage? 

From my Unix/C experience, the problem with streams is that you run into
hardware weirdness when dealing with any real device.  Things like
suppressing echoing on input from the keyboard, raw vs. cooked input,
blocking factors, cr/lf translations, parity and stop/start bit(s)
considerations, timing and padding constraints, speed(bps rate)
selection.  Additionally there are the relatively recent windowing/screen
management interfaces and issues of mixing text with windowing calls and
graphics primitives.  But, streams may still be a step in the right
direction.

		-Doug

---
Preferred: willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp
Daily: ...!{uunet,nfsun}!willett!dwp   [in a pinch: dwp@vega.fac.cs.cmu.edu]