Path: utzoo!attcan!uunet!mcvax!ukc!strath-cs!glasgow!orr
From: orr@cs.glasgow.ac.uk (Fraser Orr)
Newsgroups: comp.lang.forth
Subject: Re: Forth "Pre-Compiler" (Long)
Keywords: Design Development Forth Compiler Object Oriented FAD
Message-ID: <1500@crete.cs.glasgow.ac.uk>
Date: 19 Jul 88 14:42:57 GMT
References: <10036@eecae.UUCP>
Reply-To: orr@cs.glasgow.ac.uk (Fraser Orr)
Organization: Comp Sci, Glasgow Univ, Scotland
Lines: 108

In article <10036@eecae.UUCP> you write:
>
>	First and foremost, Forth must be small/compact/efficient.  This
>	concept has driven Forth from the early days, and is still quite
>	an important concern today.

As you mention later this is certainly a requirement for an executible
language, but is this really a burden that must be put upon the
programmer? Surely generating small/compact/efficient code is the
responsbility of a compiler. This leaves the programmer to think about
the thing he is good at - generating small/compact/efficient alogorithims.
So, yes small/compact/efficient code is an advantage both of Forth and
68000 assembler.

>	Forth must be portable.  This has been accomplished by various
>	`standards committees', and Forth exists as a `standard' language
>	for the most part.

Last time I looked at forth ( which was a while ago I admit), there were
two "standards", Fig-Forth and Forth-79 ( or whatever it was called. I know
that Forth-83 has also come into being, has this superceded both (i.e.
completely superceded both?).

>
>Why I LOVE Forth:
>
>	It is FAST! -- Above all else, Forth is one of the fastest
>	executing languages around.  Since it is functionally both a
>	compiler and an interpreter, this speed is evident both in the
>	execution of the program and in it's compilation.  The speed of
>	Forth also makes for rapid prototyping.

Yes its fast, but so is 68000 assembler. Rapid Prototyping! Speed of
execution is nothing to do with rapid prototyping, it requires facilities
to generate prototypes rapidly, i.e. being able to translate an idea or a
change to an idea quickly. This is provided by using a high level language,
not a macro assembler like Forth.

>
>	It is ELEGANT! -- Most of the implementations of Forth share a
>	cleanliness of paradigm that I find quite pleasing.  Programs
>	developed in Forth tend to be quite `bugless' because of this
>	`oneness of vision'.

Oneness of vision is a great thing in a world where we only want to do
one thing, unfortunately I want to do lots of different things such as
arithmetic, and procedure calls. to do these things I want to use the most
expressive means or most normal means avaliable to convey my intention 
to the computer,
i.e. "a+12*(37+b)" rather than "a 12 37 b add mul add"
and  "MoveCursor(x,y)" rather than "x y MoveCursor"

>
>	It is POWERFUL! -- Forth includes a flexibility of control that,
>	I believe, is unprecedented in most programming languages,
>	(except, perhaps, for Lisp).
>

Power is not necessarily a quality, the thing that makes goto such an
undesirable thing is that it is so powerful, and thus the reader finds
it dificult to follow what is going on ( so many possibilities, which
one to choose?)

>
>	It is SMALL! -- We all know this one.  Forth is a tiny language.
>

The computer I am typing this on has 12 MB of memory, small is getting to be
less and less of an advanage.

>Why I HATE Forth:
>
	[Reasons deleted, I agree with them all]

You may think from my above comments that I am a forth hater, this is not
true. I see forth as being one step up from machine code, i.e. a machine
independent assembler. I think this is a useful tool, but, for the same
reasons I don't program is 68000 assembler, I don't program in Forth.

>
>Forth Application Developer - FAD
>

One of the excellent features of forth is its ability to be changed into
a specialised language for specific tasks, for example controlling
telescopes or as a page description language, this is my field of 
interest. I am of course talking about PostScript, or more particularly
Sun Microsystem's NeWS window manager programming language ( this is a 
variant of PostScript that allows the programmer to deal with input, has 
simple multiprocessing, and object oriented features).

I think, Robert that you should have a very close look at this language
before you start work on FAD, because it answers many of the questions
you will have to ask in designing such a system.

I further agree totally with your point that one of the main problems
that has held back Forth for so long, is the inability to seperate
target machine from development machine. Why not build FAD ontop of
an existing environment such as UNIX? NeWS fits very well into the UNIX
system, ( for example, I found it simple to knock up a yacc parser to give
me a decent syntax), I see no reason why forth shouldn't do likewise, and 
if you use pure forth as the machine code generated then you loose just
about all of your porting and cross compiling problems.


==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK)
UseNet: {uk}!cs.glasgow.ac.uk!orr       JANET: orr@uk.ac.glasgow.cs
ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk