SVFig Talk
Chuck Moore
Neal Bridges
"Chuck Moore" <spi...@mindspring.com> wrote:
> I'm speaking at SVFig May 22. Any suggestions what I should talk
about?
Wish I could make it there for the talk. Were I able to attend, I'd
personally be pleased to hear you talk about whatever is presently most
interesting to you, Forth-wise.
--
Neal Bridges
<http://www.interlog.com/~nbridges/> Home of the Quartus Forth compiler!
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
cLIeNUX user
>In article <7hg209$mq8$1...@nntp3.atl.mindspring.net>,
> "Chuck Moore" <spi...@mindspring.com> wrote:
>> I'm speaking at SVFig May 22. Any suggestions what I should talk
>about?
>
>Wish I could make it there for the talk. Were I able to attend, I'd
>personally be pleased to hear you talk about whatever is presently most
>interesting to you, Forth-wise.
>
from my distant view of what's going on, the most fundamental change
with the MISCs is the address register. Marty Fraeman commented at a
MDFig a few years ago, with some consternation, "It's not Forth."
So the advantages you see with that are of interest. To me personally
especially since my address stack is, I suspect, similar.
Or may have similar tradeoffs.
Rick Hohensee
http://linux01.gwdg.de/~rhohen/H3sm.html
jf...@ricochet.net
r...@cLIeNUX.orp (cLIeNUX user) wrote:
> Ditto. I'd like to add that I think in terms of general implications
> from my distant view of what's going on, the most fundamental change
> with the MISCs is the address register. Marty Fraeman commented at a
> MDFig a few years ago, with some consternation, "It's not Forth."
If you want to see it as closer to the classic Forth virtual machine
I cannot see how the use of memory addressing through the A or R
register makes much of any difference to anyone. If you want to
ignore the potential advantage of autoincrement instructions
replacing a much longer sequence of tradition Forth you can just
think of traditional Forth addressing. If you say "@" the
compiler can generate "A! @A" So it would take ten bits to
represent "@" instead of five, and it adds 2ns. Likewise if
you say "!" the compiler can generate "A! !A" Again it adds
five bits of opcode and 2ns, big deal. Because it takes ten
bits instead of five that makes it not Forth?
Even if you simply ignore all the ways that you can take
advantage of autoincrementing memory addressing instructions
added to the Forth Virtual machine you can still think of it
in the old Forth terms "!" and "@". It is hard to explain to
people who are not familiar with Forth how "!" and "@" are
not a bottleneck. About all you can say is well trust in
the compiler to generate efficient opcodes that will take
advantage of autoincrement type things if it can or don't
worry about it. However Chuck has offered and alternative
by the introduction of a few new primitives. If you ignore
those you miss part of the value. You can ignore that and
still say it is just Forth without those additions. I don't
see how anyway can say that an "A" register in the machine
or the use of "R" for memory addressing or the availability
of autoincrement addresssing instructions in the instruction
set means that "It's not Forth."
I thought Chuck explained it very well in 1x Forth. He
talked about why to do it this way and the potential
advantages. If you choose to limit yourself to a more
traditional Forth dialect the introduction of 2ns time
and five bits of instruction overhead means that "It's
not Forth?"
--
Jeff Fox Ultra Technology
www.UltraTechnology.com
jf...@ricochet.net
"Chuck Moore" <spi...@mindspring.com> wrote:
> I'm speaking at SVFig May 22.
> Any suggestions what I should talk about?
ANS Forth? I don't know if there is time. I know you can cover
what is good in Forth but perhaps there just isn't time
to cover all the abominations in ANS Forth. I have heard
it all before but some other people might listen if you
talk about it to the Forth Interest Group. You have not
said a lot about it in public.
Jonah Thomas
>I'm speaking at SVFig May 22. Any suggestions what I should talk about?
If you have any insights about how to use the general Forth approach to
solve marketing problems (or discover marketing opportunities) that would
be fascinating.
Also any thoughts about how to use the Forth approach for big teams that
must cooperate. My first thought was that by carefully factoring the
responsibilities you might be able to turn big teams into small teams.
But then what do you do with the extra people? People seem to grow
into teams anyway, they don't just follow rules that some boss decides.
How could they be encouraged to factor themselves? And we don't mind
throwing away code while we're factoring, but we don't usually modify
code that's in use at the time, is it possible to change a working
organization and improve it while it's still working?
If your experience with these sorts of topics only tells you some of
what *doesn't* work that would still be fascinating. I'd also be
interested in whatever you've found that does work, to do whatever
you're interested in.
cLIeNUX user
>In article <7hhuer$3rs$1...@news.smart.net>,
> r...@cLIeNUX.orp (cLIeNUX user) wrote:
>
>> Ditto. I'd like to add that I think in terms of general implications
>> from my distant view of what's going on, the most fundamental change
>> with the MISCs is the address register. Marty Fraeman commented at a
>> MDFig a few years ago, with some consternation, "It's not Forth."
>
>If you want to see it as closer to the classic Forth virtual machine
Huh? I don't.
I'm saying it bears repeating.
>talked about why to do it this way and the potential
>advantages. If you choose to limit yourself to a more
>traditional Forth dialect the introduction of 2ns time
>and five bits of instruction overhead means that "It's
>not Forth?"
>
1x Forth. By that you mean your post of the transcript of
that previous talk?
Got a URL for that?
Rick
jf...@ricochet.net
r...@cLIeNUX.orp (cLIeNUX user) wrote:
> >> MDFig a few years ago, with some consternation, "It's not Forth."
> >
> >If you want to see it as closer to the classic Forth virtual machine
>
> Huh? I don't.
I guess that is the point. If you don't want to see something
having someone explain it doesn't help. It you don't want to see
something it is easy to close your eyes or mind.
If you don't want to see Chuck's machines as Forth Machines it
is easy to accept comments by people who think they know more
about Forth than Chuck that what Chuck is doing isn't Forth.
What evidence do you provide for making the statement yourself?
You say that "@" and "!" require ten bits rather than five.
Please give me a reference that explains why that would
disqualify the machine for classification as Forth machine.
You provide the lament that "It's not Forth" with no
explanation as if that were enough to convince people. Perhaps
it is since there are other people repeating things like this
without evidence. I asked for evidence to support this statement,
and I thought I produced evidence to refute your statement.
Your response was, "I don't want to see it." You have no evidence
to present in support of your claim? You don't want to see or
acknowledge the evidence that Chuck or I provide? You are
willing to accept on face value that what Chuck is doing isn't
Forth?
I think it bears repeating again, "What is the definition of
Forth that you are using?" "What evidence do you have to
support your claim?" "Why would you say that it isn't Forth?"
> 1x Forth. By that you mean your post of the transcript of
> that previous talk?
> Got a URL for that?
http://www.ultratechnology.com/1xforth.htm
If you read it after only half was transcribed you might
consider reading it again. Even if you have read it several
times you might consider reading it again.
If you are willing to consider Chuck's position that it is
possible to write good Forth code you might review his
suggestions on what that means. I thought he was very
clear and provided lots of good evidence for this opinions.
If you just don't want to see it then maybe reading it
won't help.
It seems to me to come back to the issue that I raised in Anti-
ANS Forth, that most people simply argue that Forth was
frozen and crystalized twenty years ago and that what
Chuck has been doing since then isn't Forth. These same people
claim that what they are doing is Forth by majority opinion.
Chuck is willing to admit that Forth is what Forth programmers
do rather than what they should do.
IMHO in the old days many people who worked with Forth either
experimented with extending it into a poor version of the
language they were used to using, or they studied the internals
and set about implementing their own subset of Forth called
myForth. It seems to me that this is no longer the case. Today
most people start with a Forth that has been extended 75% to
90% of the way toward another language and all they are interesed
in is completing the transformation. Essentially they are programming
in some other language and a Forth is the application. Chuck would
like to see people use Forth on applications rather than writing
a Forth compiler as an appliction in some other language, or
turning Forth into some other existing language.
Some people might say that Chuck is guilty of playing with Forth
more than applications. I would argue that his changes to his
Forth were just to make the development of applications more
productive and that he has focused most of his programming
on the application. I have lots of evidence to support this
view of his work. He has worked mostly on hardware using his
own tools. He has worked a little in software writing those
tools. An almost insignifigant amount of his time has gone
into writing the Forth tools to write the Forth applications
to make him productive. He has not wasted 20 years just
making his Forth more like other languages.
Many Forth professionals will claim that it has been Forth
amatuers who just play with Forth and don't do applications
and that professional training and professional tools and
a professional mindset are what are needed with Forth. They
may say that Chuck provides a poor example by writing his
own Forth rather than using someone else's professional tools
or going with the ANS standard Forth. People should realize
that the alternatives are paying fees like $20,000 to have
a major software house port their Forth to your machine or
spending a day writing one yourself. In fact the $20,000
was a quote to get their Forth to compile the same code
as generated by the working compiler they were given as
an example. I am sure it would have been more expensive
and taken longer if they would have had to port their
tools without a working example to copy.
Some Forth programmers will say that the biggest and buggiest
Forth systems that they ever used were also the most expensive
and poorest supported ones. These people will say that they are
more productive by writing more of their tools themselves.
I think it is difficult for Chuck to buy software that allows
him to be as productive as software he writes himself. This
is not true for everyone. For most people it makes sense to
buy and use software written by someone with more experience
than you. But the danger is that the size or price of the box
does not always correlate to the quality of the product as we
all know.
If you write 100x or 1000x code you can most certainly benefit
from not writing too much yourself. You might consider learning
to write 1x code as an alternative.
Chuck says he has an improved Forth. He provides lots of evidence
to show that it has been improved. Other people have claimed
that it is not improved but I have to see any evidence in support
of these statements. Some people also claim that it is not
even Forth. Again I have yet to see any evidence for these claims.
Please show me the accepted defintion of Forth that says that
"@" and "!" must be represented in less that ten bits. So
far that seems to be the only evidence you have given to support
your claim that what Chuck is doing isn't Forth. By that argument
only byte token treaded code with less than ten bits to represent
@ and ! may be considered Forth. Is that what you are saying?
Jonah Thomas
> r...@cLIeNUX.orp (cLIeNUX user) wrote:
>> >> MDFig a few years ago, with some consternation, "It's not Forth."
>> >If you want to see it as closer to the classic Forth virtual machine
>> Huh? I don't.
>I guess that is the point. If you don't want to see something
>having someone explain it doesn't help. It you don't want to see
>something it is easy to close your eyes or mind.
>If you don't want to see Chuck's machines as Forth Machines it
>is easy to accept comments by people who think they know more
>about Forth than Chuck that what Chuck is doing isn't Forth.
>What evidence do you provide for making the statement yourself?
>You say that "@" and "!" require ten bits rather than five.
>Please give me a reference that explains why that would
>disqualify the machine for classification as Forth machine.
I think you completely missed Rick's point. Rick quoted Marty Fraeman
as saying it wasn't Forth. Rick himself has expressed an interest in
turning Forth into something new and better, and has shown no interest
in turning Chuck's latest work into a classic oldstyle Forth machine.
It looks to me like you're haranguing the choir for being
demon-worshippers.
Elizabeth D. Rather
>It seems to me to come back to the issue that I raised in Anti-
>ANS Forth, that most people simply argue that Forth was
>frozen and crystalized twenty years ago and that what
>Chuck has been doing since then isn't Forth. These same people
>claim that what they are doing is Forth by majority opinion.
>Chuck is willing to admit that Forth is what Forth programmers
>do rather than what they should do.
I have heard very few people "argue that Forth was frozen and
crystalized twenty years ago." However, there is some conflict
in goals: if a goal is to have Forth be widely used and recognized,
it needs a measure of stability and community involvement; it
can't be defined as "what Chuck is doing this week." Having
worked with Chuck very closely for 10 years, I know that
his strength is in finding new approaches and solutions. Many
of them are wonderful, and we should certainly all pay attention.
But that should be a contributing influence into the evolution
of Forth, not its sole definition.
>IMHO in the old days many people who worked with Forth either
>experimented with extending it into a poor version of the
>language they were used to using, or they studied the internals
>and set about implementing their own subset of Forth called
>myForth. It seems to me that this is no longer the case. Today
>most people start with a Forth that has been extended 75% to
>90% of the way toward another language and all they are interesed
>in is completing the transformation. Essentially they are programming
>in some other language and a Forth is the application. Chuck would
>like to see people use Forth on applications rather than writing
>a Forth compiler as an appliction in some other language, or
>turning Forth into some other existing language.
I suppose you're saying that you're opposed to all the folks
writing Forth in C. Having never used one of those, I can't
comment knowledgably. However, I can say with some
confidence that ANS Forth hasn't gone very far "towards
another language," certainly not "75-90%". Nor have I
seen any strong desire to "turn Forth into some other existing
language" except for occasional fringe posters here who are
just learning Forth and feeling a little discomfort because it
is so different from what they knew before.
>Many Forth professionals will claim that it has been Forth
>amatuers who just play with Forth and don't do applications
>and that professional training and professional tools and
>a professional mindset are what are needed with Forth. They
>may say that Chuck provides a poor example by writing his
>own Forth rather than using someone else's professional tools
>or going with the ANS standard Forth. People should realize
>that the alternatives are paying fees like $20,000 to have
>a major software house port their Forth to your machine or
>spending a day writing one yourself. In fact the $20,000
>was a quote to get their Forth to compile the same code
>as generated by the working compiler they were given as
>an example. I am sure it would have been more expensive
>and taken longer if they would have had to port their
>tools without a working example to copy.
Um, insofar as I believe we may be the folks you're referring
to, I need to clarify a major misunderstanding: we proposed
to write a compiler that could handle your _source_ because
your representative expressed a strong desire to avoid
having to make any changes. We expect the target code would
probably be quite different, probably a lot faster given what
we've seen and heard from you, a compiler many times
faster, and a much simpler development process. That quote
also included documentation considerably beyond what we
were led to believe you have at this point.
It's also fallacious to assume that what you do in house has
no cost. It has costs in the time and energy of your engineers
developing and maintaining home-made tools rather than
devoting their energy to moving your company forward
in its mission.
>Some Forth programmers will say that the biggest and buggiest
>Forth systems that they ever used were also the most expensive
>and poorest supported ones. These people will say that they are
>more productive by writing more of their tools themselves.
Fortunately I haven't heard that said of our systems. ;-)
>I think it is difficult for Chuck to buy software that allows
>him to be as productive as software he writes himself. This
>is not true for everyone. For most people it makes sense to
>buy and use software written by someone with more experience
>than you. But the danger is that the size or price of the box
>does not always correlate to the quality of the product as we
>all know.
>
>If you write 100x or 1000x code you can most certainly benefit
>from not writing too much yourself. You might consider learning
>to write 1x code as an alternative.
True. If Chuck were your only programmer, you'd have little
incentive to go outside. But we've heard a lot from you about
the trials and tribulations of your other programmers, a situation
I think professional tools could help alleviate.
Cheers,
Elizabeth
--
===============================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-372-8493
111 N. Sepulveda Blvd. Fax: +1 310-318-7130
Manhattan Beach, CA 90266
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
===============================================
jf...@ricochet.net
"Elizabeth D. Rather" <era...@forth.com> wrote:
> I have heard very few people "argue that Forth was frozen and
> crystalized twenty years ago."
I was refering to the thread that comes up here all the time
and is in the FAQ, the misconception that Forth was defined
many years ago and hasn't changed. In response to this
people point out the evolution of Forth standards, 79, 83,
ANS.
However Chuck has said that the trend was to add more and more
stuff to Forth from other languages. We all agree that it
is a misconception that Forth hasn't changed in twenty years.
However Chuck has said that Forth standards haven't changed
for the better in the last fifteen years since things focused
on ANS and we lost all innovation. The changes he has made
to his Forths was to remove more and stuff that he said
worked it way in from other languages.
> However, there is some conflict
> in goals: if a goal is to have Forth be widely used and recognized,
> it needs a measure of stability and community involvement; it
> can't be defined as "what Chuck is doing this week." Having
I agree completely with the goal part. I simply have objected
when well known people in FIG and c.l.f gloss over the four
stages through which Chuck has taken Forth since he left
Forth Inc. as if none of it ever happened. I suggest
that people should at least check in every four years
which is about how often Chuck has made major changes to Forth
not that I want people to change to "what Chuck is doing this week."
What Chuck has been doing has a clear step by step direction
as I see it from the invention of Forth. Other than the
four stages of making Forth smaller, simpler, and faster
that Chuck has done in the last fifteen years I don't see
any signifigant changes. ANS has been and will continue
to be debated and complexified. I was interested in ANS
fifteen years ago and for years and have implemented versions
and used versions.
I understand that vendors were not entirely supportive of
ANS until everyone got their input and had time to change
their systems and documentation to get behind the standard.
But other than CELLS and a few minor things and major
complexifications I don't see much change from 83.
> worked with Chuck very closely for 10 years, I know that
> his strength is in finding new approaches and solutions. Many
> of them are wonderful, and we should certainly all pay attention.
> But that should be a contributing influence into the evolution
> of Forth, not its sole definition.
I agree. I just object to ANS being the sole definition of Forth
for the last fifteen years and beyond. I just wish people would
check in on what Chuck has done with Forth every few years with
an open mind. As I say from what I have seen there is almost
universal acceptance today that Forth means ANS and I often
read that Chuck doesn't do Forth any more.
> I suppose you're saying that you're opposed to all the folks
> writing Forth in C. Having never used one of those, I can't
I am not opposed to Forth in 'C', as long as it does not become
the standard defintion of Forth. I understand the advantages
in those environments for using part of Forth in 'C' environments.
It is one of the things that Forth can do. Just one. I do
object to the notion that I hear all the time that an ANS Forth
in 'C' is Forth and that Chuck isn't doing Forth any more.
> comment knowledgably. However, I can say with some
> confidence that ANS Forth hasn't gone very far "towards
> another language," certainly not "75-90%". Nor have I
I think Chuck's comments in the 1x Forth interview made me
feel much more strongly about this. I didn't know much about
where all the stuff in Forth came from in the old days. Chuck
mentions all the things that were borrowed from other languages
and people standardized on. He mentions how many of these
things he has removed from Forth. As he says it started out
simple and can be that way again.
> seen any strong desire to "turn Forth into some other existing
> language" except for occasional fringe posters here who are
> just learning Forth and feeling a little discomfort because it
> is so different from what they knew before.
Personally I know that when I first encountered Forth the first
things I did was extend it with "useful" things that I knew
how to do from programming in other languages. I did the things
the way I knew how to do them, Forth is extensible. I have
seen almost everyone else doing this too over the years. It is
a natural thing from what I have seen. I expect you don't
see it at Forth Inc. but that is not the majority either.
When I first started working with Chuck he criticised many of
the things I did. I realized that I had learned how to do
many things from other Forth programmers who like me were
extending Forth to be more like something else simply because
we didn't really know what some of the stuff in Forth was
really there for. I am sure Forth Inc. teaches people this
stuff, but where else can they learn it?
A lot of what has been published on Forth are these kinds of
examples. Almost every aspect of my use of Forth was based
on adding many levels of unneeded complexity before I could
do anything useful. I didn't realize this because I didn't
know how Chuck intented many Forth words to really be used.
Almost all the examples published are of they type.
I have said before that Forth Inc. is in a somewhat unique
position with regard to this. I am sure that people who
work for Forth Inc., or have been trained by Forth Inc.
have been taught many of these things. I am also sure that
most Forth programmers have not been taught this stuff.
As long as there is a standard like ANS that hides the useful
stuff inside of so much other stuff that Forth Inc. will have
lots of opportunity to do programming for other people and
to teach them how to program. Without good training in
classic Forth you can easily generate 10,000x Forth in an
ANS Forth system by following commonly promoted practices.
Forth Inc. does not encourage people to write bad Forth,
you charge people money to teach them how to write good Forth.
In a sense a bad standard benefits Forth Inc. because it
creates a greater need for experts to unravel the complexity
of the standard and avoid all the landmines.
Thank you for explaining that so that other people would not
be confused. I did understand those things myself and I tended
to see things from the same perspective as the Forth Inc.
representatives rather than the view of management at iTV. I have
no doubt that Forth Inc. could have generated higher quality tools
than the ones that were being used, and very possibly at a
lower cost as well. But the point I was making was that it was
not an off the shelf product that is already packaged. Either
you have to hire programmers to write it, hire a firm like Forth
Inc. to write it, or something else. You can't just pick it
up on the shelf.
What I found interesting was that we had two groups of programmers
that were both productive. One group required the compiler that
Forth Inc. saw demoed and could have replaced for a reasonable cost.
I agreed with Forth Inc. that there was lots of opportunity to
do it right and improve it and that it was worth some investment.
The other group of programmers were quite happy with the alternate
tool set that was simple and produced in about a day.
> It's also fallacious to assume that what you do in house has
> no cost. It has costs in the time and energy of your engineers
> developing and maintaining home-made tools rather than
> devoting their energy to moving your company forward
> in its mission.
Agreed. Hey I was one of the people who got paid to write some
of that stuff. I know that what Forth Inc. suggested was a bargain
compared to in house development costs. I am not arguing that
iTV didn't spend more than what Forth Inc. estimated and didn't
end up with a lower quality tool. I am just saying that we
used two sets of tools, one set was complex and expensive and
the other was simple and cheap. Chuck and I just wished we
could have gotten more people to try the simple tools.
> >Some Forth programmers will say that the biggest and buggiest
> >Forth systems that they ever used were also the most expensive
> >and poorest supported ones. These people will say that they are
> >more productive by writing more of their tools themselves.
>
> Fortunately I haven't heard that said of our systems. ;-)
I just like to point out that big and complex and expensive does
not necessarily equate to high quality. Nor does small and cheap
necessarily equate to low quality. It is often the case by not
catagorically.
> >If you write 100x or 1000x code you can most certainly benefit
> >from not writing too much yourself. You might consider learning
> >to write 1x code as an alternative.
>
> True. If Chuck were your only programmer, you'd have little
> incentive to go outside. But we've heard a lot from you about
> the trials and tribulations of your other programmers, a situation
> I think professional tools could help alleviate.
I agree. I think Forth Inc. provides a high quality professional
set of services from tools to training to solutions. It would be
great if everyone interested in Forth could get excellent training
like that from Forth Inc. and avoid writing poor Forth.
Bart Lateur
>It's also fallacious to assume that what you do in house has
>no cost. It has costs in the time and energy of your engineers
>developing and maintaining home-made tools rather than
>devoting their energy to moving your company forward
>in its mission.
Evaluating which tools to buy, has it's cost too.
Bart.
Bernd Paysan
jf...@ricochet.net wrote:
> I understand that vendors were not entirely supportive of
> ANS until everyone got their input and had time to change
> their systems and documentation to get behind the standard.
> But other than CELLS and a few minor things and major
> complexifications I don't see much change from 83.
I think you simply don't understand the reasons for what you call
"complexifications". The reason is that ANS Forth doesn't describe a detailed
virtual machine as Forth-83 did. To convert an existing Forth-83 system to
ANS is simple: just add CELLS, POSTPONE and a few minor things. You can even
make something like cmForth ANS compliant, without great hastles. Perhaps you
have to redefine ] and the interpreter loop, but mostly that's it. ANS Forth
covers a much wider variety of Forth systems as Forth-83 ever did, including
some of Chuck's newer ideas. You have to do some twists here or there, but
basically, even a machine Forth can be ANS compliant (ok, you have to supply
tons of sources for the missing core words, but that's easy).
I've followed Chuck's ideas. I think abandoning source was a mistake. I think
color Forth is to some extend a rehash of some of TeX's basic parser ideas
(although TeX doesn't use colors but displays the escapes as ASCII) mixed with
"syntax highlighting". Oh, cool, but I even don't need syntax highlighting.
Colors IMHO aren't very meaningful. I'm not aware of any character system that
makes use of colors to transport meaning. Ok, there are colored glyphs in some
systems, e.g. old Aegyptean, but they are there for aestetical reasons, and
those glyphs can be written b/w, too (and most of the time they are).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
richard_...@my-dejanews.com
> color Forth is to some extend a rehash of some of TeX's basic parser
ideas
> (although TeX doesn't use colors but displays the escapes as ASCII)
mixed with
> "syntax highlighting". Oh, cool, but I even don't need syntax
highlighting.
> Colors IMHO aren't very meaningful. I'm not aware of any character
system that
Agree on the following point that colours alone should not
dictate/communicate the syntax, however
If you look at a language like Visual Basic.. well the IDE anyway,
hilighting of different types of source with colour improves the
readability of the code (in my opinion)
Using colours when 'see' ing words or listing a dictionary would be
nice ...
Forcing a developer to use colours means you need a specialised editor
(when not in the Forth ide) to reproduce them, or encode them with
escape sequences?? .. it just gets too messy
he...@albany.net
"Chuck Moore" <spi...@mindspring.com> wrote:
> I'm speaking at SVFig May 22. Any suggestions what I should talk about?
>
>
I'd like to see a presentation of Forth on the order of the
1970 paper, leaving out obiter dicta until the question-and-
answer session.
--
Leo Wong
he...@albany.net
http://www.albany.net/~hello/
jf...@ricochet.net
> > color Forth is to some extend a rehash of some of TeX's basic parser
> ideas
Color change is the technique Chuck is currenly using to reduce the
size and complexity of Forth. He has gone to 1K of source and object.
It has made the smallest sharpest scalple for Forth yet. I don't
think of TeX's parser as a simple 1K programming environment. I just
think of Color Forth as Forth, not TeX.
> > (although TeX doesn't use colors but displays the escapes as ASCII)
> mixed with
> > "syntax highlighting". Oh, cool, but I even don't need syntax
> highlighting.
> > Colors IMHO aren't very meaningful. I'm not aware of any character
> system that
> > makes use of colors to transport meaning. ...
Using color to transport meaning is a common practice in Forth in
decompiling words. People seem to have liked it since people
seem to have agreed that color is a very good way to
convey meaning.
> Agree on the following point that colours alone should not
> dictate/communicate the syntax, however
The idea of Color Forth is use color change to replace syntax
to make Forth simpler, faster, and easier to use. As I say
the use of color in decompiling has been commonly accepted.
The use in source is a natural extension. Since people seem
to agree that color helps convey meaning in decompiling I
wonder why they are so resistant to the idea that it might
be useful in source.
> If you look at a language like Visual Basic.. well the IDE anyway,
> hilighting of different types of source with colour improves the
> readability of the code (in my opinion)
exactly.
> Using colours when 'see' ing words or listing a dictionary would be
> nice ...
Again this is common practice. Extending the concept from the
decompiled code back to source seems pretty natural to me. Besides
coveying meaning very effectively it is also the key to making
this Forth smaller, faster, and simpler.
> Forcing a developer to use colours means you need a specialised editor
> (when not in the Forth ide) to reproduce them, or encode them with
> escape sequences?? .. it just gets too messy
You could say that forcing a developer to use : to start a
definition means that you need a specialized editor. It has to
recognize : and know how to setup all the layout and spelling
rules etc. Displaying : is messy and requires a special editor
if you want to think of it that way. Many people do and want
editors that support layout rules, spelling rules, cross
reference rules etc. You think color tokens are messy?
It see two totally different viewpoints. One idea is that an
editor that requires a few lines of code is messy. The other
idea is that an editor that requires that you get a new hard
disk is messy. (yes, I heard about upgrading to a new multi-
gigabyte disk just to support as many different copies of
emacs as one might want for editing different types of files.)
Elizabeth D Rather
>
>I understand that vendors were not entirely supportive of
>ANS until everyone got their input and had time to change
>their systems and documentation to get behind the standard.
>But other than CELLS and a few minor things and major
>complexifications I don't see much change from 83.
On the contrary, all the major vendors except for Miller were
active, supporting members of the ANS Forth process from
the beginning. Ray Duncan dropped out midway because
he went back to medical school and was basically dropping
out of the Forth business except for continuing support to
his existing customer base. But he has re-joined for this
round.
Our membership has consistently been about 1/3 vendors.
Speaking as one, I know the existence of an ANSI/ISO
standard has significantly improved the acceptance of
Forth and Forth products.
>> worked with Chuck very closely for 10 years, I know that
>> his strength is in finding new approaches and solutions. Many
>> of them are wonderful, and we should certainly all pay attention.
>> But that should be a contributing influence into the evolution
>> of Forth, not its sole definition.
>
>I agree. I just object to ANS being the sole definition of Forth
>for the last fifteen years and beyond. I just wish people would
>check in on what Chuck has done with Forth every few years with
>an open mind. As I say from what I have seen there is almost
>universal acceptance today that Forth means ANS and I often
>read that Chuck doesn't do Forth any more.
By definition, a standard defines a baseline of a language.
When Forth entered the public domain via NRAO, and when
FORTH, Inc. accepted the responsibility for supporting customers
and projects over the long haul, an inevitable consequence was
that Forth could no longer be Chuck's property in the sense that
he could define what it is. Indeed, neither can FORTH, Inc.
nor any other single entity.
Insofar as Chuck, we, other vendors, and all the independent
implementors experiment with various approaches and
extensions to the language, we all provide paths through
which it can evolve. This is best done when we have good
means of communication to see what each other is doing.
Your publication of Chuck's remarks helps in this regard,
because he has often not been good at communicating his
ideas to the rest of the community.
It's a little extreme and unkind to say that anyone who
is experimenting with different approaches "isn't Forth,"
although it may certainly be technically accurate to say
it isn't _standard_ Forth.
>> comment knowledgably. However, I can say with some
>> confidence that ANS Forth hasn't gone very far "towards
>> another language," certainly not "75-90%". Nor have I
>
>I think Chuck's comments in the 1x Forth interview made me
>feel much more strongly about this. I didn't know much about
>where all the stuff in Forth came from in the old days. Chuck
>mentions all the things that were borrowed from other languages
>and people standardized on. He mentions how many of these
>things he has removed from Forth. As he says it started out
>simple and can be that way again.
Having been on the scene at the time, I know Chuck borrowed
a lot of ideas from other languages. We should always be
open to take good ideas wherever we find them!
A Forth being used for a project should have whatever is
appropriate to support the project. For example, if the
project needs database tools, they should be available.
An embedded project without such a need shouldn't have
to be burdened with it. This is why ANS Forth was made
modular, most features optional, and even major components
of the CORE wordset can be provided in paper form only.
Chuck has had very little to do with ANS Forth, and I suspect
he may not be really familiar with its present state.
>When I first started working with Chuck he criticised many of
>the things I did. I realized that I had learned how to do
>many things from other Forth programmers who like me were
>extending Forth to be more like something else simply because
>we didn't really know what some of the stuff in Forth was
>really there for. I am sure Forth Inc. teaches people this
>stuff, but where else can they learn it?
We tried to put a lot of this stuff in the Forth Programmer's
Handbook.
>As long as there is a standard like ANS that hides the useful
>stuff inside of so much other stuff that Forth Inc. will have
>lots of opportunity to do programming for other people and
>to teach them how to program. Without good training in
>classic Forth you can easily generate 10,000x Forth in an
>ANS Forth system by following commonly promoted practices.
>
>Forth Inc. does not encourage people to write bad Forth,
>you charge people money to teach them how to write good Forth.
>In a sense a bad standard benefits Forth Inc. because it
>creates a greater need for experts to unravel the complexity
>of the standard and avoid all the landmines.
In the first place, I strongly disagree that ANS Forth is a "bad
standard." In the second, FORTH, Inc. benefits when Forth
programmers succeed, even when they succeed independent
of our company and its products, because every Forth success
is beneficial to the community. We strive, via easy-to-use
products and good documentation to make our customers
independent and successful. People come to us because
we do good work, not because we render them helpless!
Elizabeth D Rather
>In article <7hg209$mq8$1...@nntp3.atl.mindspring.net>,
> "Chuck Moore" <spi...@mindspring.com> wrote:
>> I'm speaking at SVFig May 22.
>> Any suggestions what I should talk about?
>
>what is good in Forth but perhaps there just isn't time
>to cover all the abominations in ANS Forth. I have heard
>it all before but some other people might listen if you
>talk about it to the Forth Interest Group. You have not
>said a lot about it in public.
Last time I dared bring up the subject to Chuck he said he
hadn't read it, and didn't intend to read it, so that might be a
very short talk.
The purpose of standards is to communicate to a broad
base of people so they'll share a common view of the
technology being standardized. Since Chuck designs his
own tools for his own use, such things are irrelevant to
him. That doesn't mean they are "bad" for the purpose
for which they're intended.
Cheers,
Elizabeth
cLIeNUX user
The first time I tried to write my 3-stacker I failed. I did get a front-end
going on a c64. Color was there, for almost nothing, so I used it.
Color was the delimiter for "logical lines" within a visible screen.
Chuck works interactively. Nowadays, in an interpreter, color can be assumed.
I can see where "Forth is ANS Forth in C" can be a bit annoying. However,
something is Forth, and something isn't, independant of what Chuck is up to.
2 stacks, an address register, conditional bits, and other things I'm even
less aware of aren't Forth. Great. One can legitamately unknowingly assume
in Chuck's case that there are improvements in there. In my case, I'm just
very proud that I've done something that nobody calls me on when I say it's
not Forth. Whether it's an improvement or not is a much different matter,
but I don't want anyone calling it Forth, for clarity. For clarity of
distinction between it and the existing popular view of Forth, which ranges
from "ANS in C" to "FigForth for the 6502" or whatever.
Rick Hohensee
euph...@freenet.co.uk
On 1999-05-17 bernd....@gmx.de said:
:I've followed Chuck's ideas. I think abandoning
:source was a mistake. I think color Forth is to some extend a
:rehash of some of TeX's basic parser ideas (although TeX doesn't
:use colors but displays the escapes as ASCII) mixed with "syntax
:highlighting". Oh, cool, but I even don't need syntax highlighting.
:Colors IMHO aren't very meaningful. I'm not aware of any character
:system that makes use of colors to transport meaning. Ok, there are
:colored glyphs in some systems, e.g. old Aegyptean, but they are
:there for aestetical reasons, and those glyphs can be written b/w,
:too (and most of the time they are).
I quite like syntax highlighting, but I don't like colour for two
reasons. Firstly, I'm colourblind. Secondly, it breaks ASCII; I have a
Hercules monitor upstairs, and it's not unreasonable to want to use that
as well, and at some point I might need to plug a VT100 into an embedded
system or use a Kaypro II or something. Fonts don't cut it either, and
different video attributes look ugly, and for a meaningful set of
colours you need at least 5 (define, compile, execute, comment, number)
and you only get 4 with bold and underlined (inverse looks ugly).
Moreover, if you don't make the colour tokens the centrepiece of the
command line system, you waste an opportunity, and end up with a system
with no advantages and a fair amount of weight over a traditional outer
interpreter - especially when you can do the latter with a compilation
pointer and an interpretation pointer.
Therefore one thing puzzles me. Color Forth puts the primitives in
green, so either he isn't inlining them - since green is the 'compile'
colour - or there's still a mechanism akin to cmForth in there somewhere
(ie. immediate words). The fact that he says that IF has to be black
(interpreted) would suggest that even primitives are not inlined (you
can't implement calls by copying a code run on the x86, because of the
relative address); but ; always looks green as well, which suggests the
latter. So, does Chuck highlight primitives, and if so, why are they
green?
What I guess I am saying is that Chuck would appear to have made his
ColorForth rather more complicated than it needs to be. Why?
--
Communa -- you know soft spoken changes nothing
(*sigh* you get what you pay for where ISPs are concerned. note new
email address, account, etc. email is known not to work yet, too
euph...@freenet.co.uk
On 1999-05-17 he...@albany.net said:
:"Chuck Moore" <spi...@mindspring.com> wrote:
:> I'm speaking at SVFig May 22. Any suggestions what I should talk
:> about?
:I'd like to see a presentation of Forth on the order of the
:1970 paper, leaving out obiter dicta until the question-and-
:answer session.
I'd like to see a discussion of the internal workings of ColorForth,
preferably with source. Unless that's already been done. But then, I'm
not going to be there, so my opinion is irrelevant.
Steven Bone
<spi...@mindspring.com> wrote:
>I'm speaking at SVFig May 22. Any suggestions what I should talk about?
>
Topic suggestions for your upcoming SVFIG meeting...
1. Top Ten Commonly Used Forth Words you've been able
to write in Machine Forth at 1X (short and simple)
instead of 10X (long and slow-running).
2. Top Ten Commonly Used Forth Words you've disgarded
or generaly avoid (nX -> 0X).
3. Top Two or Three Forth Programming Concepts that
Machine Forth simplifies or eliminates.
4. The threading method you use in Machine Forth, and why:
\ Jeff has said that threading is not specified. And,
\ looking at the F21 opcodes, it looks like you could do
\ any type (or even do subroutine-call and return with
\ stack frames and temporary variables, like any old
\ processor, if so inclined).
5. More on the User Interface of Color Forth:
a. When you edit a block is it in colors?
Before and after the point you are editing?
b. When doing keyboard input is it in colors?
c. Is the cusor colored ?
d. Is use of colors tied to your use of
space-bar (instead of a CR)?
5. Something on the internals of Color Forth:
a. When you change color, does it do something
one might typically expect, like:
-change wordlist search path?
-search only a specific vocabulary?
-run in a color-specific QUIT loop?
-set a color-STATE variable?
Or some non-typical, improved concept?
b. For an embedded/non-interactive application
is there any color-related stuff happening?
There's a lot of discussion of Machine and Color Forth
on the Ultratechnology web site. Still it seems
like there are alot of "holes" in the info. The above,
and some written examples, could fill them in.
...Looking forward to reading the transcription.
Regards,
Steve Bone
richard_...@my-dejanews.com
> You could say that forcing a developer to use : to start a
> definition means that you need a specialized editor. It has to
I dont think I would,
I'm (in my mind) drawing a disctinction between the global standard of
ASCII text.. ie viewable alphanumerics, - the lowest common(ish)
denominator of computer communication - and other more complex
representations of text.. using colour etc.
> recognize : and know how to setup all the layout and spelling
> rules etc. Displaying : is messy and requires a special editor
Well notepad can display ':' .. ?
> if you want to think of it that way. Many people do and want
> editors that support layout rules, spelling rules, cross
> reference rules etc. You think color tokens are messy?
If theyre not standard and easily communicatable yes...
Look at some of your own transcripts on the UltraTech site, the one on
color forth actually apologises because it cant fully represent in the
document the colours which could be seen on the screen as the examples
were types in. (In places in the transcript the green & black color
distinction is also lost)
>
> ...
Let me qualify 'messy'
Without colour , I can use a simple editor like 'notepad' to edit my
forth source... no IDE, then pass this text file into forth..
The advantage of this simple ASCII representation of the source is i
can post it in emails and the viewer needs no special editor to view it.
Compare with the VB IDE, when in the VB IDE, it colours things for you,
even capitalises words etc, but the resulting source code is saved as
simple single colour ascii text.
As soon as you use colors (or other special formatting) the source
becomes harder to share (I think)
Bernd Paysan
jf...@ricochet.net wrote:
>
> > > color Forth is to some extend a rehash of some of TeX's basic
parser
> > ideas
>
> size and complexity of Forth. He has gone to 1K of source and object.
> It has made the smallest sharpest scalple for Forth yet. I don't
> think of TeX's parser as a simple 1K programming environment. I just
> think of Color Forth as Forth, not TeX.
>
ASCII)
> > mixed with
> > > "syntax highlighting". Oh, cool, but I even don't need syntax
> > highlighting.
> > > Colors IMHO aren't very meaningful. I'm not aware of any character
> > system that
> definition means that you need a specialized editor. It has to
> rules etc. Displaying : is messy and requires a special editor
> editors that support layout rules, spelling rules, cross
> reference rules etc. You think color tokens are messy?
>
> editor that requires a few lines of code is messy. The other
> idea is that an editor that requires that you get a new hard
> disk is messy. (yes, I heard about upgrading to a new multi-
> gigabyte disk just to support as many different copies of
> emacs as one might want for editing different types of files.)
>
> Jeff Fox Ultra Technology
> www.UltraTechnology.com
>
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---
>
--
Bernd Paysan
"If you want it done right, you have to do it
yourself"
http://www.jwdt.com/~paysan/
Bernd Paysan
jf...@ricochet.net wrote:
> Color change is the technique Chuck is currenly using to reduce the
> size and complexity of Forth. He has gone to 1K of source and object.
> It has made the smallest sharpest scalple for Forth yet. I don't
> think of TeX's parser as a simple 1K programming environment. I just
> think of Color Forth as Forth, not TeX.
TeX's parser is really simple. The parts I speak of are one or two pages
long. Most of those pages are comments, anyway. Read "TeX - the
Program", Don doesn't write bloatware. Most of TeX isn't concerned with
parsing, it's a typesetting engine, and a really good one. When I hear
of an XML renderer with "only 1.4MB (compressed)" I really wonder how
TeX gets a lot more functionality (ok, except animated gifs ;-) in a few
hundred KB.
> You could say that forcing a developer to use : to start a
> definition means that you need a specialized editor. It has to
> recognize : and know how to setup all the layout and spelling
> rules etc. Displaying : is messy and requires a special editor
> if you want to think of it that way. Many people do and want
> editors that support layout rules, spelling rules, cross
> reference rules etc. You think color tokens are messy?
Now you have gone completely mad, or I am completely misunderstanding
you. ':' is an ASCII character. It is displayed just as any other
character. Every 1x Forth editor can handle it without even knowing what
it means, a simple TYPE is all you need to display the contents. And
this TYPE handles every character in the same way.
Jeff, if you want people to treat you serious, you sometimes better shut
up. I don't worship idols, so I question what Chuck does. I question it
the same way I question other people's invention, and IMHO Chuck does a
lot of clever things. But he doesn't necessarily always find what I
need. People can look for India and discover Amerika. I follow Chuck's
inventions and copy what I like. I don't like colored sources, not even
syntax highlighting (it is distracting IMHO), so why should I copy this
one? Perhaps it's just a matter of taste, but tastes are different.
Chuck does things for him, personally. I know his vision isn't good.
Using large letters in different colors certainly helps. My vision is
still good. I use small letters all in the same color (black on white).
It's just as if you suggested trading my bike for a wheel-chair.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
jf...@ricochet.net
richard_...@my-dejanews.com wrote:
> If theyre not standard and easily communicatable yes...
> Look at some of your own transcripts on the UltraTech site, the one on
> color forth actually apologises because it cant fully represent in the
> document the colours which could be seen on the screen as the examples
> were types in. (In places in the transcript the green & black color
> distinction is also lost)
The point there was that html documents can specify that this is
red and this is blue, but ultimately it is up to the browser as
to what those mean. Chuck treaks each color and you can try to
do it in html, but you don't even really know if the user has
color at all in his viewer or browser. He may be seeing b/w
with color tags being represented in some other way or not
represented at all.
Color change tags could be ordinary ascii characters, they
are just displayed as a space by the integrated editor. There
are only a few of them. It is just a little bit more than
a few single character named words because they also can
separate other words like a space does. The fact that Chuck
is not using ascii is a similar issue that should not beconfused
with the idea of Color Forth. Color Forth can use ordinary
ascii representation. It just looks better in color.
> Let me qualify 'messy'
>
> Without colour , I can use a simple editor like 'notepad' to edit my
> forth source... no IDE, then pass this text file into forth..
> The advantage of this simple ASCII representation of the source is i
> can post it in emails and the viewer needs no special editor to view
it.
You could edit Color Forth source with notepad, but an editor
with color display would be better. It could be a lot smaller and
simpler than notepad. It takes a few lines of code.
jf...@ricochet.net
Bernd Paysan <bernd....@gmx.de> wrote:
> > You could say that forcing a developer to use : to start a
> > definition means that you need a specialized editor. It has to
> > recognize : and know how to setup all the layout and spelling
> > rules etc. Displaying : is messy and requires a special editor
> > if you want to think of it that way. Many people do and want
> > editors that support layout rules, spelling rules, cross
> > reference rules etc. You think color tokens are messy?
>
> Now you have gone completely mad, or I am completely misunderstanding
Are they mutually exclusive? That is another thread. :-)
Let's look at the point that I was making.
If you are one of those people who is on the opposite end of
computing as Chuck you may have pages of rules for spelling
of words, code layout etc. You may have so many rules in
the way you do Forth that it is handy for you to use tools
that implement these rules. Your editor sees : and recognizes
it and then enforces the proper capitilization rules and
begins the layout of the code for a : defintion etc. These
editors also support colorization of text. They can be
setup to use colorization and layout and spelling rules
for different languages.
I don't know a lot about these editors. I have downloaded some
of them and looked at them. I think someone must be completely
mad to approach Forth that way, but I guess there are a lot
of people doing it because it is one form of "state of the art."
One form of state of the art is to use the most sophisticated
off the shelf tools and know how to get them to do what you
want. The other end of the spectrum is to create your own
tools to do what you want. I am contrasting the people who
require ten copies of eMacs to edit source files to people
who use a few lines of code.
> you. ':' is an ASCII character. It is displayed just as any other
> character. Every 1x Forth editor can handle it without even knowing
Sure it can be. But the point is that people are promoting the
use of editors like emacs setup to recognize : and other Forth
rules in an analogous way to Color Forth useing a RED token
to start a defintion.
Chuck's Color Forth editor doesn't have : for defintions, it
uses the red color change for one word, define name function.
His editor deals with that just as other editors can deal
with : (they don't have to of course)
> what
> it means, a simple TYPE is all you need to display the contents. And
> this TYPE handles every character in the same way.
Well almost the same way...
> Jeff, if you want people to treat you serious,
> you sometimes better shut up.
Then I think people are going to finally start treating me
very seriously very soon. ;-)
> I don't worship idols, so I question what Chuck does.
I don't worship idols either. I also question what Chuck
does. I often argue with him about it. I REALLY don't see
what those two things have to do with one another or why
someone would put them both in the same sentance unless...
> I question it
> the same way I question other people's invention,
> and IMHO Chuck does a
> lot of clever things. But he doesn't necessarily always find what I
> need. People can look for India and discover Amerika. I follow Chuck's
> inventions and copy what I like. I don't like colored sources, not
even
> syntax highlighting (it is distracting IMHO), so why should I copy
this
> one? Perhaps it's just a matter of taste, but tastes are different.
Did I say you should copy it? I just tried to explain that I may
not see it the same way as you or Chuck. I try to explain how I see
it because I feel I see it better than most people. Most people
have not looked at it as much as I have or are looking in the opposite
direction. It is hard to see that way.
> It's just as if you suggested trading my bike for a wheel-chair.
No. I am just asking people to watch where they are going.
Reuben Thomas
>tools to do what you want. I am contrasting the people who
>require ten copies of eMacs to edit source files to people
>who use a few lines of code.
Is there really anyone who uses "ten copies of eMacs to edit source files"?
I very much doubt it. I'm no Emacs fan (I put my inability to get my head
round Emacs down to a character flaw) but one thing you never need is lots
of copies. That is the beauty of it: everything (and I do mean that) in one
(copy of) one program. (Emacs has been accurately described as both a user
environment and a lifestyle. It's just not my sort.)
--
http://www.cl.cam.ac.uk/users/rrt1001/ | certain, a. insufficiently analysed
euph...@freenet.co.uk
On 1999-05-17 r...@cLIeNUX.orp(cLIeNUXuser) said:
:The first time I tried to write my 3-stacker I failed. I did get a
:front-end going on a c64. Color was there, for almost nothing, so I
:used it. Color was the delimiter for "logical lines" within a
:visible screen. Chuck works interactively. Nowadays, in an
:interpreter, color can be assumed.
Nope. How do you specify colour in a system-independent format? How do
you save it in an interchangeable file, even if that file is just a dump
of an area of memory? How many bits? How many bitplanes? Colour may be
assumed inside some interpreters, but certainly not all, and certainly
not between interpreters. About the only thing it's safe to assume
anywhere is ASCII text, otherwise
<html> <head> <title> A header </title> </head>
<body> <h1> My email subject </h1>
this kind of text would be perfectly acceptable everywhere, and wouldn't
in fact annoy the hell out of everyone in quite the way it does. </body>
</html>
(apologies to anyone reading from something interesting ;> )
:I can see where "Forth is ANS Forth in C" can be a bit annoying.
:However, something is Forth, and something isn't, independant of
:what Chuck is up to. 2 stacks, an address register, conditional
I assume this was a typo for 3. 2 stacks are very definitely Forth. :>
:bits, and other things I'm even less aware of aren't Forth. Great.
Chuck's definition of Forth is essentially "two stacks and colon
definitions". Now he's ditched the colon, too. The address register is a
convenience - it makes memory addressing simpler on-chip - which happens
to be useful when explicitly exposed. But you don't have to expose it.
You can say
: @ >A A@ ; : ! >A A! ; : @+ >A A@+ A ; : +! >A A@ nop nop + !A ;
and ignore the A register thereafter. I suspect Chuck thought that's
what he would do, but then he realised how handy it would be.
F21 assembly language may not map in a one-to-one fashion with Forth,
but you'd find very few Forth chips that did. F21 is a hell of a lot
closer than Novix, for example. Seen cmForth? Seen where Chuck says that
DUP is better as a suffix for Novix? And the chips that do usually do it
with microcode and mirrors. It is rather hard to shift a stack by more
than one place at once. The only commonly used Forth primitive that does
it is ! - and A gets rid of that complexity. An alternative is N!, which
leaves the value; but then your data stack has to have access to the
address bus, which is more complex. A is an example of better factoring.
I can't think of anything more Forth than that. :>
cLIeNUX user
>
>
>On 1999-05-17 r...@cLIeNUX.orp(cLIeNUXuser) said:
> :The first time I tried to write my 3-stacker I failed. I did get a
> :front-end going on a c64. Color was there, for almost nothing, so I
> :used it. Color was the delimiter for "logical lines" within a
> :visible screen. Chuck works interactively. Nowadays, in an
> :interpreter, color can be assumed.
>
>Nope. How do you specify colour in a system-independent format? How do
>you save it in an interchangeable file, even if that file is just a dump
>of an area of memory? How many bits? How many bitplanes? Colour may be
>assumed inside some interpreters, but certainly not all, and certainly
>not between interpreters. About the only thing it's safe to assume
>anywhere is ASCII text, otherwise
>
vt102 has color escape sequences. ls --color "just works" via telnet.
Given also that we're talking about defining the system, system independance
is less of an issue. I.E. I mean "in an interpreter we are building" as
opposed to "in any interpreter".
The problem with color is the high incidence of blue-green colorblindness.
However, I still think using color, sparingly, is a valid default behavior
in 1999.
><html> <head> <title> A header </title> </head>
><body> <h1> My email subject </h1>
>this kind of text would be perfectly acceptable everywhere, and wouldn't
>in fact annoy the hell out of everyone in quite the way it does. </body>
></html>
>
>(apologies to anyone reading from something interesting ;> )
>
> :I can see where "Forth is ANS Forth in C" can be a bit annoying.
> :However, something is Forth, and something isn't, independant of
> :what Chuck is up to. 2 stacks, an address register, conditional
>
>I assume this was a typo for 3. 2 stacks are very definitely Forth. :>
>
Actually, that was a thinko for (don't mention that it still has two stacks).
> :bits, and other things I'm even less aware of aren't Forth. Great.
>
>Chuck's definition of Forth is essentially "two stacks and colon
>definitions". Now he's ditched the colon, too. The address register is a
>convenience - it makes memory addressing simpler on-chip - which happens
>to be useful when explicitly exposed. But you don't have to expose it.
>You can say
>
> : @ >A A@ ; : ! >A A! ; : @+ >A A@+ A ; : +! >A A@ nop nop + !A ;
>
>and ignore the A register thereafter. I suspect Chuck thought that's
>what he would do, but then he realised how handy it would be.
>
>F21 assembly language may not map in a one-to-one fashion with Forth,
>but you'd find very few Forth chips that did. F21 is a hell of a lot
>closer than Novix, for example. Seen cmForth? Seen where Chuck says that
>DUP is better as a suffix for Novix? And the chips that do usually do it
>with microcode and mirrors. It is rather hard to shift a stack by more
>than one place at once. The only commonly used Forth primitive that does
>it is ! - and A gets rid of that complexity. An alternative is N!, which
>leaves the value; but then your data stack has to have access to the
>address bus, which is more complex. A is an example of better factoring.
>I can't think of anything more Forth than that. :>
>--
>Communa -- you know soft spoken changes nothing
Sure you can hide it. But it's a fundamental design change, with an
attendant cost even to Chuck, and therefor interesting.
And it's not how little it costs to hide it, the interesting thing is
how much does it cost to emulate it? How big a win is it?
It wants indexing. An adder. Does it want general add? Does it want to
grow into an entire data structure? (That part is particulary interesting
to me, of course.)
Rick
Andrew Haley
: Oh, cool, but I even don't need syntax highlighting. Colors IMHO
: aren't very meaningful. I'm not aware of any character system that
: makes use of colors to transport meaning.
I used to think that, but since I've been using a system which does
full syntax colouring I discover that I no longer look for the syntax
but for the colour. It's certainly quicker to find things when
reading a listing. I can imagine going from that to getting rid of
the punctuation altogether and just using the colour. Sounds good to
me.
Of course, code for exchange with others would still have the
punctuation: it's not a question of how the code is stored, but how
you view it while editing.
Andrew.
Chuck Moore
stack. Cover to cover.
graham telfer
makes the role of a Word obvious and makes reading a printout of the
code easier. Eiffel uses colour very effectively in it's editors. Colour
is nice syntactic sugar. In the end it is not an important matter.
Reading the article on 1x Forth I found Chuck's comments about looping
structures and the depth of the stack more interesting. Talking about
the stack he said that, 'this is the only part of the stack, these first
two elements that you have any business worrying about'. I would like to
go further and say you only need to be concerned with the top of the
stack.
Chuck has started using recursion as his sole looping structure.
Traditionally recursion has been associated with lists.
Recursively a list is the length of the tail of the list + 1 and
The number of elements in a list is the number of elements in the tail
of the list + the Head of the list.
The Head is not just the only accessible element, it is also the only
element you need to have access to. It's a kind of 'just in time
system'. Why bother with anything you don't immediately need?
If you adopt a recursive looping structure then the act of looping
becomes a problem of traversing a data structure recursively.
jf...@ricochet.net
r...@sc3d.org wrote:
> On Tue, 18 May 1999 19:49:30 GMT, jf...@ricochet.net
<jf...@ricochet.net> wrote:
> Is there really anyone who uses "ten copies of eMacs to edit source
files"?
Sure. A Forth programmer told me recently that he got a new
hard disk just to hold as many copies of eMacs as he needs. I
don't just make this stuff up.
> I very much doubt it. I'm no Emacs fan (I put my inability to get my
head
> round Emacs down to a character flaw) but one thing you never need is
lots
> of copies. That is the beauty of it: everything (and I do mean that)
in one
> (copy of) one program. (Emacs has been accurately described as both a
user
> environment and a lifestyle. It's just not my sort.)
One thing I never need is one copy. I don't know why someone
would want one copy for use with Forth, but I was told that there
were differences between versions that make you want to
use one version for this and one version for that. I'll bet
he is reading this.
Bart Lateur
>How do you specify colour in a system-independent format? How do
>you save it in an interchangeable file, even if that file is just a dump
>of an area of memory?
Simple. For example, replace the "red" color token by
<RED>
although you may have clashes if somebody actually uses "<RED>" as a
(different) FORTH word.
Bart.
Jonah Thomas
> <RED>
Yes, but it sounds like the complaint is that it won't just work unchanged.
You have to run a file-conversion utility first.
If it's OK to run a file-conversion utility then you can have source code
in lots of formats, it could be LaTeX or rtf or maybe even Word, and you
just run your conversion to get it into a form your particular text editor
can handle. But if you want your source code to be maximally portable
among text editors with no massaging then you have to use ASCII, plain
ASCII, and you can't do anything fancy with it.
ÔMY-WORDöFIRSTöSECONDöTHIRDěIFöFOURTHěTHENÚ
If somebody wanted to argue that it isn't Forth, this looks like a better
reason than having an address register. Traditionally a Forth text
interpreter was supposed to parse *spaces*. This takes some other kind of
interpreter. But it looks easy to write an interpreter for this in Forth
so I figure we might as well call it Forth.
Bernd Paysan
Jonah Thomas <jeth...@ix.netcom.com> wrote:
> Also any thoughts about how to use the Forth approach for big teams
that
> must cooperate. My first thought was that by carefully factoring the
> responsibilities you might be able to turn big teams into small teams.
> But then what do you do with the extra people? People seem to grow
> into teams anyway, they don't just follow rules that some boss
decides.
> How could they be encouraged to factor themselves? And we don't mind
> throwing away code while we're factoring, but we don't usually modify
> code that's in use at the time, is it possible to change a working
> organization and improve it while it's still working?
Could be interesting. IMHO programming doesn't scale well in many cases.
This isn't Adam Smith's needle-maker example where one needle-maker can
make 20 needles a day, and 10 can make 48000 by specializing. There are
the "pyramid-building" tasks, where one person never could build a
pyramid, because one person isn't strong enough to move a several tons
large stone. Pyramids scale well, upon to the point where people start
waiting for the stones they build on.
The same is true for programming: you stall once you have to wait for
the layers you build on. The traditional way of team management is to
first write a spec so that the other team members can build on code that
has not been written yet, by using a defined interface. But the "rethink
everything" of factoring makes that one hard. You can only rely on an
interface after it has been implemented.
For many programming tasks, the Dilbert rule applies: what can be done
by two can be done by one for half of the costs.
However, there are tasks that can be acomplished faster with a team, but
it's reverse pyramid building here. You start with a narrow foundation,
and put larger (then independent) parts on it. Once you have a Forth,
e.g. porting it to other platforms can be done by separate team members
concurrently - each working on another platform. Or device driver
writing for Linux is another good example. But even then, many device
drivers for a certain device class (e.g. network cards) have been
written by the same person(s). Experience and information exchange is
very important for team work; and once the communication overhead
exceeds the actual work done, you better shrink the team.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Bart Lateur
>But if you want your source code to be maximally portable
>among text editors with no massaging then you have to use ASCII, plain
>ASCII, and you can't do anything fancy with it.
"<RED>" is Ascii.
>ÔMY-WORDöFIRSTöSECONDöTHIRDěIFöFOURTHěTHENÚ
>
>If somebody wanted to argue that it isn't Forth, this looks like a better
>reason than having an address register. Traditionally a Forth text
>interpreter was supposed to parse *spaces*.
So if "Ô" is the "switch to red" marker/space, replace it by " <RED> "
including spaces, and you get
<RED> MY-WORD <BLUE> FIRST <BLUE> SECOND <BLUE> THIRD
<YELLOW> IF <BLUE> FOURTH <YELLOW> THEN <GREEN>
Which may well be interpreted as plain FORTH, provided that those color
labels are immediate words, that switch the state of the interpreter
accordingly.
Bart.
Jonah Thomas
>Jonah Thomas wrote:
>>But if you want your source code to be maximally portable
>>among text editors with no massaging then you have to use ASCII, plain
>>ASCII, and you can't do anything fancy with it.
>>ÔMY-WORDöFIRSTöSECONDöTHIRDěIFöFOURTHěTHENÚ
>>If somebody wanted to argue that it isn't Forth, this looks like a better
>>reason than having an address register. Traditionally a Forth text
>>interpreter was supposed to parse *spaces*.
>So if "Ô" is the "switch to red" marker/space, replace it by " <RED> "
>including spaces, and you get
> <RED> MY-WORD <BLUE> FIRST <BLUE> SECOND <BLUE> THIRD
> <YELLOW> IF <BLUE> FOURTH <YELLOW> THEN <GREEN>
>Which may well be interpreted as plain FORTH, provided that those color
>labels are immediate words, that switch the state of the interpreter
>accordingly.
Yes. And you can make one state be default (probably <BLUE> in this
example) and leave that one out. Do <RED> as : and <GREEN> as ; and
make the convention that all immediate words begin with [ and then you
get
: MY-WORD FIRST SECOND THIRD [IF FORTH [THEN ;
Once you decide it's OK to have a simple Forth file-conversion routine
then the problems just evaporate.
Acereda Macia Jorge
: In article <slrn7k3lp...@persephone.joh.cam.ac.uk>,
: r...@sc3d.org wrote:
: > On Tue, 18 May 1999 19:49:30 GMT, jf...@ricochet.net
: <jf...@ricochet.net> wrote:
: > Is there really anyone who uses "ten copies of eMacs to edit source
: files"?
: Sure. A Forth programmer told me recently that he got a new
: hard disk just to hold as many copies of eMacs as he needs. I
: don't just make this stuff up.
I can't believe it. It's much cheaper to take a weekend to learn
elisp!
: One thing I never need is one copy. I don't know why someone
: would want one copy for use with Forth, but I was told that there
: were differences between versions that make you want to
: use one version for this and one version for that. I'll bet
: he is reading this.
As many software products, Emacs introduces some incompatible changes
from version to version, adds/removes/replaces some elisp functions or
things like that. Installing another copy of Emacs just to run a
newer/older script is not the way to go. Just modify the script to
suit your needs, most often the required changes are minimal.
Jorge
M.Simon
<jeth...@ix.netcom.com> wrote:
>"Chuck Moore" <spi...@mindspring.com> wrote:
>
>>I'm speaking at SVFig May 22. Any suggestions what I should talk about?
>
>If you have any insights about how to use the general Forth approach to
>solve marketing problems (or discover marketing opportunities) that would
>be fascinating.
Marketing FORTH has been one of my interests for a long time.
>Also any thoughts about how to use the Forth approach for big teams that
>must cooperate. My first thought was that by carefully factoring the
>responsibilities you might be able to turn big teams into small teams.
>But then what do you do with the extra people? People seem to grow
>into teams anyway, they don't just follow rules that some boss decides.
FORTH is a tool.
I am 'giving' this tool to other engineers so I don't have to write
any test code.
The engineers doing the testing write their own test programs.
Eliminates a LOT of waste since I don't have to devise code that can
cover every case.
Only the cases important to the testers are covered. By the testers.
I sell it as a hardware scripting language.
William Tanksley
>On 1999-05-17 bernd....@gmx.de said:
> :I've followed Chuck's ideas. I think abandoning
> :source was a mistake.
So does he. He's said so.
>Therefore one thing puzzles me. Color Forth puts the primitives in
>green, so either he isn't inlining them - since green is the 'compile'
>colour - or there's still a mechanism akin to cmForth in there somewhere
>(ie. immediate words). The fact that he says that IF has to be black
>(interpreted) would suggest that even primitives are not inlined (you
>can't implement calls by copying a code run on the x86, because of the
>relative address); but ; always looks green as well, which suggests the
>latter. So, does Chuck highlight primitives, and if so, why are they
>green?
Unless I'm mistaken, the primitives compile directly to P21 assembly, so
they are (in some sense) compiled. I do have to agree with you, though;
the fact that they're treated differently would seem to indicate that,
like IF, they should be executed at compile-time.
Actually, though, come to think of it... Machine forth works by
generating native code. The "primitives" are simply Forth words whose
implementation is a single instruction. Nothing special there.
He does have something he isn't mentioning, though -- gueranteed inlining
of some kind. Good idea, just like gueranteed tail recursion.
--
-William "Billy" Tanksley
"But you shall not escape my iambics."
-- Gaius Valerius Catullus
Jonah Thomas
><jeth...@ix.netcom.com> wrote:
>>If you have any insights about how to use the general Forth approach to
>>solve marketing problems (or discover marketing opportunities) that would
>>be fascinating.
>Marketing FORTH has been one of my interests for a long time.
That's another very interesting topic. What I was asking for was more
about the Forth approach. Just as John Passaniti claims to use the Forth
approach in his C code, getting small well-factored routines that are
easy to test etc, I'm wondering what it would take to use the Forth
approach in management. Is there a way to set up small teams (analogous
to small routines) that interact in simple understandable ways (analogous
to stack comments) and change the interfaces as needed during development
(analogous to Forth testing and revision)?
Michael Losh
>I'm speaking at SVFig May 22. Any suggestions what I should talk about?
>
I sent this rather long list of possible interview questions to Jeff Fox a
long time ago before your current "1x Forth" video interview. (By the way,
I just received a copy... I plan to watch it a few times and that might
stimulate some follow up questions... probably not in time for you imminent
presentation on May 22).
Ok, here is the list. Perhaps of the many items, you can find one or two
interesting ones to add to the talk:
VOICE and INPUT DEVICES
----------
Concerning voice recognition, a while ago you were quoted as saying "I
fail to see that English is a good language to describe things to a
computer." Recently, you said that voice recognition is area you may
look into later. Do you have any ideas on how you would use voice
effectively as a comptuer-human interface? Could a voice-based system
be suitable for programming? What would such a programming session
sound like?
SOFTWARE and PROGRAMMING
--------------------
You have described yourself as a "perfectionist" which is a useful
quality for a programmer, at least if you want to rewrite software to
make it as good as possible. But the commercial world is going full
bore towards pre-built software components and reuse, promoting Visual
Basic and Java as glue languages for quickly slapping together systems.
This leads to very inefficient use of computer resources, but it does
seem to save programmer time and allow mediocre programmers to put
together systems with a lot of functionality. Is it worthwile to
justify the Forth/rewrite-everything approach to the masses in this
age?
How is software different from manufactured items, where a certain
amount of standardization of parts has lead to much cheaper and better
performing products, such as automobiles? Is Forth only appropriate for
the "craftsman" or "chef" programmers?
If someone asked you to develop something like a graphical word
processor (WYSIWYG) for editing and printing formatted text, what would
be your overall approach? Would you prefer to work with other
programmers or alone? How big would your object code be? Would your
answers change much for a graphical web browser?
Your development approach seems to work well for small systems, but what
would you do if you had to develop or design an "enterprise solution"
for a major corporaion supporting very large databases? As an example,
the system has 1000 users for data entry, approval, and mangement;
stores several dozen gigabytes of data in 100+ tables; "must"
generate/display 300 reports for the users; and must automate the flow
of work in well-defined business processes. What hardware would you
recommend for the parts of the system? What software? Would you
recommend a fully custom development? Do you think that current
commercial database management systems are good and justified or
overblown and bloated? Do you think that the client/server
architechtures popular with business are appropriate?
If making a living where no concern at all, what would you work on or do
to occupy your time? Would you consider writing a column again?
--
Mike Losh ml...@tir.com
Paul E. Bennett
al00...@anubis.uji.es "Acereda Macia Jorge" writes:
> jf...@ricochet.net wrote:
>
> : Sure. A Forth programmer told me recently that he got a new
> : hard disk just to hold as many copies of eMacs as he needs. I
> : don't just make this stuff up.
>
> I can't believe it. It's much cheaper to take a weekend to learn
> elisp!
>
> : One thing I never need is one copy. I don't know why someone
> : would want one copy for use with Forth, but I was told that there
> : were differences between versions that make you want to
> : use one version for this and one version for that. I'll bet
> : he is reading this.
>
> As many software products, Emacs introduces some incompatible changes
> from version to version, adds/removes/replaces some elisp functions or
> things like that. Installing another copy of Emacs just to run a
> newer/older script is not the way to go. Just modify the script to
> suit your needs, most often the required changes are minimal.
I, for one, can see a motive in keeping several versions of software around.
As you have stated, when software gets updated you may lose a function or
feature. Whilst many applications/scripts could be altered there is a small
sub-class of applications/scripts which have to undergo lengthy certification
or validation processes and would need to re-run that gauntlet for any change.
--
Paul E. Bennett ................... <p...@tcontec.demon.co.uk>
Forth based HIDECS Consultancy
Tel: +44 (0)7971-620145
Going Forth Safely
euph...@freenet.co.uk
On 1999-05-18 bernd....@gmx.de said:
:TeX's parser is really simple. The parts I speak of are one or two
:pages long. Most of those pages are comments, anyway. Read "TeX -
:the Program", Don doesn't write bloatware. Most of TeX isn't
:concerned with parsing, it's a typesetting engine, and a really
:good one. When I hear of an XML renderer with "only 1.4MB
:(compressed)" I really wonder how TeX gets a lot more functionality
:(ok, except animated gifs ;-) in a few hundred KB.
As you say, Don doesn't write bloatware. On the other hand, TeX would
appear to have done an X-windows, and had the hardware grow into it;
apparently, its largest array has to be 64k of at least 32-bit words
(cf. sbTeX, justifying the sb). I think the quantity of code is actually
rather smaller. A bit like OKAD, I suppose... and Knuth avoids floating
point arithmetic too.
--
Communa -- you know soft spoken changes nothing
(email does work after all
William Tanksley
> "Elizabeth D. Rather" <era...@forth.com> wrote:
>However Chuck has said that the trend was to add more and more
>stuff to Forth from other languages.
As John says, this is not entirely a bad thing. As I say, it's not
obviously good, either ;-).
>We all agree that it
>is a misconception that Forth hasn't changed in twenty years.
>However Chuck has said that Forth standards haven't changed
>for the better in the last fifteen years since things focused
>on ANS and we lost all innovation.
Nonsense. We haven't lost _all_ innovation; instead, uncreative people
like me have been able to use Forth a little more. I think the level of
innovation is about the same (or better); it's just that the resistance to
it is higher because of the greater number of people.
>The changes he has made to his Forths was to remove more and stuff that
>he said worked it way in from other languages.
I see Chuck's work as being pioneering and experimental. He's not afraid
to forge into the unknown -- in fact, he seems very uncomfortable on terra
firma. I think that's _really_ cool, and I always read everything I can
find from him.
I've always been a little puzzled by people saying "I like Chuck, but his
work is a bit strange." Get used to it -- that's Chuck. I hope he never
stops, and I hope he makes enough money to follow through, and then I hope
he gets just enough idle time to write up his results for us ;-). I don't
have the resources to investigate his ideas (I've got enough of my own),
so I'm depending on him to investigate.
>> However, there is some conflict
>> in goals: if a goal is to have Forth be widely used and recognized,
>> it needs a measure of stability and community involvement; it
>> can't be defined as "what Chuck is doing this week." Having
>I agree completely with the goal part. I simply have objected
>when well known people in FIG and c.l.f gloss over the four
>stages through which Chuck has taken Forth since he left
>Forth Inc. as if none of it ever happened. I suggest
>that people should at least check in every four years
>which is about how often Chuck has made major changes to Forth
>not that I want people to change to "what Chuck is doing this week."
It's been kinda hard to do this in the past. Thanks for the website.
>universal acceptance today that Forth means ANS and I often
>read that Chuck doesn't do Forth any more.
Don't be too offended -- this is what he himself said about OKAD.
Remember? No source means no Forth. He decided it was a bad idea and
abandoned it, but the quote lingers on (yuck).
Unfortunate hyperbole, but such things are catchy.
>Personally I know that when I first encountered Forth the first
>things I did was extend it with "useful" things that I knew
>how to do from programming in other languages. I did the things
>the way I knew how to do them, Forth is extensible. I have
>seen almost everyone else doing this too over the years. It is
>a natural thing from what I have seen. I expect you don't
>see it at Forth Inc. but that is not the majority either.
Yes, true. I remember writing that OO extension... I'm glad it got lost
in the Great Disk Crash :-).
>When I first started working with Chuck he criticised many of
>the things I did. I realized that I had learned how to do
>many things from other Forth programmers who like me were
>extending Forth to be more like something else simply because
>we didn't really know what some of the stuff in Forth was
>really there for. I am sure Forth Inc. teaches people this
>stuff, but where else can they learn it?
THIS is the question. Do you have an answer? Chuck and you mention some
interesting stuff sometimes, but is there anywhere we can learn the
straight goods? How can we look at something and say, "This is Forth,"
and at another thing and say, "This is not Forth."?
Better yet, how can we write True Forth?
If there's no answer, we can always continue exploring... But I don't
think there's any room for being impatient with people who couldn't
possibly know any better, or with people who don't believe you because you
haven't presented any evidence.
>Jeff Fox Ultra Technology
Paul E. Bennett
> SOFTWARE and PROGRAMMING
> --------------------
> You have described yourself as a "perfectionist" which is a useful
> quality for a programmer, at least if you want to rewrite software to
> make it as good as possible. But the commercial world is going full
> bore towards pre-built software components and reuse, promoting Visual
> Basic and Java as glue languages for quickly slapping together systems.
> This leads to very inefficient use of computer resources, but it does
> seem to save programmer time and allow mediocre programmers to put
> together systems with a lot of functionality. Is it worthwile to
> justify the Forth/rewrite-everything approach to the masses in this
> age?
I could probably have a reasonable stab at that one which might also be
some sort of spur to others thinking.
The "slap a system together approach" (software object supermarket model)
is probably a goal of the emergent languages but they have not yet got there.
Java, in one form or another, might be considered closer to the goal but
it probably has quite a bit to do yet.
That Forthists are generally more perfectionist might be a big win eventually
as we all learn to produce fully certifiable small software components that
are able to be utilised by a wider army of integrators. Open Firmware is
probably going to be the type of platform we all build on for this if the
vendors still want to keep source to themselves (they provide the byte-codes
data-sheet and a c-of-c for each component). When we learn how to do that sort
of thing effecively as a community we will win-out.
> How is software different from manufactured items, where a certain
> amount of standardization of parts has lead to much cheaper and better
> performing products, such as automobiles? Is Forth only appropriate for
> the "craftsman" or "chef" programmers?
Craftsmen are best placed to produce quality components. The chef programmer
who takes such quality components and strings them together can feel more
comfortable knowing that the components he is using have been properly
assembled. So the answer to that one is surely both. We do need more chef
programmers in this community. Chef programmers will probably eventually
turn into craftsmen.
[%X]
he...@albany.net
wtan...@dolphin.openprojects.net wrote:
> Better yet, how can we write True Forth?
Considering the reviews I'm not one to talk, but what
I liked best about Chuck's 1X Forth presentation was
his saying that:
> The whole point of Forth was that you didn't write programs
> in Forth, you wrote vocabularies in Forth. When you devised
> an application you wrote a hundred words or so that discussed
> the application and you used those hundred words to write a
> one line definition to solve the application. It is not easy
> to find those hundred words, but they exist, they always exist.
It was good to be reminded of Leo Brodie's earlier statement of
this in _Thinking Forth_:
> You shouldn't write any serious application in Forth; as a
> language it's simply not powerful enough. What you _should_
> do is write your own language in Forth (lexicons) to model
> your understanding of the problem, in which you elegantly
> describe its solution.
Forth is words, and proper words in proper places make
the true definition of a Forth style.
--
Leo Wong
he...@albany.net
http://www.albany.net/~hello/
The Forth Ring: http://zForth.com/
Elizabeth D Rather
>On Mon, 17 May 1999 03:14:58 GMT, jf...@ricochet.net wrote:
>> "Elizabeth D. Rather" <era...@forth.com> wrote:
>>We all agree that it
>>is a misconception that Forth hasn't changed in twenty years.
>>However Chuck has said that Forth standards haven't changed
>>for the better in the last fifteen years since things focused
>>on ANS and we lost all innovation.
>
>Nonsense. We haven't lost _all_ innovation; instead, uncreative people
>like me have been able to use Forth a little more. I think the level of
>innovation is about the same (or better); it's just that the resistance to
>it is higher because of the greater number of people.
On the contrary, ANS Forth has freed people to be _more_ innovative,
by removing requirements for specific implementation strategies. On
the whole, today's Forths are faster, tighter, and more powerful as a
result. Remember that FORTH83 mandated a 16-bit cell size,
indirect threading, restrictions on what you could do with IMMEDIATE,
etc. ANS Forth systems have varying cell and character sizes optimized
for the target platform, direct compile-to-code implementations with
excellent optimization strategies, and other excellent innovations,
while maintaining a consistent programming model to support
portable applications.
Cheers,
Elizabeth
John Drake
he...@albany.net wrote:
> In article <7hg209$mq8$1...@nntp3.atl.mindspring.net>,
> "Chuck Moore" <spi...@mindspring.com> wrote:
> > I'm speaking at SVFig May 22. Any suggestions what I should talk about?
> >
> >
> I'd like to see a presentation of Forth on the order of the
> 1970 paper, leaving out obiter dicta until the question-and-
> answer session.
Considering that Chuck's latest work is in the hardware realm, I would like
to see how he would apply MISC hardware and/or concepts to real world
problems. (Similair to how Forth was originally applied to real world
control
problems). I'd like to hear answers to practical questions that keep coming
up like how to interface a 20 bit chip to a 32 bit world? Is that a problem
for using off-the-self RAM or is it not a problem? Also how does the latest
MISC stuff compare to earlier work like the Novix or the ShaBoom chip?
Bruce R. McFarling
...
> Yes. And you can make one state be default (probably <BLUE> in this
> example) and leave that one out. Do <RED> as : and <GREEN> as ; and
> make the convention that all immediate words begin with [ and then you
> get
> : MY-WORD FIRST SECOND THIRD [IF FORTH [THEN ;
> Once you decide it's OK to have a simple Forth file-conversion routine
> then the problems just evaporate.
but <GREEN> can't be ; because ; is the RETURN operation. And
the color token precedes each word of that type as a space
substitute, in which case I would assume that the "interpret
this word" would be the default state, and the "do the compile
action of this word" would be explicit. Maybe ]
: MY-WORD ] FIRST ] SECOND ] THIRD ] IF ] FORTH ] ; ] THEN ]
FOURTH ] ; CONTINUE
--
Virtually,
Bruce McFarling, Newcastle, NSW
ec...@cc.newcastle.edu.au
John Passaniti
Jonah Thomas <jeth...@ix.netcom.com> wrote in message
news:7hv36l$f...@sjx-ixn1.ix.netcom.com...
> That's another very interesting topic. What I was asking
> for was more about the Forth approach. Just as John
> Passaniti claims to use the Forth approach in his C code,
> getting small well-factored routines that are easy to test etc,
Although I sometimes call it the "Forth approach" here and where I
work, it really is nothing more than good software engineering
practice. The way some people talk, the concept of factoring was
invented with Forth! Nonsense. Nothing people say in this newsgroup
about the so-called "Forth approach" is really any different than what
you'll read as "programming virtues" in most computer science
textbooks! Now, it may be true that many programmers don't always
reach those goals, but the better ones certainly try.
The key is knowing how far to go... and when. And although you cited
me, I'm certainly not the only person on the planet who tries to apply
good software engineering practice to my code-- in whatever language
it is I write it in.
> I'm wondering what it would take to use the Forth approach
> in management. Is there a way to set up small teams
> (analogous to small routines) that interact in simple
> understandable ways (analogous to stack comments) and
> change the interfaces as needed during development
> (analogous to Forth testing and revision)?
I think that kind of thing happens in management environments that (a)
have very good internal communications and (b) are very fluid in
assuming responsibilities. And from my experience, many companies may
have one of these attributes, but not both. And it seems to get worse
the larger the company is.
The last place I worked the engineering group was small-- only seven
people. The engineers hired there were multi-disciplinary. I was
originally hired to do application-level code, and then later moved to
writing system-level code, and then later helped with hardware. One
of the hardware guys started off knowing little about programming, but
ended up doing a lot of the DSP software. We all fluidly shifted
roles and responsibilities as necessary-- if I was working on
validating some hardware, it might force someone else who normally did
hardware to look at software. Although all of this was driven largely
buy budget constraints, I think it ultimately ended up making our
engineering group very strong. Hardware people had an appreciation of
software, so they didn't design circuitry that was a pain to program.
Software people understood the underlying hardware, so they understood
how to made code that was fast and small.
But ironically, although the group was small, the communications
wasn't very good. Because we were all within earshot of each other,
most of the time we didn't bother to properly document and describe
our work. We would just hop over, say "I'm doing this" and then go
back. But by doing that, when the responsibilities shifted, all that
information needed to shift to the new person, and often that didn't
happen. Details got lost, and ideas that were scrapped because they
can't work were sometimes foolishly repeated because nobody documented
they originally failed.
Now take the current place I work. We have wonderful communications.
We have software in place that can be used to track code back to
requirements. We have procedures for changes and bug fixes to be
communicated to everyone simultaneously, and have those changes and
bug fixes flow properly through management, engineering, test,
documentation, and whoever else needs to be aware of what's going on.
That's good in a company with something like 60 engineers. We have
internal discussion groups and everyone is encouraged to participate.
I was impressed when I started there, because the entire history of
the project was laid out for me, and I could rip through it all and
bring myself up to speed quickly.
But the flaw there is that people aren't very fluid when it comes to
responsibilities. Most of the hardware people *only* do hardware-- if
they touch software at all, it's only to bring up the board so they
can give it to the software people. The software people are in
relatively strict strata. The device driver people only do that. The
communications protocol people only do that. The group I'm in (which
is largely responsible for a web interface on our products) only does
that. People do sometimes dip their toes in other areas, but it's
seldom very deep. I find this frustrating, because I often ask
questions about the underlying hardware, and the other software folks
just look at me like I'm crazy, and the hardware people look at me
like I'm invading their territory. "Why do you need to know that--
here's the interface, just code to that!" Ugh.
So getting back to the notion of using a "Forth approach" to
management, I can easily see it working, but you need to right kind of
people and the right kind of communications. You need people who
don't compartmentalize themselves into tight boxes and say, "this is
what I do, and only what I do." You need communications that keep
everyone in sync.
All this incidentally is one reason why I think that the "silver
bullet" statements that some people offer here are meaningless ("Forth
can reduce the size of your development teams! Forth can speed
development up! Forth executables are insanely small!"). None of
those claims mean much if the team-- no matter how small-- doesn't
communicate well. And none of those claims (especially about space
and/or time efficiency) matters if the people who are coding in Forth
don't understand the underlying hardware-- and if the hardware was
designed with programmers in mind. Put another way, there are larger
reasons why projects succeed or fail than the choice of language.
John Passaniti
<richard_...@my-dejanews.com> wrote in message
news:7hp073$a2s$1...@nnrp1.deja.com...
> If you look at a language like Visual Basic.. well the
> IDE anyway, hilighting of different types of source
> with colour improves the readability of the code (in
> my opinion)
>
> Using colours when 'see' ing words or listing a
> dictionary would be nice ...
I think the point was that color itself is meaningless. If you see
the word "dump" in red, does it mean anything different if it is in
green, blue, or any other color? Syntax-coloring editors may make
variables green, keywords red, and constants blue, but those are
arbitrary choices that the user learns, not that has some innate
cross-cultural significance. Color communicates purpose only through
convention.
The value of Color Forth to me wasn't in the color. The idea was in
using some syntax (in this case a color change) to indicate the
interpreter that is chosen to parse the following word. That's it.
Chuck could have easily used any other syntax, and the idea would be
the same.
John Passaniti
Bernd Paysan <bernd....@gmx.de> wrote in message
news:7hs1pd$d2o$1...@nnrp1.deja.com...
> TeX's parser is really simple. The parts I speak of are one or two
pages
> long. Most of those pages are comments, anyway. Read "TeX - the
> Program", Don doesn't write bloatware. Most of TeX isn't concerned
with
> parsing, it's a typesetting engine, and a really good one. When I
hear
> of an XML renderer with "only 1.4MB (compressed)" I really wonder
how
> TeX gets a lot more functionality (ok, except animated gifs ;-) in a
few
> hundred KB.
Because TeX was written lovingly by Don Knuth as custom software.
Many of the XML applications I've seen use components imported from
other sources. That's not good or bad-- it just is. TeX was written
to stand the test of time. XML is the current fad of the web
community. It doesn't make a lot of sense to build a custom XML
solution until (a) the standard is stable, (b) more people acutally
use XML for a variety of applications, and (c) people care enough
about XML to write custom software.
> Jeff, if you want people to treat you serious, you sometimes better
shut
> up. I don't worship idols, so I question what Chuck does. I question
it
> the same way I question other people's invention, and IMHO Chuck
does a
> lot of clever things. But he doesn't necessarily always find what I
> need. People can look for India and discover Amerika. I follow
Chuck's
> inventions and copy what I like. I don't like colored sources, not
even
> syntax highlighting (it is distracting IMHO), so why should I copy
this
> one? Perhaps it's just a matter of taste, but tastes are different.
Jeff sometimes seems to have an attitude that he brings down the work
from Mount Moore to the teaming masses of unwashed morons. If we
don't see the value in shunning ANS Forth and embrace the latest
quirky minimalist design from Chuck, we're all stupid "10x" (or worse)
programmers. I'm glad to see this seems to annoy you as well.
But I wouldn't complain too much, since you do it too-- only in a
different way. In our discussion about why GNU C was so gosh-darn
large, you missed the point that the methodology used to create GNU C
was part of it's hefty size. And while there may be competing methods
to pull off an optimizing C compiler that you claim might be better,
those are just ideas, while GNU C is a reality that people use for
production code each day. GNU C might not be a thing of beauty, but
it is far better than a theoretical compiler that doesn't exist.
I think the point here is that good software engineering is all about
balancing tradeoffs. Sometimes it seems that the only question people
want to ask in comp.lang.forth is how fast does it run and how much
memory does it take up. Those can be important factors, but sometimes
other questions are more important, like how quickly can you implement
it, and what abstractions can be created that might make the job
easier.
John Passaniti
<euph...@FreeNet.co.uk> wrote in message
news:7hsku7$ra5$3...@news1.cableinet.co.uk...
> Chuck's definition of Forth is essentially "two
> stacks and colon definitions". Now he's ditched
> the colon, too.
I don't understand this. I've seen it from several people. Are
people confusing Chuck's replacement of the *form* of colon
definitions with the *function*? Regardless of it is a ":" or a color
change that invokes a different interpreter, the concept of defining
words really isn't different at all. Chuck still has colon
definitions in Color Forth-- they just aren't colons, and they are
implemented differently than in standard Forth. But the concept
hasn't changed, only the form.
Bruce R. McFarling
> How is software different from manufactured items, where a certain
> amount of standardization of parts has lead to much cheaper and better
> performing products, such as automobiles? Is Forth only appropriate for
> the "craftsman" or "chef" programmers?
This is confusing the design stage of automobiles and programs,
and the
production stage of automobiles and programs. Begin with
whether the people
designing a new model of car and those engineering its
production line are
engaged in a mass production activity. Obviously, they aren't.
The production of a computer program for the mass market is
just as
standardised as the production of an automobile for the mass
market -- more so,
in fact. But the production can't start until the design has
been created by
the programmers.
Jonah Thomas
>Jonah Thomas wrote:
>....
>> Yes. And you can make one state be default (probably <BLUE> in this
>> example) and leave that one out. Do <RED> as : and <GREEN> as ; and
>> make the convention that all immediate words begin with [ and then you
>> get
>> : MY-WORD FIRST SECOND THIRD [IF FORTH [THEN ;
>> Once you decide it's OK to have a simple Forth file-conversion routine
>> then the problems just evaporate.
>but <GREEN> can't be ; because ; is the RETURN operation. And
>the color token precedes each word of that type as a space
>substitute, in which case I would assume that the "interpret
>this word" would be the default state, and the "do the compile
>action of this word" would be explicit. Maybe ]
>: MY-WORD ] FIRST ] SECOND ] THIRD ] IF ] FORTH ] ; ] THEN ]
>FOURTH ] ; CONTINUE
I may have missed the point due to not playing with the original. If you
aren't in a definition and you interpret DUP it's one color, and when you
compile DUP it's a different color? I'd tend to say make the words that
you use the most be the ones with no prefix. Since my source code probably
has more words being compiled than anything else, those are the ones I'd
make default.
It might work to make colon definitions that are being executed be the
default in interpret state. That would make more code look pretty.
It would take a more complicated conversion routine, though, and I
haven't thought out the details.
Anton Ertl
Jonah Thomas <jeth...@ix.netcom.com> writes:
> >: MY-WORD ] FIRST ] SECOND ] THIRD ] IF ] FORTH ] ; ] THEN ]
> >FOURTH ] ; CONTINUE
>
> I may have missed the point due to not playing with the original. If you
> aren't in a definition and you interpret DUP it's one color, and when you
> compile DUP it's a different color? I'd tend to say make the words that
> you use the most be the ones with no prefix. Since my source code probably
> has more words being compiled than anything else, those are the ones I'd
> make default.
But then you would have to introduce an immediate word: [.
> It might work to make colon definitions that are being executed be the
> default in interpret state.
IMO the attraction of the scheme above is that you don't need
different states. It's as if we had only interpret state. The
downside is that we rely a lot on the parsing word ] (which I see as
shorthand for [COMPILE]).
What you propose is having interpret state and compile state again,
and we know where this leads:-/.
The use of colour in Color Forth reminds me of the use of colour or
underlines in presentations about partial evaluation (where the
different execution times are differentiated by different colours).
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Jonah Thomas
>> >: MY-WORD ] FIRST ] SECOND ] THIRD ] IF ] FORTH ] ; ] THEN ]
>> >FOURTH ] ; CONTINUE
>> I may have missed the point due to not playing with the original. If you
>> aren't in a definition and you interpret DUP it's one color, and when you
>> compile DUP it's a different color? I'd tend to say make the words that
>> you use the most be the ones with no prefix. Since my source code probably
>> has more words being compiled than anything else, those are the ones I'd
>> make default.
>But then you would have to introduce an immediate word: [.
Well, it depends. We're looking for a format to display ColorForth code in
ASCII. We can translate it directly, with <RED> etc. I like the idea of
labeling the words that execute during compilation, like [IF [' [DO etc.
You wind up with something that doesn't run on a traditional Forth compiler
without some tweaking to either the code or the compiler, but it's pretty
readable. I think to a beginner it might be more readable because they
could tell what executes while compiling just by looking at it.
Then to handle code that you'd usually do with [ MY-VARIABLE @ COMPUTE ]
you could do [MY-VARIABLE [@ [COMPUTE and it's plain that you're executing
them during compilation. It doesn't look as pretty as the other way but
it's workable, and if you want to introduce [ as immediate (or else execute
it as [[ ) then you can. If you don't have a special [ then you'll need to
change a standard interpreter to compile this because it's no longer enough
to delimit by spaces, the prefix [ has an effect. On the other hand you
could convert your ASCII text back to ColorForth and change your interpreter
to read that.
>IMO the attraction of the scheme above is that you don't need
>different states. It's as if we had only interpret state. The
>downside is that we rely a lot on the parsing word ] (which I see as
>shorthand for [COMPILE]).
Yes. I think the code will look better if you mark the words that execute
instead of marking the words that compile, but it's more straightforward
your way. My way you have to keep track of whether you're inside a
definition or not, and your way you don't. If definitions are short and
obvious that shouldn't be a problem. Your way is conceptually simpler
and I think it will look messier on the page. I think once we agree to
have ColorForth<->ASCII conversion files we can do it as many ways as we
want to, to find out which we like better.
>What you propose is having interpret state and compile state again,
>and we know where this leads:-/.
Yes, we want to avoid that. I'm proposing a notation to write source
code, that should be independent of compilation. And it's only for
situations where you don't want to look at your source code in colors.
euph...@freenet.co.uk
On 1999-05-21 jp...@rochester.rr.com said:
:Minor point:
:> Chuck's definition of Forth is essentially "two
:> stacks and colon definitions". Now he's ditched
:> the colon, too.
:I don't understand this. I've seen it from several people. Are
:people confusing Chuck's replacement of the *form* of colon
:definitions with the *function*?
No, you're confusing a one-liner with a misunderstood concept. I know
perfectly well that he's retained the concept of colon definitions, but
he *has* dropped the colon from them. (So now what do we call them?)
Please, John, grow a sense of humour, in the interest of utilitarianism.
euph...@freenet.co.uk
On 1999-05-21 jp...@rochester.rr.com said:
:The value of Color Forth to me wasn't in the color. The idea was in
:using some syntax (in this case a color change) to indicate the
:interpreter that is chosen to parse the following word. That's it.
:Chuck could have easily used any other syntax, and the idea would be
:the same.
Indeed. Unfortunately by doing that, once of the basic concepts I always
found valuable in Forth went out of the window. There's now a clear
distinction between certain kinds of words - namely, between the colour
change tokens and the dictionary entries. Forth has been reduced to only
about a dozen words, but they're all parsing words.
Call me old-fashioned, but I preferred the other route. It complicated
things slightly because you had to worry about immediacy, but then Lisp
has macros too, and it doesn't seem to bother Lispers much. But the
return on that price seemed much more worthwhile to me, in terms of
clarity, phrasing, and just general good taste. Nor did it break ASCII.
Jerry Avins
Although you are right by and large, "design for production" keeps the
production stage in mind from the inception of a project and can bring a
large dividend. Consider the average color ink jet printer. Its
subassemblies snap together, and then snap into a frame that is just
flexible enough to accept them but rigid enough to be a robust
enclosure. It typically contains fewer than half a dozen screws, and
costs less to produce than one pays for a pair of replacement ink
cartridges. When the IBM Selectric was selling for the better part of a
thousand dollars, its production cost was fifty dollars; not the
incremental cost, but the amortized cost of design, tooling, and labor.
That cannot be achieved by thinking that one will cross the production
bridge when one comes to it.
Jerry
--
Engineering is the art | Let's talk about what
of making what you want | you need; you may see
from things you can get. | how to do without it.
---------------------------------------------------------
John Passaniti
<euph...@FreeNet.co.uk> wrote in message
news:7i4qef$ioc$1...@news1.cableinet.co.uk...
> :I don't understand this. I've seen it from several people. Are
> :people confusing Chuck's replacement of the *form* of colon
> :definitions with the *function*?
>
> No, you're confusing a one-liner with a misunderstood concept. I
know
> perfectly well that he's retained the concept of colon definitions,
but
> he *has* dropped the colon from them. (So now what do we call them?)
I woud probably just call them definitions.
> Please, John, grow a sense of humour, in the interest of
utilitarianism.
I'm not sure where this came from, unless you were reading some agenda
in my message.
John Passaniti
<euph...@FreeNet.co.uk> wrote in message
news:7i4qem$ioc$5...@news1.cableinet.co.uk...
> On 1999-05-21 jp...@rochester.rr.com said:
> :The value of Color Forth to me wasn't in the color. The idea
was in
> :using some syntax (in this case a color change) to indicate the
> :interpreter that is chosen to parse the following word. That's
it.
> :Chuck could have easily used any other syntax, and the idea
would be
> :the same.
>
> Indeed. Unfortunately by doing that, once of the basic concepts I
always
> found valuable in Forth went out of the window. There's now a clear
> distinction between certain kinds of words - namely, between the
colour
> change tokens and the dictionary entries. Forth has been reduced to
only
> about a dozen words, but they're all parsing words.
As I wrote in the past, I find the concept of Color Forth to be more
valuable than the implementation. For me, Color Forth is more of a
thought experiment than something I would actually want to use. From
it, I've taken the notion of switching interpreters on the fly for
some ideas I'm working on, but I don't see the value in doing this for
Forth itself. For example, I'm currently working on an idea where I
can embed FICL code in web pages, in a manner much like that of Active
Server Pages. The HTML tags actually serve to switch interpreters
between Forth and whatever other language I might want to call.
John Passaniti
Bruce McFarling <ec...@cc.newcastle.edu.au> wrote in message
news:3745f7cf...@seagoon.newcastle.edu.au...
> On Fri, 21 May 1999 00:47:47 -0400, "John Passaniti"
> <jp...@rochester.rr.com> wrote:
>
> >The key is knowing how far to go... and when. And although you
cited
> >me, I'm certainly not the only person on the planet who tries to
apply
> >good software engineering practice to my code-- in whatever
language
> >it is I write it in.
>
made
> in this newsgroup that paying attention to factoring makes for more
> easily tested and maintained C code.
C? It's true of any language.
> And so I'll use the above statement as an opporunity to repeat the
> point that other's have made regarding this: seperating the return
and
> datastacks moves the position of how far to go, and when. If you
> compare well factored Forth code to well factored C code, the
> individual factors in the former should be smaller than the
individual
> factors of the latter.
I didn't intend to start a contest over what language provides the
best support for factoring. I frankly don't care-- the point I was
making that regardless of language, good software engineering practice
is to factor. Forth may make it easier than C (although not all C's
use a combined return and data stack), but that's not terribly
interesting to me. What's more interesting to me is to defer thinking
about the implementation level as long as possible, and make factoring
part of the *design*, not just the implementation.
Bruce McFarling
<jp...@rochester.rr.com> wrote:
>The key is knowing how far to go... and when. And although you cited
>me, I'm certainly not the only person on the planet who tries to apply
>good software engineering practice to my code-- in whatever language
>it is I write it in.
Of course, this is not the first time that we've heard the point made
in this newsgroup that paying attention to factoring makes for more
easily tested and maintained C code.
And so I'll use the above statement as an opporunity to repeat the
point that other's have made regarding this: seperating the return and
datastacks moves the position of how far to go, and when. If you
compare well factored Forth code to well factored C code, the
individual factors in the former should be smaller than the individual
factors of the latter.
(
----------
Virtually,
Bruce McFarling, Newcastle,
ec...@cc.newcastle.edu.au
)
Bruce McFarling
<jp...@rochester.rr.com> wrote:
>Minor point:
>
><euph...@FreeNet.co.uk> wrote in message
>news:7hsku7$ra5$3...@news1.cableinet.co.uk...
>> Chuck's definition of Forth is essentially "two
>> stacks and colon definitions". Now he's ditched
>> the colon, too.
>I don't understand this. I've seen it from several people. Are
>people confusing Chuck's replacement of the *form* of colon
>definitions with the *function*?
Yes, exactly. Chuck still has "colon definitions", he's just ditched
the colon word and "compilation mode" as the way to make them.
Bruce McFarling
<jeth...@ix.netcom.com> wrote:
...
>>: MY-WORD ] FIRST ] SECOND ] THIRD ] IF ] FORTH ] ; ] THEN ]
>>FOURTH ] ; CONTINUE
>I may have missed the point due to not playing with the original. If you
>aren't in a definition and you interpret DUP it's one color, and when you
>compile DUP it's a different color? I'd tend to say make the words that
>you use the most be the ones with no prefix. Since my source code probably
>has more words being compiled than anything else, those are the ones I'd
>make default.
But you don't have to write the prefix. Your block editor
would stay "on" in compile-space and interpret-space mode. But the
above is easier to parse directly, since if you compile, you need an
interpret mode, but if you interpret, you just need one short 'compile
this word' word. And it may as well be ] because that interpreter
can't *stay* in compile mode---no compile mode exists.
>It might work to make colon definitions that are being executed be the
>default in interpret state. That would make more code look pretty.
>It would take a more complicated conversion routine, though, and I
>haven't thought out the details.
The other alternative is to translate non-portable non-printing
characters that act as white space into ASCII white space. The
durable ASCII white-space combinations are:
<!ws><ws>{<ws>...}
<cr><!ws>
<cr><ws!=cr>{<ws!=cr>...}
<cr><cr><!ws>
<cr><cr><ws!=cr>{<ws>...}
I'm not sure that this is enough. <tab> and <ws!=(tab|cr> or not
necesserily durable (the "make file" problem), but if it was, the
problem would be more straightforwrd.
If all words beginning with [ are immediate, then one can say that the
leading [ is stripped, and the word (or literal number?) following is
interpreted even if found in a string that is being compiled. Then
[IF] etc. would be stored as IF] and you don't need POSTPONE for IF --
just write ``IF'' instead of ``[IF''.
these words are interpreted (following double carriage return)
these words are two (single carriage return leaves mode alone)
this is the definition of the word ``this'' [IF ;
and that wasn't the end of the word, this is ;
this is another definition for ``this''
so is this another definition, but this time for ``so''.
and here we are interpreting again.
Jack Brien
> Because TeX was written lovingly by Don Knuth as custom software.
> Many of the XML applications I've seen use components imported from
> other sources. That's not good or bad-- it just is. TeX was written
> to stand the test of time. XML is the current fad of the web
> community. It doesn't make a lot of sense to build a custom XML
> solution until (a) the standard is stable, (b) more people acutally
> use XML for a variety of applications, and (c) people care enough
> about XML to write custom software.
>
I don't know much about XML, but it seems _in principle_ pretty simple
to write an application in Forth to handle XML files. All it has to do
is parse out and evaluate <tags in angle brackets> What it actually did
would be defined in Forth words with the same names as the tags. That
would be very much a quick-and-dirty custom thing. I don't know how you
would transform such a program into a DTD or vice versa...
>
--
Jack Brien
http://www.users.zetnet.co.uk/aborigine/forth.htm
Home of the FigUK website
John Passaniti
Jack Brien <jack...@ballinamallard8.freeserve.co.uk> wrote in
message news:37470B56...@ballinamallard8.freeserve.co.uk...
As with anything, you can write something specific to your application
that will be optimized for what you need, or you can use a more
generic approach which will likely have broader application to a
larger set of problems. Neither approach is right or wrong-- it all
depends on needs.
It is trivial in almost any language to write an XML parser for a
specific application. Since you know the syntax of the tags you'll be
receiving, you also know the data structures you'll likely want to
populate when you receive an XML stream. In this case, you don't need
anything generic. You know what to expect, and you can code exactly
for that. Your code in this case can be extremely small, fast, and
efficient.
However the approach that many XML libraries take (and the reason why
many applications that use such libraries are large) is because they
aren't written for any specific application. They will first use a
DTD or other indirect specification to describe the XML streams that
will be received. Upon receipt, they will accept and store the data
in (typically) a tree-like data structure that may not have a direct
relationship to how your program wants to view it's data.
Both approaches have their value. Writing hard-coded XML parsers for
specific applications is great when you know what to expect, and when
you need the fastest, smallest, and tightest code. Using more generic
libraries is best when you're not sure what to expect, and when you
want a high-level approach to describe data.
m...@intranetsys.com
"John Passaniti" <jp...@rochester.rr.com> wrote:
> Minor point:
>
> <euph...@FreeNet.co.uk> wrote in message
> news:7hsku7$ra5$3...@news1.cableinet.co.uk...
> > Chuck's definition of Forth is essentially "two
> > stacks and colon definitions". Now he's ditched
> > the colon, too.
>
> I don't understand this. I've seen it from several people. Are
> people confusing Chuck's replacement of the *form* of colon
> change that invokes a different interpreter, the concept of defining
> words really isn't different at all. Chuck still has colon
> definitions in Color Forth-- they just aren't colons, and they are
> implemented differently than in standard Forth. But the concept
> hasn't changed, only the form.
Exactly.
I suspect retrofitting my immediate execution Forth with optional color
change token capabilities would be fairly trivial.
A function key is programmed for each color to execute (but not echo)
the appropriate word, ] [ COMPILE etc...
The executed word is not echoed to the console but the current color is
changed.
A console log file has two modes. An ascii mode where
the appropriate word is echoed to the log file thereby storing a normal
text version of the program, and a raw color mode where the raw key
codes are stored.
My Forth can already process either ascii or raw key code files (2
bytes per key) so I won't need any additional code for loading.
Cheers,
Mark W. Humphries
Anton Ertl
ec...@cc.newcastle.edu.au (Bruce McFarling) writes:
[factoring]
> seperating the return and
> datastacks moves the position of how far to go, and when.
I don't think this is important when comparing Forth to C, because C
has no programmer-visible stacks at all.
What does make Forth easier to factor than C is its syntactic
uniformity. Everything is a word, and any sequence of words can be
factored out (let's not consider control structures for a moment).
In contrast, in C you have a pretty comlex syntax that makes the same
things look differently sometimes (e.g., a+i and &a[i]). It also
require that everything is put in local variables and also makes it
more costly to factor in other ways (more typing etc.). It's no wonder
that my typical C function is ten times as long (10-50 lines) a my
typical Forth colon definition (1-5 lines).
Anton Ertl
Jonah Thomas <jeth...@ix.netcom.com> writes:
> If you don't have a special [ then you'll need to
> change a standard interpreter to compile this because it's no longer enough
> to delimit by spaces, the prefix [ has an effect.
Yes, I thought about that approach, too, but of course the other way
round:
No ] -> execute
prefix ] -> compile
prefix ]] -> postpone
More is not needed, because we can postpone postponing words to
achieve more.
You are right, with "]" it looks ugly. So how about using "_"? And of
course with a nice editor, as you proposed, this would be displayed as
colour or underlining or somesuch.
Jonah Thomas
>No ] -> execute
>prefix ] -> compile
>prefix ]] -> postpone
>More is not needed, because we can postpone postponing words to
>achieve more.
Yes! So we need no STATE at all. We need only two immediate words
that can be built into the compiler, and everything else just does
its thing, either it executes, or ] compiles it, or ]] postpones it.
I thought I understood from Jeff Fox that the existing ColorForth
doesn't do it that way. A token sets the color and it stays that
color until some other token sets the color to something else.
But the basic idea still applies. Immediate isn't a property of a
command, it's something you set whenever you want to. You never
have to know whether a word is immediate or what its compilation
behavior is, you just make it do what you want and the source code
*shows* you which it's set to do this time.
Bernd Paysan
> However the approach that many XML libraries take (and the reason why
> many applications that use such libraries are large) is because they
> aren't written for any specific application. They will first use a
> DTD or other indirect specification to describe the XML streams that
> will be received. Upon receipt, they will accept and store the data
> in (typically) a tree-like data structure that may not have a direct
> relationship to how your program wants to view it's data.
Indeed. I still wonder if the Forth approach would be helpful for the
generic XML parser approach. I think first parsing and then interpreting
what you got is the wrong order. First specify your XML tags and *then*
parse the thing. I.e. a Forth XML application may look like
requre xml.fs
$Variable title
$Variable author
$Variable class
Date document-date
nested-tag title title $! ;
nested-tag author author $! ;
structured-tag date
numeric sub-tag day document-date day ! ;
numeric sub-tag month document-date month ! ;
numeric sub-tag year document-date year ! ;
\ beware of year 4G bug!
end-tag
structured-tag document
sub-tag class class $! ;
end-tag
accept-all-tags
: .bib-tex-entry
." @" class $@ type ." {"
author $@ 3 min type document-date year @ 0 .r ." ," cr
.' author = "' author $. .' ",' cr
.' title = "' title $. .' ",' cr
.' year = "' document-date year @ 0 .r .' ",' cr
." }" cr ;
: xml2bibtex ( addr u -- ) parse-xml .bib-tex-entry ;
\ Usage: s" foo.xml" xml2bibtex
This would read web-published articles and extract a bibTeX entry (the
rest, like abstracts, and class-specific tags like publishing journal
etc. is left to the reader ;-).
I don't have to do any XML stuff to do, but I think that what people
need isn't a generic parser, but a parser that is easily tailored to
their specific needs.
The implementation in Forth would be quite simple. You basically look
for XML tags, and if you find one (<xxxx[ >]), you look it up in a
specific dictionary (the tag dictionary). If this is successful, execute
it, if not, execute the error handler (which is set to NOOP with
ACCEPT-ALL-TAGS). Structured tags have associated wordlists for
syntactic elements inside the tag, like <date year="1999" month="5"
day="23">.
I still think this will give you a very small application, which doesn't
contain more weight than just the basic XML scanning and a few Forth
words to handle the tags you are interested in.
> Both approaches have their value. Writing hard-coded XML parsers for
> specific applications is great when you know what to expect, and when
> you need the fastest, smallest, and tightest code. Using more generic
> libraries is best when you're not sure what to expect, and when you
> want a high-level approach to describe data.
IMHO there are two approaches to solve a class of problems: either
provide a small basic framework that can easily be extended to the
application purpose, or provide a huge framework that can easily be
reduced to the application purpose. Your generic XML to DTD approach is
a good illustration of the latter - and reducing to the application
purpose may be more difficult than extending the empty XML parser I
sketched above to what's needed.
My point is that you'd be hard pressed to redo such an approach in a
static language like C. You'd have to recreate the dictionary. People
seem to hate generated code, yet generated code is often a very easy way
to get things working. I would never handwrite a parser, if there is
modest complexity, since I've Gray. This is a parser generator that just
generates executable Forth code.
I don't think I could write a parser by hand much better. Both the
generator and the generated code is small and fast. It beated Anton's
handwritten Gforth primitive converter by orders of magnitude (ok, the
original was written in Emacs Lisp ;-).
For me, bloated code doesn't have any excuse. It means that someone has
taken the wrong turn to solve the problem, and people follow this way
because they are driven by inertia (and inertia is proportional to mass,
thus the more bloated system has more inertia). This approach doesn't
make the program easier to use, it just makes the other (right) approach
look too different to switch over.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Bart Lateur
>However the approach that many XML libraries take (and the reason why
>many applications that use such libraries are large) is because they
>aren't written for any specific application. They will first use a
>DTD or other indirect specification to describe the XML streams that
>will be received.
Hey, what?
The main difference between XML and SGML is that you DON'T NEED a DTD.
Ever. The XML document files are fully self-describing: tags are either
nested (opening AND closing tag), or empty, in which case they are
marked as being empty (a slash just before the closing bracket:
"<sometag/>".
Therefore, an XML parser, even an extremely general one, can be quite
simple.
Compare that to, say, HTML's <p> tag. What follows this tag, is *inside*
the <p> element, until you encounter some tags that cannot possibly be
enclosed inside a <p> element, for example another <p> tag. Then, you
know that this element is closed, and the next one started.
OTOH, <br> is an empty tag. See the difference? No? That is because
there isn't any. You need the DTD to TELL you that these are a different
kind of tags.
Thus, well-behaving HTML parsers must be far more complicated than XML
parsers.
Bart.
John Passaniti
Bart Lateur <bart....@skynet.be> wrote in message
news:374b5f54...@news.skynet.be...
> The main difference between XML and SGML is that you
> DON'T NEED a DTD. Ever. The XML document files are
> fully self-describing: tags are either nested (opening AND
> closing tag), or empty, in which case they are marked as
> being empty (a slash just before the closing bracket:
> "<sometag/>".
>
> Therefore, an XML parser, even an extremely general one,
> can be quite simple.
I probably used the wrong terminology. If it isn't called a DTD, it's
called something else-- a specification of what expected tags an XML
application will use, and if those tags are considered containers for
other tags. This is then usually mapped onto a data structure.
There is a big difference between parsing the actual characters of an
XML stream-- which I agree is easy-- and converting the data the XML
stream describes to be useful for an application.
Bruce R. McFarling
<jeth...@ix.netcom.com> wrote:
>I thought I understood from Jeff Fox that the existing ColorForth
>doesn't do it that way. A token sets the color and it stays that
>color until some other token sets the color to something else.
I didn't catch whether that was in the editor or the compiler. That
is, if the editor continues to use the same token for space until the
color is changed, or if the compiler keeps track.
OTOH, the "state" of the compiler would simply be most recent
color token, so there's very little difference between "use this color
token spacer" and "if this is a color token spacer, use it and store
it, and if it is a space, use the most recent color token spacer."
Anton Ertl
Jonah Thomas <jeth...@ix.netcom.com> writes:
> an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
> >No ] -> execute
> >prefix ] -> compile
> >prefix ]] -> postpone
>
> >More is not needed, because we can postpone postponing words to
> >achieve more.
>
> Yes! So we need no STATE at all.
Yes, that's what I like about it.
> We need only two immediate words
> that can be built into the compiler, and everything else just does
> its thing, either it executes, or ] compiles it, or ]] postpones it.
With ] and ]] these words need not even be immediate, because
everything is interpreted anyway.
However, I don't like parsing words, so I prefer these as interpreter
prefixes. Since we have only depth 0-2 of ]] (not infinite depth), we
can simply use different letters for prefixes:
[ -> execute
_ -> compile
] -> postpone
For experimentation I built a little program that patches the Gforth
text interpreter:
: doword ( ... xt c -- ... )
case
'[ of execute endof
'_ of compile, endof
'] of postpone (compile) , endof
-13 throw
endcase ;
: ]literal[ ( n -- ; compiles: -- n )
postpone literal ;
: donumber ( n c -- ? )
case
'[ of endof
'_ of postpone literal endof
'] of postpone literal postpone ]literal[ endof
-13 throw
endcase ;
: newparser ( c-addr u -- )
over c@ >r
1 /string 2dup find-name ?dup-if ( c-addr1 u1 nt R: c )
nip nip name>comp drop r> doword
else ( c-addr1 u1 R: c )
snumber? -1 = if \ just handle single numbers for now
r> donumber
else
-13 throw
endif
endif ;
: substituteword ( xt1 xt2 -- )
\ xt1 is substituted by xt2
over >body !
dodefer: swap code-address! ;
' compiler ' newparser substituteword
' interpreter ' newparser substituteword
From this point on everything needs to use prefixes. To see how this
looks I have translated a POSTPONE-heavy program to this notation. The
original:
200 constant row-size
row-size cells constant row-byte-size
: gen-innerproduct ( a[row][*] -- xt )
\ xt is of type ( b[*][column] -- n )
\ this would be a candidate for using ]] ... [[
>r :noname r>
0 POSTPONE literal POSTPONE SWAP
row-size 0 do
POSTPONE dup POSTPONE @
dup @ POSTPONE literal POSTPONE * POSTPONE under+
POSTPONE cell+ row-byte-size +
loop
drop
POSTPONE drop POSTPONE ;
;
And here's the new version:
[5 [constant row-size
[row-size [cells [constant row-byte-size
[: gen-innerproduct [( a[row][*] -- xt )
[\ xt is of type ( b[*][column] -- n )
[\ this would be a candidate for using ]] ... [[
_>r _:noname _r>
]0 ]SWAP
_row-size _0 [do
]dup ]@
_dup _@ _literal ]* ]under+
]cell+ _row-byte-size _+
[loop
_drop
]drop _;
[;
This is a kind of best case, but I think I could get used to this.
> I thought I understood from Jeff Fox that the existing ColorForth
> doesn't do it that way.
Probably; it just inspired this idea that I find exciting.
Jack Brien
>
> I probably used the wrong terminology. If it isn't called a DTD, it's
> called something else-- a specification of what expected tags an XML
> application will use, and if those tags are considered containers for
> other tags. This is then usually mapped onto a data structure.
>
> There is a big difference between parsing the actual characters of an
> XML stream-- which I agree is easy-- and converting the data the XML
> stream describes to be useful for an application.
Like I say, I don't know much about XML, but there seems to be two
possible specifications the producer's ("these are the tags my documents
use, and this is what they mean) and the consumer's (these are the parts
of the document I am interested in, and this is what to do with them).
Bernd has given one way of writing the latter which is pretty much in
line with my own thinking.
> However the approach that many XML libraries take (and the reason why
> many applications that use such libraries are large) is because they
> aren't written for any specific application. They will first use a
> DTD or other indirect specification to describe the XML streams that
> will be received. Upon receipt, they will accept and store the data
> in (typically) a tree-like data structure that may not have a direct
> relationship to how your program wants to view it's data.
That makes sense when you have a lot of programs working on the same
data, or sub-sets thereof. You don't want to force them all to parse
the entire file independently. But the process of building a tree looks
to be the same whatever the meaning of the tags or the structure of the
file.
CONTAINER = TAG + list of pointers to (text or container)
Somehow, this reminds me of the structure of a Forth word ;-)
If the application interprets the tags as Forth word according to its
own wordlist, then all that has to be provided in addition are some
generic tree-walking routines.
Some further speculation:
Anything can be ASCII for the purposes of an XML file. You might for
example have a tag <JPG> for a MIME-encoded Jpeg picture (better yet,
use a tag with a more descriptive name, _defined_ using JPG). An
application without a JPG word obviously cannot view or edit the
picture. What it can do, though, is copy it, move it somewhere else in
the tree, or to another tree, or delete it altogether. So you have the
makings of a very useful extensible browser/editor. You need the basic
tree movement functions:
Forward/Back to next/previous item in current container
Cut/Copy/Paste current item
Up close current container - display contents of its parent
Down edit current item - if the tag is unknown then you only
see the
text read/only but you get the opportunity to redefine the tag,
to do something more useful.
The more I think about this, the more I see it as being scalable -
whether dealing with directories or single characters the interface is
the same. It's certainly small and simple enough to be worth
experimenting with.
What else is needed?
John Passaniti
> That makes sense when you have a lot of programs
> working on the same data, or sub-sets thereof. You
> don't want to force them all to parse the entire file
> independently. But the process of building a tree looks
> to be the same whatever the meaning of the tags or the
> structure of the file.
>
> CONTAINER = TAG + list of pointers to (text or container)
>
> Somehow, this reminds me of the structure of a Forth word ;-)
I still think what is being missed here is that parsing XML and
storing an internal representation (such as the one you present) is
only part of what makes an XML application. XML's structure is rigid.
It's designed for easy parsing. So it isn't surprising to me that one
might use your representation of an XML document in Forth. Perl
programmers would probably use nested arrays. Python programmers
would use ordered dictionaries. Lisp programmers would use nested
lists. It goes on and on.
But the next step is the more important one.
Once you have an internal representation of the XML document, you want
to actually do something with it. And one of the first things you'll
want to do is validate your input data. Since XML defines a standard
structure but not content, you have to validate that the data you
received makes sense. Maybe some of the tags you define don't allow
nesting. Maybe some of the tags only have meaning when other tags are
present. What I'm talking about is more the semantics of the data,
not the representation.
My contention is the reason why some of the XML applications are large
are because they have means to specify, enforce, detect, and/or report
the kind of semantics that are required by the XML application.
Again, it makes perfect sense to me that if you have a *specific*
application that has *specific* needs, you can write very small,
extremely efficient code in Forth (or almost any language). That
might make sense for resource-starved environments. But that's not
what was being discussed-- we were discussing applications that are
*generic* that have to have not only the means to represent XML
documents (the easy part), but also represent the semantics of that
XML document.
> Anything can be ASCII for the purposes of an XML file.
> You might for example have a tag <JPG> for a MIME-encoded
> Jpeg picture (better yet, use a tag with a more descriptive name,
> _defined_ using JPG). An application without a JPG word
> obviously cannot view or edit the picture. What it can do, though,
> is copy it, move it somewhere else in the tree, or to another tree,
> or delete it altogether. So you have the makings of a very useful
> extensible browser/editor. [...]
This is why Microsoft, Apple, Sun, IBM, and others are interested in
XML. Since the structure but not the content is defined,
editor/browser applications can manipulate XML documents without much
fear of breaking them. Of course, that depends on treating unknown
data as an atomic unit and not touching what you don't understand, but
it is far better than many of the private binary file formats most
applications tend to use today.
Jack Brien
>
> My contention is the reason why some of the XML applications are large
> are because they have means to specify, enforce, detect, and/or report
> the kind of semantics that are required by the XML application.
Ah yes, the type-checking problem.
>
> Again, it makes perfect sense to me that if you have a *specific*
> application that has *specific* needs, you can write very small,
> extremely efficient code in Forth (or almost any language). That
> might make sense for resource-starved environments. But that's not
> what was being discussed-- we were discussing applications that are
> *generic* that have to have not only the means to represent XML
> documents (the easy part), but also represent the semantics of that
> XML document.
>
I'd need to know a whole lot more about XML before I could decide how
difficult that would be. For now (and perhaps forever) it is the humble
problems that interest me.
> > Anything can be ASCII for the purposes of an XML file.
> > You might for example have a tag <JPG> for a MIME-encoded
> > Jpeg picture (better yet, use a tag with a more descriptive name,
> > _defined_ using JPG). An application without a JPG word
> > obviously cannot view or edit the picture. What it can do, though,
> > is copy it, move it somewhere else in the tree, or to another tree,
> > or delete it altogether. So you have the makings of a very useful
> > extensible browser/editor. [...]
>
> This is why Microsoft, Apple, Sun, IBM, and others are interested in
> XML. Since the structure but not the content is defined,
> editor/browser applications can manipulate XML documents without much
> fear of breaking them. Of course, that depends on treating unknown
> data as an atomic unit and not touching what you don't understand, but
> it is far better than many of the private binary file formats most
> applications tend to use today.
Yes, that is what is most important IMHO, the open and extensible
structure. In fact, the format of any reasonably complex document
resembles a directory more than it does a file. The operations that I
outlined can all be done on files in a directory too, but there is no
natural way of imposing an order on them.
Patrick Chapman
euph...@FreeNet.co.uk wrote:
> On 1999-05-21 jp...@rochester.rr.com said:
> :Minor point:
> :> Chuck's definition of Forth is essentially "two
> :> stacks and colon definitions". Now he's ditched
> :> the colon, too.
>
> :I don't understand this. I've seen it from several people. Are
> :people confusing Chuck's replacement of the *form* of colon
> :definitions with the *function*?
>
> No, you're confusing a one-liner with a misunderstood concept. I know
> perfectly well that he's retained the concept of colon definitions, but
> he *has* dropped the colon from them. (So now what do we call them?)
>
> Please, John, grow a sense of humour, in the interest of utilitarianism.
Patrick Chapman
Patrick Chapman
he...@albany.net
"Chuck Moore" <spi...@mindspring.com> wrote:
> I'm speaking at SVFig May 22. Any suggestions what I should talk
> about?
So...what did you talk about?
--
Leo Wong
he...@albany.net
http://www.albany.net/~hello/
The Forth Ring: http://zForth.com/
Sent via Deja.com http://www.deja.com/
Mark Humphries
he...@albany.net wrote:
> In article <7hg209$mq8$1...@nntp3.atl.mindspring.net>,
> "Chuck Moore" <spi...@mindspring.com> wrote:
>> I'm speaking at SVFig May 22. Any suggestions what I should talk
>> about?
> So...what did you talk about?
Seeing as Chuck is probably too busy to reply right now, could someone
who attended be kind enough to give us a general overview? Thanks.
Cheers,
Mark W. Humphries
Forth Chat Room on ICQ #37160535
he...@albany.net
Mark Humphries <m...@intranetsys.com> wrote:
> Seeing as Chuck is probably too busy to reply right now, could someone
> who attended be kind enough to give us a general overview? Thanks.
>
I'm afraid that, like me, you will have to order the video.
line noise
>In article <7kgkaj$ush$1...@nnrp1.deja.com>,
> Mark Humphries <m...@intranetsys.com> wrote:
>
>> Seeing as Chuck is probably too busy to reply right now, could someone
>> who attended be kind enough to give us a general overview? Thanks.
>>
>
>I'm afraid that, like me, you will have to order the video.
And the adress is... and we make the chequs out to whom?
--
----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCPAjBLsOcAAAED/ArhyRBT+BCUswtoZjflht+IJR1OOv5FiaTJ3lRvXPDfBCAt
a32Z7T+p7PJkEEWz5rnWaUMgNS8bVM0exU9hAjT7frkZogOjZ7z0OyLQRqwuDFAx
RilC0PNvi/8KsDxVU9/pjnQxwEiEWpw1jF0L31YmXSiXKQCvUiUD/HERsCpdABEB
AAG0IUxpbmUgTm9pc2U8T3V0IE9mIFBhcGVyIEAgaWQuY29tPokAlQIFEDBtpuMl
A/xxEbAqXQEBqSgD/Ao9nLK1XflDLrWX/UazWAe2Z3WsiJBJjukSeTgTH8GPNjbq
HCaTOEpX736OmAhGEBntcqYWPe+opbj9IPfLabka+UAYin6xNuhU3vNzx10Bnv59
HnL8L3p2owc2+FY/4tlKkeLvqOo7e9SiAF9ULnlQ4KzPhypIoMqdIDWt8+Sf
=BadZ
-----END PGP PUBLIC KEY BLOCK-----
Mary Murphy and Leo Wong
> And the adress is... and we make the chequs out to whom?
See:http://www.UltraTechnology.com/
Leo Wong
--
jf...@ricochet.net
> Seeing as Chuck is probably too busy to reply right now, could someone
> who attended be kind enough to give us a general overview? Thanks.
On 5/22/99 Chuck Moore did a presentation for the Silicon Valley
Forth Interest Group. I would list his presentation in six sections:
1. The status of the iTV Corporation and and explanation of projected
micro amps per micro meter of transistor width from 1.0 micro to .1
micron and 5 volt to 1.5 volt processes. The numbers also happen to
be mips. Where should he go now that the .8u lines are shut down?
Wouldn't 1000+mips at 1.5V be nice?
2. ANS Forth, the good and bad. What Chuck would add and how it
should be used. He plans to publish a simple explanation of the
ANS document. Comparisons to Machine Forth and Color Forth and
some comments on SDRAM. "ANS Forth documents where Forth was
twenty years ago, we could do more."
3. Color Forth internals, and the 4x3 stack for color transitions.
4. ICE is cool, it is a factor to that 90% to 99% improvement
in code that is available. Systems should interpret, compile, and
execute. Some big systems have lost that ability to interpret. It
is simpler than compiling and executing. Chuck likes the idea of
a 1K Forth that interprets or compiles an application in the blink
of an eye.
5. A detailed Color Forth BMP file example code walk through.
Another example to continue to "prove the point to anyone's
reasonable satisfaction" regarding his outrageous claims about
code size and efficiency.
6. questions and comments from Dr. C. H. Ting, John Rible, John
Carpenter, J. Thomas and others.
Chuck suggested the opportunity sell tee shirts.
He also suggested a FIG uniform. ;-) It should be that butterscotch
color that they make termimals so they could blend in in their
natural environment. Those who do ANS Forth could have white
pipeing, those who do Color Forth could have red and green pipeing
so that one could immediately determine the mix and sophistication
of the audience. John Rible suggested silver and grey pipeing for
FigForth programmers. :-)
Chuck also came back to the ICE theme regarding embedded systems
being mandated to include source. He also covered the idea of
dispelling the User Illusion.
--
Jeff Fox Ultra Technology
www.UltraTechnology.com
Mark Humphries
jf...@ricochet.net wrote:
> In article <7kgkaj$ush$1...@nnrp1.deja.com>,
> Mark Humphries <m...@intranetsys.com> wrote:
>
>> Seeing as Chuck is probably too busy to reply right now, could
>> someone who attended be kind enough to give us a general overview?
> On 5/22/99 Chuck Moore did a presentation for the Silicon Valley
> Forth Interest Group. I would list his presentation in six sections:
[snip]
Thanks for volunteering Jeff, much appreciated.
Cheers,
Mark W. Humphries
Forth Chat Room on ICQ #37160535
euph...@freenet.co.uk
On 1999-06-23 m...@intranetsys.com said:
:jf...@ricochet.net wrote:
:> In article <7kgkaj$ush$1...@nnrp1.deja.com>,
:> Mark Humphries <m...@intranetsys.com> wrote:
:>> Seeing as Chuck is probably too busy to reply right now, could
:>> someone who attended be kind enough to give us a general
:overview?
:> On 5/22/99 Chuck Moore did a presentation for the Silicon Valley
:> Forth Interest Group. I would list his presentation in six
:sections: [snip]
:Thanks for volunteering Jeff, much appreciated.
Ditto. Jeff, will you be posting a detailed transcript at all? I don't
own a VCR, or hold a credit card, so I can't really buy the video...
Chuck Carlson
> 1. The status of the iTV Corporation and and explanation of projected
> micro amps per micro meter of transistor width from 1.0 micro to .1
> micron and 5 volt to 1.5 volt processes. The numbers also happen to
> be mips. Where should he go now that the .8u lines are shut down?
> Wouldn't 1000+mips at 1.5V be nice?
Also Chuck explained that he is designing a better interface to SDRAM.
This would allow I21's to perform closer to their burst performance all
the time.
Chuck Carlson
Berkeley
(despam e-mail address)
jf...@ricochet.net
Yes. I have transcribed and posted section 1 only in
http://www.UltraTechnology.com/cm52299.htm
sections 2-6 will follow when I get time to transcrible and
proofread the other sections. I think lots of interesting
material was covered.
(part 1) <B>Charles Moore</B><BR>
I asked a question on comp.lang.forth to see what I should talk about
today and
I got a, (pause) I got a reaction. (laughter)
I will talk about maybe 10% of it. It had to agree with
what I was going to already say you see. But I invite you to do the
same. I
will stop early enough that less than trivial questions can be asked.<P>
To answer one question: iTV is alive and well. Things look very
promising
who will say what will happen next week. But we are working at it.
I am not permitted to say more than that except that, an amuse aside,
we had a due diligence review from a silicon valley technical expert.
I was looking forward to this because I wanted to see what a real
authority
would say about what we were doing. It was disastrous, absolutely
disastrous.
I think the kindest word he said was esthetically elegant and the
harshest word was anachronistic. And in a sense he is accurate.
Silicon valley is not looking forward to the products that we are
making.<P>
Q: Who is this person?<BR>
Chuck: I shouldn't say. He is a respected authority. I would welcome a
chance to debate him some time. But that will never happen.<P>
(graphic to be inserted here)<PRE>
1000 .
500 . . .
0 . . . . 1.0</PRE>
Here is an interesting picture. We are talking to a new fab. We burned
through two fabs. I don't know if you know this but. But
the HP .8 micron is gone and that is what
I was using for the last four years. We ported to
a .6 micron process at LG last year but that is now gone.<P>
This fab had a lot of different processes so I had a chance to make this
picture on the right you see the feature size from .1 to 1 micron.
and vertically is the number of
micro amps of current per micro meter of transistor width.
So this is the current through a transistor.
Roughly speaking the speed of a process is going to be proportional to
the
current through the transistor. That is about the only variable left.
Here we are at .8 micron at about 500 and that just happens to be mips
too, which is convenient.
If we were at one we would be slower if we were at .5 or .6 we would
be faster but not by much.
This is five volts (in black), this is three volts in red. And when
you go to three volts you slow way down because you aren't going to
get as much current. This is .35 and this is .25.<P>
I've plotted it offscale too to make it look linear.
It is interesting that is mostly linear on each line (5V and 3V).
This is an IBM process up here at .2 (u) and 1.5V and that to me
is enormously impressive. Given that these are the marginal gains
that you get at 3V to get way up there at 1.5. I would like to work
with that process. But that is only a factor of 2 in speed
from where we are now. Which is a little bit disappointing.
I think it may be more than that, maybe 2.5 or 3. You can't
know until you try. But these are going to be 50% faster
than we are now but not a factor of two. (pointing to .25 and .35)
And at a fairly considerable cost in going to smaller geometries
in cost, dollars.
The smaller geometries cost you more than larger ones.
That is why we were sitting at .8 for so long
because it was a nice mature comfortable process
low cost fabrication. we can't sit there, this is obsolete
there is no particular reason to move to there
unless we run out of speed.<P>
One of the criticisms of our process is that we were claiming these
ridiculous speeds. But everybody in the world has agreed that Drystone
mips as the proper measure of processor speed... Now
am I wrong is saying that Drystone mips measures 'C' compiler
performance?
That has nothing to do with processors. That is a weird comment to
make.<P>
These speeds are, I think, honest.
I have been claiming, I have been telling you for years, that
this is burst rate (pointing to 500 mips)
for a series of four instructions and
then we have to wait for memory access.<P>
Well I spent some time building and designing an
SDRAM interface. SDRAM will give me 10ns access to a significant amount
of memory. Something that was long overdue.
I've got to redesign the memory interface and the interface to the
coprocessors to take advantage of that. And when I do,
and that is another months work, if it is funded,
I'll have a sustained 500 mips.<P>
If we were to go to .35 I would have
a burst of 600 mips but I can't sustain it. I certainly can't
sustain 1000 mips because memory isn't fast enough any more.
If I get 4 instructions per word, you take whatever your memory access
rate is and you divide that by four and that is the maximum speed that
can be sustained. I have always felt comfortable having a clock speed
two or three times as fast as I needed so I would have something to
do with it. SDRAM may do that.<P>
(part 2)<BR>
all right let's go on to what people really want to hear about. This
was one of the most popular questions.<P>
ANS Forth is an increasingly significant fact of life in the world
as we know it. It may not to be to my taste but I think it is to lots
of people's and I have no quarrel with it.
What is it that I don't like about ANS Forth?<P>
This page is in the process of being transcribed, please be patient.
parts 2-6 will follow.<P>
--
Jeff Fox Ultra Technology
www.UltraTechnology.com
John Passaniti
this interesting:
<jf...@ricochet.net> wrote in message
news:7l2pq8$18o$1...@nnrp1.deja.com...
Regarding the technical expert's critical analysis of what iTV is
doing, Chuck said:
> I think the kindest word he said was esthetically elegant
> and the harshest word was anachronistic. And in a sense
> he is accurate. Silicon valley is not looking forward to
> the products that we are making.
Dismissing the technical expert's analysis based on some kind of "sour
grapes" motif is interesting. It presumes that Silicon Valley as a
whole (a) knows what iTV is doing, (b) cares what products may come
out in the future, and (c) thinks the technology is competitive. I'm
curious what evidence there is that any of these three presumptions
are true.
Put more plainly, what evidence is there that other Silicon Valley
companies find iTV's technology compelling? Are they planting fake
janitors who clean up at night who are really there to photograph
whiteboards? Have other companies adopted MISC-like designs? Have
they thrown away their expensive VLSI CAD systems and replaced it with
Rocky's Boots simulators? Has going through their dumpsters found
receipts for copies of "Thinking Forth?" and discarded copies of K&R?
It strikes me that while there may be a couple CEO's who are ready to
slash wrists the moment iTV releases its first product, it is more
likely that the inevitable press release will simply show up on page
47 of "EE Times" and cause at most a raised eyebrow at lunch. Then
they will go back to their work, and continue to pump out products
using technologies that may not be as cutting edge, but which do
translate into real products that generate real revenues.
I honestly hope that iTV makes good on the sometimes grandiose claims
offered by Jeff, Chuck, and others who parrot them. As I have said
before, I can think of plenty of applications for Chuck's MISC chips
that I would love to be a part of. But it's kind of hard to design
microprocessor-based products without microprocessors. Availability
(and in quantity) is everything.
Oh, and then there is this:
> One of the criticisms of our process is that we were
> claiming these ridiculous speeds. But everybody in the
> world has agreed that Drystone mips as the proper
> measure of processor speed... Now am I wrong is
> saying that Drystone mips measures 'C' compiler
> performance?
Chuck is of course absolutely right. A really good optimizing C
compiler can make a lower-performance processor look stellar against a
higher-performance processor with a poorly optimizing C compiler.
That's not specific to the C language-- there are Java virtual
machines that are unusably slow on fast processors, and more carefully
crafted virtual machines that make slower processors scream on past.
But this ultimately doesn't matter. Say I've got a design that needs
a microprocessor. "X" is the language I wish to implement my design
in, but I am open to a processor. So I go off and look at benchmarks
that compare language "X" code on various processors. I look through
the numbers, and finally find a combination of a specific "X" compiler
and processor that rip through the code, and which meet whatever other
criteria I have.
In that kind of scenario, benchmarks like Dhrystone are completely
valid. That's because if you have already fixed on an implementation
language, then it makes perfect sense to find a combination of
compiler and processor that execute that code the fastest. Sure, a
Forth (or other) compiler might make some other processor come to the
top, but if you have decided that you'll be using some other language,
that's completely irrelevant.
jf...@ricochet.net
"John Passaniti" <jp...@rochester.rr.com> wrote:
> Regarding the technical expert's critical analysis of what iTV is
> doing, Chuck said:
>
> > I think the kindest word he said was esthetically elegant
> > and the harshest word was anachronistic. And in a sense
> > he is accurate. Silicon valley is not looking forward to
> > the products that we are making.
>
> Dismissing the technical expert's analysis based on some kind of "sour
> grapes" motif is interesting.
I did not hear the report itself, only Chuck's description of it.
I didn't see any sour grapes tone to what Chuck said about it. I
thought Chuck's description sounded interesting. Maybe you got a
different flavor from the transcription that I got seeing the
presentation.
> It presumes that Silicon Valley as a
> whole (a) knows what iTV is doing,
It only states that one person was considered an "expert", it says
nothing about Silicon Valley as a whole although Chuck has said
things about that in other places. I am sure Chuck view of the
report was in line with his view of Silicon Valley as whole.
(b) cares what products may come
> out in the future, and (c) thinks the technology is competitive.
Again I didn't hear the review but someone was paying big bucks no
doubt to get this opinion so someone was interested in what products
come out in the future and are looking for compeditive technologies.
> I'm
> curious what evidence there is that any of these three presumptions
> are true.
There is evidence that they are truely your presumptions. I think
they are unrelated to the point.
> Put more plainly, what evidence is there that other Silicon Valley
> companies find iTV's technology compelling?
Well that is proprietary information but I can assure you that there
has been interest in Silicon Valley and around the world.
> Are they planting fake
> janitors who clean up at night who are really there to photograph
> whiteboards?
Not that I know of. However at one meeting scheduled at a Silicon
Valley office of a large international electronics company the iTV
officers came into the conference room and began the presentation
by asking about the iTV staff meeting outline that was already on
their white board.
They replied that the iTV white board was clearly visible from the
parking lot outside the iTV office. To be prepared they had taken
photographs of the whiteboards, but I guess that that is also really
considered proprietary information too. :-)
> It strikes me that while there may be a couple CEO's who are ready to
> slash wrists the moment iTV releases its first product, it is more
> likely that the inevitable press release will simply show up on page
> 47 of "EE Times" and cause at most a raised eyebrow at lunch. Then
> they will go back to their work, and continue to pump out products
> using technologies that may not be as cutting edge, but which do
> translate into real products that generate real revenues.
I don't know of any CEO's ready to slash wrists related to the
release of any iTV products. I am sure that the amount of notice
taken would be related to the scale of the operation. Few people
will notice of care if it is on a small scale and few people will
not notice if it is on a very large scale.
> Availability (and in quantity) is everything.
The economics of quantity are the main issue. To compete in
anything but a specialized niche market (of which there are
many) the economics of scale are very important. The scale
of investor for MISC to compete is lower than for more expensive
technologies but it is still on a price/quantity curve.
> In that kind of scenario, benchmarks like Dhrystone are completely
> valid.
If Dhrystones represent a fair profile of your application code
then it is a valid benchmark. But of course this is mostly
mutually exclusive with MISC technology so anyone who even considers
Dhrystones or Specmarks on MISC has missed 90% of the idea of MISC.
I have written many times that for someone to consider things like
Dhrystones or Specmarks as valid benchmarks for MISC is either
trying the most distored argument that they can come up with or
they don't understand the first thing about the technology.
I am sure Chuck feels the same way about it.
I think Chuck was just sort of joking about dumb this guy was
that he couldn't see it beyond such a surface level of understanding.
A lot of people who claim that they know Forth will describe it like
a blind man describing an elephant. ;-)
If you've seen one Forth, there is no telling what you have seen.
Len Zettel
John Passaniti wrote:
>
> Fully realizing this is a transcript which may have errors, I found
> this interesting:
>
> <jf...@ricochet.net> wrote in message
> news:7l2pq8$18o$1...@nnrp1.deja.com...
>
> Regarding the technical expert's critical analysis of what iTV is
> doing, Chuck said:
>
> > I think the kindest word he said was esthetically elegant
> > and the harshest word was anachronistic. And in a sense
> > he is accurate. Silicon valley is not looking forward to
> > the products that we are making.
>
Am I missing something or am I living on another planet?
My reading on this was "Silicon Valley doesn't give a damn
about what we are doing (because they totally misunderstand it)."
-LenZ-
(snip)
jf...@ricochet.net
zet...@acm.org wrote:
> > Regarding the technical expert's critical analysis of what iTV is
> > doing, Chuck said:
> >
> > > I think the kindest word he said was esthetically elegant
> > > and the harshest word was anachronistic. And in a sense
> > > he is accurate. Silicon valley is not looking forward to
> > > the products that we are making.
>
> Am I missing something or am I living on another planet?
> My reading on this was "Silicon Valley doesn't give a damn
> about what we are doing (because they totally misunderstand it)."
> -LenZ-
I think you may be missing the fact that many people do understand
it and are working on competing low cost solutions but would only
be _concerned_ if it is funded to the point that they have to play
catch up. As long as they are not playing against a major
compeditor they don't give a damn. That is the bottom line.
There are many business reasons for this, companies don't need to
take such risks unless the marketplace demands it. Until your
compeditor is selling digital watches for $5 do you have to
stop selling them for $150? As long as they were competing
with analog watches and people expected to pay that much there
as no market for give away digital watches. It is the same
thing with paperback computers.
In the case of the review by a silicon valley technical expert
that Chuck talked about it sounded like he clearly did miss the
major idea involved. He may well be an expert in
his field and have given valid advice as Chuck said. I think
what Chuck said expressed it very clearly, he couldn't see it
as an economic solution because it was too far ahead of the
supporting industries. He thought other people would see it
that way too from what Chuck said. So what he says may sort
of be right.
The funny part is that I have written so many documents and
sent so much email to various people explaining that if you
demand to see Winmarks, Specmarks, or Dhrystones you are
missing the whole point. You can explain it to your dog
but he is not likely to really understand it the way you do.
If his review mentioned one of those he clearly missed
the basic idea.