Syntax alterability, strength or weakness? (was: What good is it?) 
Author Message
 Syntax alterability, strength or weakness? (was: What good is it?)

 lets face it, you either like K&R or you like Chuck Moore, and
that's it. If you want something inbetween you're on your own....

--
via Fortress Gateway at uumind.mind.ORG



Sat, 02 Dec 1995 13:49:00 GMT  
 Syntax alterability, strength or weakness? (was: What good is it?)

:

Quote:
> lets face it, you either like K&R or you like Chuck Moore, and
>that's it. If you want something inbetween you're on your own....

Point is well-taken, altho I don't much care for either specific example:

I'm not much into K&R since I'll likely never write a C program without a
prototype nor on a compiler that refuses to support prototypes.

(is this unrealistic? Will K&R C compilers continue to linger and plague QA
departments everywhere? Can I always find a prototype-supporting compiler on
every platform I meet? Even if 'no', I feel prototypes envaluable for compiler
type checking.)

And: I also don't much care for the Moore Minimalism un-standard. I think that
the better defined a standard is, the better and more robust is the portability
factor. I like FIG's work, however, and I like the fact that they brought
high quality FORTH systems to the world for _reasonable_ prices, much to Moore's
chagrin.

And on this (small) issue of the Device Word Set vs. <stdio.h>, I feel that
83-standard forth (as well as 79-standard) has the more rigorous standards
definition. It defines what KEY should do across _all_ implementations; it
also defines what it doesn't define! (that being an environmental dependancy).

With UNIX and C, all implementations support buffered I/O and that's portable
across most if not all machine boundaries. Someone correct me if I'm wrong on
this next point, but I don't believe that non-buffered I/O was originally
supported. For this reason non-buffered I/O is probably installation-dependant
(my guess). Somehow, however, vi is portable (why?) and vi does interactive,
non-buffered I/O. Perhaps Mike could explore how vi accomplishes this
portability and emulate it to produce a portable KEY-like function should that
really be what he wants to do rather than flaming about it here.



Wed, 06 Dec 1995 08:53:28 GMT  
 Syntax alterability, strength or weakness? (was: What good is it?)

Quote:

>I'm not much into K&R since I'll likely never write a C program without a
>prototype nor on a compiler that refuses to support prototypes.

K&R doesn't support prototype definitions?  Since when?
The prototypes do not usually include argument specification, but
prototype definitions are certainly utilized!  I don't know how
many times I'd gotten a K&R-level compiler tell me that
a function is being multiply-defined because I tried to
return a non-int return value from something that had no
prototype.

Quote:

>(is this unrealistic? Will K&R C compilers continue to linger and plague QA
>departments everywhere?

I haven't used a K&R compiler commercially for 4 years.  All ANSI.

Quote:
>Can I always find a prototype-supporting compiler on
>every platform I meet? Even if 'no', I feel prototypes envaluable for compiler
>type checking.)

I assume you mean ANSI-compatible compilers, and yes, I would think
that if ANYTHING was available on every platform, it would be that.

Quote:

>And: I also don't much care for the Moore Minimalism un-standard. I think that
>the better defined a standard is, the better and more robust is the portability
>factor. I like FIG's work, however, and I like the fact that they brought
>high quality FORTH systems to the world for _reasonable_ prices, much to Moore's
>chagrin.

Absolutely true.  And I think you put it well... Chuck is a minimalist,
and seldom seems concerned with what anyone wants or needs
but himself.

Quote:

>And on this (small) issue of the Device Word Set vs. <stdio.h>, I feel that
>83-standard forth (as well as 79-standard) has the more rigorous standards
>definition. It defines what KEY should do across _all_ implementations; it
>also defines what it doesn't define! (that being an environmental dependancy).

Quite a trick.

Quote:

>With UNIX and C, all implementations support buffered I/O and that's portable
>across most if not all machine boundaries.

