Re: Forth Frustrations

On Apr 15, 11:19 pm, John Doty <j...@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
J Thomas wrote:

This does not seem difficult to me. In practice pretty much nobody
writes out their environmental dependencies,

How would they even know what they are without being language lawyers?

Why does it matter?

If you want a Forth system you can use somebody else's or build your
own. If you use somebody else's you can choose among a number of
standard systems and a large number of nonstandard ones.

Then if you choose a standard system you can write code for it, or you
can write code with the idea you might want to port it to another
standard system. If it's the latter then you benefit by learning about
the standard. But if you don't do that, you can still port your code
to another system. Just test it very very thoroughly and find out
where it's going wrong and rewrite little sections for the new system.
You did build thorough test suites, didn't you? Then you shouldn't
have a lot of trouble. More trouble than if you'd written with that in
mind in the first place, and you'll have it to do over again when you
port again, but it's also discounted time -- the time you would have
spent earlier thinking about how to make your code portable was *more
valuable* than the time you spend later, when you're older and
depreciated.

If you use a nonstandard system you'll have more trouble porting your
code. But that's fine, maybe you don't care about porting your code.

If you build your own Forth system you can make an effort to get it
standard or you can do whatever you like. If it's closer to standard
than other users will have less trouble learning to use it, and they
can port code easier to it, and you get to say it's standard with some
environmental restrictions. If you don't care about those things then
do whatever you want.

I repeat, if you aren't concerned about porting code, you don't need
the standard. Now, if you're a professional Forth programmer it's good
to learn how to write with standard Forth systems because many of the
jobs will use standard systems. But your resume will look better if it
says you're familiar with SwiftForth and MPE's Forths Win32Forth and
GForth and polyForth and ChipForth etc than if it just says ANS
standard Forth and polyForth and ChipForth etc.

So what's the problem? If you don't like the standard, ignore it.

I'm really not clear what value you get out of poking at this. You
appear not to know much about standard Forth, but you object to it,

I have studied it enough to understand what a ridiculous mess it is. It
reminds me very much of PL/I, whose enthusiasts never understood that it
was complex. Maybe I was one of them, once. But after a few times of
helping PL/I newbies whose only crime is the naiive belief that "/" is a
sane way to divide things, you realize this isn't a sensible language,
despite the propaganda. At least you do if you have your brains turned on.

So, is there a PL/I newsgroup still up with diehard PL/I users talking
about how great it is? Do you go there and tell them they don't have
their brains turned on? Do you have anything better to do with your
leisure time?

and you leave it quite unclear what it is you want other people to do
about it.

Think about what a real 21st century Forth might be. Forth without
simplicity is pretty pointless.

Agreed. Now, I expect it's possible to make about fifty dozen
different very simple Forth systems that are ANS Standard Forths. You
don't want their user manuals to be based on the standard, describing
what they all have in common plus something about the differences.
That would not be a good user manual.

You don't want the user manual to explain about the control-flow stack
which may or may not be on the data stack and which may or may not
even be a stack -- provided it behaves like a stack for DO LOOP IF
THEN etc.

You don't want your user manual to explain about the things that can
clobber data left at HERE -- any interpreting, any compiling, any
numeric output, any block addressing, and of course any use of ALLOT ,
C, etc by the user. And those might interfere with each other?! any .S
while compiling might mess up the compilation?! Yes, but only in
minimal systems that try to save as much space as possible. Your users
don't have to worry about that.

Do you want your user manual to have to explain how the loop stack and
return stack interfere with each other? That if you do >R DO that the
saved data is unavailable until after the loop quits? That if you do
DO >R you absolutely have to do R> before the loop iterates? Extra
things for your user to remember, and all it gets you is one less
stack.

If you have a simple system -- standard or not -- let your users know
how your simple system works. They can learn about the standard if
they get interested in porting their code to other systems.

But note -- the standard doesn't prevent standard systems from being
simple. (Except perhaps in requiring a lot of words to be available.)
The worst the standard does is to prevent some portable programs from
using all the simplicity that a particular standard system provides.

Well, but you've talked about how you'd like us to improve
our Forths into things that are simpler, that are better than LSE64.
Only you've left it kind of vague what you think of as simple.

I can't even get most people here to understand how useless the
interpreter is, although that should have been obvious to anyone with a
true interest in Forth since about 1978. But even smart people have
blind spots.

I explained the problem to you several times, but I'll try again. When
you keep everything else in a modern Forth and get rid of the
interpreter, you don't make it simpler. You just move the complexity
around. To make it simpler you have to make other changes too, that
fit together with that change. Lots of people have tried removing the
interpreter and decided it wasn't worth doing, because it made too
many other things complicated. So to preach to us about that, you need
to talk about the other simple improvements that work with it.

I figure if your virtual machine is actually doing something simple,
then you can tell the users what it's doing and it will be simple for
them too.

But that doesn't engage the language instinct. Tell them how to say "add
two numbers" or "create a definition" to the computer. The VM can (and
should!) still be simple. One of the nice things about RPN is that it's
isomorphic to the operation of a simple stack machine. But that doesn't
mean you can forget linguistics and just implement a VM.

