m-coughlin <m-coughlin@[EMAIL PROTECTED]
> wrote:
> The problem is not having too many versions of Forth. We have
> solved the problem of how to easily create new programming
> languages. This is a great advance in what is loosely called
> computer science. Now we have the problem of creating a new
> version of a Forth like language that doesn't immediately need
> to be changed.
Or a way to change it that doesn't cause trouble. If you can easily
change it to suit yourself and nobody minds, then we're set.
> I have also met several people who had implemented new
> versions of Forth, but have not done much with them later. They
> had seen many versions of other Forth's, used another Forth to
> start with, or started with a small amount of assembly language.
> Sometimes they only needed a special purpose system that was to
> be used for a short time.
No problem there. If you can build what you need quicker than you can
program a solution in another language, then you're set.
> Sometimes they wanted to produce a
> better version of Forth than they could get anywhere else and
> then got lost in trying to write the do***entation.
So a better way to do***ent Forth systems would be good. Maybe a sort of
framework that describes how the pieces fit together, and you do***ent
the things you changed? What do***entation do users need? If we could
make sure that gets supplied.... If you could find the sort of user you
care about and get him to call you whenever he has a problem.... and you
record what went on and look at just what he needed, and arrange to
supply it....
> I think you
> can only learn to write Forth well enough if you learn to write
> your own version. Its like learning mathematics or physics. You
> have to be able to prove all the formulas, not because the old
> formulas might be wrong, but because this is the way you learn
> how to derive new ones.
There are people who feel like they understand well enough without
knowing the details at all. Hardly anybody who programs in Algol
languages feels like he has to understand precisely how the language
gets its results. Even fewer when it's a scripting language. Most Perl
programmers don't care how Perl is implemented, all they care is that it
gets the results they want.
If you build your own Forth then you can understand Forth routines that
otherwise might not do what you expect. You know why they work the way
they do. If we had better ways to show people what to expect from Forth
then this sort of person would like Forth better. And if you've written
your own Forth you have an idea which things have higher overhead.
You're more likely to use compiler macros than text macros, for example.
To a naive user they both look like they do the same thing, but the text
macro does lots of things at runtime that the compiler macro handles at
compiletime.
The advantages you get from building your own Forth ought to be somehow
available to people who don't want to build their own Forth. Because a
lot of people don't want to.
|