C Standards, even K&R, never specified Unix.  They may have included C
Unix examples, but they did not stipulate that C required Unix.

Quote:
>Someone correct me if I'm wrong on
>this next point, but I don't believe that non-buffered I/O was originally
>supported.

Not possible.  VI has always supported such I/O, as you mention below.

Quote:
>For this reason non-buffered I/O is probably installation-dependant
>(my guess). Somehow, however, vi is portable (why?) and vi does interactive,
>non-buffered I/O. Perhaps Mike could explore how vi accomplishes this
>portability and emulate it to produce a portable KEY-like function should that
>really be what he wants to do rather than flaming about it here.

Number 1...

I haven't been flaming ANYTHING, except perhaps those
Forthers who are so short-sighted and myopic that they think their
incorrect statements like "KEY can't be implemented portably" actually
benefit Forth somehow.

I suspect many of those folks think that portability means that
application-specific code is never necessary (an impossibility
for any language).

Number 2...

Forth has lacked the most important facility in writing portable
code... an equivalent to #if and #ifdef, etc.  Without these
in STANDARD SPECIFICATION, portability is fantasy.

Once this capability exists, one can port code from system
to system...even between different Forth dialects.  One can
conditionally compile anything necessary.

Of course, a good specification minimalizes this, but when it
comes to I/O, things get application-specific fast, especially
when the desires of the programmer differ from what the
compiler vendor considers the "default" I/O methodology.

I can't imagine a C environment that would not allow
unbuffered I/O to a keyboard... such a product would be laughed off the
market (What C compiler wants to be the one that can't
compile VI?).

Number 3...

It is easy to specify I/O to a limited device such as a keyboard.
This is all that Forth has ever done (I don't even consider
BLOCK an I/O system, but the most minimalist basis upon one
could be built.  Anything that requires an application to
be aware of the actual physical location of every 1024-byte
chunk of mass-based data is NOT an I/O system).

Number 4...

There IS one I/O feature that Forth specifies that is NOT
EVEN THOUGHT ABOUT in C and, I think, might actually not be
able to be implemented in C, platform wide.  This is
?TERMINAL.

Now, I do not prefer C to Forth, although I think it definitely
very close.  I choose to be truthful in my comparisons of
the languages, and wish Forth would adopt, rather than oppose,
the applicable concepts C has established worldwide.
however.



Wed, 13 Dec 1995 11:47:05 GMT  
 Syntax alterability, strength or weakness? (was: What good is it?)
Quote:

>Now, I do not prefer C to Forth, although I think it definitely
>very close.  I choose to be truthful in my comparisons of
>the languages, and wish Forth would adopt, rather than oppose,
>the applicable concepts C has established worldwide.

    I can't agree with this at all. Forth stands on its own. It doesn't
need to take anything from any other language. Not from C, fortran, Lisp,
Algol, assembler, or anything else. It has already taken what it needs
from these languages and a bunch of others besides. If there is anything
some programmer wants from any other computer language then he has the
ability to add it to Forth in any way he wants. But the additions are
not part of Forth, they only create a specific application.
    There are many people who have written Forth in C and linked to
the system calls of a disk operating system. This is perfectly fine
with me, but please don't think of such systems as Forth. They are
something else and they need a different name. I think of them as
Forth emulators. Real Forth is what Charles Moore invented in the
late 1970's and even in its chaotic unstandardized state it is
superior to every other computer language I have worked with.
    It is natural to stop thinking about the mental constructs we
have learned as being arbitrary symbols and think of them as laws of
nature. People who have spent a few years learning C think it is the
way God programs computers. I can barely write a half page C program,
so I see C as a jumble of cryptic symbolic junk. I shudder at the
thought of C constructs cluttering up the logical structure of Forth.
There is always a better way of combining symbols to direct a logical
process, but we have to stop creating these sometime if we want to
get any work done. Forth has a certain style that works very well
and I can't see how it can really be improved by dropping in chuncks
of other computer languages. English literature is not improved by
including large quotations from foreign languages.

