John Passaniti wrote:
On Nov 9, 10:38 am, Coos Haak <chfo... at (no spam) hccnet.nl> wrote:
Chuck Moore even wrote a BASIC compiler in Forth, long ago. For fun,
not a serious undertaking, just to prove it could be done, not out of
necessity.

He did? Seems like an odd thing for him to waste his time on.
Reference?

It was quite a long time ago, maybe 1980. It was semi-recreational,
semi-to prove a point. And not very full-functioned, really a toy. I
think it was published (maybe a Rochester conf. paper?), but I have no
idea where.

Cheers,
Elizabeth

On Mon, 09 Nov 2009 13:21:35 -1000, Elizabeth D Rather wrote:

John Passaniti wrote:
On Nov 9, 10:38 am, Coos Haak <chfo... at (no spam) hccnet.nl> wrote:
Chuck Moore even wrote a BASIC compiler in Forth, long ago. For fun,
not a serious undertaking, just to prove it could be done, not out of
necessity.
He did? Seems like an odd thing for him to waste his time on.
Reference?
It was quite a long time ago, maybe 1980. It was semi-recreational,
semi-to prove a point. And not very full-functioned, really a toy. I
think it was published (maybe a Rochester conf. paper?), but I have no
idea where.

Cheers,
Elizabeth

Forth Dimensions volume 3 page 175 has an article about the compiler by
Michael Perry, including a listing. It says the original was
presented at
1981 FORML as "BASIC Compiler in FORTH". You can find the FD article at
forth.org (SVFIG).

On Nov 10, 9:46 am, "David N. Williams" <willi... at (no spam) umich.edu> wrote:
Forth Dimensions volume 3 page 175 has an article about the compiler by
Michael Perry, including a listing. It says the original was
presented at
1981 FORML as "BASIC Compiler in FORTH". You can find the FD article at
forth.org (SVFIG).

Right. I found it tricky to determine which issue in volume 3
contains page 175, so here's the link:

http://www.forth.org/fd/FD-VO3N6.pdf

zero as in zero three, not capital O as in VOLUME

http://www.forth.org/fd/FD-V03N6.pdf

On Nov 10, 10:45 am, Brad <hwfw... at (no spam) gmail.com> wrote:

I've noticed that in C, addressing items in a data structure requires
a different syntax than addressing items that aren't in a data
structure. If you have data that you might have multiple instances of
someday, you might want to use a structure from the outset. This leads
to a habit of using structures "just because". In Forth, there is no
such restriction. You can add as much indirection to a pointer as you
want without being forced to change syntax.

It's often said in this newsgroup that programmers coming to Forth
from other languages sometimes try to bring the mindset of those other
languages into Forth.  The result is not fully understanding how to
effectively use Forth.

You've just demonstrated the opposite-- a Forth programmer trying to
apply a Forth mindset to C and coming up with a bizarre notion that C
programmers use structures "just because."  That's like a C programmer
saying that Forth's traditional avoidance of locals in favor of
unnamed items on the stack is "just because."  No, it's idiomatic of
not only the language, but the mindset that comes from the language.

A C programmer uses structures because they are a convenient notation
for aggregating data that also provides a number of useful
facilities.  The most obvious facility is to keep track of the overall
size of the data structure, which is used for indexing and increment/
decrement of pointers to that structure without explicit math.  So no,
a C programmer doesn't wake up and say, "today I think I'll aggregate
unrelated data together for no reason other than I know that in some
point in the future, I'm probably going to have to add periods and
arrows to dereference them."  If that's what you think, then you're
not obviously not a C programmer.  Or at least not a very good C
programmer.

A Forth programmer is indeed free to hide all manner of beauty and/or
horror behind a single abstraction.  I'm not convinced that is always
a good thing.  I came across a critical review of C# a few years back
that asked the cost of a single line of code.  I don't remember the
exact example that was given, but it was something like this:

     a[b+1] = c++;