I assert (without evidence, really on faith) that if you can make a
simple VM you can explain it simply. If the language to use the simple
VM is truly simple, it will be easy to learn. People are good at
learning simple languages.

The miracle of the early Forths was that you could easily see right down
to the hardware if you needed to, but the language was still simple.
Then standard Forth went the TCL route obfuscating the hardware (but far
more sloppily than TCL).

They wanted to allow lots of different hardwares. Remember that the
Forth 83 standard restricted standard Forths to 16-bit indirect-
threaded. They didn't want to make that mistake again.

LSE64 is a compromise. Few nowadays know much
about the hardware, so C is about the lowest foundation that makes
sense.

That doesn't make sense to me. When you make a virtual machine, the
virtual machine gives you a simplified look at the hardware. You want
to fuzz out the complexities that aren't worth paying attention to and
leave the things that are important to pay attention to. If your users
are figuring out the peculiarities of your system by looking at the
workarounds you needed to use to write it in C then something is
wrong.

And you keep on trying to persuade everybody else that they're on the
wrong track. Wouldn't it make sense to lay off?

Maybe it would, but you guys are helping sharpen my ideas on how to
proceed with LSE. What the hell do I know?

Ah. You keep telling us we're wrong instead of asking for help. Here's
one thing -- you might try looking at the proposed cross-compiler
standard. They set up four states -- HOST INTERPRETER COMPILER
TARGET . You could follow their lead for something that isn't a cross-
compiler, then HOST is TARGET . The default state is TARGET . Target
words get compiled, compiler words get executed, interpreter words get
executed on lines that get executed, but mustn't get compiled into
target words. To make a new compiler word you switch to compiler
state, and compiler words can get compiled into new compiler words. To
make a new interpreter word (interpreter words define things or allot
data) you switch to interpret state, and then you can compile
interpreter words.

I believe it eliminates most of the IMMEDIATE mess. You can only
compile compiler words into other compiler words. Simple and easy. I
don't see how to compile compiling words into interpreter words, which
is an inconvenience but not a gotcha.

But if you want to get people to pay attention to your ideas and maybe
try them out or something like that, wouldn't you like to consider
some alternate methods?

Wouldn't *you* like to consider some alternate methods?

I'm doing that. People criticise them. I try to get a sense of the
complaints and find I sometimes agree. This last time it was better to
agree to disagree. I realised that what in Forth is a wordset is in
some other languages an associative array or a database. You provide a
key, and it returns a value. It made perfect sense to me that to add
an element to the array you shuld give it the key and the value, when
you have both ready. And getting the name from the source code is
easy, so do that last. One single operation to add to the dictionary.
But the main response was that people wanted the name in front.

Every time I seem to get *you* interested into coming out onto dry
ground, you immediately wander back into the swamp! If only I could get
you to see that a standard (any standard) is not a good idea for Forth.
Most languages that are growing have no standard...

I don't feel like inventing my own language and using it all by
myself. And I don't feel charismatic enough at the moment to make my
own language and proselytise it to businesses etc like you do. And I
sure don't want to teach a computer course and make my students learn
my special language. I tried that with Forth years ago. It was pretty
successful among the students for two years, and then the dean handed
me the Pascal package he'd bought that the students would use the next
year....

I dunno. Most growing languages today have a reference implementation.
If you come up with a neat idea to add to the language that requires
changing something already there, either the language's inventor looks
at it and decides yes or no or some big committee kicks it around for
a year or three before tossing it out or possibly putting it into
Version 8.0 of the language. Chuck isn't interested and the committee
wouldn't have a reference implementation, they got multiple important
vendors before they had a standard. I just don't know. Forth isn't
particularly growing, and we have a standard that's no substitute for
a reference implementation. I just don't know.

There are various people who make their entire income off Forth. I'm
not one of them. I remember about fifteen years ago I was looking into
making a living off Forth and I described what was going on then with
Forth to a friend who had an MBA and some experience with sales and
such. He listened to me for awhile and then he said, "Jet, you're
trying to milk a bull.".

If somebody got one very large customer for a particular simple Forth,
somebody who'd hire a lot of people to use that version, and they gave
it a new name, they might get a lot of growth that way. I dunno.

.

Relevant Pages

  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)
  • Re: Forth Frustrations
    ... How would they even know what they are without being language lawyers? ... standard systems and a large number of nonstandard ones. ... interpreter, ... They set up four states -- HOST INTERPRETER COMPILER ...
    (comp.lang.forth)
  • Re: to learn jQuery if already using prototype
    ... language is inherently using that process. ... Compiler, then it becomes clearer how to, at least, distinguish the ... An interpreter is defined by *two* things: ... you run the implementation language and give ...
    (comp.lang.javascript)
  • Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... > the standard language. ... Or did they just implemented some 80% of the new features? ... there was a fully compiant C compiler available. ...
    (comp.lang.ada)
  • Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... > the standard language. ... Or did they just implemented some 80% of the new features? ... there was a fully compiant C compiler available. ...
    (comp.lang.cpp)