--



Wed, 13 Dec 1995 20:09:30 GMT  
 Syntax alterability, strength or weakness? (was: What good is it?)

Quote:


>>Now, I do not prefer C to Forth, although I think it definitely
>>very close.  I choose to be truthful in my comparisons of
>>the languages, and wish Forth would adopt, rather than oppose,
>>the applicable concepts C has established worldwide.

>    There are many people who have written Forth in C and linked to
>the system calls of a disk operating system. This is perfectly fine
>with me, but please don't think of such systems as Forth. They are
>something else and they need a different name. I think of them as
>Forth emulators. Real Forth is what Charles Moore invented in the
>late 1970's and even in its chaotic unstandardized state it is
>superior to every other computer language I have worked with.

  And what would you propose to call them?  PseudoForths?  NonForths?  I
would consider a Forth written in C the same as a Forth written in Assembly
Language.  If it looks like a duck, sounds like a duck, smells like a duck,
then it probably is a duck.

  And correct me if I'm wrong, but wasn't one of the first Forth systems
Mr. Moore wrote in Algol?  Why is that Forth, and one on C not?

Quote:
>    It is natural to stop thinking about the mental constructs we
>have learned as being arbitrary symbols and think of them as laws of
>nature. People who have spent a few years learning C think it is the
>way God programs computers.

  No, God programs directly in binary by toggling little switches at the
back of the computer 8-)

Quote:
>                           I can barely write a half page C program,
>so I see C as a jumble of cryptic symbolic junk. I shudder at the
>thought of C constructs cluttering up the logical structure of Forth.
>There is always a better way of combining symbols to direct a logical
>process, but we have to stop creating these sometime if we want to
>get any work done. Forth has a certain style that works very well
>and I can't see how it can really be improved by dropping in chuncks
>of other computer languages.

  I can barely write a half page Forth program (sorry) half block Forth
program, so I see Forth as a jumble of cryptic symbolic junk, but at least
I realize that Forth is powerful, and an trying to learn it right now, and
one of those steps was writing a Forth-like language.  I got flammed pretty
bad (by two people) for trying to reinvent Forth, but aren't you doing some-
thing similar by ignoring the vast libraries that exist written in other
languages by saying "That's not Forth, so let's not clutter up Forth with it."

Quote:
>                            English literature is not improved by
>including large quotations from foreign languages.

  Ah, but English is improved by including lots of small words from other
languages.  Do you want Forth to be like French, where any change, no matter
how small, has to be approved by a comittee?

  -spc (C, Forth, Lisp, Fortran, it doesn't matter.  In the end, they all
        get translated to bits anyway ... )



Fri, 15 Dec 1995 05:16:24 GMT  
 Syntax alterability, strength or weakness? (was: What good is it?)


: >    It is natural to stop thinking about the mental constructs we
: >have learned as being arbitrary symbols and think of them as laws of
: >nature. People who have spent a few years learning C think it is the
: >way God programs computers.
:
:   No, God programs directly in binary by toggling little switches at the
: back of the computer 8-)
:
On many machines God could also toggle bits in DRAMs by sending rays of alpha
particles...




Fri, 15 Dec 1995 18:09:47 GMT  
 Syntax alterability, strength or weakness? (was: What good is it?)

[stuff about not prefering C compilers not supporting fn prototypes deleted]

Quote:
>>And: I also don't much care for the Moore Minimalism un-standard. I think that
>>the better defined a standard is, the better and more robust is the portability
>>factor. I like FIG's work, however, and I like the fact that they brought
>>high quality FORTH systems to the world for _reasonable_ prices, much to Moore's
>>chagrin.

>Absolutely true.  And I think you put it well... Chuck is a minimalist,
>and seldom seems concerned with what anyone wants or needs
>but himself.

laughable case in point: Moore's 3-key keyboard that he uses to input ascii
in binary or commands or something.

