Diagramming Robust AI

Jonah Thomas jethomas at ix.netcom.com
Thu Mar 26 13:09:55 EST 1998


In article <351A7C08.A41BA378 at clickshop.com>,
	Seth Russell <sethruss at clickshop.com> wrote:
>Jonah Thomas wrote:

>> >What language was FORTH written in?

>> Mostly in Forth.  A limited number of
>> "primitives" got written in assembler, and then
>>  the rest were done using those primitives.

>This is an excellent approach.  However it can be improved
by writing
>the original primitives in C.  Then the whole system will
be portable.

Then it will be portable to all the systems you have a
compatible C 
compiler for.  Back in the days when doing that was new,
there was a lot 
of discussion about ways to handle Forth I/O within the
limits imposed by 
C.  I didn't hear how that turned out, but presumably they
found workable 
tricks that let them do what they needed.  Even if it's a
lot more 
trouble to write the primitives in C, still it gives
portability to a 
whole lot of systems.  And you can still write an assembler
and 
primitives for new systems, if you need to.

>I took your approach some years ago on the Apple II and if
I had written
>the primitives in C, my system would still be alive today.   

It depends.  It wasn't worth it to you to rewrite the
primitives in a new assembler.  If you'd written the
primitives in Fledermaus C (I wonder how many versions of C
were available for the Apple II?) then you'd have had 
to rewrite the primitives for a different C compiler.  Same
problem, but more complex.

>> Some people have taken to writing Forths in C
>> so they won't have to rewrite the primitives
>> when they switch to a new system that already
>> has a C compiler.  But traditionally Forths have
>> been written in Forth and assembler.  And typically
>> the first step in writing a Forth for a new system
>> has been to write an assembler in an existing Forth.

>The real question is how standard is Forth already.  Could
you just take
>your particular Forth code and run it on somebody else's
Forth?  If you
>can't do that, then you should factor the responsibility
of portability
>into your project.

It's possible to write in ISO-Standard, ANS-Standard Forth. 
Typically people build some habits that tend to lead toward
portability, and they 
also use special nonstandard conveniences their particular
systems 
provide.  I think this might be partly that by the time the
specs get written in stone and no more rewriting will be
needed, then it's time to give it to some hack to slowly
rewrite in C.  Why try for the maximum in portability when
you'll just have to rewrite it again to meet new
requirements, anyway, long before it gets ported?

>I have a sneaking suspicion that this is a rationalization
for using the
>skills and computers at hand, rather than a choice of the
best possible
>course of action for your project (my apologies in advance
if I am
>misinformed, which is an distinct possibility).

Not my project.  But I think you're right about Mentifex's
project.  
MVP Forth is not standard, but he has a working system and
documentation.  
He's exploring.  We could advise him which computer to buy
to get the 
best possible result for his project, and which Forth
compiler would give the best possible result, and he could
spend a few months learning to use them before he gets
started.  As it is he has a system he can use to make 
an adequate demo, and when someone gets interested they can
translate it into C or standard Forth or lisp or whatever,
and improve the algorithms while they're at it.



More information about the Neur-sci mailing list