Re: Forth Frustrations

J Thomas wrote:
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.

If you want to use somebody else's code, how do you figure out what to fix to get it to work on your Forth?


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.

Think about the barriers to *reusing* code, not to writing it.

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.

Anyone who wants to use *my* code can install a practically portable LSE64 system for free. Now all I have to do is document and publish something worth using ;-)


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.

What other users? No current user of my code knows anything about Standard Forth, so it would be *more* trouble for them if I used Standard Forth (much more complex and difficult to learn) than LSE64.

There are these weird myths that you return to:

1. Standard Forth is what users know.

In fact, few users know *any* Forth dialect, so the advantage goes to a simple dialect over a standard one.

2. There's a vast valuable code base out there ready to be used.

C has this. Python has this. Forth doesn't.

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.

LSE64, with its single portable implementation, is more practically portable than Standard Forth.

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.

It's a ball and chain dragging Forth into the depths. Forth is to valuable a programming technique to be left to a handful of Standard Forth programmers.


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?

No, Ritchie led us out of that particular bind, there is no issue any longer. There are still a few diehards, but they don't matter. Forth needs a Ritchie, but it never got one. Any volunteers?


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.

Nope. "You can't add simplicity".

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.

Not quite. It makes sense to explain the machinery, but you should be able to present the language linguistically without forcing the user to be excessively conscious of the machinery all the time. That is, after all, the way we teach natural language.


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.

I think we could find better abstractions. But plainly memory manipulation needs some explanation.

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?

Mine does, although I'm pretty well decided I want to separate them.

That if you do >R DO that the
saved data is unavailable until after the loop quits?

Should the implementation permit return stack manipulation at all? It's not very linguistic, it's a source of bugs, and it doesn't really gain much. A recent constructive criticism of LSE64 here suggested getting rid of it, and I think I agree.

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.

Again backwards. The real burden is on the importer.


But note -- the standard doesn't prevent standard systems from being
simple. (Except perhaps in requiring a lot of words to be available.)

Sure it does. The worst thing is it requires both the real language and the interpreted pidgin. Two languages where only one is needed.

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.

Don't keep everything else, then.

To make it simpler you have to make other changes too, that
fit together with that change.

Yes! All you need to see is that this is an opportunity, not a problem.

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.

"You can't add simplicity."


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.

Maybe. But Standard Forth isn't simple.


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.

How do you decide? Tricky business. Ritchie nailed it pretty well, though (for a much wider range of applications that he intended). I'll stand on those shoulders.

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.

The peculiarities needed to write it in Standard Forth are worse.


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.

Only way to get you outside the box. Doesn't work well, but nothing else works at all.

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.

I don't agree that IMMEDIATE is a mess. It's only a mess because it doesn't fit the pidgin model of the interpreted language. But for the compiled language, IMMEDIATE and its generalizations are *precisely* the tools you need for grammar beyond RPN.

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.

No you aren't, you're stuck in the Standard Forth box. What's really diabolical about Standard Forth is that it is a stable attractor. Have to climb pretty far to find another basin.

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.

If you're using Standard Forth you're pretty close to that already. A very tiny community that doesn't share very effectively.

And I don't feel charismatic enough at the moment to make my
own language and proselytise it to businesses etc like you do.

I don't. It's a tool I use to solve their problems. I document the solutions and they take over. But the jobs are not primarily programming jobs. Keeping the programming quick and simple so the tougher problems get addressed is the goal.

Besides, nobody has ever called *me* charismatic ;-)

And I
sure don't want to teach a computer course and make my students learn
my special language.

You keep it *simple*, it's trivial to teach.

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.

Ok, now you're starting to glimpse what I'm talking about.


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.".

The money comes from solving the problem, not from using the tool. Still, good tools are helpful.


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.

--
John Doty, Noqsi Aerospace, Ltd.
--
Specialization is for robots.
.

Relevant Pages

  • Re: Forth Frustrations
    ... How would they even know what they are without being language lawyers? ... Then if you choose a standard system you can write code for it, ... interpreter, ... They set up four states -- HOST INTERPRETER COMPILER ...
    (comp.lang.forth)
  • 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)
  • 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: Two Questions about "strlen", "strcat" and "strcpy"
    ... >> No. zero terminated strings is the whole problem in the first place. ... > OR length prefixed strings the language would retain compatibility ... is not easily duplicated with the old standard then it will foster interest. ... The C standards committee is dead. ...
    (comp.lang.c)