Quote:
>>And on this (small) issue of the Device Word Set vs. <stdio.h>, I feel that
>>83-standard forth (as well as 79-standard) has the more rigorous standards
>>definition. It defines what KEY should do across _all_ implementations; it
>>also defines what it doesn't define! (that being an environmental dependancy).

>Quite a trick.

>>With UNIX and C, all implementations support buffered I/O and that's portable
>>across most if not all machine boundaries.

>C Standards, even K&R, never specified Unix.  They may have included C
>Unix examples, but they did not stipulate that C required Unix.

>>Someone correct me if I'm wrong on
>>this next point, but I don't believe that non-buffered I/O was originally
>>supported.

>Not possible.  VI has always supported such I/O, as you mention below.

>>For this reason non-buffered I/O is probably installation-dependant
>>(my guess). Somehow, however, vi is portable (why?) and vi does interactive,
>>non-buffered I/O. Perhaps Mike could explore how vi accomplishes this
>>portability and emulate it to produce a portable KEY-like function should that
>>really be what he wants to do rather than flaming about it here.

I got the word through email that vi uses the curses package for interactive
I/O.

Quote:
>Number 1...

>I haven't been flaming ANYTHING, except perhaps those
>Forthers who are so short-sighted and myopic that they think their
>incorrect statements like "KEY can't be implemented portably" actually
>benefit Forth somehow.

Then perhaps it's my perception of your writing. Alternatively, it might
be that you forget to set your tone when you write. Chris always does this,
setting a light tone occasionally using the smiley thingies.

Quote:
>I suspect many of those folks think that portability means that
>application-specific code is never necessary (an impossibility
>for any language).

>Number 2...

>Forth has lacked the most important facility in writing portable
>code... an equivalent to #if and #ifdef, etc.  Without these
>in STANDARD SPECIFICATION, portability is fantasy.

You can do conditional compilation either in a load screen
or using programmer-defined compiling words. Forth has far more
facility than C for doing things like this because the entire language
is available all the time (unlike the C preprocessor).

Quote:
>Once this capability exists, one can port code from system
>to system...even between different Forth dialects.  One can
>conditionally compile anything necessary.

>Of course, a good specification minimalizes this, but when it
>comes to I/O, things get application-specific fast, especially
>when the desires of the programmer differ from what the
>compiler vendor considers the "default" I/O methodology.

>I can't imagine a C environment that would not allow
>unbuffered I/O to a keyboard... such a product would be laughed off the
>market (What C compiler wants to be the one that can't
>compile VI?).

Neither can I, but a portable one in UNIX is what I haven't found yet.

Quote:
>Number 3...

>It is easy to specify I/O to a limited device such as a keyboard.
>This is all that Forth has ever done (I don't even consider
>BLOCK an I/O system, but the most minimalist basis upon one
>could be built.  Anything that requires an application to
>be aware of the actual physical location of every 1024-byte
>chunk of mass-based data is NOT an I/O system).

That's why there's stream files and block _files_. That is to say, it's
possible to map a block structure on a file, and this is often done; however
stream files are easier to integrate with the mainstream.

Then again, if you're digging in the guts of a new machine which has a disk
drive but no DOS, Forth is arguably the fastest way to be up and running
in a powerful way. I think that the boot code for Sun workstations was created
in just this way: first there was the machine with no ROM, then there was
a Forth system used as a loader (and I have heard there is a way to run that
Forth kernel on the Sun). The first disk IO that suns ever had was probably
a _physical_ Forth block system.

Quote:
>Number 4...

>There IS one I/O feature that Forth specifies that is NOT
>EVEN THOUGHT ABOUT in C and, I think, might actually not be
>able to be implemented in C, platform wide.  This is
>?TERMINAL.

>Now, I do not prefer C to Forth, although I think it definitely
>very close.  I choose to be truthful in my comparisons of
>the languages, and wish Forth would adopt, rather than oppose,
>the applicable concepts C has established worldwide.
>however.

