Language X, not Forth ?
sxccaa.email
as a newer incoming member to all things forth,
it is very puzzling to me why such a marvellous
language is able to fire up most microchips but
not fire up the programmers/users community
it will not be forth but a language built on top of it ?
Language X ?? (maybe a language which evolved
out of forth .. maybe ColorForth ?)
( but then, isn't colorForth being too much tied down
to a particular chip design .. GA2/4/32/40 haypress2 ..
which are optimized to run CF ? i recall it was okay
to run upto pentium .. but pentiums are ancient history)
so here's the relevant copy paste :
idknow <idk...@gmail.com> wrote:
> Forth is unused and unknown by the general public because we the
> devotee's of it haven't done anything with it to make it competitive
> with Perl, Python, Ruby and the other scriptable languages.
But they're *designed* for that job. Forth is a multi-level general
purpose programming language, particularly strong in the area of
embedded applications. You could certainly build a good language for
this application area on top of Forth, and it might well gain some
advantages from that, but it would be Language X, not Forth.
sxccaa.email
Andrew Haley wrote:
> But they're *designed* for that job. Forth is a multi-level general
> purpose programming language, particularly strong in the area of
> embedded applications. You could certainly build a good language for
> this application area on top of Forth, and it might well gain some
> advantages from that, but it would be Language X, not Forth.
Well, maybe it would (like JavaScript compiled using Forth in Firefox
3.5),
but not necessarily so. Take e.g. MINOS: This contains a lot of
"scaffolding" to allow OO style GUI programming. Now, that wasn't
what he
asked for (he asked for scripting languages), but if I was interested
in
such scripting language scaffolding, I could do that as well. You
want
associative arrays? You want easy to write down regexps? You want
to
generate HTML? All not really difficult, all can be an extension to
Forth
like my OOF and the MINOS class library is an extension to Forth.
I usually have problems designing a scripting language because I have
problems with that programming mindset. I occasionally use awk+sed
+bash for
some simple scripting language tasks, but when I reach the limits of
those
tools (which are low), I rethink the problem and come to the
conclusion that
all this regexp+associative array stuff wasn't at all appropriate, and
end
up writing it in Forth using a completely different paradigm.
Example: We had a gds2txt and txt2gds C program to manipulate GDSII
files
(layout for chips). The processing of this txt format was done by
some
scripts as above. At one point in time I decided to dump the C
program (it
was unmaintainable, it even didn't compile with GCC on a Linux box),
and
rewrite it in Forth (it became small and maintainable, and much more
powerful, it even can convert GDS to Postscript, and it can do
manipulations
right on the data). After doing so, I ditched the scripts that
manipulated
the txt stream, and wrote them right on top of the Forth program that
now
directly manipulates GDS on binary level.
It is much faster, it is much more flexible, and it is a lot easier to
use
than the language-zoo scripts+C program before. Note that "much
faster" is
not really the point here. I don't care that if it takes 10 seconds
or 10
milliseconds to create a ROM pattern, though I find any reaction of a
computer that's not instant "sluggish" (I do care a lot if it takes
one
hour, as it did with our first approach, using the scripting language
of the
layout editor). I care that it now takes some minutes instead of
hours to
write a new ROM pattern generator for another ROM geometry - it goes
down
that much because a lot of conversions don't have to happen anymore,
and
some manual steps can be automated by having a way more powerful tool.
sxccaa.email
The major reason Forth hasn't been accepted is lack of marketing,
either
in the form of adoption by major companies or organizations or papers
in
various publications, meetings, etc. The vast majority of
programmers
out there haven't considered Forth and rejected it for some reason
(although some have heard -- and passed on -- rumors about
unreadability, etc.), they simply never heard of it.
As for "cpu cycles, memory conservation, and other such minutia"
these
issues remain vitally important in the area of embedded systems,
which
is vast and thriving, and where folks developing products are
desperate
to wring maximum functionality and performance out of the cheapest
possible hardware. That is the main area where Forth excels.
sxccaa.email
Uwe Kloß :
In that case we have to ask "why".
What do other languages have, that Forth has not?
My impression is, that for many popular uses where other
languages offer capabilities, Forth offers just possibilities.
This is perhaps due to the primary target the laguages
were developed for. I understand that Forth was first
designed to control hardware. That is still it's main
playground (OpenBoot) in terms of installations.
Perl, for example,.......
In more than 25 years I was just once able to sneak in
a Forth like scripting facility. And that only because
I didn't tell them in advance that it was in fact Forth.
Uwe
25 years and just ONCE ?? that too "sneak" in because
"didn't tell them" ???
sxccaa.email
Jonah Thomas :
I want a scripting language to be easy to use.
I just want to solve some simple problems without
the language getting in the way.
(every person wants different things from forth ?)
sxccaa.email
Jonah Thomas schrieb:
> So just like I don't want to learn regexp, how many scripting language
> users will want to learn how to use the data stack?
Uwe Kloß :
Next to none!
That's why you hide it.
At first.
At least that's what I did.
(real world situation ??)
sxccaa.email
Uwe Kloß wrote:
> In that case we have to ask "why".
> What do other languages have, that Forth has not?
Elizabeth D Rather :
An organization behind them that is either large,
well-funded, or both.
Uwe Kloß wrote:
> My impression is, that for many popular uses where
> other languages offer capabilities, Forth offers
> just possibilities.
> This is perhaps due to the primary target the
> languages were developed for. I understand that Forth
> was first designed to control hardware.
> That is still it's main playground (OpenBoot) in
> terms of installations.
Elizabeth D Rather :
Yes, it is much easier for a language targeted
at a particular application domain to be tailored
for that domain. Forth is very general; Forth programmers
tailor it to the domain they're working in.
(domain specific ..
programmers tailor it to the domain they're working in)
sxccaa.email
>Uwe Kloß wrote:
>> What do other languages have, that Forth has not?
Elizabeth D Rather <erat...@forth.com> writes:
>An organization behind them that is either large,
well-funded, or both.
Anton Ertl :
I very much doubt that this is the decisive factor.
Ok, it made Java widely known quickly, but that's
rather the exception. I am not aware of particular
organizational support for Python, Ruby, or Perl
...
And if the size and funds of the supporting organization
were the decisive factor, everyone would program in Ada.
...
A good way to become popular is to have a killer application,
or at least a good demo and some marketing based on that.
For Java there was HotJava and the write-once-run-everywhere
propaganda (selling it as the "Internet language").
For Ruby there is Ruby-on-Rails,
for PHP there is server-side web scripting,
for Perl there were reports and scripts for the sh/awk-illiterate.
I'm not sure how Python became popular, mostly I saw it mentioned
as a saner alternative to Perl.
(A good analysis of reasons for others' popularity !)
sxccaa.email
>> The major reason Forth hasn't been accepted is lack
>> of marketing, either in the form of adoption by major
>> companies or organizations or papers in various
>> publications, meetings, etc. The vast majority
>> of programmers out there haven't considered Forth
>> and rejected it for some reason (although some have
>> heard -- and passed on -- rumors about unreadability,
>> etc.), they simply never heard of it.
Wayne :
Even with money, it is hard to market unless you
can occupy a development sector (wide) and provide tools
up to visual software and data editing modeling development
environments+ script etc. You also need to make it
easier (scripting as you are talking about,
crosses over into language changes).
I have considered these things for a while, and I imagine
Elisabeth thinks about them a bit as well, considering
where she works.
In my own scheme, the only people that need to know
machine code programming, are OS, driver, object and
custom api writers, ...
applications programmers use objects with little code to
control objects, custom code and application development systems,
next up is content providers with scripting (using objects etc)
and then authoring packages).
All having available visual environments.
What I concluded is that most of the processing is done in
the objects, api, drivers and OS, so need the most
refinement (a couple of levels there) and their behavior
limits the efficiency of all upper levels.
Depending on application, much less processing will be done
on the application level. Less processing again is used on
scripting level, but most people can write a script to waste
time.
With the authoring package you are simply using the efficiently
made code before, so these authors need only know what they
are doing, but not even how to program.
The proceeding layers ensure maximum efficiency for the authors,
as for the programmers on each proceeding level.
If you write the lower levels right and make the objects well,
you get rid of a lot of bugs, raise efficiency and reduce the
amount of work upper levels do.
There is one more secret ingredient involved, I'll leave you too it.
Of course it is not as simple as this, you would need
suitable management, I came up with a system years ago that
could be classified as a type of extreme programming to
ensure efficiency, reliability and quality before
test stage.
By being lazy, arrogant ("don't need" to do it properly or
listen) it is doomed to the quality failures, as with many
other projects.
Design is a root of all efficiency, analysis and ability are
roots of design.
(Wayne here)
(along with the previous post, a rather nice analysis of
what's the ground reality and what is lacking or needed)
peekay
people will make forth usable for more people
aka linux was made usable for more people (by
public participation and involvement in coding)
but if ColorForth is the way this is being pushed,
perhaps a lot of support/work/marketing/awareness/
apps/papers/publicity/articles/press-releases will
help
the common perception that an intelligent venture
capitalist is what is needed may be quite wrong
a big diamond too needs grinding, polish and
most importantly DISPLAY, VISIBILITY, to get
the WOW reactions !!
Jerry Avins
The best way to apply forth to many tasks is using it to write a
language for a specific task. Even with a compile-to-machine-code Forth,
most of my interactive programs are interpreters that don't look like
Forth. My car doesn't look like a bunch of screws, either. In fact, it's
hard even to find the fasteners that hold the dash in place.
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Rod Pemberton
news:c5cea333-c43a-4aa2...@x25g2000prf.googlegroups.com...
>
> starting new thread
>
Are your other replies all from comments in the "continued fractions" thread
and "acceptance of FORTH" subthread?
Rod Pemberton
Rod Pemberton
news:c5cea333-c43a-4aa2...@x25g2000prf.googlegroups.com...
>
>
I see no reason why this couldn't be done. I've personally - in a very
limited and in a temporary situation - converted C into an IL (intermediate
language) which was _almost_ FORTH. It required some work: deblocking,
unrolling, un-parameterizing. So, I think it could be done with other
languages too, but I don't believe it'd be optimal. Any language which is
"Turing complete", can have a working computable language implemented for
it. The real issue is: "How does one convert one language to another
efficiently with programmatic methods?" The most efficient code written for
one coding model is usually inefficient when converted to a different model.
I.e., C on top of FORTH wouldn't be a good solution to implementing C
efficiently.
Rod Pemberton
Rod Pemberton
>
> > Uwe Klo� :
> >
> > In that case we have to ask "why".
> > What do other languages have, that Forth has not?
> >
sxccaa,
I'll tersely list what I think is different about FORTH for non-FORTH-ers.
Some of these are good. Some aren't. Some are claimed to be myths... A
few issues may be dismissed or repudiated by others here (e.g., Elizabeth
will politely claim FORTH is readable...), I'll then go into more depth on
what I "see" as a FORTH outsider.
1) cryptic and/or readability
2) programmer must keep track of data on stack
3) limited automatic tracking of data, e.g., via name
4) interpreted and/or old implementations
5) real-time control
#1: cryptic and/or readability
1a) IMO, this is the point of contention consistently ranked first. To
non-FORTH-ers, this is true without exception: "FORTH is unreadable." Those
who claim FORTH is easily readable are fanatical FORTH programmers who
readily dismiss "unreadable" arguments. This creates a class-warfare
mentality that separates the two groups.
1b) FORTH uses "words" which correspond to parameterless procedures or
functions in other languages. But, FORTH users also use the concept of
"factoring", which means to break thing down into the smallest parts and
components. So, you end up with many nested FORTH words for the simplest
task. This would be like using many nested procedures in C. The code
becomes real hard to follow, real quick.
1c) FORTH allows naming of these words using non-alphabetic characters.
This isn't allowed in many other languages. The use of non-alphabetic
characters in other languages is for operators that perform mathematical
functions. In these languages, non-alphabetics characters are called
graphics characters. In FORTH, these graphics can be used in naming. The
use of non-readable graphics characters doesn't help FORTH to become known
as "readable"...
1d) FORTH allows control flow operators within FORTH words, but FORTH has no
syntax. It is purely space separated. There are no visual cues. There is
nothing to indicate grouping or blocks of code, except the colon and
semicolon operators used to define a FORTH word. Once you've got multiple
IF-ELSE-THEN's in a FORTH word, it becomes very difficult to figure out
which ELSE goes with which IF. If you avoid multiple IF-ELSE-THEN's in a
word, then you've created more nested words... 25% of people are visually
oriented, versus 75% who are verbally oriented. This is a real problem for
the acceptance of FORTH. This is especially true when you take into account
that many visually oriented people become scientists, engineers, and
programmers. To the visually oriented, "a picture is worth a thousand
words," for real.
#2: programmer must keep track of data on stack
This is like counting cards. That's a difficult task for most people. Can
you keep track of 52 items? Can you keep track of 5 items while attempting
to program and solve a problem? Can you do so while adding and removing
data from the stack? The data on the stack is just there. It has value.
But, it's nameless. The only way to reference it is by it's current
position, which is relative to the other data on the stack. I.e., it's
moving around. This is a total PIA and a complete waste of a programmers
time. Where it at now? Is it the fourth or five item on the stack?
#3: limited automatic tracking of data, e.g., via name
Other languages have variables. In these languages, the compiler places the
data for that variable where it's an optimal fit. It can move the data
around from memory to stack, from stack to register, etc. No matter where
the data is currently located, the data is accessable via it's name. FORTH
also has variables. These are placed into memory. Once the variable is put
onto the stack to perform some mathematical operation, it's naming is
immediately lost. It's on the stack. While it's on the stack, it's
nameless and can be moving around in the stack until used or stored. It can
be stored back into the original variable, whereby it regains it's original
name. But, it can also be stored into some other variable. Name, no name,
name, no name... Reread #2.
#4: interpreted and/or old implemenations
Historically, FORTH has been interpreted. Yes, there are FORTH's which
compile. But, these aren't the FORTH's that most people end up using. Most
people end up using an "obsolete" FORTH, like Fig-FORTH or FORTH-83, instead
of an ISO version. Why? Because everyone is still learning FORTH from Leo
Brodie's "Starting FORTH". Interpretation allows for faster code
development, than program-compile-run methods. But, you need to be able to
compile to have performance. If you're not using a modern FORTH with
compilation, FORTH becomes a waste of time.
#5: real-time control
FORTH has developed a name for itself in areas of real-time control of
machines. This is because highly "factored" FORTH essentially becomes a
small, interpreted, finite-state machine (FSM). FSM's are highly responsive
to transient, non-sequential, or random events. But, one doesn't need to
code in FORTH to implement an FSM. It can be done in any language. FORTH
only has an advantage here because the "factoring" concept natively leads to
an efficient FSM. Programmers for other HLL's, like C, must learn a new
programming paradigm in order to implement an FSM. Once you've got a few C
programmers who can do this, why use FORTH? C is everywhere. C is somewhat
portable. C compilers optimize very well.
HTH,
Rod Pemberton
Bernd Paysan
> #1: cryptic and/or readability
>
> 1a) IMO, this is the point of contention consistently ranked first.
> To
> non-FORTH-ers, this is true without exception: "FORTH is unreadable."
> Those who claim FORTH is easily readable are fanatical FORTH
> programmers who
> readily dismiss "unreadable" arguments. This creates a class-warfare
> mentality that separates the two groups.
Any suggestion to solve this? When I started programming, I found C
extremely unreadable. I found Pascal programs hard to understand. I
liked Logo, but despite the Lisp-background, the implementations back
then weren't serious. I also liked Forth, and since it was more than
powerful, it became my favorite language. Today, I can read quite many
different programming languages, though I still think Perl programs are
pretty bad.
> 1b) FORTH uses "words" which correspond to parameterless procedures or
> functions in other languages. But, FORTH users also use the concept
> of "factoring", which means to break thing down into the smallest
> parts and
> components. So, you end up with many nested FORTH words for the
> simplest
> task. This would be like using many nested procedures in C. The code
> becomes real hard to follow, real quick.
Ah, I had this argument from one of my former co-workers, who used to
write flat spaghetti code. Some people just don't have the proper
mindset for Forth. Maybe they are the big majority, would explain quite
well why Forth can't become mainstream.
Please: You don't follow the nested procedures. You use the abstraction
level to understand in a few words what the procedure does, and ignore
the pesky details. If it's good code, the name of the word is
descriptive.
> 1c) FORTH allows naming of these words using non-alphabetic
> characters.
> This isn't allowed in many other languages. The use of non-alphabetic
> characters in other languages is for operators that perform
> mathematical
> functions. In these languages, non-alphabetics characters are called
> graphics characters. In FORTH, these graphics can be used in naming.
> The use of non-readable graphics characters doesn't help FORTH to
> become known as "readable"...
All graphics characters in Forth are readable, and have a pronunciation.
Most other languages I know heavily use the same graphics characters,
but often for different purposes. When you learn a new language, you
have to learn the "alphabet" that comes with that language. When you
learn Perl, you have to learn quite a lot of meanings of these special
characters. Perl used to be a pretty popular language.
> 1d) FORTH allows control flow operators within FORTH words, but FORTH
> has no
> syntax. It is purely space separated. There are no visual cues.
Oh now please come on. All programmers I know use one sort or another
to indent or highlight control flow. And: Apart from Python, no other
programming language I know mandates a certain indentation style.
> #2: programmer must keep track of data on stack
>
> This is like counting cards. That's a difficult task for most people.
> Can
> you keep track of 52 items? Can you keep track of 5 items while
> attempting
> to program and solve a problem?
No, but I just don't have to. I'm not Spiderman, and I don't want to
get caught in my own web. Therefore, I just don't do this kind of crazy
things like juggling around with many stack elements (ok, to be honest,
sometimes I do, just to show off ;-).
> Can you do so while adding and
> removing
> data from the stack? The data on the stack is just there. It has
> value.
> But, it's nameless. The only way to reference it is by it's current
> position, which is relative to the other data on the stack. I.e.,
> it's
> moving around. This is a total PIA and a complete waste of a
> programmers
> time. Where it at now? Is it the fourth or five item on the stack?
Fortunately, the human brain has a built-in stack. It's called grammar,
and every natural language has one, and it requires a stack to keep
track of things (more so for German than for English, though ;-). It
allows to keep track of a few stack items without even thinking about
them. They are there, and it takes only days to get fluent enough in
Forth to do that.
Elizabeth compares that to the "wobbly feeling" when riding a bike first
time. I can't remember well enough how to ride a normal bike (I was
about 4, and it didn't take long), but I remember learning to ride a
recumbent bike. I bought my recumbent in a shop in the outback of
Munich and then rode 40km back home. If you are a wimp, this isn't for
you.
BTW: You need the same stack to evaluate and write down an expression
like
(int *)foo) = ((ptr->member)+3)*5;
It's just a different grammar, it uses the same part of your brain.
> #4: interpreted and/or old implemenations
>
> Historically, FORTH has been interpreted. Yes, there are FORTH's
> which
> compile. But, these aren't the FORTH's that most people end up using.
> Most people end up using an "obsolete" FORTH, like Fig-FORTH or
> FORTH-83, instead
> of an ISO version. Why? Because everyone is still learning FORTH
> from Leo
> Brodie's "Starting FORTH". Interpretation allows for faster code
> development, than program-compile-run methods.
I think you don't really get it at all. A modern Forth like VFX or
iForth with an analytic compiler *feels* exactly like an old Forth with
a threaded code interpreter, apart of some details like how big a number
can be. You type in your definitions at the prompt, and you can invoke
them right after. It's called "incremental compiler", and it doesn't
need a program-compile-run loop. Its so fast that you don't care about
the compile speed. You can compile some large library like MINOS in
0.1s on bigForth (peephole optimized native code), or on 0.4s on VFX
(analytic optimized native code).
And the examples of the online Starting Forth edition should work on
both of them, though I'm only sure that they will work on iForth
(because Marcel is behind the online Starting Forth edition).
> Once you've got a
> few C
> programmers who can do this, why use FORTH? C is everywhere. C is
> somewhat
> portable. C compilers optimize very well.
Wrong newsgroup. The language X you are looking for is already there,
it is popular and widely used. It doesn't have to be reinvented. Forth
does not try to be a slightly better C than C, that's what C++, D, Java,
C#, and others are for. Forth is a radically different approach. It's
not made for the spaghetti programmers, it's not made for people who
want to be mainstream. Chuck once said, people don't want another
programming language, they just want a better Fortran. Nowadays, they
just want a better C. If you are looking for a better C, look somewhere
else.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Elizabeth D Rather
> Rod Pemberton wrote:
>> #1: cryptic and/or readability
>>
>> 1a) IMO, this is the point of contention consistently ranked first.
>> To
>> non-FORTH-ers, this is true without exception: "FORTH is unreadable."
>> Those who claim FORTH is easily readable are fanatical FORTH
>> programmers who
>> readily dismiss "unreadable" arguments. This creates a class-warfare
>> mentality that separates the two groups.
>
> Any suggestion to solve this? When I started programming, I found C
> extremely unreadable. I found Pascal programs hard to understand. I
> liked Logo, but despite the Lisp-background, the implementations back
> then weren't serious. I also liked Forth, and since it was more than
> powerful, it became my favorite language. Today, I can read quite many
> different programming languages, though I still think Perl programs are
> pretty bad.
Bottom line: any language you're unfamiliar with is unreadable.
As you become more familiar with a language, it's readability is a
function of how much care the programmer took to make it more readable
(see below for more on this).
>> 1b) FORTH uses "words" which correspond to parameterless procedures or
>> functions in other languages. But, FORTH users also use the concept
>> of "factoring", which means to break thing down into the smallest
>> parts and
>> components. So, you end up with many nested FORTH words for the
>> simplest
>> task. This would be like using many nested procedures in C. The code
>> becomes real hard to follow, real quick.
>
> Ah, I had this argument from one of my former co-workers, who used to
> write flat spaghetti code. Some people just don't have the proper
> mindset for Forth. Maybe they are the big majority, would explain quite
> well why Forth can't become mainstream.
>
> Please: You don't follow the nested procedures. You use the abstraction
> level to understand in a few words what the procedure does, and ignore
> the pesky details. If it's good code, the name of the word is
> descriptive.
Exactly! If you factor logical functions (as opposed to just arbitrary
code sequences) and give them names that clearly suggest what they do,
you can read a short definition and have a pretty good understanding of
what it does.
>> 1c) FORTH allows naming of these words using non-alphabetic
>> characters.
>> This isn't allowed in many other languages. The use of non-alphabetic
>> characters in other languages is for operators that perform
>> mathematical
>> functions. In these languages, non-alphabetics characters are called
>> graphics characters. In FORTH, these graphics can be used in naming.
>> The use of non-readable graphics characters doesn't help FORTH to
>> become known as "readable"...
>
> All graphics characters in Forth are readable, and have a pronunciation.
> Most other languages I know heavily use the same graphics characters,
> but often for different purposes. When you learn a new language, you
> have to learn the "alphabet" that comes with that language. When you
> learn Perl, you have to learn quite a lot of meanings of these special
> characters. Perl used to be a pretty popular language.
The graphic characters have mnemonic significance, so once you learn
some, meanings of others become clear. For example, . displays a
number, while .S displays a string, .D displays a double, .( displays a
comment, etc. They are never arbitrary (at least is standard words).
>> 1d) FORTH allows control flow operators within FORTH words, but FORTH
>> has no
>> syntax. It is purely space separated. There are no visual cues.
>
> Oh now please come on. All programmers I know use one sort or another
> to indent or highlight control flow. And: Apart from Python, no other
> programming language I know mandates a certain indentation style.
Exactly.
>> #2: programmer must keep track of data on stack
>>
>> This is like counting cards. That's a difficult task for most people.
>> Can
>> you keep track of 52 items? Can you keep track of 5 items while
>> attempting
>> to program and solve a problem?
>
> No, but I just don't have to. I'm not Spiderman, and I don't want to
> get caught in my own web. Therefore, I just don't do this kind of crazy
> things like juggling around with many stack elements (ok, to be honest,
> sometimes I do, just to show off ;-).
We have done some studies on completed application code. The stack very
rarely gets more than half a dozen items deep, and individual words are
rarely concerned with more than two or three logical items (counting a
double number as one logical item).
>> Can you do so while adding and
>> removing
>> data from the stack? The data on the stack is just there. It has
>> value.
>> But, it's nameless. The only way to reference it is by it's current
>> position, which is relative to the other data on the stack. I.e.,
>> it's
>> moving around. This is a total PIA and a complete waste of a
>> programmers
>> time. Where it at now? Is it the fourth or five item on the stack?
>
> Fortunately, the human brain has a built-in stack. It's called grammar,
> and every natural language has one, and it requires a stack to keep
> track of things (more so for German than for English, though ;-). It
> allows to keep track of a few stack items without even thinking about
> them. They are there, and it takes only days to get fluent enough in
> Forth to do that.
>
> Elizabeth compares that to the "wobbly feeling" when riding a bike first
> time. I can't remember well enough how to ride a normal bike (I was
> about 4, and it didn't take long), but I remember learning to ride a
> recumbent bike. I bought my recumbent in a shop in the outback of
> Munich and then rode 40km back home. If you are a wimp, this isn't for
> you.
:-)
Actually, last year I thought I'd take up bike riding again after 30
years. It was kinda scary, but it came back pretty fast.
In the courses I teach, students are pretty comfortable with the stack
after 3 days.
I'm not at all sure so many people are using Brodie any more. There are
a number of more recent books. I wrote two, Stephen Pelc wrote one, and
there's a very good on-line tutorial that comes with gForth. FWIW
there's an even better online Starting Forth on www.forth.com, with the
original Brodie illustrations.
But Bernd is right, to a user there's not much difference, except that
modern Forths tend to have a better user interface, documentation, and
debugging tools. And Forth was *never* "interpreted" in the sense that
Basic and Lisp were/are. "Classical" Forths compiled addresses of
called words, and the "call" overhead was comparable to a subroutine
call minus the fuss of managing calling sequences.
>> Once you've got a
>> few C
>> programmers who can do this, why use FORTH? C is everywhere. C is
>> somewhat
>> portable. C compilers optimize very well.
>
> Wrong newsgroup. The language X you are looking for is already there,
> it is popular and widely used. It doesn't have to be reinvented. Forth
> does not try to be a slightly better C than C, that's what C++, D, Java,
> C#, and others are for. Forth is a radically different approach. It's
> not made for the spaghetti programmers, it's not made for people who
> want to be mainstream. Chuck once said, people don't want another
> programming language, they just want a better Fortran. Nowadays, they
> just want a better C. If you are looking for a better C, look somewhere
> else.
Agreed.
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."
==================================================
Roger Ivie
> Bernd Paysan wrote:
>> Oh now please come on. All programmers I know use one sort or another
>> to indent or highlight control flow. And: Apart from Python, no other
>> programming language I know mandates a certain indentation style.
>
> Exactly.
occam uses indentation to mark which statements can be run in parallel.
--
roger ivie
ri...@ridgenet.net
Wayne
> sxccaa.email wrote:
>> Uwe Kloￜ wrote:
>> Elizabeth D Rather :
>> Yes, it is much easier for a language targeted
>> at a particular application domain to be tailored
>> for that domain. Forth is very general; Forth programmers
>> tailor it to the domain they're working in.
>> (domain specific ..
>> programmers tailor it to the domain they're working in)
>
> The best way to apply forth to many tasks is using it to write a
> language for a specific task. Even with a compile-to-machine-code Forth,
> most of my interactive programs are interpreters that don't look like
> Forth. My car doesn't look like a bunch of screws, either. In fact, it's
> hard even to find the fasteners that hold the dash in place.
>
> Jerry
That's actually a good idea, not that I want to get bogged down in c like
library dilemma, and api, where you can create something faster than to
wade through and learn to use somebody else's. The idea of language sets
as something you implement on top of there core standard, is good, because
each language set can be a core of functionality and efficiency, rather
then realms of extras. It keeps the language functionality and head space
specific and separate to those in that particular field, but is there to
access (but also given universal access of course, but then again loading
can also be optional). In the older OS project I tried to cover
everything relevant but in the practically least way (even eliminating
scripting or text files originally, but for uncertain and trickle serial
Internet delivery it was impractical).
(Just in case anybody reading gets confused with this, I am not talking in
direct forth terms, of language word sets, but in generic language design
terms, as I usually do on design issues (it is useful when designing a
language, in order to avoid getting stuck in present concepts).
sxccaa.cal
> "sxccaa.email" <sxccaa.em...@gmail.com> wrote in message
hello rod
the topic of forth mutating to a "LanguageX" (ColorForth?)
had been buzzing in my mind for quite a while and suddenly
the "continued fractions" thread was discussing it in the
right perspectives
since this is a needed discussion to give proper bearings
to 21st century programmers (whatwith them many flavours
of Operating Systems being born for kindles, palms, netbooks,
cellphones, embeddedSystemDevices, etc) i did indeed do
a bit of copy/paste from the "continued fractions" to
collate and put together what appeared to have a bearing
on this aspect of mutating/maturing/morphing of forth
AND
more importantly, of ways and means needed to make it
more visible, known, used
i didn't research much the other thread "acceptance of
FORTH"
its heartening to note "authorities" chipping in with
their inputs .. looks like this might help us getting
this gem into the limelight it deserves and be known
for a good, reliable back-bone with a small enough
footprint to become an eternal presence like asm has
sxccaa.cal
correction .. on re-searching, i find that the
subject line was changed several times by those
who were replying .. so the posts appear under
"acceptance of FORTH" and perhaps some others
Rod Pemberton
news:ieuot6-...@vimes.paysan.nom...
> Rod Pemberton wrote:
> > 1b) FORTH uses "words" which correspond to parameterless procedures or
> > functions in other languages. But, FORTH users also use the concept
> > of "factoring", which means to break thing down into the smallest
> > parts and
> > components. So, you end up with many nested FORTH words for the
> > simplest
> > task. This would be like using many nested procedures in C. The code
> > becomes real hard to follow, real quick.
>
> Ah, I had this argument from one of my former co-workers, who used to
> write flat spaghetti code.
Well, I use structured programming. I learned the concepts just prior to
being self-taught in BASIC (around mid 1980's). So, while his use of
"spaghetti" code creates a mess, it has no bearing IMO on the mess due to
nesting of FORTH words or C procedures.
> Some people just don't have the proper
> mindset for Forth.
Do you really believe it is just an issue of mindset? I did quite well in
school with abstractions far beyond FORTH. Isn't this attitude the reason
why the pro-FORTH community is seen as being dismissive of others?
> All graphics characters in Forth are readable, and have a pronunciation.
They aren't "readable". They are "viewable". Their use in FORTH has no
correlation to any other language or symbology, e.g., mathematics.
Somewhere you stated you've programmed in many computer languages. I have
too. Do you do as well with other spoken or written languages as you do
with programming languages? I don't. It's not even remotely close. I'm
not good with French, Spanish, or German: spoken or written. I've had
classes for all three. You can forget about me "reading" Chinese or
Japanese "drawings", er... sentence pictograms. But, I've picked up many
programming languages quickly.
> A modern Forth like VFX or
> iForth with an analytic compiler *feels* exactly like an old Forth with
> a threaded code interpreter, apart of some details like how big a number
> can be. You type in your definitions at the prompt, and you can invoke
> them right after. It's called "incremental compiler", and it doesn't
> need a program-compile-run loop. Its so fast that you don't care about
> the compile speed. You can compile some large library like MINOS in
> 0.1s on bigForth (peephole optimized native code), or on 0.4s on VFX
> (analytic optimized native code).
>
...
> "incremental compiler"
Yes, that's an old technique of interpreters. The Microsoft BASIC
interpreter in the C64 roms used the exact same method (1982). As a return
was entered, the line of C64 BASIC was parsed, tokenized, converted into
bytecodes, and inserted into the proper location within the BASIC program.
When the bytecode was encountered during execution, it was used as an offset
into a pre-compiled table of addresses. Each address in the table was for a
BASIC function to be called. I.e., the C64's BASIC bytecode interpreter was
what FORTHers know as TTC (Token Threaded Code). The method is very similar
to ITC (Indirect Threaded Code) except a bytecode is used instead of an
address. It's likely the technique was in use earlier especially since
Microsoft was producing BASIC in the mid 1970's for other early personal
computers. So, it was probably even older than that. Where was the
technique used first? I don't know.
> > Once you've got a
> > few C
> > programmers who can do this, why use FORTH? C is everywhere. C is
> > somewhat
> > portable. C compilers optimize very well.
>
> Wrong newsgroup. The language X you are looking for is already there,
> it is popular and widely used. It doesn't have to be reinvented.
That point wasn't about C. The point was that FORTH has no real advantage
over other languages, if programmers of other languages learn certain
techniques.
Rod Pemberton
Elizabeth D Rather
>> All graphics characters in Forth are readable, and have a pronunciation.
>
> They aren't "readable". They are "viewable". Their use in FORTH has no
> correlation to any other language or symbology, e.g., mathematics.
Eh? Those symbols with mathematical meanings carry their meanings into
Forth (e.g. + - * / and their combinations such as */ and M*/). But,
yes, there are some that have "pure Forth" meanings, such as . which I
discussed in a different post. I certainly haven't found that an
impediment when teaching Forth classes, though. Here's a question for
you: which more clearly suggests taking the modulus of something?
% (C) or MOD (Forth)
...
>> A modern Forth like VFX or
>> iForth with an analytic compiler *feels* exactly like an old Forth with
>> a threaded code interpreter, apart of some details like how big a number
>> can be. You type in your definitions at the prompt, and you can invoke
>> them right after. It's called "incremental compiler", and it doesn't
>> need a program-compile-run loop. Its so fast that you don't care about
>> the compile speed. You can compile some large library like MINOS in
>> 0.1s on bigForth (peephole optimized native code), or on 0.4s on VFX
>> (analytic optimized native code).
>>
> ...
>
>> "incremental compiler"
>
> Yes, that's an old technique of interpreters. The Microsoft BASIC
> interpreter in the C64 roms used the exact same method (1982). As a return
> was entered, the line of C64 BASIC was parsed, tokenized, converted into
> bytecodes, and inserted into the proper location within the BASIC program.
> When the bytecode was encountered during execution, it was used as an offset
> into a pre-compiled table of addresses. Each address in the table was for a
> BASIC function to be called. I.e., the C64's BASIC bytecode interpreter was
> what FORTHers know as TTC (Token Threaded Code). The method is very similar
> to ITC (Indirect Threaded Code) except a bytecode is used instead of an
> address. It's likely the technique was in use earlier especially since
> Microsoft was producing BASIC in the mid 1970's for other early personal
> computers. So, it was probably even older than that. Where was the
> technique used first? I don't know.
Token-threaded Forths are very rare. ITC, the original and classic
Forth implementation strategy is significantly faster, comparable (as I
said elsewhere) to a subroutine call without the overhead of parameter
passing. On a PDP-11 it was faster than a subroutine call. The ITC
strategy was not based on BASIC (at the time Chuck developed it, in
1970, he hadn't seen a BASIC). Modern Forths generate optimized machine
code, comparable to the output of a C compiler. Yet they retain the
interactive "feel" of the ITC Forth, still not requiring a separate
compile-link-load cycle.
Andrew Haley
> > Rod Pemberton wrote:
> >> #2: programmer must keep track of data on stack
> >>
> >> This is like counting cards. That's a difficult task for most people.
> >> Can
> >> you keep track of 52 items? Can you keep track of 5 items while
> >> attempting
> >> to program and solve a problem?
> >
> > No, but I just don't have to. I'm not Spiderman, and I don't want
> > to get caught in my own web. Therefore, I just don't do this kind
> > of crazy things like juggling around with many stack elements (ok,
> > to be honest, sometimes I do, just to show off ;-).
> We have done some studies on completed application code. The stack
> very rarely gets more than half a dozen items deep, and individual
> words are rarely concerned with more than two or three logical items
> (counting a double number as one logical item).
Exactly: this thing about "programmer must keep track of data on
stack" is a myth. I have *never* been able to cope with stack
juggling in my head: anything with more than three elements requires
me to draw diagrams on a page. I have always striven to avoid ROT,
because it's just too confusing. But this is not a problem for anyone
writing Forth code: you just avoid stack juggling. It is a problem
for anyone reading badly-written Forth code, that's true. But, as
I've said here NN times before, bad code is hard to read in any
language.
Andrew.
George Hubert
> "Bernd Paysan" <bernd.pay...@gmx.de> wrote in message
>
> news:ieuot6-...@vimes.paysan.nom...
> > "incremental compiler"
>
> Yes, that's an old technique of interpreters. The Microsoft BASIC
> interpreter in the C64 roms used the exact same method (1982). As a return
> was entered, the line of C64 BASIC was parsed, tokenized, converted into
> bytecodes, and inserted into the proper location within the BASIC program.
> When the bytecode was encountered during execution, it was used as an offset
> into a pre-compiled table of addresses. Each address in the table was for a
> BASIC function to be called. I.e., the C64's BASIC bytecode interpreter was
> what FORTHers know as TTC (Token Threaded Code). The method is very similar
> to ITC (Indirect Threaded Code) except a bytecode is used instead of an
> address. It's likely the technique was in use earlier especially since
> Microsoft was producing BASIC in the mid 1970's for other early personal
> computers. So, it was probably even older than that. Where was the
> technique used first? I don't know.
>
Actually it only tokenised a limited number (<127) of keywords into
tokens (using bytes >127 for them). Numbers, strings, variable names
were still stored as ASCII so had to be evaluated each time. Also
GOTO and GOSUB had to scan the linked list of line numbers to locate
the line each time they were executed (rather than storing the
destination
as an adress or offset). It was basically interpreted with a limited
amount
of token look-up, rather than a list of bytes that were virtual
machine
instructions plus binary operands as in Java byte code, USD Pascal P-
code
etc.
George Hubert
>>
> Rod Pemberton
Bernd Paysan
> "Bernd Paysan" <bernd....@gmx.de> wrote in message
>> Ah, I had this argument from one of my former co-workers, who used to
>> write flat spaghetti code.
>
> Well, I use structured programming. I learned the concepts just prior to
> being self-taught in BASIC (around mid 1980's). So, while his use of
> "spaghetti" code creates a mess, it has no bearing IMO on the mess due to
> nesting of FORTH words or C procedures.
Of course it has - it is just the opposite "mess", it is all flat and using
primitive operations, while the nested stuff is using all high-level
operations, which you probably don't know and have to dive in to see what
they do (which still won't allow you to understand what they try to
achieve).
Chuck said something like "Forth is compressing programs", i.e. compressing
like a LZW algorithm compresses text by identifying identical sequences, and
replacing these sequences with a single token - the same is true for Forth
programs, identical sequences are factored out, and replaced by a single
token. I like the compressed representation, it makes it easier for me to
understand things when the description is condensed; I also like to have the
compression in reading order. I know other people don't like dense
information, they like it more verbose. If you like it verbose and flat,
Forth isn't for you.
>> Some people just don't have the proper
>> mindset for Forth.
>
> Do you really believe it is just an issue of mindset? I did quite well in
> school with abstractions far beyond FORTH. Isn't this attitude the reason
> why the pro-FORTH community is seen as being dismissive of others?
We often hear that people tell us "I don't get this Forth thing". I found
Forth easy to learn. When others have severe problems, it's probably
because they are different. I accept that not all people are equal. I
believe any healthy ecosystem has a high variety inside, so I have no
problems with multiple options to choose from. Chose what fits best to you.
After all, *you* have to use it.
I like Forth more than other programming languages. That's my opinion. If
you have a different opinion, you are entitled to that, but just don't
expect me to agree with you.
>> All graphics characters in Forth are readable, and have a pronunciation.
>
> They aren't "readable". They are "viewable". Their use in FORTH has no
> correlation to any other language or symbology, e.g., mathematics.
Hm, you think e.g. of @ and !? Memory is not a usual concept found in
mathematics, so it needs a new symbol, doesn't it? Higher mathematics is
not shy on symbols, some seem to invent a new symbol every day ;-).
> Somewhere you stated you've programmed in many computer languages. I have
> too. Do you do as well with other spoken or written languages as you do
> with programming languages? I don't. It's not even remotely close. I'm
> not good with French, Spanish, or German: spoken or written. I've had
> classes for all three. You can forget about me "reading" Chinese or
> Japanese "drawings", er... sentence pictograms. But, I've picked up many
> programming languages quickly.
I speak English, and French quite fluently. I speak some Chinese and can
read more common symbols (my vocabulary is limited, though), I understand
the way Chinese glyphs are constructed, and you are simply wrong. 80% of
Chinese glyphs are composed of two "radicals": One conveys the sound, the
other the general meaning, not so much different to our letters, which
originally had a meaning, too, and the meaning indicated the sound (e.g. the
letter A comes from the phoenician "aleph", which means "cow", and by
rotating the A and extending the bar you can see the head of a cow with two
corns and ears).
I had difficulties with language in school, because the language teachers
didn't like me, they liked the girls in the front row, but not the boys in
the back row. But in general, I have no troubles picking up languages or
other alphabets (I can reed greek and cyrillic, at least enough to
understand road signs).
>> "incremental compiler"
>
> Yes, that's an old technique of interpreters.
No, you don't understand. Most modern Forths don't produce indirect
threaded code, they produce machine code (and that includes even gforth-
fast). There are tokens kept around in some systems, e.g. for the inliner
in VFX, or for the backend compiler in Gforth (gforth-fast first compiles
threaded code, and then converts that threaded code to native code), but
these tokens are *not* interpreted. They only help the compiler.
It really is like this (session with VFX Forth):
variable foo ok
: bar foo @ 3 + ; ok
see bar
BAR
( 0817E370 8B1550E31708 ) MOV EDX, [0817E350]
( 0817E376 83C203 ) ADD EDX, 03
( 0817E379 8D6DFC ) LEA EBP, [EBP+-04]
( 0817E37C 895D00 ) MOV [EBP], EBX
( 0817E37F 8BDA ) MOV EBX, EDX
( 0817E381 C3 ) NEXT,
( 18 bytes, 6 instructions )
ok
or in bigForth:
variable foo ok
: bar foo @ 3 + ; ok
disw bar Adresse : 268664152
10037D58: xchg ESP,ESI 87F4
10037D5A: push EAX 50
10037D5B: mov EAX,[$10037D48] A1487D0310
10037D60: add EAX,$3 0503000000
10037D65: xchg ESP,ESI 87F4
10037D67: ret C3
> That point wasn't about C. The point was that FORTH has no real advantage
> over other languages, if programmers of other languages learn certain
> techniques.
Then you just don't understand the advantages of Forth. Indeed, you can
solve every problem in every turing complete programming language, including
Piet and Brainfuck, that's not an argument at all; nobody uses Piet or
Brainfuck for anything but silly examples. The amount of effort it takes to
solve a problem, and the help you get from certain design decisions of the
language is different.
The main advantages of Forth IMHO are:
* You can refactor words easier, since it's mostly cut&paste, while in
conventional languages, the named variables require either a complex
refactoring editor, or lots of manual intervention. You said factoring
doesn't help you, so this isn't an advantage for you. But it is for others.
* You have an interactive environment to try things out. Use it!
* You have full meta-programming power, i.e. you can extend the compiler in
any way you like. It probably won't help you, either.
* Recompilation is fast, and doesn't create unproductive coffee break pauses
(distracting people, and distraction means a great loss of productivity).
* The system is simple enough to be understood by the user.
This all comes at the cost that Forth looks and feels a lot different from
other programming languages. Removing the costs also removes the benefits.
It's not hard to add a "language X" on top of Forth, even a C-like
mainstream one. Take gray as parser generator, implement it. It won't be
Forth anymore, but it might have common properties - e.g. it still can have
an incremental compiler, and an interactive prompt. It still can compile
quickly and create fast code. It still may allow you to go back to Forth to
have the full control over everything.
Anton Ertl
>occam uses indentation to mark which statements can be run in parallel.
Occam uses indentation for grouping, just like Python. It uses PAR
to indicate parallel execution.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2009: http://www.euroforth.org/ef09/
Aleksej Saushev
> Rod Pemberton wrote:
>
>> That point wasn't about C. The point was that FORTH has no real advantage
>> over other languages, if programmers of other languages learn certain
>> techniques.
>
> The main advantages of Forth IMHO are:
>
> * You can refactor words easier, since it's mostly cut&paste, while in
> conventional languages, the named variables require either a complex
> refactoring editor, or lots of manual intervention. You said factoring
> doesn't help you, so this isn't an advantage for you. But it is for others.
How do you handle situations when you change net stack effect?
Who reworks stack juggling for you?
Contrary to what you assert named variables don't require that much
special handling.
> * You have an interactive environment to try things out. Use it!
There're many other interactive environments around. You have CINT.
Though you may ignore it personally, it doesn't make CINT nonexistent.
Note, that this is even for C and C++, which Forth advocates like to use
for comparison. Pretty any modern and more powerful language provides
interpreter.
> * You have full meta-programming power, i.e. you can extend the compiler in
> any way you like. It probably won't help you, either.
How frequently do you use meta-programming facilities?
> * Recompilation is fast, and doesn't create unproductive coffee break pauses
> (distracting people, and distraction means a great loss of productivity).
Recompilation is fast for C, for instance NetBSD GENERIC kernel takes
about 15 min to rebuild on 3-year old hardware, maybe more maybe less,
I don't know exactly, because this is damn fast. You never bring examples
of comparable complexity in Forth, thus you rule Forth out of comparison.
Humans don't work for hours without loss of attention, breaks are unavoidable.
> * The system is simple enough to be understood by the user.
This statement is lie usual to Forth advocates.
For instance, you've broken FFI again and it isn't easy to understand
what the hell is happening:
*a file*:4: Invalid memory address
libc ioctl int int ptr >>>(int)<<< ioctl ( fdesc cmd ptr -- result | -1 )
Certainly this doesn't create unproductive "coffee break" pause.
--
HE CE3OH...
Stephen Pelc
wrote:
>> * Recompilation is fast, and doesn't create unproductive coffee break pauses
>> (distracting people, and distraction means a great loss of productivity).
>
>Recompilation is fast for C, for instance NetBSD GENERIC kernel takes
>about 15 min to rebuild on 3-year old hardware, maybe more maybe less,
>I don't know exactly, because this is damn fast. You never bring examples
>of comparable complexity in Forth, thus you rule Forth out of comparison.
As I have posted several times before, I regularly recompile 850,000
lines of Forth source code in 25 or so seconds leading to an 18Mb
binary. Our client reports that on a box with hardware selected
for compilation speed, compilation time is below 20 seconds.
Our VFX cross compilers generate binary at about 500kb/sec, mostly
dominated by disk speed.
In both cases, final compilation speed is heavily affected by source
file size and number, and by the disk and disk cache performance.
Since you have not given us any statistics for C, e.g. lines of
code and optimisation level, I await figures.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Bernd Paysan
>> The main advantages of Forth IMHO are:
>>
>> * You can refactor words easier, since it's mostly cut&paste, while in
>> conventional languages, the named variables require either a complex
>> refactoring editor, or lots of manual intervention. You said factoring
>> doesn't help you, so this isn't an advantage for you. But it is for
>> others.
>
> How do you handle situations when you change net stack effect?
> Who reworks stack juggling for you?
Granted, when refactoring, you have to give the factor a name, and document
its stack effect. It's you who decides if the stack juggling goes into the
factor or stays outside.
> Contrary to what you assert named variables don't require that much
> special handling.
Well, you have to find out which names you are using in the sequence you cut
out, and you have to define a calling convention (order) for that, and
what's worst: If you update more than one in the part you've cut out, you
hit the limit of first class return values, and have to change your code for
second class return values (aka pointers).
>> * You have an interactive environment to try things out. Use it!
>
> There're many other interactive environments around. You have CINT.
> Though you may ignore it personally, it doesn't make CINT nonexistent.
Of course not. SuSE however comes with gforth, but without CINT. So it's
probably even more fringe than Forth.
> Note, that this is even for C and C++, which Forth advocates like to use
> for comparison. Pretty any modern and more powerful language provides
> interpreter.
Java? C#? Out of the box (Mono provides one, Microsoft AFAIK not). Python
gives me an interactive shell, or TCL, but when I start ruby from the
command line, it's showing me an obvious shell. I must agree with you, I
think by now any reasonable modern and powerful language should have a
console with interpreter. But I don't think we are quite there yet.
I haven't said these are unique selling points. I've said these are
advantages, and thus you don't get them everywhere.
>> * You have full meta-programming power, i.e. you can extend the compiler
>> in
>> any way you like. It probably won't help you, either.
>
> How frequently do you use meta-programming facilities?
They are the foundation of what I do, e.g. the OOF MINOS bases on. Usually,
I have a few lines with CREATE DOES> or POSTPONE in even small projects.
Some Lisp advocates state that 1/4 of their program is metaprogramming,
which is probably grossly overstated. The use of words that use
metaprogramming (either to be created or at compile-time) in my programs is
significant.
>> * Recompilation is fast, and doesn't create unproductive coffee break
>> pauses (distracting people, and distraction means a great loss of
>> productivity).
>
> Recompilation is fast for C, for instance NetBSD GENERIC kernel takes
> about 15 min to rebuild on 3-year old hardware, maybe more maybe less,
> I don't know exactly, because this is damn fast.
Sorry, we have two different meanings of the word "damn fast". 0.1 seconds
is damn fast, all below 3 seconds is fast, 15 minutes is several coffee
breaks, and "dog slow". I want interaction, not falling asleep and then
need coffee to wake up again ;-).
> You never bring examples
> of comparable complexity in Forth, thus you rule Forth out of comparison.
Stephen Pelc once quoted that CCS, which is a million lines of source code,
compiles in 20s on VFX. My benchmark is compiling MINOS, which takes only
0.4s on VFX and 0.1s on bigForth on a 2GHz machine, and I would compare that
to compiling Motif or Gtk, since it achieves something similar, though it is
not as complex as the latter two (accidental complexity vs. inherent
complexity).
> Humans don't work for hours without loss of attention, breaks are
> unavoidable.
Yes, but breaks should be between workflow stages, not within them.
>> * The system is simple enough to be understood by the user.
>
> This statement is lie usual to Forth advocates.
>
> For instance, you've broken FFI again and it isn't easy to understand
> what the hell is happening:
>
> *a file*:4: Invalid memory address
> libc ioctl int int ptr >>>(int)<<< ioctl ( fdesc cmd ptr -- result | -1 )
>
> Certainly this doesn't create unproductive "coffee break" pause.
I've no idea what kind of problem you are currently facing. The example you
give works fine here, both on Linux and Mac OS X (BSD based). Anyways,
using an external C library of course is no simple stuff, because you
involve four systems: Forth, dynamic library loader, libffi, and the C
library. If any one of them fails, boom. If it's a fringe OS where we
don't test on (like NetBSD), a lot more difficult to debug.
ken...@cix.compulink.co.uk
Paysan) wrote:
> And: Apart from Python, no other
> programming language I know mandates a certain indentation style.
That is true for individuals, but most programming groups have a house
style. Still on the question of readability I find C and APL worse than
Forth and Pascal is not much better. As for non alphabetical characters
APL makes much heavier use of them and at least originally could not be
used with a standard keyboard.
Mind you even Basic and Cobol programs can end up as unreadable.
Create> does should in my opinion be compared to something like
Pascal's user declared variables not objects.
Ken Young
peekay
> >> The main advantages of Forth IMHO are:
>
> >> * You can refactor words easier, since it's mostly cut&paste, while in
> >> conventional languages, the named variables require either a complex
> >> refactoring editor, or lots of manual intervention. You said factoring
> >> doesn't help you, so this isn't an advantage for you. But it is for
> >> others.
Bernd Paysan -
Granted, when refactoring, .......
<snipped>
thanks to all for the variety of viewpoints, sharing
views, ideas, beliefs, practices, experiences, methods,
etc etc
i have a question - how many would agree/disagree
that ColorForth IS the LanguageX above/beyond Forth ?
FORTH would branch off into one of the two directions :
Forth would proceed/mutate/evolve into ColorForth
OR
Forth would proceed/mutate/evolve into Forth+
(leaving ColorForth to become a totally different spieces)
i feel that the 2nd direction is already being taken
peekay
Jerry Avins
...
> Somewhere you stated you've programmed in many computer languages. I have
> too. Do you do as well with other spoken or written languages as you do
> with programming languages? ...
That's a silly question. You must be aware that English isn't Bernd's
native tongue.
Anton Ertl
>Our VFX cross compilers generate binary at about 500kb/sec
Using the generated code size as a metric does not make sense: Double
the code size by inserting the appropriate amount of nops, and this
metric goes up by a factor of 2, but the compilation speed does not
improve.
>mostly
>dominated by disk speed.
What kinds of disks and what kind of OS are you using? The disks I
use can write up to 70MB/s, and when writing large files, a
significant part of that bandwidth can actually be used. Moreover,
the OS I am using can use most of the memory for buffering written
files, so the disk speed does not play a role at all.
E.g., just writing a 1MB file to the buffer:
[/tmp:69661] time dd if=/dev/zero of=xxx bs=1024 count=1024
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB) copied, 0.0042764 s, 245 MB/s
real 0m0.006s
user 0m0.004s
sys 0m0.008s
And now with forcing the data out to disk, and waiting for that:
[/tmp:69662] sync; time (dd if=/dev/zero of=xxx bs=1024 count=1024; sync)
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB) copied, 0.00419056 s, 250 MB/s
real 0m0.092s
user 0m0.000s
sys 0m0.008s
I.e. >10MB/s write speed to disk.
>In both cases, final compilation speed is heavily affected by source
>file size and number, and by the disk and disk cache performance.
With a good OS and enough RAM, only on the first compilation in a
session.
Elizabeth D Rather
> Bernd Paysan <bernd....@gmx.de> writes:
>
>> Rod Pemberton wrote:
>>
>>> That point wasn't about C. The point was that FORTH has no real advantage
>>> over other languages, if programmers of other languages learn certain
>>> techniques.
>> The main advantages of Forth IMHO are:
>>
>> * You can refactor words easier, since it's mostly cut&paste, while in
>> conventional languages, the named variables require either a complex
>> refactoring editor, or lots of manual intervention. You said factoring
>> doesn't help you, so this isn't an advantage for you. But it is for others.
>
> How do you handle situations when you change net stack effect?
> Who reworks stack juggling for you?
"Re-factoring" doesn't usually require different stack effects. It's
the same as the original code, except at some point there's the name of
the new word instead of a sequence of words.
...
>> * You have an interactive environment to try things out. Use it!
>
> There're many other interactive environments around. You have CINT.
> Though you may ignore it personally, it doesn't make CINT nonexistent.
>
> Note, that this is even for C and C++, which Forth advocates like to use
> for comparison. Pretty any modern and more powerful language provides
> interpreter.
Yeah, I've watched folks using tools like that. They do a *lot* more
typing than I do for an equivalent task in Forth.
>> * You have full meta-programming power, i.e. you can extend the compiler in
>> any way you like. It probably won't help you, either.
>
> How frequently do you use meta-programming facilities?
It's the kind of thing that you may not use every day, but when the
occasion arises it's incredibly valuable.
>> * Recompilation is fast, and doesn't create unproductive coffee break pauses
>> (distracting people, and distraction means a great loss of productivity).
>
> Recompilation is fast for C, for instance NetBSD GENERIC kernel takes
> about 15 min to rebuild on 3-year old hardware, maybe more maybe less,
> I don't know exactly, because this is damn fast. You never bring examples
> of comparable complexity in Forth, thus you rule Forth out of comparison.
>
> Humans don't work for hours without loss of attention, breaks are unavoidable.
The last time I saw a 15-minute compile in Forth was in 1975, and I've
worked with some really complex programs. Recompiling SwiftForth takes
a few milliseconds (no perceptable delay). Likewise the largest apps
we're currently working with. You don't need a slow compiler to give
you an excuse for a break!
>> * The system is simple enough to be understood by the user.
>
> This statement is lie usual to Forth advocates.
I've heard it often from our users. Are they lying?
> For instance, you've broken FFI again and it isn't easy to understand
> what the hell is happening:
>
> *a file*:4: Invalid memory address
> libc ioctl int int ptr >>>(int)<<< ioctl ( fdesc cmd ptr -- result | -1 )
Not sure what this is supposed to be an example of.
Jerry Avins
...
> How frequently do you use meta-programming facilities?
About as often as I used to use the crank to start my Austin A-30. Not
often, but very valuable when I needed it.
...
Rod Pemberton
>
> My benchmark is compiling MINOS, which takes ...
>
What other publicly available, large sized, FORTH applications are there?
If I wanted FORTH tests - other than John Hayes ISO core tests - what would
I run?
Rod Pemberton
Aleksej Saushev
> Aleksej Saushev wrote:
>>> The main advantages of Forth IMHO are:
>>>
>>> * You can refactor words easier, since it's mostly cut&paste, while in
>>> conventional languages, the named variables require either a complex
>>> refactoring editor, or lots of manual intervention. You said factoring
>>> doesn't help you, so this isn't an advantage for you. But it is for
>>> others.
>>
>> How do you handle situations when you change net stack effect?
>> Who reworks stack juggling for you?
>
> Granted, when refactoring, you have to give the factor a name, and document
> its stack effect. It's you who decides if the stack juggling goes into the
> factor or stays outside.
>
>> Contrary to what you assert named variables don't require that much
>> special handling.
>
> Well, you have to find out which names you are using in the sequence you cut
> out, and you have to define a calling convention (order) for that, and
> what's worst: If you update more than one in the part you've cut out, you
> hit the limit of first class return values, and have to change your code for
> second class return values (aka pointers).
I don't have to, compiler does it for me, it has special knobs to warn
me about unused variables. As for other problems you point to, they are
shared by Forth. You still have to define calling convention, you don't
normally rework more than one place because you cannot do it in general.
>>> * You have an interactive environment to try things out. Use it!
>>
>> There're many other interactive environments around. You have CINT.
>> Though you may ignore it personally, it doesn't make CINT nonexistent.
>
> Of course not. SuSE however comes with gforth, but without CINT. So it's
> probably even more fringe than Forth.
This is voluntary decision, I'm afraid that if you go through
university you'll find more people who heard about CINT rather than
Forth. Mainly because it is part of ROOT.
>> Note, that this is even for C and C++, which Forth advocates like to use
>> for comparison. Pretty any modern and more powerful language provides
>> interpreter.
>
> Java? C#? Out of the box (Mono provides one, Microsoft AFAIK not). Python
> gives me an interactive shell, or TCL, but when I start ruby from the
> command line, it's showing me an obvious shell. I must agree with you, I
> think by now any reasonable modern and powerful language should have a
> console with interpreter. But I don't think we are quite there yet.
>
> I haven't said these are unique selling points. I've said these are
> advantages, and thus you don't get them everywhere.
It is easier to list cases when you don't have interactive environment
than otherwise.
>>> * You have full meta-programming power, i.e. you can extend the compiler
>>> in
>>> any way you like. It probably won't help you, either.
>>
>> How frequently do you use meta-programming facilities?
>
> They are the foundation of what I do, e.g. the OOF MINOS bases on. Usually,
> I have a few lines with CREATE DOES> or POSTPONE in even small projects.
> Some Lisp advocates state that 1/4 of their program is metaprogramming,
> which is probably grossly overstated. The use of words that use
> metaprogramming (either to be created or at compile-time) in my programs is
> significant.
It may easily be that foundations are those, but the question isn't
about foundations. Using same argument you may claim that you're doing
particle physics everyday because it is (kind of) foundations.
"I like that it's there when I need it" argument is weak, you have YACC
and similar tools just in case you need it.
>>> * Recompilation is fast, and doesn't create unproductive coffee break
>>> pauses (distracting people, and distraction means a great loss of
>>> productivity).
>>
>> Recompilation is fast for C, for instance NetBSD GENERIC kernel takes
>> about 15 min to rebuild on 3-year old hardware, maybe more maybe less,
>> I don't know exactly, because this is damn fast.
>
> Sorry, we have two different meanings of the word "damn fast". 0.1 seconds
> is damn fast, all below 3 seconds is fast, 15 minutes is several coffee
> breaks, and "dog slow". I want interaction, not falling asleep and then
> need coffee to wake up again ;-).
For small programs, comparable to what you do, you have your 0,1 s.
Computers are fast these days.
>> You never bring examples
>> of comparable complexity in Forth, thus you rule Forth out of comparison.
>
> Stephen Pelc once quoted that CCS, which is a million lines of source code,
> compiles in 20s on VFX. My benchmark is compiling MINOS, which takes only
> 0.4s on VFX and 0.1s on bigForth on a 2GHz machine, and I would compare that
> to compiling Motif or Gtk, since it achieves something similar, though it is
> not as complex as the latter two (accidental complexity vs. inherent
> complexity).
First, how do I check it if this "million LoC" isn't available?
Second, I doubt that it has comparable complexity. Is it flexible?
Reconfigurable to target hardware ranging from small devices to servers?
Just in case you're interested, here're real numbers:
find /usr/src/sys -type f -exec wc -l {} \+ | awk '{n+=$1} END {print n}'
10606644
This includes CVS bookkeeping and my local modifications, still it's
order of magnitude larger even in terms of lines of code.
>> Humans don't work for hours without loss of attention, breaks are
>> unavoidable.
>
> Yes, but breaks should be between workflow stages, not within them.
If natural break happens in the middle of your workflow, it's still
unavoidable.
>>> * The system is simple enough to be understood by the user.
>>
>> This statement is lie usual to Forth advocates.
>>
>> For instance, you've broken FFI again and it isn't easy to understand
>> what the hell is happening:
>>
>> *a file*:4: Invalid memory address
>> libc ioctl int int ptr >>>(int)<<< ioctl ( fdesc cmd ptr -- result | -1 )
>>
>> Certainly this doesn't create unproductive "coffee break" pause.
>
> I've no idea what kind of problem you are currently facing. The example you
> give works fine here, both on Linux and Mac OS X (BSD based). Anyways,
> using an external C library of course is no simple stuff, because you
> involve four systems: Forth, dynamic library loader, libffi, and the C
> library. If any one of them fails, boom. If it's a fringe OS where we
> don't test on (like NetBSD), a lot more difficult to debug.
Putting aside your inability to write portable code (NetBSD isn't "fringe"
contrary to your claims, it is mainstream operating system widely used
in production), lets' concentrate on the point you're trying to avoid.
Sure, there are many systems involved, but it were you, developers, who
decided to rely on GCC-at-run-time approach. It is easy to see that your
original assertion, that "the system is simple enough to be understood
by user", is a lie. It is obvious that the exemplar system isn't easy to
understand, instead it is impenetrable mess in many of its parts.
--
HE CE3OH...
Anti Vigilante
> stack" is a myth. I have *never* been able to cope with stack
> juggling in my head: anything with more than three elements requires
> me to draw diagrams on a page. I have always striven to avoid ROT,
> because it's just too confusing. But this is not a problem for anyone
> writing Forth code: you just avoid stack juggling. It is a problem
> for anyone reading badly-written Forth code, that's true. But, as
> I've said here NN times before, bad code is hard to read in any
> language.
>
> Andrew.
There's a slight problem with this. I have to think ahead of time which
values need to go in which order on the stack and when to dup swap and
spindle them before I actually throw in the words. This is insane.
Forth behaves like a 1 register machine. I'd be glad to play with a
register based forth. Would be quite interesting.
Bernd Paysan
> It may easily be that foundations are those, but the question isn't
> about foundations. Using same argument you may claim that you're doing
> particle physics everyday because it is (kind of) foundations.
>
> "I like that it's there when I need it" argument is weak, you have YACC
> and similar tools just in case you need it.
They are far more cumbersome to use and far less flexible. If I was going
to do something like OOF based on bison/gcc, it would take a lot longer than
it takes in Forth (it took three days to write OOF, the first two days
resulted each in an implementation I decided to throw away and restart with
a better one).
What you snipped out is the most important thing: Even my small programs
contain a little bit of metaprogramming here and there. Not just as
foundation by using OOF, but directly.
> For small programs, comparable to what you do, you have your 0,1 s.
> Computers are fast these days.
For something comparable to MINOS in C, I easily get compile times in
minutes. MINOS is 17kLoC. I know, you think this is a small program, but
it has a lot of functionality, which requires a lot more lines to express if
written in typical C style.
> First, how do I check it if this "million LoC" isn't available?
By extrapolation: 400 850000 17000 */ . 20000 ok
So when it takes 400ms for 17kLoC on VFX, it takes 20s for 850kLoC. Stephen
reported that, so the extrapolation seems to be surprisingly good.
> Second, I doubt that it has comparable complexity. Is it flexible?
> Reconfigurable to target hardware ranging from small devices to servers?
CCS is a resource planning product for construction sites. It is not an OS.
Of course it is flexible, and of course it can run on small and large
devices; you better talk to Willem if you want to know more (he's not on
clf, but he is a regular visitor at EuroForth).
> Just in case you're interested, here're real numbers:
>
> find /usr/src/sys -type f -exec wc -l {} \+ | awk '{n+=$1} END {print n}'
> 10606644
>
> This includes CVS bookkeeping and my local modifications, still it's
> order of magnitude larger even in terms of lines of code.
We all know here that C programs tend to be orders of magnitudes larger for
the same functionality. If it was Forth, it would take 4 minutes to compile
with VFX or about one minute with bigForth.
>> Yes, but breaks should be between workflow stages, not within them.
>
> If natural break happens in the middle of your workflow, it's still
> unavoidable.
Breaks in the middle of workflows are distractions, and not "natural".
> Putting aside your inability to write portable code (NetBSD isn't "fringe"
> contrary to your claims, it is mainstream operating system widely used
> in production), lets' concentrate on the point you're trying to avoid.
I don't have access to any NetBSD machine. Give me an SSH login, and I'll
test on NetBSD, too. There ain't no such thing as portable code per se, all
you can do is write code, try and *test* it. What hasn't been tested
shouldn't be expected to run. You can rely on the people who use it on this
platform that they will properly maintain their platform, and test code from
others - this apparently doesn't work on NetBSD. This libffi stuff in
Gforth worked on all platforms we tested on, and that were about 10 or so.
I remember that I gave you the task to try bigForth on NetBSD, you didn't
even bother to report your failure (or whatever it was, you probably didn't
accomplish anything).
> Sure, there are many systems involved, but it were you, developers, who
> decided to rely on GCC-at-run-time approach. It is easy to see that your
> original assertion, that "the system is simple enough to be understood
> by user", is a lie. It is obvious that the exemplar system isn't easy to
> understand, instead it is impenetrable mess in many of its parts.
Sorry, libffi.fs doesn't use GCC-at-run-time. It uses GCC at build time,
libffi at run time. If even that fails, we have to question to use GCC at
all - or at least libffi (which, BTW, we already did: It's not reliable
enough to work). Honestly speaking, we do question the GCC approach since
the GCC 3.x series.
On the other hand: libffi.fs is just 500 lines. You really sound like a
crybaby when you complain that this is impenetrable, and you can't debug it
to give a more meaningful report. Some suggestions:
According to your report, (int) fails. Could you nail down where it fails
by putting some ~~ into the DOES>-part of the rettype definition?
Wayne
wrote:
I hope your not referring to me, I am not a forth expert, however I can
contribute from some guidance from my own knowledge and design efforts.
The new language OS I am looking at doing was to be based on the
colorforth spec and commercial open-sourced. In a way it is a simpler
VOS, because it is not as comprehensive. It basically has all patentable
features of the old VOS project stripped out, which is too many. The
design draft spec if still complete, especially the documentation, but I
am still willing to do the old VOS, if enough money is available to patent
and properly commercialise it, but it is virtually everything everybody
wants (except the AI people). So, I hope to concentrate instead on the
little OS next year.
I fully support your idea in general, what is needed is a ratification of
Forth down to and across to a new simple standard alongside the present.
It doesn't matter if it is not a standard compatible with developing in
the industry presently, that can come latter, at the moment it can be just
a research tool. You might want to research the best stack, register and
machine instruction model, but if you want to use colorforth you will
still need to add to it.
Name? (Forht+, Gorth or Horth, North, frth or xorth ;) ),
Thanks for your contribution sxccaa (what was your name again?).
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Aleksej Saushev
> Aleksej Saushev wrote:
>> It may easily be that foundations are those, but the question isn't
>> about foundations. Using same argument you may claim that you're doing
>> particle physics everyday because it is (kind of) foundations.
>>
>> "I like that it's there when I need it" argument is weak, you have YACC
>> and similar tools just in case you need it.
>
> They are far more cumbersome to use and far less flexible. If I was going
> to do something like OOF based on bison/gcc, it would take a lot longer than
> it takes in Forth (it took three days to write OOF, the first two days
> resulted each in an implementation I decided to throw away and restart with
> a better one).
>
> What you snipped out is the most important thing: Even my small programs
> contain a little bit of metaprogramming here and there. Not just as
> foundation by using OOF, but directly.
savesys.fs is signed by your initials, if I understand it right.
What are meta-programming concepts used there?
Same with search.fs, string.fs, tasker.fs, several sieve benchmarks.
Have I started from the long letter?
>> For small programs, comparable to what you do, you have your 0,1 s.
>> Computers are fast these days.
>
> For something comparable to MINOS in C, I easily get compile times in
> minutes. MINOS is 17kLoC. I know, you think this is a small program, but
> it has a lot of functionality, which requires a lot more lines to express if
> written in typical C style.
>
>> First, how do I check it if this "million LoC" isn't available?
>
> By extrapolation: 400 850000 17000 */ . 20000 ok
>
> So when it takes 400ms for 17kLoC on VFX, it takes 20s for 850kLoC. Stephen
> reported that, so the extrapolation seems to be surprisingly good.
This extrapolation is invalid, in larger project you get into non-linear area
where you have to spend more resources on organizational matters. You can write
long program in a single text file, but this has major drawbacks people try
to avoid.
>> Just in case you're interested, here're real numbers:
>>
>> find /usr/src/sys -type f -exec wc -l {} \+ | awk '{n+=$1} END {print n}'
>> 10606644
>>
>> This includes CVS bookkeeping and my local modifications, still it's
>> order of magnitude larger even in terms of lines of code.
>
> We all know here that C programs tend to be orders of magnitudes larger for
> the same functionality. If it was Forth, it would take 4 minutes to compile
> with VFX or about one minute with bigForth.
Humans need some redundancy. In this post-Dijkstra world code is meant
to be read by humans, "C" complies with this statement to some extent,
Forth doesn't do it well enough. Not in its current state at least.
>> Putting aside your inability to write portable code (NetBSD isn't "fringe"
>> contrary to your claims, it is mainstream operating system widely used
>> in production), lets' concentrate on the point you're trying to avoid.
>
> I don't have access to any NetBSD machine. Give me an SSH login, and I'll
> test on NetBSD, too. There ain't no such thing as portable code per se, all
> you can do is write code, try and *test* it. What hasn't been tested
> shouldn't be expected to run. You can rely on the people who use it on this
> platform that they will properly maintain their platform, and test code from
> others - this apparently doesn't work on NetBSD. This libffi stuff in
> Gforth worked on all platforms we tested on, and that were about 10 or so.
Yes, and that's what I tell you, it worked till some moment between 10. Oct
and 15 Nov. Something broke in between, and there are too many subsystems
involved to claim Forth is simple and easy to understand.
> I remember that I gave you the task to try bigForth on NetBSD, you didn't
> even bother to report your failure (or whatever it was, you probably didn't
> accomplish anything).
I didn't get to that. I have other things to do besides Forth.
>> Sure, there are many systems involved, but it were you, developers, who
>> decided to rely on GCC-at-run-time approach. It is easy to see that your
>> original assertion, that "the system is simple enough to be understood
>> by user", is a lie. It is obvious that the exemplar system isn't easy to
>> understand, instead it is impenetrable mess in many of its parts.
>
> Sorry, libffi.fs doesn't use GCC-at-run-time. It uses GCC at build time,
> libffi at run time. If even that fails, we have to question to use GCC at
> all - or at least libffi (which, BTW, we already did: It's not reliable
> enough to work). Honestly speaking, we do question the GCC approach since
> the GCC 3.x series.
libffi.fs reads:
\ The ffi.h of XCode needs the following line, and it should not hurt elsewhere
\c #define MACOSX
include-ffi.h-string save-c-prefix-line \ #include <ffi.h>
\c #include <stdio.h>
\c static void **gforth_clist;
\c static void *gforth_ritem;
In other words, it requires gcc at run time unless you made some magic rollover.
You seem to make all possible things to distrust you. This can't make Forth
good publicity, and that's my major point in all this counter-advocacy.
I want you to be honest to your users and not tell obvious lies to them,
at least not when it is so easy to check.
> On the other hand: libffi.fs is just 500 lines. You really sound like a
> crybaby when you complain that this is impenetrable, and you can't debug it
> to give a more meaningful report. Some suggestions:
>
> According to your report, (int) fails. Could you nail down where it fails
> by putting some ~~ into the DOES>-part of the rettype definition?
When I get to the failing part since I don't use it in current project.
I run full tests from time to time just to check everything works.
--
HE CE3OH...
Bernd Paysan
> savesys.fs is signed by your initials, if I understand it right.
> What are meta-programming concepts used there?
> Same with search.fs, string.fs, tasker.fs, several sieve benchmarks.
> Have I started from the long letter?
Try regexp.fs. And even tasker.fs contains a small amount of meta-
programming:
:noname ' >body @ ;
:noname ' >body @ postpone literal ;
interpret/compile: user' ( 'user' -- n )
\G USER' computes the task offset of a user variable
Just look for postpone and does> to find little meta-programming.
>>> First, how do I check it if this "million LoC" isn't available?
>>
>> By extrapolation: 400 850000 17000 */ . 20000 ok
>>
>> So when it takes 400ms for 17kLoC on VFX, it takes 20s for 850kLoC.
>> Stephen reported that, so the extrapolation seems to be surprisingly
>> good.
>
> This extrapolation is invalid, in larger project you get into non-linear
> area where you have to spend more resources on organizational matters. You
> can write long program in a single text file, but this has major drawbacks
> people try to avoid.
You dismiss an extrapolation that *worked*. I.e. the extrapolated number
matches observation. I suppose the overhead is constant per LoC - e.g.
splitting CCS in many more files than MINOS will not result in higher
overhead per LoC, since the average file size is probably the same.
>> We all know here that C programs tend to be orders of magnitudes larger
>> for the same functionality. If it was Forth, it would take 4 minutes to
>> compile with VFX or about one minute with bigForth.
>
> Humans need some redundancy. In this post-Dijkstra world code is meant
> to be read by humans, "C" complies with this statement to some extent,
> Forth doesn't do it well enough. Not in its current state at least.
Well, some redundancy, maybe. But as I said in another thread here, humans
differ. Some need an abundance of redundancy, others don't (I find a lot of
blah blah and not coming to the point much more disgusting than a terse
statement). Please don't generalize from your personal experience to all
humans, humans are not all the same. I think I made myself more than clear
in that posting that I understand differences between humans, and probably
Forth is not right for everybody. This is not about discrimination, it is
about choice. I perceive Forth's terseness as advantage, you as
disadvantage.
> Yes, and that's what I tell you, it worked till some moment between 10.
> Oct and 15 Nov. Something broke in between, and there are too many
> subsystems involved to claim Forth is simple and easy to understand.
Well, the main change we did to libcc.fs in between was adding some warning
messages. And as I said: If you want to access C libraries, you are well
aware that you leave the Forth-only environment, and therefore you have to
deal with the added complexity of a C compiler, a shared library system, a
foreign function interface, and so on (and as a result, it breaks).
Our main reason to use the libcc.fs interface is to reduce this dependency
to what we absolutely need for this complex task: The C compiler and the
shared library loader. The C calling conventions are sometimes so insanely
complex that everything else will fail.
If you want to prove by example that my point "A Forth system is simple" is
a lie, than you picked the wrong example. You just proved that C is
complex, and even interfacing to C is a nightmare. Full agreement from my
side.
> libffi.fs reads:
>
> \ The ffi.h of XCode needs the following line, and it should not hurt
> elsewhere \c #define MACOSX
> include-ffi.h-string save-c-prefix-line \ #include <ffi.h>
> \c #include <stdio.h>
> \c static void **gforth_clist;
> \c static void *gforth_ritem;
>
> In other words, it requires gcc at run time unless you made some magic
> rollover.
Scroll back a bit:
c-library libffi
This will try to load the c library for the interface, and only when it's
not there, it will compile the C code. Since during the build process, this
is already compiled, it will not use the C compiler. This is even
documented.
Anton Ertl
>What other publicly available, large sized, FORTH applications are there?
Some of them are collected in the application benchmark suite:
http://www.complang.tuwien.ac.at/forth/appbench.zip
Brew is particularly large.
You can find other applications through
http://www.complang.tuwien.ac.at/forth/program-links.html
Robert Epprecht
> "Rod Pemberton" <do_no...@nohavenot.cmm> writes:
>>What other publicly available, large sized, FORTH applications are there?
>
> Some of them are collected in the application benchmark suite:
> http://www.complang.tuwien.ac.at/forth/appbench.zip
>
> Brew is particularly large.
The brew version in the application benchmark suite is very old, btw.
There is a newer version on http://reppre51.home.solnet.ch/
Robert Epprecht
Aleksej Saushev
> Aleksej Saushev wrote:
>> savesys.fs is signed by your initials, if I understand it right.
>> What are meta-programming concepts used there?
>> Same with search.fs, string.fs, tasker.fs, several sieve benchmarks.
>> Have I started from the long letter?
>
> Try regexp.fs. And even tasker.fs contains a small amount of meta-
> programming:
>
> :noname ' >body @ ;
> :noname ' >body @ postpone literal ;
> interpret/compile: user' ( 'user' -- n )
> \G USER' computes the task offset of a user variable
>
> Just look for postpone and does> to find little meta-programming.
I don't consider this "meta-programming". Even if you do so,
it is used because bare Forth is too weak in this area.
regexp.fs makes it 1 file of 5 or more.
>>>> First, how do I check it if this "million LoC" isn't available?
>>>
>>> By extrapolation: 400 850000 17000 */ . 20000 ok
>>>
>>> So when it takes 400ms for 17kLoC on VFX, it takes 20s for 850kLoC.
>>> Stephen reported that, so the extrapolation seems to be surprisingly
>>> good.
>>
>> This extrapolation is invalid, in larger project you get into non-linear
>> area where you have to spend more resources on organizational matters. You
>> can write long program in a single text file, but this has major drawbacks
>> people try to avoid.
>
> You dismiss an extrapolation that *worked*. I.e. the extrapolated number
> matches observation. I suppose the overhead is constant per LoC - e.g.
> splitting CCS in many more files than MINOS will not result in higher
> overhead per LoC, since the average file size is probably the same.
It is to be dismissed. If extrapolation works in one case and doesn't in
another one, you didn't present enough evidence. I showed you that C is
used in larger projects, where only amount of C code is (decimal) order
of magnitude larger than in your cases. Order of magnitude changes
everything sometimes.
>> Yes, and that's what I tell you, it worked till some moment between 10.
>> Oct and 15 Nov. Something broke in between, and there are too many
>> subsystems involved to claim Forth is simple and easy to understand.
>
> If you want to prove by example that my point "A Forth system is simple" is
> a lie, than you picked the wrong example. You just proved that C is
> complex, and even interfacing to C is a nightmare. Full agreement from my
> side.
You're trying to represent it as if it is because C part is complex. Let's see.
I modify libffi.fs a bit:
--- libffi.fs.bak 2009-11-25 14:23:19.000000000 +0300
+++ libffi.fs 2009-11-27 14:27:09.000000000 +0300
@@ -312,7 +312,7 @@
cifbuf cell+ cifbuf @ over - ;
: create-cif ( rtype -- addr ) cif,
- cif@ cifs search-wordlist
+ cif@ cifs wordlist-words cr cifs search-wordlist
IF execute EXIT THEN
get-current >r cifs set-current
cif@ nextname Create here >r
Now I run my tests and observe:
^L^L
^F^F ^L^L
^F^F ^L^L
^F^F ^L^L
^F^F ^L^L
^F^F^F^F ^F^F ^L^L
^F^L^F^F ^F^F^F^F ^F^F ^L^L
^F^L^L ^F^L^F^F ^F^F^F^F ^F^F ^L^L
where "^F" and "^L" are ASCII control characters ACK and FF respectively.
And I see them _only_ when I use that "broken" by your opinion teletype
interface. When I use anything closer to VT100/VT220, which you consider
the only "non-broken" one, I cannot see anything, blank space only.
Does the code in consideration do anything that low level? No.
Is that low level hack really needed? No.
Is it simple? Hell, no!
I'd have orders of magnitude less chances to notice that,
if I hadn't pushed you to comply to common accepted standards in past.
Maybe it is a clever hack, but it isn't documented as such.
>> libffi.fs reads:
>>
>> \ The ffi.h of XCode needs the following line, and it should not hurt
>> elsewhere \c #define MACOSX
>> include-ffi.h-string save-c-prefix-line \ #include <ffi.h>
>> \c #include <stdio.h>
>> \c static void **gforth_clist;
>> \c static void *gforth_ritem;
>>
>> In other words, it requires gcc at run time unless you made some magic
>> rollover.
>
> Scroll back a bit:
>
> c-library libffi
>
> This will try to load the c library for the interface, and only when it's
> not there, it will compile the C code. Since during the build process, this
> is already compiled, it will not use the C compiler. This is even
> documented.
How is it documented? Comments read:
\ replacements for former primitives
\ note that the API functions have their arguments reversed and other
\ deviations.
That's all on the matter.
JFYI, my tests make me think that FFI rots away with run time, similar
to what marker did recently. I.e. it stops working after some point
rather than on specific functions.
--
HE CE3OH...
Bernd Paysan
> How is it documented?
Maybe you should read the documentation, not the source code ;-). Go to
"Defining library interfaces" in the documentation.
I probably tend to agree with Stephen, that the source and the documentation
really should be one and only one file, because then it's easier to find the
documentation when you are only looking at the source.
Rod Pemberton
news:hYadnZndwYyY25fW...@supernews.com...
> >> iForth with an analytic compiler *feels* exactly like an old Forth with
> >> a threaded code interpreter, apart of some details like how big a
> >> number
> >> can be. You type in your definitions at the prompt, and you can invoke
> >> them right after. It's called "incremental compiler", and it doesn't
> >> need a program-compile-run loop. Its so fast that you don't care about
> >> the compile speed. You can compile some large library like MINOS in
> >> 0.1s on bigForth (peephole optimized native code), or on 0.4s on VFX
> >> (analytic optimized native code).
> >>
> >
> >
> > Yes, that's an old technique of interpreters. The Microsoft BASIC
> > interpreter in the C64 roms used the exact same method (1982). As a
> > return
> > was entered, the line of C64 BASIC was parsed, tokenized, converted into
> > bytecodes, and inserted into the proper location within the BASIC
> > program.
> > When the bytecode was encountered during execution, it was used as an
> > offset
> > into a pre-compiled table of addresses. Each address in the table was
> > for a
> > BASIC function to be called. I.e., the C64's BASIC bytecode interpreter
> > was
> > what FORTHers know as TTC (Token Threaded Code). The method is very
> > similar
> > to ITC (Indirect Threaded Code) except a bytecode is used instead of an
> > address. It's likely the technique was in use earlier especially since
> > Microsoft was producing BASIC in the mid 1970's for other early personal
> > computers. So, it was probably even older than that. Where was the
> > technique used first? I don't know.
>
> Token-threaded Forths are very rare.
So? Nothing to do with my statements...
> Token-threaded Forths are very rare.
But, yes, I'd doubt TTC was ever used as a FORTH interpreter. How does one
add words to the dictionary with a fixed size address lookup table?
> ITC, the original and classic
> Forth implementation strategy is significantly faster, comparable (as I
> said elsewhere) to a subroutine call without the overhead of parameter
> passing.
I'm not sure why you continue to imply there is a huge distinction between
ITC and TTC (and/or bytecode). You should know their basic implementation
is almost identical. There are only a handful instructions needed to
implement either one. In ITC, one needs two addresses to perform a
subroutine call. The first is used for an indirect lookup of the second.
In TTC, one needs a byte and an address to perform subroutine call. The
byte is used an offset for a table lookup for the second. Of the
interpreters, STC is usually the fastest. It's the only one supported
natively by the host hardware. Because STC is supported natively, one could
debate that STC is not "interpreted" code at all. The other methods must be
emulated in software, i.e., should be slower than STC. Of the three methods
that clearly are interpreted (DTC, STC, TTC), DTC has the fewest steps
needed to call a subroutine. I.e., DTC should be faster than STC and TTC on
most micro's. If I had to guess whether STC or TTC was faster, I'd guess
TTC, but they are both likely to be very close. However, TTC has more
potential for optimization.
> The ITC
> strategy was not based on BASIC (at the time Chuck developed it, in
> 1970, he hadn't seen a BASIC).
The technique in question was "incremental compiler".
Rod Pemberton
Andrew Haley
> > Token-threaded Forths are very rare.
> But, yes, I'd doubt TTC was ever used as a FORTH interpreter. How
> does one add words to the dictionary with a fixed size address
> lookup table?
Well, just as dictionary size imposes a limt on the amount of code, so
token table size imposes a limit on the number of words. I've done it
on an 8051 (which had 4k of program memory.) I allocated 512 bytes
for tokens, which was more than enough. Also, I made the table
zero-based to save code and make NEXT faster, even though the first
part of program memory can't be used for the token table. This meant
that a few potential tokens were wasted, but it really didn't matter.
> > ITC, the original and classic Forth implementation strategy is
> > significantly faster, comparable (as I said elsewhere) to a
> > subroutine call without the overhead of parameter passing.
> I'm not sure why you continue to imply there is a huge distinction
> between ITC and TTC (and/or bytecode). You should know their basic
> implementation is almost identical. There are only a handful
> instructions needed to implement either one. In ITC, one needs two
> addresses to perform a subroutine call. The first is used for an
> indirect lookup of the second. In TTC, one needs a byte and an
> address to perform subroutine call.
That's direct token threading: there is also an indirect variant which
combines indirect threaded code with tokens.
Andrew.
Stephen Pelc
<do_no...@nohavenot.cmm> wrote:
>Of the three methods
>that clearly are interpreted (DTC, STC, TTC), DTC has the fewest steps
>needed to call a subroutine. I.e., DTC should be faster than STC and TTC on
>most micro's. If I had to guess whether STC or TTC was faster, I'd guess
>TTC, but they are both likely to be very close. However, TTC has more
>potential for optimization.
The numbers may surprise you. Back in the 1970s and 1980s, the DTC
approach was marginally faster than STC when calling primitives. Yes,
the DTC NEXT could be faster than a CALL/RET pair. But, especially
in well factored Forth, the colon NEST/UNNEST pair for DTC kills
performance.
In nearly all cases STC is way faster when the impact of colon
NEST and UNNEST is factored in. We *measured* plain STC with no
optimisations as being over twice as fast as DTC on most micros.
And then you can start optimising STC. Once your optimiser is
good enough, there need be no increase in code size. Unoptimised
STC is nearly always larger than DTC.
Unless binary size and/or binary portability across several CPU
families are the driving design requirements, TTC has few advantages.
Despite this, I know of two commercial TTC projects in the last
year or so, both to get round the restrictions of a particular
CPU architecture.
Having designed several tokenised systems (one of which was the
starting point of the OTA project), if I really needed code
portability across a heterogeneous network (multiple CPU
families), I would spend my effort on a Forth source interpreter.
I believe that Mitch Bradley, the architect of Open Firmware,
is of the same opinion.
The numbers show that compressed Forth source is often only
20% larger than the best tokenised binary. The OTA project
demonstrated just how much overhead is required for real
world use of a tokenised system.
Bernd Paysan
> Having designed several tokenised systems (one of which was the
> starting point of the OTA project), if I really needed code
> portability across a heterogeneous network (multiple CPU
> families), I would spend my effort on a Forth source interpreter.
> I believe that Mitch Bradley, the architect of Open Firmware,
> is of the same opinion.
Open Firmware uses tokenized Forth source code. Tokenized source code is
essentially a dictionary-based compression scheme with comment removal. By
just removing comments and then compressing the source with LZ-W/77/MA, you
probably get even better results.
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
> > Exactly: this thing about "programmer must keep track of data on
> > stack" is a myth. I have *never* been able to cope with stack
> > juggling in my head: anything with more than three elements
> > requires me to draw diagrams on a page. I have always striven to
> > avoid ROT, because it's just too confusing. But this is not a
> > problem for anyone writing Forth code: you just avoid stack
> > juggling. It is a problem for anyone reading badly-written Forth
> > code, that's true. But, as I've said here NN times before, bad
> > code is hard to read in any language.
> There's a slight problem with this. I have to think ahead of time
> which values need to go in which order on the stack and when to dup
> swap and spindle them before I actually throw in the words. This is
> insane.
The solution is to write your Forth code so that it doesn't need as
much stack dancing. This takes skill, that's true, but in the long
run it's easier than actually doing the stack dancing, and it's way
easier than having do debug it.
Once common technique is, rather than passing a bunch of items on the
stack, use a struct and pass an address. So, if you have a word that
takes a bunch of 3d co-ordinates (x y z)
: foo ( x y z) rot >r ... over ... dup >r swap dup ... r@ ... barf etc.
do
begin-structure 3d
field: x
field: y
field: z
end-structure
: foo ( 3d) dup x ... dup y ...
or perhaps:
: foo ( 3d) >r r@ x r@ y ...
I remember one truly heoric Forth word that set up a bunch of things
on the stack and ended:
... ! ! ! ;
Now, I know that code was correct and I had no desire to debug it, but
oh my goodness that was hairy.
> Forth behaves like a 1 register machine. I'd be glad to play with a
> register based forth. Would be quite interesting.
You just need to be a bit more patient. If you persist, you'll get
it.
Andrew.
Anton Ertl
>How does one
>add words to the dictionary with a fixed size address lookup table?
One way would be to use primitive-centric code, e.g., an invocation of
a colon definition is compiled into a CALL primitive followed by the
PFA of the colon definition.
Rod Pemberton
news:hf04jd$e76$1...@aioe.org...
> Of the three methods
> that clearly are interpreted (DTC, STC, TTC), DTC has the fewest steps
> needed to call a subroutine. I.e., DTC should be faster than STC and TTC
on
> most micro's. If I had to guess whether STC or TTC was faster, I'd guess
> TTC, but they are both likely to be very close. However, TTC has more
> potential for optimization.
>
Uh, oops... STC in that section should've said ITC.
(No one picked up on the contradictions? Me saying it could be debated that
STC was threaded code just prior to that, and then me saying STC was clearly
interpreted there.)
Sorry,
RP
MarkWills
>on the stack and ended:
> ... ! ! ! ;
Oh no. I have some Forth a bit like that. It is probably terrible. It
is my implementation of DUMP.
<hangs head in shame>
: DUMP ( address length -- )
BASE @
HEX CR
-ROT
2DUP + SWAP DROP SWAP
DO
I I I U. 8 + SWAP
2DUP
DO
I C@ DUP
16 < IF 48 EMIT THEN
U.
LOOP
DO
I C@ EMIT
LOOP
CR
8
+LOOP
BASE ! ;
See that line I I I U. 8 + SWAP
I guess that's evil, right there?
It works though. For example, I can do:
$2000 256 DUMP and I get:
2000 00 fe df 34 82 a1 b9 44 ........
etc etc (i.e. hex on the left, ASCII on the right).
I'm still at the stage where, having got some code like the above to
work, I'm more likely to breathe a huge sigh of relief, and move on
quickly before I break it!
Andrew Haley
> >I remember one truly [ heroic ] Forth word that set up a bunch of things
> <hangs head in shame>
No, sorry. Doesn't even come close to being evil enough. :-)
Andrew.
Josh Grams
>>I remember one truly heroic Forth word that set up a bunch of things
>>on the stack and ended:
>> ... ! ! ! ;
>
> Oh no. I have some Forth a bit like that. It is probably terrible. It
> is my implementation of DUMP.
Nah, that's not bad. Though this line could be simpler:
( addr u ) 2DUP + SWAP DROP SWAP ( addr+u addr )
The usual Forth idiom for that is `OVER + SWAP` (sometimes factored out
as BOUNDS).
> I'm still at the stage where, having got some code like the above to
> work, I'm more likely to breathe a huge sigh of relief, and move on
> quickly before I break it!
I don't know how you attacked this, but I can't help thinking that it
might have been easier if you had factored it further. I tend to
program in bigger chunks in other languages, but my experience with
Forth has been that it is *much* easier and more enjoyable when I break
it into pieces that are simple enough that they're obviously correct (or
at least easily testable). Maybe something like this?
: BOUNDS ( addr u -- addr+u addr ) OVER + SWAP ;
: .2DIGITS ( u -- ) S>D <# # # #> TYPE SPACE ;
: DUMP-DIGITS ( addr u -- ) BOUNDS DO I C@ .2DIGITS LOOP ;
: PRINTABLE ( char -- char' )
DUP 32 128 WITHIN 0= IF DROP [CHAR] . THEN ;
: DUMP-CHARS ( addr u -- ) BOUNDS DO I C@ PRINTABLE EMIT LOOP ;
: DUMP ( addr u -- )
BASE @ >R HEX
CR BOUNDS DO
I U. I 8 2DUP DUMP-DIGITS DUMP-CHARS CR
8 +LOOP
R> BASE ! ;
--Josh
MarkWills
Hi Josh,
Thanks for your helpful comments. Of course, you are correct,
factoring does indeed make it much easier. The reason it isn't
factored is simply because in actuality, the code I presented is
written as mnemonics (actually labels which represent the entry points
into each word) in assembler. Something like this:
E.g. 2DUP + SWAP DROP SWAP would exist in the source code as
data dup2,add,swap,drop,swap (basically a list (a thread) of pointers
to Forth words - classic ITC)
The code is hard burned in ROM (or will be), so it doesn't exist in
source code form, rather in a pre-compiled form (hand compiled by me
as data statements), so there wasn't so much value in factoring it, as
it has no source code - it's hand compiled - write onece and forget.
In addition, each word would require a header which takes extra
memory. I have to fit my entire forth environment in 8K. It's nearly
done and appears to work fine (though I have not tackled DOES yet!) -
just writing an editor for it now. It's interesting that on my target
platform (TMS9900) ITC Forth is pretty much exactly on par in terms of
code density as assembler (in TMS9900 the smallest instruction is 2
bytes, the largest 6, whereas in ITC Forth on the 9900, all Forth
words are two bytes).
But yes, thanks for the pointers. I'll have a look at your code and
digest it! If I can save a few bytes here and there then that is good
news!
Mark