So, how many operations could be hidden in that simple expression?
The surprising answer was huge-- something like 35.  That's because in
C# you have numerous opportunities to overload syntax and inject
hidden function calls.  The point was that a C# programmer can write
code that uses a wonderfully simple single consistent syntax, but
which has operational costs that aren't immediately obvious by
casually reading the code.  Call it once, maybe it doesn't matter.
Put it in a loop, and watch your system crawl.

The same applies to Forth:

     42 example !

We can assume some semantics here-- 42 is being stored... somewhere.
But what is "example" doing?  Is it a variable?  Is "example"
calculating an address within a data structure?  Is is reading data
from a disk drive?  Will it take nanoseconds to run, milliseconds, or
seconds?  Are there side effects of "example"?

A C programmer's mindset isn't that they are saddled with syntax.  A C
programmer's mindset is that they want to be in control and they use
syntax to provide that control.  When a C programmer writes this:

     example = 42;

They *know* it's just a simple variable assignment.  When they write
this:

     thing.example = 42;

They *know* it's a simple address calculation.  When they write this:

     *(example()) = 42;

They *know* there is a function call involved because they can see
it.  A (good) C compiler may make all kinds of clever optimizations to
the code, but at the end of the day, a C programmer knows what code is
going to come out of the compiler.  That . or -> operator is going to
result in an address calculation and depending on what side of the
equal sign, an assignment or dereference.  That () operator is going
to result in a function call.  The person using Forth can't say that
without code inspection.

The point is that the C programmer's mindset is to use different
syntax for different operations so they can know the cost.  When you
hide indirection inside a Forth word, you are indeed simplifying
syntax.  But you're also hiding costs.

But getting back to the original point you were making, C programmers
can and do defer the choice of putting data into structures all the
time.  They just do behind an explicit function call or macro.  A good
real-world example is a tiny Forth-like language I wrote called
Tester.  Tester's intent is to provide interactive testing for C
applications.  Traditionally, Tester only had a single context, so
code that pushed items to the stack looked like this:

     #define SP    sp

     void push(int cell) { *SP++ = cell; }

When I changed Tester to allow multiple contexts, having a single
stack pointer no longer worked.  Now, I needed to have not just a
stack pointer but other per-context data.  So a natural tool for C was
to create a data structure that had the stack pointer and other per-
context data in it).  So that changed:

     #define SP    context->sp

So that's an example of where the C programmer changed from using a
simple variable to a structure member without changing code.  If I was
doing anything more complicated than that, I could change the macro
again and hide how the stack pointer was obtained, such as through a
function call.  But as a C programmer, I typically wouldn't.  While it
would make the rest of the code *read* nicer, it would be hiding a
potentially expensive function call.

On Dec 12, 12:04 am, gavino <gavcom... at (no spam) gmail.com> wrote:

you seem to know some stuff, but why so angery?

I'm not an angry person.  The message you quoted started with an
arrogant and pompous assumption about C programmers.  That kind of
nonsense is something I will often react to in this newsgroup.  I
wouldn't class the emotion there as anger.  I'd consider it
frustration driven by disappointment.

do you know forth really well?

I've used Forth, as well as a variety of other languages for about 25
years.  I do think I know Forth "really well," which above all is
evidenced by my choice to not use Forth when better languages exist.

what apps did you make in forth?

My work with Forth is in embedded systems.  In my case, the Forth
"apps" are software tools used to build larger systems, such as
assemblers and related tools for custom DSP chips and frameworks to
support interactive and automated testing of C and C++ code.  Forth is
also a language I've put in as a "back door" in many of the systems
I've worked on, and has proven to be very useful as a way to provide
functionality that wasn't designed in from the start.

do you prefer c?

No.  I prefer Forth.  Forth allows much more expression and control
than C does.

On Dec 12, 6:42 pm, John Passaniti <john.passan... at (no spam) gmail.com> wrote:

No. I prefer Forth. Forth allows much more expression and control
than C does.

but you said better languages exist? hmm you must mean for each its
own purpose eh