First, I don't have a problem with your intent to be truthful and I don't,
in general, have a problem with you. I am sure I'm not the first to admit
that I sometimes just start writing without considering tone, for example
what I consider to be a half-serious statement when spoken can be interpreted
as a _very_ serious, carved-in-stone kind of feel when it's written and the
reader has no initial idea or clue as to the desired tone (since it was not
set). I'll try harder to set my tone, and I hope you will also.

-Jim (lack of a signature line like this can also contribute to tone...)



Sat, 16 Dec 1995 20:21:34 GMT  
 Syntax alterability, strength or weakness? (was: What good is it?)

Quote:


>>Now, I do not prefer C to Forth, although I think it definitely
>>very close.  I choose to be truthful in my comparisons of
>>the languages, and wish Forth would adopt, rather than oppose,
>>the applicable concepts C has established worldwide.
>    I can't agree with this at all. Forth stands on its own. It doesn't
>need to take anything from any other language. Not from C, Fortran, Lisp,
>Algol, assembler, or anything else. It has already taken what it needs
>from these languages and a bunch of others besides. If there is anything
>some programmer wants from any other computer language then he has the
>ability to add it to Forth in any way he wants. But the additions are
>not part of Forth, they only create a specific application.
>    There are many people who have written Forth in C and linked to
>the system calls of a disk operating system. This is perfectly fine
>with me, but please don't think of such systems as Forth. They are
>something else and they need a different name. I think of them as
>Forth emulators. Real Forth is what Charles Moore invented in the
>late 1970's and even in its chaotic unstandardized state it is
>superior to every other computer language I have worked with.

This I don't understand: are you saying that Forth-in-C is not Forth
even if it adheres to a standard? If so, I have to disagree: you'd
be talking about the difference between Forth running under an OS
versus a stand-alone Forth; either way, it's Forth. Yes, one of Forth's
great strengths is being able to get a kernel working on a hardware
platform that has _no_ software, not even a ROM, much less an OS and
then using it to bootstrap a much more complex OS into existance (or load
one, like UNIX). But Forth as an OS is enhanced by running under an existing
OS as well; I don't see why this is not Forth. Of course, I'm a little biased;
I have already stated that a) I like standardization when used to allow portable
programs and b) I don't much care for the Moore Minimalism Un-standard.

Quote:
>    It is natural to stop thinking about the mental constructs we
>have learned as being arbitrary symbols and think of them as laws of
>nature. People who have spent a few years learning C think it is the
>way God programs computers. I can barely write a half page C program,
>so I see C as a jumble of cryptic symbolic junk. I shudder at the
>thought of C constructs cluttering up the logical structure of Forth.
>There is always a better way of combining symbols to direct a logical
>process, but we have to stop creating these sometime if we want to
>get any work done. Forth has a certain style that works very well
>and I can't see how it can really be improved by dropping in chuncks
>of other computer languages. English literature is not improved by
>including large quotations from foreign languages.

As you must know, C and Forth are competitors for the World's Most Unreadible
Computer Language (if you ever saw John Draper's original implementation of
EasyWriter 1.0, you would conclude that Forth is potentially the world's most
unreadible any-kind-of language. Of course, john did this on purpose.)

However, C and Forth can be made readible to a _manager_. How? By teaching
the programmer to write in english, by adopting such things as good nesting
habits and by keeping things as simple as possible (but no simpler - einstein).
C programmers should not nest so frequently; breaking functions up will help
with readibility in both languages as would choosing very descriptive names.

I'm learning to not use subscripting in C when a variable is involved; increment
a pointer instead as not doing so would cause a multiply instruction to get
compiled whereas an add instruction would be done for the pointer bump. This
is hardly readible, however and leads to such code as

        printf("%c\n", ++*--*++argv + 1);

which was taken from a quiz I took for the C/C++ class I am taking. (actually,
this is an extreme example...)

