Databases in Forth
Mark Carter
I was reading at
http://www.ultratechnology.com/essence.htm
such statements as: "This is probably one of the greatest differences
between Forth and C. C was designed to write an OS in which the concept
is that everything is a file. Databases are built using the file system
and C structures as the containers. In Forth we have the virtual memory
system and dictionary instead, the concept of extensible database below
file system level."
and: "How would you implement C style structures which are essential to
my work?" Chuck's reply was his famous, "I wouldn't."
So, how would I, for instance, go about implementing a database in
Forth? Take, for example, that I have 2 tables: departments and
employees. Each department has a name and many employees. Each employee
has a name, department, and salary. Maybe I would want to see the total
salary for a department, or find an employees salary based on his name.
To make things a little easier, let's suppose that I can define the
contents of the database statically - by which I mean through Forth files.
Elizabeth D Rather
That's not a question that can be answered in a brief post, I'm afraid!
I'll try to give you an overview.
Jeff's description in the first paragraph refers (obliquely) to the
traditional Forth practice of organizing disk in 1024-byte blocks.
Native Forth implementations using this scheme in the 70's and 80's were
capable of supporting large databases using software developed at FORTH,
Inc. for this purpose. Performance was far beyond what contemporary OSs
and databases of the time could produce. For example, in the late 80's
we developed a large database system for the KKIA airport at Riyadh,
Saudi Arabia, that supported a network of several hundred computers
monitoring over 30,000 digital and analog points throughout the 100 sq
mi airport. One of the acceptance criteria for this system was that a
message could be passed through the maximum path in 3 ms; on our test we
delivered it in under 1 ms (a factor of 10 faster than the previous system).
Since the early 90's, Forths have mostly run on top of commercial OSs
such as Windows and variants of Unix. Dependence on their file systems
has limited disk performance, although it's a convenience in many
respects. As a result, most applications (in Forth as in other
languages) rely on the underlying OS, and on external programs for
database access.
The FORTH, Inc. database system is still used, however, for managing
databases in flash on embedded systems. The software may be available
through FORTH, Inc. (for FORTH, Inc. Forth implementations); email
sup...@forth.com for info.
On a smaller scale, and in more direct response to your limited
question, Forth's ability to define custom data objects and structures
facilitates defining related records and fields as in your example, and
Forths based on a host OS have straightforward commands for accessing
their files.
Cheers,
Elizabeth
Hugh Aguilar
> and: "How would you implement C style structures which are essential to
> my work?" Chuck's reply was his famous, "I wouldn't."
C-style structures are easy in Forth. The question of how to do this
came up a couple of days ago in the "Questions about Forth Philosophy"
thread: http://groups.google.com/group/comp.lang.forth/browse_thread/thread/f1ff4be6f50c63c0#
Myself and another guy both provided code to do this.
By "Chuck," I assume that you mean Chuck Moore. His quote must have
been taken out of context, as it seems to imply that Forth isn't
capable of C-style structs, but any novice can easily do this. I've
read interviews of him and noticed that he tends to be somewhat
flippant, which results in quotes like this floating around and
providing ammunition for anti-Forth C enthusiasts.
Chuck Moore has gotten involved in some pretty far-out chip technology
without much general-purpose applicability. As for myself, I'm pretty
focused on mundane chips such as the PIC24, and I think that most of
the other people on c.l.f. are too. I don't mean to say that building
custom hardware ("Forth engines") isn't cool --- I wrote the MFX cross-
compiler for the MiniForth that was built on a Lattice-1048isp --- and
that was the coolest program that I've ever written. I'm just saying
that this kind of technology isn't mainstream at this time.
Aleksej Saushev
> On Oct 20, 1:12О©╫pm, Mark Carter <m...@privacy.net> wrote:
>> and: "How would you implement C style structures which are essential to
>> my work?" Chuck's reply was his famous, "I wouldn't."
>
> C-style structures are easy in Forth.
"C" style structures are not (ever tried bit fields?), Oberon style are.
--
HE CE3OH...
Hugh Aguilar
> Hugh Aguilar <hugoagui...@rosycrew.com> writes:
> > On Oct 20, 1:12špm, Mark Carter <m...@privacy.net> wrote:
> >> and: "How would you implement C style structures which are essential to
> >> my work?" Chuck's reply was his famous, "I wouldn't."
>
> > C-style structures are easy in Forth.
>
> "C" style structures are not (ever tried bit fields?), Oberon style are.
>
> --
> HE CE3OH...
I could implement bit fields, but the guy's question indicated that he
was only interested in simple structures. His database of employees
can easily be implemented using the FIELD code that I provided for
him. Most anything can be implemented in ANS-Forth. It is somewhat
unrealistic to believe that you are going to convince somebody like me
to throw up my hands and announce: "Forth doesn't support the xxx
feature, so I'll just have to give up. Sob! The last 25 years of my
life have been for nothing!" lol
I don't normally visit c.l.f. and have just recently begun doing so. I
don't have a lot of enthusiasm for forums such as this due to all of
the negativity that I encounter. Life is more fun when I spend my time
programming, rather than trying to convince other people that I am a
programmer in posts such as this one. It is not just c.l.f., but I
also find too much negativity on the entire internet. I used to visit
(http://forum.911movement.org/) quite a lot, but the 9-11-01 issue
just made me feel depressed all of the time, so I had to back off on
that.
Really, I find too much negativity in the whole world. I think that
this is why humans have chronic problems with poverty, pollution and
warfare, despite having been provided with a perfectly good planet ---
reality is a projection of our minds --- if our minds are filled with
mean thoughts, then our world will become a mean place.
I'm getting way off the subject of Forth programming, but if you are
interested in what I'm telling you, I would recommend reading John
Perkin's book: "The World is as You Dream It." When your mind becomes
filled with negative thoughts, put all of that negativity into an
email and send it to me personally, rather than post it here on
c.l.f.. My email address is available on my website: www.rosycrew.org
Hugh Aguilar
> For example, in the late 80's
> we developed a large database system for the KKIA airport at Riyadh,
What has Forth Inc. done recently?
I don't see a whole lot of advertising for Forth programmers being
done.
Elizabeth D Rather
Major projects recently have involved a series of products for GE
Multilin (http://www.forth.com/resources/appNotes/app-GE-Multilin.html),
a research project involving sensors on elite swimmers to monitor their
form for training purposes.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Elizabeth D Rather
> Hugh Aguilar wrote:
>> On Oct 20, 2:35 pm, Elizabeth D Rather <erat...@forth.com> wrote:
>>> For example, in the late 80's
>>> we developed a large database system for the KKIA airport at Riyadh,
>>> Saudi Arabia...
>>
>> What has Forth Inc. done recently?
>>
>> I don't see a whole lot of advertising for Forth programmers being
>> done.
>
> Major projects recently have involved a series of products for GE
> Multilin (http://www.forth.com/resources/appNotes/app-GE-Multilin.html),
> a research project involving sensors on elite swimmers to monitor their
> form for training purposes.
>
> Cheers,
> Elizabeth
>
It has been pointed out to me that I mis-phrased this response. The GE
Multilin project and the sensors-on-swimmers project are two different
projects. There have also been a number of smaller projects, but these
have been pretty long-term (in phases for years).
jmdrake
> On Oct 20, 1:12 pm, Mark Carter <m...@privacy.net> wrote:
>
> > and: "How would you implement C style structures which are essential to
> > my work?" Chuck's reply was his famous, "I wouldn't."
>
> C-style structures are easy in Forth. The question of how to do this
> came up a couple of days ago in the "Questions about Forth Philosophy"
> Myself and another guy both provided code to do this.
Chuck didn't say "I couldn't". He said "I wouldn't". Sure you can
create C style structures in Forth. You can even write an entire C
compiler in Forth. I saw one forth system that could compile both
Forth and JavaScript. Sure it CAN be done, but that doesn't mean
that it's the BEST way to handle a problem. Maybe you think it is.
Chuck apparently thinks it's not. To each his own. There's certainly
more than one way to approach a problem. You can look at available
source code that fits the problem (which will likely be written in
C) and tailor your environment to match the source. Or you can
try to look at the problem directly, ignore previous C solutions,
and come up with your own through factoring.
Really, this is no different than the "infix versus postfix" debate.
Sure Forth CAN be made to interpret infix. A FORMula TRANSlator
has been posted here years ago. But I doubt Chuck would do that
either. That doesn't mean he couldn't.
> By "Chuck," I assume that you mean Chuck Moore. His quote must have
> been taken out of context, as it seems to imply that Forth isn't
> capable of C-style structs, but any novice can easily do this. I've
> read interviews of him and noticed that he tends to be somewhat
> flippant, which results in quotes like this floating around and
> providing ammunition for anti-Forth C enthusiasts.
It doesn't imply any such thing. Please note the difference between
the words "would" and "could".
> Chuck Moore has gotten involved in some pretty far-out chip technology
> without much general-purpose applicability. As for myself, I'm pretty
> focused on mundane chips such as the PIC24, and I think that most of
> the other people on c.l.f. are too. I don't mean to say that building
> custom hardware ("Forth engines") isn't cool --- I wrote the MFX cross-
> compiler for the MiniForth that was built on a Lattice-1048isp --- and
> that was the coolest program that I've ever written. I'm just saying
> that this kind of technology isn't mainstream at this time.
I'm not sure what your point is. Chuck doesn't use C structs when
programming mundane chips like the Pentium either. See:
http://colorforth.com/ide.html
And did it occur to you that the reason most people probably (I
haven't
done a survey) don't use Forth chips is a lack of AVAILABILITY rather
than a lack of APPLICABILITY? And again, that has nothing to do with
whether or not you choose to use C structs.
Regards,
John M. Drake
Coos Haak
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.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
John Passaniti
> 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?
Elizabeth D Rather
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.
Brad
> Chuck didn't say "I couldn't". He said "I wouldn't". Sure you can
> create C style structures in Forth.
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.
-Brad
Charley Shattuck
> John Passaniti wrote:
>> On Nov 9, 10:38 am, Coos Haak <chfo...@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).
Charley.
David N. Williams
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
-- David
foxchip
> > 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
Best Wishes
David N. Williams
Oops! Thanks!
-- David
John Passaniti
> 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.
MarkWills
> Forth n00b here.
> So, how would I, for instance, go about implementing a database in
> Forth? Take, for example, that I have 2 tables: departments and
> employees. Each department has a name and many employees. Each employee
> has a name, department, and salary. Maybe I would want to see the total
> salary for a department, or find an employees salary based on his name.
>
> To make things a little easier, let's suppose that I can define the
> contents of the database statically - by which I mean through Forth files.
Have a look here for interesting article about databases in forth. The
article includes source for a simple Forth DB:
http://www.theforthsource.com/fp003.html
Mark
gavino
you seem to know some stuff, but why so angery?
do you know forth really well?
what apps did you make in forth?
do you prefer c?
gavino
> On Oct 21, 1:30 pm, Aleksej Saushev <a...@inbox.ru> wrote:
>
> > Hugh Aguilar <hugoagui...@rosycrew.com> writes:
interesting stuff
did you learn forth from starting and thinking forth by brodie?
John Passaniti
> 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.
gavino
but you said better languages exist? hmm you must mean for each its
own purpose eh
Jerry Avins
> On Dec 12, 6:42 pm, John Passaniti <john.passan...@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
You seem to be beginning to learn. Keep it up!
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������