In article <CEFI10.1pn@murdoch.acc.Virginia.EDU>, jvn@fermi.clas.Virginia.EDU (Julian V. Noble) writes:
|> pop@dcs.glasgow.ac.uk writes:
|> > Code Speed Availability Price Size GC INC
|> > -----------------------------------------------------------------------------
|> > C excellent near-universal cheap Modest no no
|> >
|> > Poplog VM good but Unix&VMS - most expensive Big yes yes
|> > poor floats major architectures
|> >
|> > Forth poor? cheap? Modest? no yes
Let me first complete the table:
Forth implementation-dep. near-universal imp-dep. Small no yes
Interpreted Forths are 5-10 times slower than assembly language,
Native code Forths as fast as C. Since there are Forths written in C,
the availability of Forth is art least as good as that of C. There are
commercail Forths for all price ranges, and some usable free
implementations, too. If C is modest-sized, even F-PC is small.
|> > Now, there are various gaps to close. How good can Forth code be made? Is
|> > a built in garbage collector desirable?
|>
|> FORTH generally does not need garbage collection because all
|> memory allocation is under the user's control. That is, FORTH
|> does not often use linked lists (other than the dictionary) and
|> if a user defines a LL, then it is his responsibility to see that
|> the trash is taken out.
Those numeric guys obviously have never felt the need for garbage
collection. But for the work I do, having to program storage
reclamation by hand is a pain in the ass. So, yes, garbage collection
would be desirable. However, in contrast to Robin Popplestone I don't
think that conservative garbage collectors don't count. They may have
their problems, but they are better than nothing. Although having no
storage reclamation also works for my applications in my environment
(64MB RAM, 384MB swap space).
- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
|