Point is, both C and Forth can be write-only languages; it depends solely upon
the writer.

-Jim



Sat, 16 Dec 1995 20:57:11 GMT  
 Syntax alterability, strength or weakness? (was: What good is it?)
Quote:

> lets face it, you either like K&R or you like Chuck Moore, and
>that's it. If you want something inbetween you're on your own....

>--
>via Fortress Gateway at uumind.mind.ORG

But what about me? *I* like `em both... (Hint: this is yet another plug for
my article in FORTH Dimensions, Jul-Aug(?) `93 -- the (?) means I'm not
exactly sure which month)


Sun, 17 Dec 1995 14:54:43 GMT  
 Syntax alterability, strength or weakness? (was: What good is it?)
Quote:

>K&R doesn't support prototype definitions?  Since when?
>The prototypes do not usually include argument specification, but
>prototype definitions are certainly utilized!  I don't know how
>many times I'd gotten a K&R-level compiler tell me that
>a function is being multiply-defined because I tried to
>return a non-int return value from something that had no
>prototype.

Although this isn't germain to comp.lang.forth, this is where I ran across
it so this is where I'll answer it.  A prototype defines for a C compiler
the types of the arguments that a function expects, not just what the function
returns!  For example, this is a prototype:

void foo_function(int,char *);
                   ^   ^

This example tells the compiler that foo_function expects an int argument and
a char pointer argument, and returns no value.  This will definitely cause
a K&R compiler to choke.  The type of error you are talking about is
inconsistent external declarations, not inconsistent prototypes.

If you want to learn more about C compilers, and you don't want to subscribe to
comp.lang.c, you might try picking up FORTH Dimensions.  Although the magazine
is about FORTH, I recently started a series of articles about porting the UNIX
operating system to FORTH, and I will be covering the C compiler I'm writing
to that end.



Sun, 17 Dec 1995 15:04:46 GMT  
 Syntax alterability, strength or weakness? (was: What good is it?)

Quote:


>>>Now, I do not prefer C to Forth, although I think it definitely
>>>very close.  I choose to be truthful in my comparisons of
>>>the languages, and wish Forth would adopt, rather than oppose,
>>>the applicable concepts C has established worldwide.

>>    There are many people who have written Forth in C and linked to
>>the system calls of a disk operating system. This is perfectly fine
>>with me, but please don't think of such systems as Forth. They are
>>something else and they need a different name. I think of them as
>>Forth emulators. Real Forth is what Charles Moore invented in the
>>late 1970's and even in its chaotic unstandardized state it is
>>superior to every other computer language I have worked with.

>  And what would you propose to call them?  PseudoForths?  NonForths?  I
>would consider a Forth written in C the same as a Forth written in Assembly
>Language.  If it looks like a duck, sounds like a duck, smells like a duck,
>then it probably is a duck.

   The part of Forth that is most unlike other computer languages is the
inner interpreter. It is the part that needs the most effort at optimization
since it sets the speed of operation and determines where the executable
code can be located in memory. If you can write an efficient inner
interpreter in straight C, then I might be inclined to consider a Forth
written in C to be worthwhile.

Quote:
>  And correct me if I'm wrong, but wasn't one of the first Forth systems
>Mr. Moore wrote in Algol?  Why is that Forth, and one on C not?

    Chuck Moore tried a lot of different programming languages and
creative ways to use them before he came up with something that he
named Forth. The way I understand the history articles I've read,
the first versions of Forth were started by writing enough code in
assembly language to compile ASCII Forth source on a new system.
When there was one Forth system running on a DEC LSI-11, it
was used to write new Forth assemblers for other computers. Then
the inner and outer intrepreters were written on the LSI-11, cross
compilied (or assembled) and loaded into the new computer. Then
there was enough code running on the new computer to compile or
intrepret Forth source sent over from the LSI-11.
    Now I wasn't there at the time and I've never written my own
