Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!mailrus!tut.cis.ohio-state.edu!ukma!uflorida!haven!uvaarpa!hudson!vivaldi!pmy
From: pmy@vivaldi.acc.virginia.edu (Pete Yadlowsky)
Newsgroups: comp.lang.forth
Subject: Re: type checking
Message-ID: <556@hudson.acc.virginia.edu>
Date: 13 Sep 88 22:46:14 GMT
References: <8808121826.AA23206@jade.berkeley.edu> <1575@crete.cs.glasgow.ac.uk> <7071@well.UUCP> <1457@ficc.uu.net> <17702@glacier.STANFORD.EDU>
Sender: news@hudson.acc.virginia.edu
Reply-To: pmy@vivaldi.acc.Virginia.EDU (Pete Yadlowsky)
Distribution: na
Organization: University of Virginia, Charlottesville
Lines: 41

In article <17702@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes:

>      "while maintaining the thing everybody likes - the environment."
>The block-oriented disk files and the heap-structured dictionary?
>That's a desirable environment?

Apparently so, to those who know it. Actually, many modern forths
interface well to the presiding OS, and use named disk files instead
of blocks.

>      I've used Forth out of dire necessity on very tiny machines in
>embedded applications.  But I cannot see much use for it on anything
>large enough to support a serious compiler.

You may be confusing "serious" with "traditional" here. There's nothing
I see about, say, C (which I write in quite a bit), which makes it
more serious than Forth. The main reason I use traditional compilers
is for convenience. They are much more heavily supported by the OSs
I work in than is Forth. This does not mean that Forth is somehow less
"serious".

>On the other hand, a compiled Forth with type checking might be useful.

Such a "Forth" would not be Forth at all, but a crippled facsimile.
We already have lots of languages with the above characteristics. Why
add another? Why mutilate Forth?

>      One observation is that novice programmers get excited about small
>scale syntactical issues, such as RPN vs infix, and more experienced
>programmers get excited about large scale issues, such as modularity and
>name-space management.  As program size grows, these issues dominate,
>for combinatorial reasons.

Yes, but what is your point here?



Peter M. Yadlowsky
Academic Computing Center
University of Virginia
pmy@vivaldi.acc.Virginia.EDU