Post by Tristan WibberleyPost by Anton ErtlPost by mhxWhat if the program writes a float to a byte location?
That's not a safety problem (as long as the location is big enough for
the float), so one can design a Safe Forth variant that allows that.
I'm not very familiar with forth yet, does this refer to writing to a
machine addressed location? If so, plenty of computers have alignment
requirements, a DoS can be introduced by the above action.
Also, if you write a byte to a float location, a variety of problems can
be introduced including running trap callbacks that were insufficiently
tested for the new program state, etc, killing the process and running
restart sequences where less volatile state can now be in an unusual
condition and new side-effects induced, and so on.
memory safety means maintaining invariant relations wrt. each memory
location.
This entire discussion really made me laugh. How sentiments change..
I can remember when I wrote 4tH people were dismissing it, because of
its safety features: "This is not Forth".
But 4tH addresses most of the issues at hand. You cannot write a float
on a character, because those reside in different segments. You cannot
overwrite execution code - because that not only resides in a different
segment, but it's also "read only".
If your execution pointer goes outside the code segment, the program
simply stops. If you do a MOVE - any MOVE - it will check the bounds
before going at it at C speed.
Now - I won't say you can't do any damage. It doesn't do any array
bounds checking, so a string can spill into another string. But it will
not spill outside its segment. If you use a random integer value as a
pointer, it will be okay to corrupt anything inside that segment, but
not *OUTSIDE* that segment. And frankly, that's all the safety I need.
If you think you will revive Forth by jumping on that Rust bandwagon, I
think you're wrong. You won't attract a new audience and you won't get
the acceptance you crave for. First and foremost, because I think Rust
is the wrong idea. It's been tried before - Ada, Pascal, Java - in some
sense: BASIC.
Good programmers exist because they are good programmers. Bad programs
exist because of bad programmers. Let me quote one of the foremost CS
scientists who ever lived:
"Ada will not meet its major objective, viz. that of reducing software
costs by standardization, and it will not be the vehicle for programs we
can rely upon, for it is so complicated that it defies the unambiguous
definition that is essential for these purposes. Long before the design
was frozen, computing scientists from all over the world have given
plenty of warning but the political body in question preferred to ignore
these warnings and to decide on a design that cannot be salvaged. From a
scientific point of view all further attention paid to Ada is a waste of
effort. But the sheer buying-power of the DoD makes Ada an undeniable
reality, which in combination with DARPA's policies for the funding of
software research can only increase the pressure to spend research
effort on the wrong problems.
Another series of stones in the form of "programming tools" is produced
under the banner of "software engineering", which, as time went by, has
sought to replace intellectual discipline by management discipline to
the extent that it has now accepted as its charter "How to program if
you cannot."
Let that sink in: "It will not be the vehicle for programs we can rely
upon, for it is so complicated that it defies the unambiguous definition
that is essential for these purposes". That is the very definition of Rust.
All the time you're spending getting your code to compile, you're not
creating programs. I'd say that's the reverse of productivity. The
higher the abstraction, the more difficult it is to understand - let
alone to teach.
Compare "pointer" to "a variable containing an address", the beauty of
"an object" to "a structure with a few function pointer fields" and a
bunch of syntactic sugar (i.e. object.method vs. method(object)).
Lifetimes? Borrowing? Are you kidding me? After programming in Forth for
over 30 years now, I'm slowly getting why I get things done in Forth
that I would never have imagined to tackle in C. Forth has some
remarkable principles. The stack is one of them. The principle "execute,
throw on the stack or throw an error" is another one. The dictionary,
consisting of a function pointer and a string is another one.
Simple principles, simple to grasp, but very powerful - especially when
combined. ColorForth added a few more, BTW.
I tend to trust my Forth programs a lot more than my C ones, for the
simple reason that there were a million (stack) errors I could have made
along the way - every single one of them capable of turning my beautiful
program into a steaming pile of dung.
So, safety, yes. I like that very much. I ventured into that very early
and I never regretted it. But apart from some basic checks it should
stop at the point where I have to convince a compiler that I know what
I'm doing.
Hans Bezemer