Forth system for a bare computer board, so I can't give all the
exact details. Perhaps someone with more experience will tell us
about it.
    . . . .
Quote:
>I realize that Forth is powerful, and an trying to learn it right now, and
>one of those steps was writing a Forth-like language.  I got flammed pretty
>bad (by two people) for trying to reinvent Forth, but aren't you doing some-
>thing similar by ignoring the vast libraries that exist written in other
>languages by saying "That's not Forth, so let's not clutter up Forth with it."

    One of the things that most impressed me when I first learned Forth
was how it got its power by leaving out large amounts of things that
other languages and operating systems couldn't get along without. Before
I knew about Forth, I thought it was impossible to use a computer without
floating point numbers, compiliers, linkers and complicated disk managers.
Forth opened my eyes. The vast libraries that exist for other languages
are an impediment to using computers. It takes more time to understand
what all that code really does than it takes to re-write it in Forth.
    Many people learn a little about Forth and immediately see how they
can re-write systems and invent their own computer languages. Forth
makes doing this easy. The hard part of computer programming remains.
That is learning what other people have done so you can profit from
their experiments. Since Forth programmers are very poor at commenting
and documentation, it is easier for the new Forth student to write
his own version of Forth instead of finding the best ideas that
have been developed and published over the years by other Forth
programmers. It is also easier to learn about programming by
studing other languages than it is by studing Forth since most of
the programming textbooks and new computer algorithms are published
using other languages. I've asked enthusiastic Forth programmers to
write a Forth program that did the same thing as a C program that
they understood very well. Their reaction was "Why re-invent the
wheel?" Well, if all the important routines are published in C,
who is going to want to use Forth?
    The stories Forth programmers tell about the success of Forth
seem to involve ignoring the C code that was written for some
project that doesn't work and doing everything over in Forth.

--



Thu, 21 Dec 1995 12:26:13 GMT  
 Syntax alterability, strength or weakness? (was: What good is it?)
Quote:



>>>    There are many people who have written Forth in C and linked to
>>>the system calls of a disk operating system. This is perfectly fine
>>>with me, but please don't think of such systems as Forth. They are
>>>something else and they need a different name. I think of them as
>>>Forth emulators. Real Forth is what Charles Moore invented in the
>>>late 1970's and even in its chaotic unstandardized state it is
>>>superior to every other computer language I have worked with.

>>  And what would you propose to call them?  PseudoForths?  NonForths?  I
>>would consider a Forth written in C the same as a Forth written in Assembly
>>Language.  If it looks like a duck, sounds like a duck, smells like a duck,
>>then it probably is a duck.

>   The part of Forth that is most unlike other computer languages is the
>inner interpreter. It is the part that needs the most effort at optimization
>since it sets the speed of operation and determines where the executable
>code can be located in memory. If you can write an efficient inner
>interpreter in straight C, then I might be inclined to consider a Forth
>written in C to be worthwhile.

  Well, on some systems, that is the only way.  I would like to have a Forth
system for my Unix box at work (and I do have one).  And while it is entirely
possible to write a Forth system in MIPS Assembler (I think I have a Forth
written in MIPS Assembler, but don't quote me on that), it would be easier to
write one in C.

  While you (or I) might do better than a C compiler on a CISC CPU, have you
even looked at assembly for a RISC CPU?  Sure, it has less instructions, but
certainly more restrictions on instruction placement, and I'm sure that the
C compiler can beat me quite easily (and I consider myself a very good asm
programmer BTW).

Quote:
>>I realize that Forth is powerful, and an trying to learn it right now, and
>>one of those steps was writing a Forth-like language.  I got flammed pretty
>>bad (by two people) for trying to reinvent Forth, but aren't you doing some-
>>thing similar by ignoring the vast libraries that exist written in other
>>languages by saying "That's not Forth, so let's not clutter up Forth with it."

>    One of the things that most impressed me when I first learned Forth
>was how it got its power by leaving out large amounts of things that
>other languages and operating systems couldn't get along without. Before
>I knew about Forth, I thought it was impossible to use a computer without
>floating point numbers, compiliers, linkers and complicated disk managers.
>Forth opened my eyes. The vast libraries that exist for other languages
>are an impediment to using computers. It takes more time to understand
>what all that code really does than it takes to re-write it in Forth.

  Really?  You mean I should just forget about using the system libraries on
my Amiga because they are an impediment to using the Amiga?  I should be forced
to impliment ZModem in Forth, even though I already have a pre-written, pre-
compiled ZModem library on the system?

  Or, I should forget about the graphics library on the Unix box here at work,
and roll my own.  I'm sorry, but I have more important things to do than to
figure out the hardware on my SGI machine here and attempt to do an as fast
3D library for the given hardware I have, and then have it not work on the
newer machines (since the SGI box here is about 2 years old 8-)  And that's
assuming I can get hardware docs in the first place (I'm sure I might be
able to, but I hope my point is clear ... )

  Hey, I could make the same complaint ("It takes more time to understand
what all that code really does than it takes to re-write it") about Forth
in general, but, as you later write, you yourself make that statement ...

- Show quoted text -

Quote:
>    Many people learn a little about Forth and immediately see how they
>can re-write systems and invent their own computer languages. Forth
>makes doing this easy. The hard part of computer programming remains.
>That is learning what other people have done so you can profit from
>their experiments. Since Forth programmers are very poor at commenting
>and documentation, it is easier for the new Forth student to write
>his own version of Forth instead of finding the best ideas that
>have been developed and published over the years by other Forth
>programmers. It is also easier to learn about programming by
>studing other languages than it is by studing Forth since most of
>the programming textbooks and new computer algorithms are published
>using other languages. I've asked enthusiastic Forth programmers to
>write a Forth program that did the same thing as a C program that
>they understood very well. Their reaction was "Why re-invent the
>wheel?" Well, if all the important routines are published in C,
>who is going to want to use Forth?

  I wouldn't lump Forth programmers into the "poor documentors" catagory.  I
would lump about 90% of all programmers into that catagory, reguardless of
language 8-)  And you also have to remember, programmers can be lazy at times,
and if a tool they wrote (reguardless of language) works, why rewrite it?

Quote:
>    The stories Forth programmers tell about the success of Forth
>seem to involve ignoring the C code that was written for some
>project that doesn't work and doing everything over in Forth.

  I would say that by that time, they had a better understanding of the
problem at hand, and a re-implimentation was in order.  Either that, or
they were more comfortable with Forth than with C (I'm guessing here, I
don't know any more details than what you've given).

  Certainly, there have been programs I've written that I would love to do
over again, reguardless of the language I pick.  I would argue that design
is more important than language (although there are languages that do ease
the implimentation of a given design).

  I'm not trying to put Forth down.  It's just that for what I would like
to do using Forth, using pre-written libraries is one of them.  And living
nicely under an OS is another (although MS-DOS is an exception 8-)

  -spc (And please don't make me use Unix Assemblers ... if you think C
        is bad, you obviously haven't used an Assembler under Unix ... )



Thu, 21 Dec 1995 14:53:14 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. I am not deaf, but am I mute?

2. Availablity ads a sign of weakness or strength?

3. Availability ads a sign of weakness or strength?

4. Ada95 Strengths/Weaknesses.

5. I am looking for the GPIB command syntax for a HP8505 network analyzer

6. I am just learning verilog any good books or websites

7. I am new to LabVIEW and I am having the classic problem of...

8. I am using LABview 5.0 and I am having difficulty with...

9. I am using a timed while loop and am unable to get the loop...

10. I am using HP 4263ALCR meter, and I am trying to use the...

11. I am working in LabVIEW 6i and I am wanting to build a exe in Apllication Builder

12. I am inputting my guitar tunes(.wav files) and I am trying...

 

 
Powered by phpBB® Forum Software