'C' Expression Parsing in Forth?
PagCal
It seems like a handy addition and provides an easy bridge to the
language for us 'c' types.
Here's what I added:
...
( -- cexp-value-returned )
cexp { any-valid-c-expression }
thus, you can do things like:
...
cexp { ~1 % 3*5 & 4/(9-1) } . cr
and not have to bother with figuring out the rpn for forth.
It gets real handy when you allow variable names, with indexing, so
you end up with things like:
...
cexp { 1 + tmpvar [ 3 ] / othervar [ 9 ] } . cr
and more extensions - by allowing subroutine calls, casting, ->, and the
like.
---
Of course, the real goal is to add full 'c' statement processing as
well, but that's the next step, ie:
...
c-stmt {
for ( i = 0 ; i < 10 ; i++ )
x += somefct(i);
} drop
... or for that matter, take the full bnf/bison for JAVA to allow it to
be compiled into forth.
... or, have I gone mad.
Howerd
It sounds like you are trying to write a C compiler in Forth - this is
a non-trivial application ;)
There is certainly no need for C syntax in Forth, unless you are trying
to get Forth to compile C source directly. MPE's VFX Forth for Windows
goes a long way towards C compatibility with "#define" working as
expected, and a really neat WinAPI interface.
Take a look at my Cweed program (http://www.inventio.co.uk/Cweedexe.htm
) - this parses a C source file and extracts the non-commented bits.
The code is very ugly, and demonstrates just how complicated everything
is in C compared to Forth.
Parsing C syntax into something that Forth can read is relatively
simple - there are BNF parsers that should do the job quite easily...
Regards
Howerd 8^)
Jerry Avins
> Is there any need for 'c' expression parsing within forth?
>
> It seems like a handy addition and provides an easy bridge to the
> language for us 'c' types.
Have a look at FORMula TRANslator at
http://galileo.phys.virginia.edu/classes/551.jvn.fall01/programs.htm
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Andrew Haley
> ...
> ---
See http://groups.google.co.uk/group/comp.lang.forth/msg/471651c087b5bb5a?hl=en&
This allows you to do thing like
: q exp ( ( - b + ( sqrt ( b * b - 4 * a * c ) ) ) / ( 2 * a ) ) ;
but it's not full C syntax. Adding [] syntax for arrays is nearly
trivial, and is left as an exercise for the reader. Also, it's
trivial to add operator names lile |, &, and ~.
Andrew.
PagCal
> Hi PagCal,
>
> It sounds like you are trying to write a C compiler in Forth - this is
> a non-trivial application ;)
Is it a bridge too forth ?-)
Coos Haak
> Is it a bridge too forth ?-)
This one? http://home.hccnet.nl/j.j.haak/forth.html
--
Coos
PagCal
Thanks for the link.
I ended up with an c-expression analyizer from some bnf/bison fluff I
found gpl'd on the net that almost works like the above:
( -- run-time-value-of-c-expression )
cexp { any-valid-c-expression }
Pushing the results of the cexp onto the data stack and letting the cexp
parser access the data dictionary (variables/subroutines) gives it a
natural fit into forth, it seems.
The only interesting problem was function calling. For forth->forth
calls inside cexps, I had to keep track of the call arguments and then
drop them on return from the subroutine, save for only one, the value of
the return function. If the function had no call arguments, I'd push a 0
before the call.
Now, it's on to support for 'c' and 'java' statements!
Andrew Haley
> The only interesting problem was function calling. For forth->forth
> calls inside cexps, I had to keep track of the call arguments and
> then drop them on return from the subroutine, save for only one, the
> value of the return function.
IMO, that's a mistake. If you have a function a that returns two args
and a function b that takes two args it makes perfect sense to say
b(a)
There's no need at all to restrict yourself to returning a single arg:
that's just a syntactic disadvantage of (originally) FORTRAN.
Andrew.
PagCal
OK, I'll modify it so that if you declare return stack values, it'll
leave them there, otherwise take the above as the default.
Julian V. Noble
>
> Is there any need for 'c' expression parsing within forth?
>
> It seems like a handy addition and provides an easy bridge to the
> language for us 'c' types.
http://galileo.phys.virginia.edu/classes/551.jvn.fall01/programs.htm
Jerry Avins already referred you to this link, which provides formula
translation (to Forth); it could easily be modified to recognize Pascal,
Algol or C expressions. As I have written it, it is in many ways more
convenient than the original mathematical expression parsers of these
languages.
I would not recommend a full Fortran->Forth or C->Forth translator,
however. As I have noted at this site before, the result is terrible
Forth code. The languages are really not a good fit--lots of impedance
mismatch. If you want to see why I prefer Forth, compare the routines
found in items #4 and #5 under the link
http://galileo.phys.virginia.edu/classes/551.jvn.fall01/Cprogs.htm
--
Julian V. Noble
Professor Emeritus of Physics
j...@lessspamformother.virginia.edu
^^^^^^^^^^^^^^^^^^
http://galileo.phys.virginia.edu/~jvn/
"For there was never yet philosopher that could endure the
toothache patiently."
-- Wm. Shakespeare, Much Ado about Nothing. Act v. Sc. 1.
PagCal
One of the problems I've been trying to solve with forth was it's
arcaine language with a steep learning curve. I felt that a 'c' syntax,
optionally provided within forth, would provide a stepping stone. New
users would stick to the familiar 'c' but then branch out into forth as
they became more comfortable with it.
Thus, Calforth was born.
Example:
: times ( a b -- resultant-product )
c-expression ( a*b ) \ results of any 'c' expression pushed
\ onto data stack
nip nip
;
I've also added 'c' statements, so you could rewrite the above as:
: times ( a b -- resultant-product )
c-statement ( a = a*b; )
drop
;
A second plus for such an approach, is that a great deal of open-source
'c' code is available to be included into your project and this could be
just compiled into forth along with whatever else you wanted. You thus
shrink the project time down considerably.
Compare the above with what you can groak in with CREATE DOES> and you
can see the above is a lot cleaner.
I concede an optomized code generator is tough to do, but this is
usually of secondary concern in todays market place (time to market).
Further, todays really fast cpus just swollow the stuff without any
noticable (measurable yes, but so what?) delay.
Jerry Avins
alphabet, a certain amount of transliteration is appropriate for
beginners. The object of study ought to be learning to read the language
as it is written, rather than creating a standardized transliteration
method and building it into the studied language. Programming languages
are not much different.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
...
John Passaniti
> One of the problems I've been trying to solve with forth was it's
> arcaine language with a steep learning curve. I felt that a 'c' syntax,
> optionally provided within forth, would provide a stepping stone. New
> users would stick to the familiar 'c' but then branch out into forth as
> they became more comfortable with it.
A fundamental question to ask here is what value do you think Forth has
as a language? With your (optional) facility, you've removed two of
it's defining attributes (a programmer-visible stack with nameless items
on it). So what's left? What value is there in programming in Forth
for you?
> Example:
>
> : times ( a b -- resultant-product )
>
> c-expression ( a*b ) \ results of any 'c' expression pushed
> \ onto data stack
>
> nip nip
> ;
>
> I've also added 'c' statements, so you could rewrite the above as:
>
> : times ( a b -- resultant-product )
>
> c-statement ( a = a*b; )
>
> drop
> ;
I think you've just wonderfully illustrated the "impedance mismatch"
between Forth and C with these examples. In 'times' you presumably push
the result of the a*b on the stack, which now doesn't have a name-- just
a position on the stack. And because it doesn't have a name, if I want
to use this value in a subsequent calculation, how do I reference it
from a c-expression? Even better, is the 'nip nip' that occurs in
'times'. The programmer is freed from having to deal with the stack
with c-expression, and then in the next couple statements is forced
to... deal with the stack. And this helps the programmer how?
> A second plus for such an approach, is that a great deal of open-source
> 'c' code is available to be included into your project and this could be
> just compiled into forth along with whatever else you wanted. You thus
> shrink the project time down considerably.
This is perhaps your worst argument. In order to use that open source
'C' code, your solution requires me to edit the original 'C' code (which
is typically going to be a set of functions and data structures, not
just a simple c-expression and c-statement) and wrap it with Forth. Why
would I want to do that?
If I want to integrate C and Forth code, a much better and cleaner
solution is to come up with a call interface between the two languages.
Allow C code to call words from Forth, and Forth code to call
functions from C. Both languages stay as they are, both fully retaining
all their benefits.
> Compare the above with what you can groak in with CREATE DOES> and you
> can see the above is a lot cleaner.
It's horrific. You have the programmer having to shift mindsets between
Forth and C with no benefit visible other than you don't have to juggle
items on the stack inside a c-expression or c-statement. But as soon as
that c-expression or c-statement ends, the programmer is tossed back
into the world of dealing with the stack-- presumably what you were
trying to avoid.
> I concede an optomized code generator is tough to do, but this is
> usually of secondary concern in todays market place (time to market).
> Further, todays really fast cpus just swollow the stuff without any
> noticable (measurable yes, but so what?) delay.
Today's really fast CPUs are in desktop and server systems. Much of the
space that Forth best addresses isn't there. It's in embedded systems,
where slow 8-bit and 16-bit microcontrollers and limited memory are the
norm, not the exception.
Your c-expression and c-statement can't be seen as a way to improve
time-to-market. It slows the programmer by having to switch mindsets
between Forth and C and it only considers C code reuse at the expression
and statement level which doesn't seem particularly compelling.
Gosh, all this work on your part just to avoid having to learn how to
use the stack effectively. Was it worth it?
PagCal
> PagCal wrote:
>
>> One of the problems I've been trying to solve with forth was it's
>> arcaine language with a steep learning curve. I felt that a 'c'
>> syntax, optionally provided within forth, would provide a stepping
>> stone. New users would stick to the familiar 'c' but then branch out
>> into forth as they became more comfortable with it.
>
>
> A fundamental question to ask here is what value do you think Forth has
> as a language? With your (optional) facility, you've removed two of
> it's defining attributes (a programmer-visible stack with nameless items
> on it). So what's left? What value is there in programming in Forth
> for you?
>
It provides a useful structure to investigate what a programming
language should be.
>> Example:
>>
>> : times ( a b -- resultant-product )
>>
>> c-expression ( a*b ) \ results of any 'c' expression pushed
>> \ onto data stack
>>
>> nip nip
>> ;
>>
>> I've also added 'c' statements, so you could rewrite the above as:
>>
>> : times ( a b -- resultant-product )
>>
>> c-statement ( a = a*b; )
>>
>> drop
>> ;
>
>
> I think you've just wonderfully illustrated the "impedance mismatch"
> between Forth and C with these examples. In 'times' you presumably push
> the result of the a*b on the stack, which now doesn't have a name-- just
> a position on the stack. And because it doesn't have a name, if I want
> to use this value in a subsequent calculation, how do I reference it
> from a c-expression? Even better, is the 'nip nip' that occurs in
> 'times'. The programmer is freed from having to deal with the stack
> with c-expression, and then in the next couple statements is forced
> to... deal with the stack. And this helps the programmer how?
Well, I left out a bit. Along with c-statements, I support
class/union/struct, subroutines, and am generally extending the 'c'
syntax over time to where it'll do the entire c file.
The 'times' example above could have been re-written:
c-subroutine (
int times ( int a, int b)
{
return a*b;
}
)
>
>> A second plus for such an approach, is that a great deal of
>> open-source 'c' code is available to be included into your project and
>> this could be just compiled into forth along with whatever else you
>> wanted. You thus shrink the project time down considerably.
>
>
> This is perhaps your worst argument. In order to use that open source
> 'C' code, your solution requires me to edit the original 'C' code (which
> is typically going to be a set of functions and data structures, not
> just a simple c-expression and c-statement) and wrap it with Forth. Why
> would I want to do that?
>
> If I want to integrate C and Forth code, a much better and cleaner
> solution is to come up with a call interface between the two languages.
> Allow C code to call words from Forth, and Forth code to call functions
> from C. Both languages stay as they are, both fully retaining all their
> benefits.
>
I've done that as well in two ways. dlopen/close will map constructs out
of libraries, and I wrote a tool to declare 'c' subroutines to my forth
engine. The tool builds all of the hooks necessary to just plop the 'c'
code into the executable.
Using GTK+2 to create a label Widget would be done as:
C" My Label" 1+ gtk_label_new
>> Compare the above with what you can groak in with CREATE DOES> and you
>> can see the above is a lot cleaner.
>
>
> It's horrific. You have the programmer having to shift mindsets between
> Forth and C with no benefit visible other than you don't have to juggle
> items on the stack inside a c-expression or c-statement. But as soon as
> that c-expression or c-statement ends, the programmer is tossed back
> into the world of dealing with the stack-- presumably what you were
> trying to avoid.
Shift Mindsets? That's an interesting way to look at programming languages.
I rather view all these modern languages trying to do the same things,
but using different syntax to achieve these goals.
For example, you've got to interate over something. In 'c', you'd do
for ( i = 0 ; i < 10 ; i++ ) {
}
but in forth, you'd do:
10 0 do
loop
Other common goals are branching, memory-management, exception handling,
and so on.
Each 'language' must solve these same problems, so they cook up some
syntax to get the job done.
The problem langages run into is they try to 'extend' their syntax to
solve problems it wasn't designed for. Take the following 'c' construct
(void (*)(int int))m
If you can 'understand' it, you've spent too many hours in the pits of
tartarous.
Forth does the same sort of thing. Example, using DOES> in some clever
way to add classes.
So, since all languages are fundamentally the same, the only mindset you
have to switch is the syntax overlay onto the language goals. Then, you
can pretty much code in any language and get the job done.
>
>> I concede an optomized code generator is tough to do, but this is
>> usually of secondary concern in todays market place (time to market).
>> Further, todays really fast cpus just swollow the stuff without any
>> noticable (measurable yes, but so what?) delay.
>
>
> Today's really fast CPUs are in desktop and server systems. Much of the
> space that Forth best addresses isn't there. It's in embedded systems,
> where slow 8-bit and 16-bit microcontrollers and limited memory are the
> norm, not the exception.
>
True in the past. I remember when closit sized computers fit into that
category. Now, I seem to be doing embedded projects with pentiums. The
client wants all the high level stuff like interconnectivity, graphics,
internationalization etc, AND, wants rapid time to market.
Coos Haak
> So, since all languages are fundamentally the same, the only mindset you
> have to switch is the syntax overlay onto the language goals. Then, you
> can pretty much code in any language and get the job done.
>
Even people that know C and those that know C++ can have difficulties
translating to the other language. The gap to Algol is bigger and to
Fortran even bigger. Not to speak of Lisp or Forth.
You can't open a book about another language (computer or people's) and
translate correct in some days. It takes learning and experimenting. The
structure may be (and in case of Forth and C) is very different, despite
that both are 'structured languages'.
So stop writing Forth as being a form of C. It's inefficient and
unreadable. Use your knowledge of C as a means of constructing a program,
not as mortar or wooden beam.
Coos
--
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
PagCal
People that have trouble switching between languages didn't learn them
the right way in the first place.
Fortran is exactly the same as 'c', only the syntax varies.
Library packs do vary however. You might have linpack with Fortran but
libc with 'c' - but this isn't what I was talking about.
Further, they make the mistake that the language syntax is reality, that
is, it can't be extended or modified - which just isn't true.
Some languages 'solve' certain structural problems better than others.
For example, JAVA has a strict signaling stack, but 'C' does not.
However, you can get the job done in 'C' with setjump/longjump if you
wanted to.
The trick with any programming-system, is to solve as many of these
structural problems automatically for the developer as possible -
resulting in better code quality, better time to market, and lower cost.
You also seem to be criticizing my poly-lingual programming environment.
By analogy, is it really a mad-man that speaks both French and English
interchangeably? No, more its the speaker choosing the best word at any
particular moment.
bobja...@juno.com
>
>TOPIC: 'C' Expression Parsing in Forth?
>http://groups.google.com/group/comp.lang.forth/browse_thread/thread/ea1e29e3abddf3f6
>
>
>
>
> 3 of 3
>Date: Fri 5 Aug 2005 16:42
>From: John Passaniti
>
>PagCal wrote:
>
>> One of the problems I've been trying to solve with forth was it's
>> arcaine language with a steep learning curve. I felt that a 'c' syntax,
>> optionally provided within forth, would provide a stepping stone. New
>> users would stick to the familiar 'c' but then branch out into forth as
>> they became more comfortable with it.
>
>A fundamental question to ask here is what value do you think Forth has
>as a language? With your (optional) facility, you've removed two of
>it's defining attributes (a programmer-visible stack with nameless items
>on it). So what's left? What value is there in programming in Forth
>for you?
This is your fundamental objection, John. It is not so much
that you object to implementing named stack items because
of innumerable objections that you can pick on, but that
you are really _attached_ to nameless stack items as a
fundamental value in Forth.
PagCal and I, however, see nameless stack items as a
very serious impediment to people becoming interested
in Forth. In addition I see nameless stack items within the
high-level source as unclear and not self-documenting.
Where PagCal and I differ is in the use of a stack
frame. But even there there are times when the extra
small overhead is something that can be lived with.
I see your purism as a stick-in-the-mud attitude.
To answer your question of what value is there in
programming in Forth, I would answer that it is not
in a stack with nameless items, but it its
efficient modularity, ease in testing, and many
other features that have nothing to do with the
stack items being nameless.
>> Example:
>>
>> : times ( a b -- resultant-product )
>>
>> c-expression ( a*b ) \ results of any 'c' expression pushed
>> \ onto data stack
>>
>> nip nip
>> ;
>> I've also added 'c' statements, so you could rewrite the above as:
>>
>> : times ( a b -- resultant-product )
>>
>> c-statement ( a a*b; )
>>
>> drop
>> ;
>I think you've just wonderfully illustrated the "impedance mismatch"
>between Forth and C with these examples. In 'times' you presumably push
>the result of the a*b on the stack, which now doesn't have a name-- just
>a position on the stack. And because it doesn't have a name, if I want
>to use this value in a subsequent calculation, how do I reference it
>from a c-expression? Even better, is the 'nip nip' that occurs in
>'times'.
I have to agree with the objection here. I don't see a value
to naming things if you proceed to abandon naming within
the code and do it in such a way that the source is _less_
self-documenting.
>The programmer is freed from having to deal with the stack
>with c-expression, and then in the next couple statements is forced
>to... deal with the stack. And this helps the programmer how?
I don't see that it does. What this indicates to me is
that PagCal's implementation is incomplete.
>> A second plus for such an approach, is that a great deal of open-source
>> 'c' code is available to be included into your project and this could be
>> just compiled into forth along with whatever else you wanted. You thus
>> shrink the project time down considerably.
>This is perhaps your worst argument. In order to use that open source
>'C' code, your solution requires me to edit the original 'C' code (which
>is typically going to be a set of functions and data structures, not
>just a simple c-expression and c-statement) and wrap it with Forth. Why
>would I want to do that?
You would want to do this for the _very_ reason given - _if_
conversion will cut down project time by reusing C-code in
a Forth way.
>If I want to integrate C and Forth code, a much better and cleaner
>solution is to come up with a call interface between the two languages.
No. It may be cleaner but then you have all the disadvantages
of the C-code and the overhead of the call interface.
> Allow C code to call words from Forth, and Forth code to call
>functions from C. Both languages stay as they are, both fully retaining
>all their benefits.
That, of course, has already been done.
But I already asked the question recently (Linux in Forth?)
if C-libararies had been converted into Forth with the
thought that the result _ought_ to be more compact and
run faster. Instead, what I see is Forth written in
C.
>> Compare the above with what you can groak in with CREATE DOES> and you
>> can see the above is a lot cleaner.
>It's horrific. You have the programmer having to shift mindsets between
>Forth and C with no benefit visible other than you don't have to juggle
>items on the stack inside a c-expression or c-statement. But as soon as
>that c-expression or c-statement ends, the programmer is tossed back
>into the world of dealing with the stack-- presumably what you were
>trying to avoid.
You nay-sayers keep presuming this, but it is as obvious
as can be that PagCal is _not_ trying to avoid the stack.
He is rather trying to provide an avenue for people put off
by Forth to get into it. And he said exactly that.
>> I concede an optomized code generator is tough to do, but this is
>> usually of secondary concern in todays market place (time to market).
>> Further, todays really fast cpus just swollow the stuff without any
>> noticable (measurable yes, but so what?) delay.
This is the usual attitude taken by people interested
in _some_ of the virtues of Forth, particularly shorted
development time and ease in testing, but put off by
the undocumented stack with nameless stack items. The
documentation of the stack is essential but optional
to the language!
>Today's really fast CPUs are in desktop and server systems. Much of the
>space that Forth best addresses isn't there. It's in embedded systems,
>where slow 8-bit and 16-bit microcontrollers and limited memory are the
>norm, not the exception.
I agree.
>Your c-expression and c-statement can't be seen as a way to improve
>time-to-market. It slows the programmer by having to switch mindsets
>between Forth and C and it only considers C code reuse at the expression
>and statement level which doesn't seem particularly compelling.
>Gosh, all this work on your part just to avoid having to learn how to
>use the stack effectively. Was it worth it?
This latter is an unworthy taunt, which doesn't correspond
to the motivation of expressed by PagCal.
Bob Jaffray
Jeff Fox
> People that have trouble switching between languages
> didn't learn them the right way in the first place.
Language limits thought. Not all languages can express
the same ideas. Things get lost in translation. The
more languages and cultures one studies the more one
see this. This is also true of computer languages.
> Fortran is exactly the same as 'c',
> only the syntax varies.
Yes, they are pretty close, both Algol derived. It
is fairly easy to translate without too many problems.
Unlike say Forth and C.
> Library packs do vary however. You might have
> linpack with Fortran but libc with 'c' - but
> this isn't what I was talking about.
The whole concept of a library pack is dependent
on the concept of a library which is dependent on
the concept of a file system which is dependent
on the concept of an OS outside of the language
providing file, file system, and library features.
Speakers of one language can often get the idea
when they hear something in a language with close
family ties to their language. Languages derived
from Latin are an good example. Languages derived
from Algol are another.
> Further, they make the mistake that the language
> syntax is reality, that is, it can't be extended
> or modified - which just isn't true.
Well much of C or Fortran syntax is fixed and
standardized. To be properly labeled C or Fortran
many things can't be modified.
> Some languages 'solve' certain structural problems
> better than others.
And some solve problems that are impossible to solve
in other languages. Forth is a good example of a
language that can do thigns that some languages in
some other families can't do. This is why it is
still in use after so many decades.
> For example, JAVA has a strict signaling stack,
> but 'C' does not. However, you can get the job done
> in 'C' with setjump/longjump if you
> wanted to.
>
> The trick with any programming-system, is to solve
> as many of these structural problems automatically
> for the developer as possible - resulting in better
> code quality, better time to market, and lower cost.
Indeed.
> You also seem to be criticizing my poly-lingual
> programming environment.
Poly-lingual can solve some problems better. If
you have a French program fighting an English
program a poly-lingual solution is probably needed.
> By analogy, is it really a mad-man that speaks
> both French and English interchangeably?
Those are certainly not necessarily related things.
> No, more its the speaker choosing the best word at any
> particular moment.
Right. And as you say, a solution in French and English
might be needed.
Best Wishes
Elizabeth D Rather
news:v_WdneEWY--...@giganews.com...
> Coos Haak wrote:
>> Op Sat, 06 Aug 2005 03:31:58 -0400 schreef PagCal:
>>
>>
>>>So, since all languages are fundamentally the same, the only mindset you
>>>have to switch is the syntax overlay onto the language goals. Then, you
>>>can pretty much code in any language and get the job done.
>>
>> Even people that know C and those that know C++ can have difficulties
>> translating to the other language. The gap to Algol is bigger and to
>> Fortran even bigger. Not to speak of Lisp or Forth.
>
> People that have trouble switching between languages didn't learn them the
> right way in the first place.
>
> Fortran is exactly the same as 'c', only the syntax varies.
>
> Library packs do vary however. You might have linpack with Fortran but
> libc with 'c' - but this isn't what I was talking about.
Forth is actually more different than you appreciate. It's built on a
fairly complete conceptual framework that differs from languages whose
underlying structure is merely expressions and a syntax parser with
libraries. As John Passaniti was trying to point out, unless you invest the
effort to learn what Forth has to offer, you won't be in a position to make
use of it effectively.
I have taught Forth to several thousand programmers over my career. Those
who come to the language believing that it's just a strange syntax that
needs to be twisted into the programming style they already know have a lot
of trouble and end up either writing very bad Forth or just giving up.
Those who are willing to be open to some new ideas find wonderful
opportunities open up.
> Further, they make the mistake that the language syntax is reality, that
> is, it can't be extended or modified - which just isn't true.
Yes, and Forth is easier to modify than most once you've mastered the
fundamentals (which you have apparently not done entirely). However, the
most successful extensions and modifications are those that work within
Forth's basic conceptual framework rather than attempting to override it.
> ...
> The trick with any programming-system, is to solve as many of these
> structural problems automatically for the developer as possible -
> resulting in better code quality, better time to market, and lower cost.
Forth has a different approach. Rather than emphasizing an "omniscient,
omnipotent" massively complicated compiler that tries to do your thinking
for you, it empowers the programmer to make the best use of his/her skills
and knowledge of where the program is going. Optimizing compilers in modern
Forths seek to improve the result, not replace the application of skills
going in.
> You also seem to be criticizing my poly-lingual programming environment.
> By analogy, is it really a mad-man that speaks both French and English
> interchangeably? No, more its the speaker choosing the best word at any
> particular moment.
Learning multiple languages is certainly a good thing. But applying French
or German syntax or word order on to English, or vice-versa, will just make
you unintelligible. An eloquent speaker masters each language and uses the
language superbly within its own rules and structure.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Elizabeth D Rather
news:1123344939....@z14g2000cwz.googlegroups.com...
> ...
> This is your fundamental objection, John. It is not so much
> that you object to implementing named stack items because
> of innumerable objections that you can pick on, but that
> you are really _attached_ to nameless stack items as a
> fundamental value in Forth.
Bingo.
> PagCal and I, however, see nameless stack items as a
> very serious impediment to people becoming interested
> in Forth. In addition I see nameless stack items within the
> high-level source as unclear and not self-documenting.
Yes, that is clear. However, that is like saying to get more people
interested in swimming you have to introduce water-bicycles to attract
bikers. Swimming is a skill in itself, and the pleasures of water are
different from the pleasures of biking. The important attractions to Forth
are its interactive programming style and overall simplicity, both of which
are direct consequences of using the stack as it was designed to be used.
Learning to use the stack effectively is far easier than developing
complicated mechanisms for avoiding it.
> ...
> To answer your question of what value is there in
> programming in Forth, I would answer that it is not
> in a stack with nameless items, but it its
> efficient modularity, ease in testing, and many
> other features that have nothing to do with the
> stack items being nameless.
Actually, it has a lot to do with it. It's a lot easier to type a sequence
of commands that operate on nameless stack items than having to make up a
whole definition with names, for example, which is a major component in the
"ease in testing" that we love. The simplicity and modularity of Forth is
also considerably facilitated by the stack as it is; the mechanisms you
propose add a considerable layer of complexity to the process of defining
and testing a word.
...
>
> You nay-sayers keep presuming this, but it is as obvious
> as can be that PagCal is _not_ trying to avoid the stack.
> He is rather trying to provide an avenue for people put off
> by Forth to get into it. And he said exactly that.
One does not learn swimming by practicing bicycling skills. One needs to
get wet. Concealing Forth's essential nature and compromising its main
advantages will not do anything for anyone.
Jeff Fox
> This is your fundamental objection, John. It is not so much
> that you object to implementing named stack items because
> of innumerable objections that you can pick on, but that
> you are really _attached_ to nameless stack items as a
> fundamental value in Forth.
John might find it funny to be accused of not making
rational decisions about Forth because of an emotional
attachment to it. I think it's funny because for years
John has said that I can't make rational decisions about
Forth because I love it and have an emotional attachment
to it and I have saidthat he can't make rational decisions
about Forth because he has a different kind of emotional
attachement to Forth. ;-)
But in this case John and I seem to agree that we
both understand Forth well enough to understand that
the logic behind Forth starts with the idea that
Forth is factoring facilitated by a parameter stack
for unnamed items. Everyone says, throw that and
you are throwing out Forth and doing something
totally different.
> PagCal and I, however, see nameless stack items as a
> very serious impediment to people becoming interested
> in Forth.
Many many people see throwing out Forth as the only
way to get people who don't like Forth to become
interested. There is serious logic there. It is
true.
If you call for Forth to be drummed out and expunged
from the face of the earth the idea will be popular
with more people than those who like Forth today.
So throwing away Forth and substituting something else
to 'Forth' can be popular is the sort of logic that is
popular in the world today.
> In addition I see nameless stack items within the
> high-level source as unclear and not self-documenting.
Translation to English, "I see Forth as unclear and
ineffective for programming and think it needs to be
discarded and replaced with something completely
and fundamentally different. And my opinion is
the most popular opinion out there."
> Where PagCal and I differ is in the use of a stack
> frame. But even there there are times when the extra
> small overhead is something that can be lived with.
> I see your purism as a stick-in-the-mud attitude.
That's John's problem. People always call him a
Forth purist! Or a Forth puritan. Or a Forth
fundamentalist because he can't make rational
decisions about Forth because of his religious
attachment to it. ;-) (He is probably just trying
to organize a Forth cult! Just joking John.)
I probably shouldn't say anything, but I can't
help but be amused by your dismissing John's
arguments because he seems like a Forth purist
to you. Don't worry if you don't get exactly
why I would find that funny.
So far I have been completey with John and everyone
else except you and PagCal on this one.
> But I already asked the question recently (Linux in Forth?)
> if C-libararies had been converted into Forth with the
> thought that the result _ought_ to be more compact and
> run faster.
Forth can sometimes be significantly more compact and
sometimes faster than C. But almost never when it is
doing things in the C way, like you would have to if
you make copies of Unix drivers written in C.
Most of the cases of the worst Forth I have seen were
copies of C programs that did the same things as C but
in in Forth instead.
Years ago Mr. Moore said that it would be interesting
to get a small group of Forth programmers and do
something like Windows in Forth. I also think it would
be interesting to do something like that, perhaps more
Linux like than Windows like under the hood. I have
no problem with the idea unless it is to make a copy
of the C code in Forth.
> Instead, what I see is Forth written in C.
I know. It isn't what you are talking about.
> You nay-sayers keep presuming this, but it is as obvious
> as can be that PagCal is _not_ trying to avoid the stack.
> He is rather trying to provide an avenue for people put off
> by Forth to get into it. And he said exactly that.
Right. He is talking about the programmer avoiding thinking
about a stack. Thinking about a stack is what puts programmers
who don't like stack languages off in the first place. The
idea of a stack hidden in the implementation doesn't bother
them, it is just having to think about factoring for a
stack that is foreign to them.
> >Your c-expression and c-statement can't be seen as a way to improve
> >time-to-market. It slows the programmer by having to switch mindsets
> >between Forth and C and it only considers C code reuse at the expression
> >and statement level which doesn't seem particularly compelling.
>
> >Gosh, all this work on your part just to avoid having to learn how to
> >use the stack effectively. Was it worth it?
>
> This latter is an unworthy taunt, which doesn't correspond
> to the motivation of expressed by PagCal.
I think John was being direct and trying to express the idea again
that if you learn to use the stack effectively in the first place you
won't think it needs to be hidden behind a layer of C abstraction in
the Forth language.
He was saying that he thinks that you haven't given the
idea of a stack, of Forth, a fair evaluation and that you
can't give it a fair evaluation until you understand it.
He was saying that you are premature in throwing out
the Forth from Forth to make it more like C.
I have been saying for years that lots of people like
the idea that throwing the Forth out of Forth could make
it (Forth without Forth) more like C and COULD make it
(Forth without Forth) more popular with people who like C
but don't like Forth/stacks than Forth is today.
What I find funny is that every few months someone in
C.L.F proposes throwing out stack syntax, or throwing
out stacks, or adding C expression parsing, or adding
C stack frames and locals, or adding C style string
handling, or adding C style printf syntax, or adding
C function calls, or adding C library access, or
adding C OS hooks, or adding C structures, or C
this or that in order to make Forth more popular
in a C world. What is funny is that they always
get told, we already did all that but learned that
throwing out the stacks and stack syntax was going
too far. But complementing stack syntax with local
syntax and all those other C ideas works very
well in a C world.
And it is well worth the admission price when you
tell John that he doesn't understand your idea
because he is a Forth purist. (It's an old joke
don't worry about it.) John is very open to
the idea of experimentation with new ideas in
programming and to mixing ideas to get something
new. I don't think he is too locked in to Forth
purism. I might be. But so far I am with John
on this one.
Best Wishes
Jerry Avins
Bob,
Your response is by form directed to PagCal.
This discussion reminds me of a 1928 cartoon in the New Yorker:
(Mother aka Bob Jaffray) It’s broccoli, dear.
(Daughter aka most of us) I say it’s spinach, and I say the hell with it.
I think you guys want a Tour de France bike with training wheels.
Jeff Fox
> to get more people interested in swimming you have
> to introduce water-bicycles to attract bikers.
>
> Swimming is a skill in itself, and the pleasures
> of water are different from the pleasures of biking.
>
> The important attractions to Forth
> are its interactive programming style and overall
> simplicity, both of which are direct consequences of
> using the stack as it was designed to be used.
>
> Learning to use the stack effectively is far easier
> than developing complicated mechanisms for avoiding it.
That about sums Forth up!
> One does not learn swimming by practicing
> bicycling skills. One needs to get wet.
> Concealing Forth's essential nature and
> compromising its main advantages will not do
> anything for anyone.
I think it would. Destroying Forth by throwing
away what makes it work is precisely what people
who don't like Forth would like to see.
Replace it with C. Call it Forth. The majority
would then like Forth. PagCal and Bob are right
about that.
All the people who like and use Forth are saying
that throwing out the idea of unnamed stack items
would cripple and destroy Forth. Those who don't
like the way Forth works say, so what, the result
would be more to the liking of C programmers and
there are more of them who don't like Forth than
Forth programmers who do like Forth.
We can run the bike paths off the pier and give
those biking enthusiasts a chance to join the
swimmers. But swimming on a bike is not really
likely to become popular. And if it does it will
ruin swimming for the people who prefer swimming
without bikes.
Best Wishes
Alex McDonald
> PagCal wrote:
>
>>Fortran is exactly the same as 'c',
>>only the syntax varies.
>
>
> Yes, they are pretty close, both Algol derived. It
> is fairly easy to translate without too many problems.
> Unlike say Forth and C.
>
>
They belong to the same family of programming languages, but C and
Fortran are not derived from Algol.
Fortran predates Algol; Backus was heavily involved in both languages,
as designer first of Fortran and the later BNF, used in the
specification of Algol.
Fortran, PL/I and Algol influenced the development of C (or rather,
Ritchie and Thompson were influenced by them); but Thompson thought all
three languages too large to implement on the limited PDP-7.
BCPL begat B begat C. Entertainingly, in the context of this post, B,
C's immediate parent, was a stack based threaded interpreter.
--
Regards
Alex McDonald
bobja...@juno.com
>TOPIC: 'C' Expression Parsing in Forth?
>http://groups.google.com/group/comp.lang.forth/browse_thread/thread/ea1e29e3abddf3f6
>
>
>From: PagCal
>
>John Passaniti wrote:
>> PagCal wrote:
>>
>>> One of the problems I've been trying to solve with forth was it's
>>> arcaine language with a steep learning curve. I felt that a 'c'
>>> syntax, optionally provided within forth, would provide a stepping
>>> stone. New users would stick to the familiar 'c' but then branch out
>>> into forth as they became more comfortable with it.
>>
>>
>> A fundamental question to ask here is what value do you think Forth has
>> as a language? With your (optional) facility, you've removed two of
>> it's defining attributes (a programmer-visible stack with nameless items
>> for you?
>
>It provides a useful structure to investigate what a programming
>language should be.
You are kidding.
But my question to you is, what is it about Forth that
attracts you?
>>> Example:
>>>
>>> : times ( a b -- resultant-product )
>>>
>>> c-expression ( a*b ) \ results of any 'c' expression pushed
>>> \ onto data stack
>>>
>>> nip nip
>>> ;
>>>
>>> I've also added 'c' statements, so you could rewrite the above as:
>>>
>>> : times ( a b -- resultant-product )
>>>
>>> c-statement ( a a*b; )
>>>
>>> drop
>>> ;
>>
>>
>> I think you've just wonderfully illustrated the "impedance mismatch"
>> between Forth and C with these examples. In 'times' you presumably push
>> the result of the a*b on the stack, which now doesn't have a name-- just
>> a position on the stack. And because it doesn't have a name, if I want
>> to use this value in a subsequent calculation, how do I reference it
>> from a c-expression? Even better, is the 'nip nip' that occurs in
>> 'times'. The programmer is freed from having to deal with the stack
>> with c-expression, and then in the next couple statements is forced
>> to... deal with the stack. And this helps the programmer how?
>
>Well, I left out a bit. Along with c-statements, I support
>class/union/struct, subroutines, and am generally extending the 'c'
>syntax over time to where it'll do the entire c file.
Your goal is to take C syntax and produce what you
think is Forth code. But it is not handling data in
the ordinary Forth way because you are using a stack
frame. I asked you before, and now ask you again,
where do you implement the stack frame that you referred
to?
>The 'times' example above could have been re-written:
>
> c-subroutine (
> int times ( int a, int b)
> {
> return a*b;
> }
> )
>
>>> A second plus for such an approach, is that a great deal of
>>> open-source 'c' code is available to be included into your project and
>>> this could be just compiled into forth along with whatever else you
>>> wanted. You thus shrink the project time down considerably.
>>
>>
>> This is perhaps your worst argument. In order to use that open source
>> 'C' code, your solution requires me to edit the original 'C' code (which
>> is typically going to be a set of functions and data structures, not
>> just a simple c-expression and c-statement) and wrap it with Forth. Why
>> would I want to do that?
PagCal, you do not answer this. But it seems clear to me that
you want to be able to compile just about any C source.
>> If I want to integrate C and Forth code, a much better and cleaner
>> solution is to come up with a call interface between the two languages.
>> Allow C code to call words from Forth, and Forth code to call functions
>> from C. Both languages stay as they are, both fully retaining all their
>> benefits.
>>
>
>I've done that as well in two ways. dlopen/close will map constructs out
>of libraries, and I wrote a tool to declare 'c' subroutines to my forth
>engine. The tool builds all of the hooks necessary to just plop the 'c'
>code into the executable.
(cut)
>>> Compare the above with what you can groak in with CREATE DOES> and you
>>> can see the above is a lot cleaner.
>>
>>
>> It's horrific. You have the programmer having to shift mindsets between
>> Forth and C with no benefit visible other than you don't have to juggle
>> items on the stack inside a c-expression or c-statement. But as soon as
>> that c-expression or c-statement ends, the programmer is tossed back
>> into the world of dealing with the stack-- presumably what you were
>> trying to avoid.
>
>Shift Mindsets? That's an interesting way to look at programming languages.
>
>I rather view all these modern languages trying to do the same things,
>but using different syntax to achieve these goals.
>
>For example, you've got to interate over something. In 'c', you'd do
>
> for ( i 0 ; i < 10 ; i++ ) {
>
> }
>
>but in forth, you'd do:
>
> 10 0 do
>
> loop
>
My question is about the implementation in Forth. What kind of
code do you generate from your c-expressions and c-statements?
They don't seem to be Forth-like, or are they. What about factoring?
Your example doesn't really illustrate what kind of code
you generally produce.
(cut)
Bob Jaffray
bobja...@juno.com
>TOPIC: 'C' Expression Parsing in Forth?
>Date: Sat 6 Aug 2005 09:51
>From: "Elizabeth D Rather"
>
><bobja...@juno.com> wrote in message
>news:1123344939....@z14g2000cwz.googlegroups.com...
>> ...
>> This is your fundamental objection, John. It is not so much
>> that you object to implementing named stack items because
>> of innumerable objections that you can pick on, but that
>> you are really _attached_ to nameless stack items as a
>> fundamental value in Forth.
>
>Bingo.
The fundamental value in Forth is the fact of data items
on a data stack handled off the stack, not whether or
not they are named in the source code. In what I
presented, it should be obvious that the stack order
is just as important as ever. And the proof is the
Forth stack operations that are generated. The
stack thrashing should be obvious on testing.
>> PagCal and I, however, see nameless stack items as a
>> very serious impediment to people becoming interested
>> in Forth. In addition I see nameless stack items within the
>> high-level source as unclear and not self-documenting.
>Yes, that is clear. However, that is like saying to get more people
>interested in swimming you have to introduce water-bicycles to attract
>bikers.
That is a very poor analogy, and does not illustrate the
problem at all.
>Swimming is a skill in itself, and the pleasures of water are
>different from the pleasures of biking. The important attractions to Forth
>are its interactive programming style and overall simplicity,
This is true, along with its extensibility.
>... both of which
>are direct consequences of using the stack as it was designed to be used.
Using the stack as it was designed to be used and the
source code to use the stack as it was designed to be
used are different things.
In PagCal's use, he says he is not using the Forth
data stack in the normal way. I object. He says he
doesn't care about the inefficiencies introduced.
I object. He is doing something entirely different
from what I proposed.
But I applaud his interest in doing something about
the extensive C-libraries to bring them into the
Forth world. If he can produce a method of converting
them with little effort, then they would be in
Forth instead of having to call them in a foreign
environment. Then they could be converted further
to make them work in a Forth way instead of his
hybrid way.
>Learning to use the stack effectively is far easier than developing
>complicated mechanisms for avoiding it.
That is for another thread.
>> ...
>> To answer your question of what value is there in
>> programming in Forth, I would answer that it is not
>> in a stack with nameless items, but it its
>> efficient modularity, ease in testing, and many
>> other features that have nothing to do with the
>> stack items being nameless.
>
>Actually, it has a lot to do with it. It's a lot easier to type a sequence
>of commands that operate on nameless stack items than having to make up a
>whole definition with names, for example, which is a major component in the
>"ease in testing" that we love.
You are content to type a lot. I am not, so I _very_
much prefer a source file. But the turnaround even
then is very easy.
>The simplicity and modularity of Forth is
>also considerably facilitated by the stack as it is; the mechanisms you
>propose add a considerable layer of complexity to the process of defining
>and testing a word.
That may be true for PagCal's development, but
not with what I proposed. I deny it. When used
with a decompiler and debugger it is identical to
your Forth. When used without a decompiler and
debugger it is identical to your Forth. The
only difference is if you don't use source code.
>>
>> You nay-sayers keep presuming this, but it is as obvious
>> as can be that PagCal is _not_ trying to avoid the stack.
>> He is rather trying to provide an avenue for people put off
>> by Forth to get into it. And he said exactly that.
>
>One does not learn swimming by practicing bicycling skills. One needs to
>get wet. Concealing Forth's essential nature and compromising its main
>advantages will not do anything for anyone.
I agree entirely. The way PagCal is proposing it,
he is substituting C-like expressions and complicating
Forth without helping non-Forthers to obtains its
main advantages. His solution will not do anything
to help non-Forthers get into writing good Forth,
or even get into Forth at all. It is misguided
in that regard.
However, his efforts may be valuable in other ways,
if he can provide all those C-libraries in a Forth
enviornment with the possibility of removing
his hybrid features. Most respondents have indicated
that translations of C produce very bad Forth
code.
Is there a way to automatically convert the
typical implementation of locals into normal
unnamed stack items?
Bob Jaffray
bobja...@juno.com
>TOPIC: 'C' Expression Parsing in Forth?
>Date: Sat 6 Aug 2005 10:37
>From: "Jeff Fox"
>
>bobja...@juno.com wrote:
>> This is your fundamental objection, John. It is not so much
>> that you object to implementing named stack items because
>> of innumerable objections that you can pick on, but that
>> you are really _attached_ to nameless stack items as a
>> fundamental value in Forth.
(cut)
>
>But in this case John and I seem to agree that we
>both understand Forth well enough to understand that
>the logic behind Forth starts with the idea that
>Forth is factoring facilitated by a parameter stack
>for unnamed items. Everyone says, throw that and
>you are throwing out Forth and doing something
>totally different.
I agree that the logic behind Forth starts with the
idea of factoring facilitated by a parameter stack,
but not that the items on the ordinary Forth data
stack must be unnamed in the source. What is important
to Forth is the actual stack and seeing what is
going on - which is what I insist be retained for
the very efficiency of the language - not whether
or not they are named.
>> PagCal and I, however, see nameless stack items as a
>> very serious impediment to people becoming interested
>> in Forth.
>Many many people see throwing out Forth as the only
>way to get people who don't like Forth to become
>interested. There is serious logic there. It is
>true.
There is serious failure in logic here. If you were
implementing a different language in an un-Forth-like
way, it would indeed be throwing out Forth. And this
has been done. PagCal is doing it all over again. Or
else he is constructing a hybrid. It is doubtful that
anyone starting with and using his hybrid would ever
get to coding that would generate Forth. I agree with
his stated motive but I think his prescription is
self-defeating and wrong.
>If you call for Forth to be drummed out and expunged
>from the face of the earth the idea will be popular
>with more people than those who like Forth today.
>So throwing away Forth and substituting something else
>to 'Forth' can be popular is the sort of logic that is
>popular in the world today.
I repeat that creating another languages that doesnt
act like Forth though it is written in Forth is
not Forth. But doing Fortran-like things and Lisp-like
things in one environment is immensely valuable.
Doing that is not throwing away Forth, but using
Forth in its normal way because it is so very
extensible.
>> In addition I see nameless stack items within the
>> high-level source as unclear and not self-documenting.
>Translation to English, "I see Forth as unclear and
>ineffective for programming and think it needs to be
>discarded and replaced with something completely
>and fundamentally different. And my opinion is
>the most popular opinion out there."
That is a false slander because I have taken pains
to counter that at every turn, and you know it!
Now I agree that what PagCal proposed is a hybrid
and not normal Forth. I proposed something
entirely different, and you know it!
>> Where PagCal and I differ is in the use of a stack
>> frame. But even there there are times when the extra
>> small overhead is something that can be lived with.
>> I see your purism as a stick-in-the-mud attitude.
>That's John's problem. People always call him a
>Forth purist! Or a Forth puritan. Or a Forth
>fundamentalist because he can't make rational
>decisions about Forth because of his religious
>attachment to it. ;-) (He is probably just trying
>to organize a Forth cult! Just joking John.)
Well I am not joking. I see you as too peas in a
pod, because you exhibit the same mentality of
confusing Forth source code with the way Forth
works. But in the case of locals, the use of a
stack frame, etc., _does_ add extra overhead because
it involves extra copying of data. Yet it can
be lived, especially when the overhead is not
an issue. I look on it as a crutch that is likely
to lead to sloppy programming.
I deny this in connection with my proposal of
named stack items, which are fundamentally
different. But naming the stack items would
go a long way to removing barriers to more
people becoming interested in Forth, and making
source code more self-documenting, but without
changing the way Forth works in the slightest
way.
>I probably shouldn't say anything, but I can't
>help but be amused by your dismissing John's
>arguments because he seems like a Forth purist
>to you. Don't worry if you don't get exactly
>why I would find that funny.
Well, does he think you are too much of a purist?
>So far I have been completey with John and everyone
>else except you and PagCal on this one.
PagCal and I have _entirely_ different views of
things. We only agree that there needs to be
something done about the barrier to people
getting interested in Forth. We have totally
different visions about what to do about it.
I don't share his vision of _mixing_ C and
Forth.
I don't dismiss his efforts at all, thought.
_If_ he can find a way to convert C libraries
into efficient Forth, that would be fine.
We might just get all the benefits of the work
of non-Forth programming into Forth. Then
we _could_ easily have Linux in Forth.
I am afraid though, that PagCal will not get
those libraries into efficient Forth but
a hybrid that really doesn't act like Forth.
>> But I already asked the question recently (Linux in Forth?)
>> if C-libararies had been converted into Forth with the
>> thought that the result _ought_ to be more compact and
>> run faster.
>Forth can sometimes be significantly more compact and
>sometimes faster than C. But almost never when it is
>doing things in the C way, like you would have to if
>you make copies of Unix drivers written in C.
I agree with this entirely. PagCal, would have to
demonstrate how his use of stack frames does
not introduce so much overhead that he gets
both the overhead of Forth plus the overhead
of C, making the it less efficient. Only if
C-libararies are converted into Forth working
in the Forth way would I expect the result to be
more compact and run faster.
>Most of the cases of the worst Forth I have seen were
>copies of C programs that did the same things as C but
>in in Forth instead.
Right.
>Years ago Mr. Moore said that it would be interesting
>to get a small group of Forth programmers and do
>something like Windows in Forth. I also think it would
>be interesting to do something like that, perhaps more
>Linux like than Windows like under the hood.
That was my question starting the other thread.
It looks like too much effort with too little interest.
But if PagCal could produce some code showing
us a small C-library that he has converted, then
it might be of interest to do it in Forth (rather
than his hybrid) for the comparison.
>I have no problem with the idea unless it is to make a copy
>of the C code in Forth.
I agree.
>> Instead, what I see is Forth written in C.
>I know. It isn't what you are talking about.
True. I was simply making a contrast. C-library
functions have not been written in Forth in the
Forth way.
>> You nay-sayers keep presuming this, but it is as obvious
>> as can be that PagCal is _not_ trying to avoid the stack.
>> He is rather trying to provide an avenue for people put off
>> by Forth to get into it. And he said exactly that.
>Right. He is talking about the programmer avoiding thinking
>about a stack.
That is patently false, otherwise he wouldn't have
given us an example that included stack operations like
NIP. You can't include stack operations in your code
without thinking about the stack. That should have
been obvious. My objection to that is that it makes
it more difficult to see what the code is doing. It
is even less self-documenting.
>Thinking about a stack is what puts programmers
>who don't like stack languages off in the first place.
That is probably true. Supplying names for the stack
items would ease this, while retaining the centrality
of the stack.
>The idea of a stack hidden in the implementation doesn't bother
>them, it is just having to think about factoring for a
>stack that is foreign to them.
That is also true. So that difficulty should also
be addressed. So I will ask it: Apart from the
rules of thumb given in _Thinking Forth_ etc.,
how do you go about determining the order of stack
items.
>>>Your c-expression and c-statement can't be seen as a way to improve
>>>time-to-market. It slows the programmer by having to switch mindsets
>>>between Forth and C and it only considers C code reuse at the expression
>>>and statement level which doesn't seem particularly compelling.
>>
>>>Gosh, all this work on your part just to avoid having to learn how to
>>>use the stack effectively. Was it worth it?
>>
>> This latter is an unworthy taunt, which doesn't correspond
>> to the motivation of expressed by PagCal.
>
>I think John was being direct and trying to express the idea again
>that if you learn to use the stack effectively in the first place you
>won't think it needs to be hidden behind a layer of C abstraction in
>the Forth language.
I agree with the basic criticism that John makes about
having to switch mindsets and the greater difficulty in
understanding what is happening on the stack. I disagree
that PagCal's motive was to avoid having to learn how to
use the stack, which he obviously was not saying in
view of the very examples he gave.
>He was saying that he thinks that you haven't given the
>idea of a stack, of Forth, a fair evaluation and that you
>can't give it a fair evaluation until you understand it.
>He was saying that you are premature in throwing out
>the Forth from Forth to make it more like C.
I deny all of that totally and completely.
>I have been saying for years that lots of people like
>the idea that throwing the Forth out of Forth could make
>it (Forth without Forth) more like C and COULD make it
>(Forth without Forth) more popular with people who like C
>but don't like Forth/stacks than Forth is today.
>What I find funny is that every few months someone in
>C.L.F proposes throwing out stack syntax, or throwing
>out stacks, or adding C expression parsing, or adding
>C stack frames and locals, or adding C style string
>handling, or adding C style printf syntax, or adding
>C function calls, or adding C library access, or
>adding C OS hooks, or adding C structures, or C
>this or that in order to make Forth more popular
>in a C world. What is funny is that they always
>get told, we already did all that but learned that
>throwing out the stacks and stack syntax was going
>too far. But complementing stack syntax with local
>syntax and all those other C ideas works very
>well in a C world.
The fact that it keeps coming back over and over and
over should tell you purists something. There wouldn't
be these continual repeated suggestions if the people
who make them were not attracted to Forth. You haven't
bothered to find out what the attraction is. If
they were satisfied with C they definitely would
never have approached Forthers. But I dare say
that you don't bother to do any more than you do
with PagCal.
>And it is well worth the admission price when you
>tell John that he doesn't understand your idea
>because he is a Forth purist. (It's an old joke
>don't worry about it.) John is very open to
>the idea of experimentation with new ideas in
>programming and to mixing ideas to get something
>new. I don't think he is too locked in to Forth
>purism. I might be. But so far I am with John
>on this one.
That is what I suspected from your other post
below.
>Date: Sat 6 Aug 2005 13:43
>From: "Jeff Fox"
>
>Elizabeth D Rather wrote:
>> to get more people interested in swimming you have
>> to introduce water-bicycles to attract bikers.
>>
>> Swimming is a skill in itself, and the pleasures
>> of water are different from the pleasures of biking.
>>
>> The important attractions to Forth
>> are its interactive programming style and overall
>> simplicity, both of which are direct consequences of
>> using the stack as it was designed to be used.
>>
>> Learning to use the stack effectively is far easier
>> than developing complicated mechanisms for avoiding it.
>
>That about sums Forth up!
>
>> One does not learn swimming by practicing
>> bicycling skills. One needs to get wet.
>> Concealing Forth's essential nature and
>> compromising its main advantages will not do
>> anything for anyone.
>
>I think it would. Destroying Forth by throwing
>away what makes it work is precisely what people
>who don't like Forth would like to see.
>
>Replace it with C. Call it Forth. The majority
>would then like Forth. PagCal and Bob are right
>about that.
I complained precisely about this attitude that you
are expressing. There is an immense value to Forth
other than unnamed items on the stack. PagCal
I think is really working toward C in Forth. I
am not and I really object to the insinuation that
what I suggested was replacing Forth with C and
calling it Forth. I did not! And I did not suggest changing
the way Forth works at all.
Other languages _have_ been implemented in Forth.
They are not Forth but languages implemented in
Forth. But Forth is eminently extensible, so
there is no reason for not implementing Forth-like
features compatible with Forth in a Forth-like
way.
>All the people who like and use Forth are saying
>that throwing out the idea of unnamed stack items
>would cripple and destroy Forth.
You mean all who are Forth purists say that, not
all who like and use Forth. You just don't like
their extensions, such as locals. I don't like
locals as they have been explained to me, but I
accept them. (Do you object to using >R and R>?
compared to the alternative?)
But you forgot completely that what I proposed
was named stack items, not locals, which uses
the Forth stack in the normal ordinary way, and
requires thinking in terms of the stack. But
you object even to that! And there is _no way_
that named stack items _in any way whatsoever_
cripples and destroys Forth.
Yet this proposal of naming stack items goes to
the heart of your objection as well as that of
other purists who think that unnamed stack items
in the source code are the essence of Forth,
rather than the way items actually are and are
used on the stack being the essence of Forth.
>Those who don't like the way Forth works say, so what, the result
>would be more to the liking of C programmers and
>there are more of them who don't like Forth than
>Forth programmers who do like Forth.
This is a totally false objection to named stack
items, since use of NSI does not change the way
Forth works in any way shape or form.
(cut)
Bob Jaffray
bobja...@juno.com
>TOPIC: 'C' Expression Parsing in Forth?
>Date: Sat 6 Aug 2005 14:14
>From: Jerry Avins
>
>bobja...@juno.com wrote:
>
>Bob,
>
>Your response is by form directed to PagCal.
>
>(cut)
>
That is an extremely pedantic objection.
Rather than sending out two posts with another
set of words duplicating each other, I
responded to both an earlier post and
the response to it together in one post.
Bob Jaffray
bobja...@juno.com
Alex McDonald
Pedantry has got nothing to do with it; it's an incredibly irritating
and annoying habit you have. You have now responded to me, and then
yourself, then yourself, then yourself...
Will you please find out how to use a newsreader properly. Your
credibility on any subject to do with computers is now accelerating
towards zero due to your inability to handle something as simple as a
set of reply buttons on a Google newsreader.
--
Regards
Alex McDonald
David Given
Hash: SHA1
Elizabeth D Rather wrote:
[...]
> I have taught Forth to several thousand programmers over my career. Those
> who come to the language believing that it's just a strange syntax that
> needs to be twisted into the programming style they already know have a
> lot of trouble and end up either writing very bad Forth or just giving up.
I agree with you; if you're writing in Forth you'll always end up with
better, simpler code by designing from the ground up using Forth's
conceptual framework.
However, there are situations where you're *not* doing this, and probably
don't want to. For example, for programs that do any sort of mathematical
heavy lifting, you've probably already had to solve the problem in terms of
a mathematical conceptual framework and have come up with a solution that's
almost certainly expressed as formulae. Converting these into Forth is a
completely mechanical process, and so it's entirely reasonable to have the
compiler do it for you.
For example, to pull some Forth-like syntax out of the air, this:
: solve-quadratic { a b c -- x1 }
((
( - b + sqrt ( b * b - 4 * a * c ) ) /
( 2 * a )
))
;
...is, to anyone with a mathematical background, *far* more familiar than
this:
: solve-quadratic ( a b c -- x1 )
over dup * >r ( a b c ) ( b^2 )
4 pick * 4 * ( a b 4ac ) ( b^2 )
r> swap - sqrt ( a b sqrt(...) )
swap - ( a topline )
swap 2 * ( topline 2a )
/
;
Hell, that took me five minutes and I don't even know if I did it right.
Plus, I'm really not happy about that pick.
[...]
> Learning multiple languages is certainly a good thing. But applying
> French or German syntax or word order on to English, or vice-versa, will
> just make
> you unintelligible. An eloquent speaker masters each language and uses
> the language superbly within its own rules and structure.
But there *are* some things that one language can say that simply cannot be
said in another language. English does not have a direct equivalent to the
German word schadenfreude, for example; and it's generally considered that
the Koran must be read in Arabic for it to make sense. It's all a matter of
picking the most appropriate tool for the job.
- --
+- David Given --McQ-+ "P.S. If you do not receive this, of course it
| d...@cowlark.com | must have been miscarried; therefore I beg you to
| (d...@tao-group.com) | write and let me know." --- Sir Boyle Roche, in a
+- www.cowlark.com --+ letter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFC90amf9E0noFvlzgRAvfdAKDDr5xOVGZ1bjNKr0K0OTh2/AvMiQCfe4n2
UWSFc/wnG3/ATDbwMdfwC9g=
=qu0B
-----END PGP SIGNATURE-----
Elizabeth D Rather
news:dCHJe.19452$Aw4....@newsfe5-win.ntli.net...
Well, I for one can't read that. The quadratic I learned in high school is:
a**2 + 2ab + b**2 + c
This factors quite nicely to:
(a + b)**2 + c
which in Forth is simply:
: quadratic ( a b c -- x )
-ROT + DUP * + ;
Simple, yes?
> ...is, to anyone with a mathematical background, *far* more familiar than
> this:
>
> : solve-quadratic ( a b c -- x1 )
> over dup * >r ( a b c ) ( b^2 )
> 4 pick * 4 * ( a b 4ac ) ( b^2 )
> r> swap - sqrt ( a b sqrt(...) )
> swap - ( a topline )
> swap 2 * ( topline 2a )
> /
> ;
>
> Hell, that took me five minutes and I don't even know if I did it right.
> Plus, I'm really not happy about that pick.
Blecch. Any time you get into a snarl like that you need to back out and
invest a little more thought in your solution. Brute force programming
always produces ugly results in any language. When we say the key to good
Forth programming is factoring, we don't just mean making small, callable
words. We also mean looking at the problem from the perspective of what its
natural logical elements are, which in the context of an algebraic
expression, means factoring it algebraically.
Jerry Avins
...
> Well, I for one can't read that. The quadratic I learned in high school
> is:
>
> a**2 + 2ab + b**2 + c
Sorry; not this time.
The classic quadratic factor is (ax^2 + bx + c), and equating that to
zero gives a the quadratic equation of elementary algebra fame. X is a
free variable, and a, b, and c are fixed coefficients.
> This factors quite nicely to:
>
> (a + b)**2 + c
>
> which in Forth is simply:
>
> : quadratic ( a b c -- x )
> -ROT + DUP * + ;
>
> Simple, yes?
Yes, but not to the point.
>> ...is, to anyone with a mathematical background, *far* more familiar than
>> this:
>>
>> : solve-quadratic ( a b c -- x1 )
But the solution has _two_ roots, so this is only half right even if it
works.
>> over dup * >r ( a b c ) ( b^2 )
>> 4 pick * 4 * ( a b 4ac ) ( b^2 )
>> r> swap - sqrt ( a b sqrt(...) )
>> swap - ( a topline )
>> swap 2 * ( topline 2a )
>> /
>> ;
Jerry
Andrew Haley
> Elizabeth D Rather wrote:
> ...
>> Well, I for one can't read that. The quadratic I learned in high school
>> is:
>>
>> a**2 + 2ab + b**2 + c
> Sorry; not this time.
> The classic quadratic factor is (ax^2 + bx + c), and equating that to
> zero gives a the quadratic equation of elementary algebra fame. X is a
> free variable, and a, b, and c are fixed coefficients.
>> This factors quite nicely to:
>>
>> (a + b)**2 + c
>>
>> which in Forth is simply:
>>
>> : quadratic ( a b c -- x )
>> -ROT + DUP * + ;
>>
>> Simple, yes?
> Yes, but not to the point.
>>> ...is, to anyone with a mathematical background, *far* more familiar than
>>> this:
>>>
>>> : solve-quadratic ( a b c -- x1 )
> But the solution has _two_ roots, so this is only half right even if it
> works.
And it's none too good even then, as you (probably :-) remember we
discussed in 1999 ?
http://groups.google.co.uk/group/comp.lang.forth/msg/c3c5cc8a4263a7cc?hl=en&
The code I posted then looks pretty nasty to me now. Must resist
temptation to rewrite...
Andrew.
ward mcfarland
> Will you please find out how to use a newsreader properly. Your
> credibility on any subject to do with computers is now accelerating
> towards zero due to your inability to handle something as simple as a
> set of reply buttons on a Google newsreader.
At least he should figure out how to keep a reply in a thread. Each of
his replies shows up as a new topic of the same name in my newsreader,
which usually does an excellent job of handling threaded discussions.
ward mcfarland
> But the solution has _two_ roots, so this is only half right even if it
> works.
and does not deal with the case of imaginary roots, nor with scaling
issues if done with integer math.
Writing the algorithm in C would also have these issues, and might need
some way to return two imaginary values (four numbers). So the
protoytpe would need 7 arguments - 3 for the coeff's and pointers to
each of the real and imaginary results.
-- w
Andrew Haley
>>TOPIC: 'C' Expression Parsing in Forth?
>>Date: Sat 6 Aug 2005 09:51
>>From: "Elizabeth D Rather"
>>
>><bobja...@juno.com> wrote in message
>>news:1123344939....@z14g2000cwz.googlegroups.com...
>>> ...
>>> This is your fundamental objection, John. It is not so much
>>> that you object to implementing named stack items because
>>> of innumerable objections that you can pick on, but that
>>> you are really _attached_ to nameless stack items as a
>>> fundamental value in Forth.
>>
>>Bingo.
> The fundamental value in Forth is the fact of data items
> on a data stack handled off the stack, not whether or
> not they are named in the source code.
No, that's not true. The fact that items are passed on the stack is
of fundamental importance.
>>> PagCal and I, however, see nameless stack items as a
>>> very serious impediment to people becoming interested
>>> in Forth. In addition I see nameless stack items within the
>>> high-level source as unclear and not self-documenting.
>>Yes, that is clear. However, that is like saying to get more people
>>interested in swimming you have to introduce water-bicycles to attract
>>bikers.
> That is a very poor analogy, and does not illustrate the
> problem at all.
Works for me. Elizabeth's explanantion was excellent. If you want to
ignore the most experienced teacher of Forth in the world, that's your
loss.
>>... both of which
>>are direct consequences of using the stack as it was designed to be used.
> Using the stack as it was designed to be used and the source code to
> use the stack as it was designed to be used are different things.
>>Learning to use the stack effectively is far easier than developing
>>complicated mechanisms for avoiding it.
> That is for another thread.
It is the crux of the matter. If you ever learn to use the stack
you'll wonder what all the fuss was about. It's a skill, just like
riding a bike.
>>The simplicity and modularity of Forth is
>>also considerably facilitated by the stack as it is; the mechanisms you
>>propose add a considerable layer of complexity to the process of defining
>>and testing a word.
> That may be true for PagCal's development, but not with what I
> proposed. I deny it. When used with a decompiler and debugger it is
> identical to your Forth. When used without a decompiler and debugger
> it is identical to your Forth.
No it isn't: the source form is different.
> The only difference is if you don't use source code.
No, we're talking about source. To repeat: the simplicity and
modularity of Forth is facilitated by the explicit use of the stack
*in Forth source code*.
Andrew.
Jerry Avins
...
>>>>: solve-quadratic ( a b c -- x1 )
>
>
>>But the solution has _two_ roots, so this is only half right even if it
>>works.
>
>
> And it's none too good even then, as you (probably :-) remember we
> discussed in 1999 ?
> http://groups.google.co.uk/group/comp.lang.forth/msg/c3c5cc8a4263a7cc?hl=en&
I remember it well. It seemed like more detail than the current thread
warrants.
> The code I posted then looks pretty nasty to me now. Must resist
> temptation to rewrite...
Good idea.
Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Jerry Avins
How about a single pointer to a structure that holds the coefficients on
entry and the results on exit? That works for both C and Forth. Since
only three entries are use on entry, but four are needed on exit, the
programmer must know whether she's coming or going. Admittedly, that's
too big a burden for some, but they don't count. :-)
Jerry Avins
In Thunderbird, his replied appear to be to the first message in the
thread and therefore usually to himself. What reader do you use?
Alex McDonald
> ward mcfarland wrote:
>
>> Alex McDonald <alex...@btopenworld.com> wrote:
>>
>>
>>> Will you please find out how to use a newsreader properly. Your
>>> credibility on any subject to do with computers is now accelerating
>>> towards zero due to your inability to handle something as simple as a
>>> set of reply buttons on a Google newsreader.
>>
>>
>>
>> At least he should figure out how to keep a reply in a thread. Each of
>> his replies shows up as a new topic of the same name in my newsreader,
>> which usually does an excellent job of handling threaded discussions.
>
>
> In Thunderbird, his replied appear to be to the first message in the
> thread and therefore usually to himself. What reader do you use?
>
> Jerry
Not addressed to me directly, I know, but Tbird at home and Google
groups at work. Dropped Outlook after Anton rightly complained that the
line wrapping on my posts was all out.
--
Regards
Alex McDonald
John Passaniti
> John might find it funny to be accused of not making
> rational decisions about Forth because of an emotional
> attachment to it. I think it's funny because for years
> John has said that I can't make rational decisions about
> Forth because I love it and have an emotional attachment
> to it and I have saidthat he can't make rational decisions
> about Forth because he has a different kind of emotional
> attachement to Forth. ;-)
I can't remember ever making that argument about you, Jeff. My
statements about your irrationality have nothing to do with your love
for Forth. Your irrationality comes more from an assortment of
character flaws, a deep persecution complex, and your constant need to
divide the world into a them-verses-us conflict.
> But in this case John and I seem to agree that we
> both understand Forth well enough to understand that
> the logic behind Forth starts with the idea that
> Forth is factoring facilitated by a parameter stack
> for unnamed items. Everyone says, throw that and
> you are throwing out Forth and doing something
> totally different.
Not exactly. I don't agree that "Forth is factoring." Statements like
that are good if you want to express an idea in vague and useless koans,
but as an engineer, they don't do much for me. And I bet they certainly
won't do much for Bob Jaffrey or PagCal. I've worked with enough
different languages and methodologies over the years to know that *all*
worthwhile programming is factoring, and that is completely independent
of language.
What I do see in Forth is a set of facilities that allow and encourage
factoring to occur at a lower level than most other languages. But I
don't believe that makes Forth superior in terms of factoring.
Sometimes the higher-level factoring that can be done in other languages
leads to solutions that are intensely satisfying and elegant.
A good example of this comes from the interest, research, and tools used
to "refactor" code. While the Forth community talks a lot about
factoring, it is usually not much more than general and often vague
statements that apply specifically to Forth. The refactoring community
on the other hand has studied higher-level factoring to the point where
the transformations have been cataloged, have specific names, can often
be applied independent of language, and are discussed pragmatically not
only in terms of benefit, but also cost.
In other words, there is a much larger and more sophisticated world out
there concerned with factoring. I see Forth filling one end of the
factoring spectrum, and the work and research from the refactoring
community filling the other. Any modern programmer who wants to remain
relevant needs to understand the complete spectrum of factoring, not
just low-level factoring in Forth, and not just the higher-level
factorings the refactoring community has come up with.
But back to Forth, I do agree that the kind of factoring that happens in
Forth is greatly facilitated by unnamed items on a stack. And there is
no great mystery there-- a fundamental and distinguishing feature that
defines Forth is a programmer-visible stack. If you don't have that,
you don't have Forth.
Named stack items and automatically generated code from C-style
expressions serve to do the exact opposite; they insulate the programmer
from the stack. And worse, in both Bob's and PagCal's descriptions they
don't even do that completely enough. There is still a jarring
transition between the programmer having to be aware of and responsible
for the stack, and abstraction to insulate the programmer from the stack.
> He was saying that he thinks that you haven't given the
> idea of a stack, of Forth, a fair evaluation and that you
> can't give it a fair evaluation until you understand it.
> He was saying that you are premature in throwing out
> the Forth from Forth to make it more like C.
Mostly. Whenever these discussions come up, you tediously lump
everything that isn't Forth as being "like C." Maybe it's because I
work with some many languages, but I can think of a variety of
abstractions that programming languages use to hide parameter passing
that aren't anything like the semantics of C.
In other words, Bob's idea to add named stack items doesn't make Forth
"like C" unless your threshold for "like C" is absurdly low. I don't
consider named stack items to be "like C" at all, especially considering
that syntactically, he doesn't try to use infix expressions.
It's PagCal's ideas that are more "like C," but ironically he seems to
have come up with a hybrid that ignores the unique benefits of both
languages and blends them into a mess that I can't imagine would be
compelling to any programmer. He cites the ability to incorporate the
wealth of C code in the world-- after tediously wrapping it in
c-expressions, c-statements, and apparently other constructs. Not
answered is what benefit the programmer gains by taking perfectly good C
code, wrapping and decorating it with some Forth syntax, and then having
to deal with the impedance mismatch between the mental models the
languages provide. It would be far simpler to recognize the strengths
of both languages and provide a sensible call interface between the two.
> And it is well worth the admission price when you
> tell John that he doesn't understand your idea
> because he is a Forth purist. (It's an old joke
> don't worry about it.) John is very open to
> the idea of experimentation with new ideas in
> programming and to mixing ideas to get something
> new. I don't think he is too locked in to Forth
> purism. I might be. But so far I am with John
> on this one.
I understand both Bob's and PagCal's idea. I reject them not because
I'm a Forth purist, but because when I objectively evaluate them, I
can't see the benefit in either. I might warm to Bob's named stack
items if he could actually define the semantics clearly and fully, but
he doesn't do that. And that's why I reject the idea. I've brought up
real problems and concerns with the idea that Bob tosses away with vague
statements about how the compiler automagically figures out how to
address items on the stack. Sorry, not good enough.
PagCal's idea I reject because C and Forth are perfectly good languages
by themselves, but make little sense blended together in the way he
proposes. And I reject it on philosophical grounds: He hasn't yet
figured out how language shapes thought; how the idioms and abstractions
provided by languages don't all reduce down to the same thing at the
conceptual level. And that I gather is because he either hasn't yet
been exposed to radically different models for computation, or he has
but is considering them only superficially.
ward mcfarland
> How about a single pointer to a structure that holds the coefficients on
> entry and the results on exit? That works for both C and Forth. Since
> only three entries are use on entry, but four are needed on exit, the
> programmer must know whether she's coming or going. Admittedly, that's
> too big a burden for some, but they don't count. :-)
After posting, I got thinking along those lines myself. Of course, this
supports Moore's position that when the solution starts to get to
complex, one should rethink the problem.
-- w
ward mcfarland
> In Thunderbird, his replied appear to be to the first message in the
> thread and therefore usually to himself. What reader do you use?
I use MacSoup, which usually very vigorously preserves threads and
displays them graphically in a handy tree format.
On the thread title "'C' Expression Parsing in Forth?", I show one
longish (26 msg) thread, and 6 additional ones, all started by Bob J
(ranging from 1 to 6 messages each).
The "Named Stack Items" thread had spawned into 15 identically named
threads, each new one started by a message from him.
Each time he replies, it starts a new thread.
David Given
Hash: SHA1
Elizabeth D Rather wrote:
[...]
> Well, I for one can't read that. The quadratic I learned in high school
> is:
Actually, I'm trying to *solve* the quadratic, not simply evaluate it ---
given:
ax^2 + bx + c = 0
...where a, b and c are constants, I'm trying to find x. There's a standard
formula for doing this. You just plug in the numbers and evaluate:
-b +/- sqrt(b^2 - 4*a*c)
x = ------------------------
2*a
For simplicity (I probably should have mentioned this), I was only
considering the positive root, and was ignoring any float-vs-int problems.
http://en.wikipedia.org/wiki/Quadratic
[...]
> Blecch. Any time you get into a snarl like that you need to back out and
> invest a little more thought in your solution. Brute force programming
> always produces ugly results in any language.
*nods*
Unfortunately, the solution to this problem can't really be refactored ---
that formula *is* the way to solve the problem. It's been worked out by
generations of mathematicians and is probably as good as it gets. My task,
as a Forth programmer, is to translate that formula efficiently into Forth.
However I do it, I have to have a word that takes three parameters and
returns one.
(I should point out that I'm not actually trying to solve *this* problem.
I'm just presenting this as an example of a class of problems.)
In languages such as Fortran (== Formula Translator), I can just give it the
formula --- the language was designed like that because it's the most
appropriate way of solving its particular design requirements. In Forth,
well, I can't; Forth's design requirements did not include being able to
plug in mathematical formulae. What you I really want to do in this case is
to use infix notation, and Forth doesn't give me that option.
This is a situation where a language addon that implements infix would be a
*real* help. That doesn't mean that every problem should use it, though.
(Incidentally, the only elegant ways I can think of to do this in standard
Forth is to either use locals or to indirect through a memory structure,
which means my word is slow and not thread-safe any more.)
- --
+- David Given --McQ-+ "There is one thing a man must do // Before his
| d...@cowlark.com | life is done; // Write two lines in APL // And make
| (d...@tao-group.com) | the buggers run."
+- www.cowlark.com --+ --- The Devil's DP Dictionary
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFC+LV/f9E0noFvlzgRAgsiAJsFdPzD5/S0yeoGcIz54vnUlWBBXwCeO5fi
zqZebyTlFYRyHwrdYo5yDaE=
=jrl+
-----END PGP SIGNATURE-----
Andrew Haley
> Elizabeth D Rather wrote:
> [...]
>> Well, I for one can't read that. The quadratic I learned in high school
>> is:
> Actually, I'm trying to *solve* the quadratic, not simply evaluate it ---
> given:
> ax^2 + bx + c = 0
> ...where a, b and c are constants, I'm trying to find x. There's a standard
> formula for doing this. You just plug in the numbers and evaluate:
> -b +/- sqrt(b^2 - 4*a*c)
> x = ------------------------
> 2*a
> For simplicity (I probably should have mentioned this), I was only
> considering the positive root, and was ignoring any float-vs-int problems.
> http://en.wikipedia.org/wiki/Quadratic
[ ... ]
> Unfortunately, the solution to this problem can't really be refactored ---
> that formula *is* the way to solve the problem. It's been worked out by
> generations of mathematicians and is probably as good as it gets.
No it isn't! The notion that this is the one true way to solve a
quadratic is Just Plain Wrong -- it probably shouldn't be taught, and
it certainly shouldn't be mentioned in Wikipedia in this form. See my
posting.
Andrew.
Jerry Avins
...
> Actually, I'm trying to *solve* the quadratic, not simply evaluate it ---
> given:
>
> ax^2 + bx + c = 0
>
> ...where a, b and c are constants, I'm trying to find x. There's a standard
> formula for doing this. You just plug in the numbers and evaluate:
>
>
> -b +/- sqrt(b^2 - 4*a*c)
> x = ------------------------
> 2*a
>
> For simplicity (I probably should have mentioned this), I was only
> considering the positive root, and was ignoring any float-vs-int problems.
1) Both roots of the quadratic can be positive.
2) For certain values of the coefficients, the solution for one of the
roots becomes numerically unstable. It is then wise to use the formula
2*c
x = ------------------------
-b -/+ sqrt(b^2 - 4*a*c)
There's more discussion in A.H.'s reference to
http://groups.google.co.uk/group/comp.lang.forth/msg/c3c5cc8a4263a7cc?hl=en&.
bobja...@juno.com
You addressed this to Ward but my "newsreader" is the digest sent
out and downloaded so that it is offline through juno.com.
This as well as google groups intercollates my posts so
that they appear in the normal way (except once, where the
thread topic got duplicated). My replies in both cases do
not appear to be the first message or appear to be me
replying to myself.
I have mentioned that the reply method given at the bottom
of each post for sending an email does not work for me, so
I am forced to cut and paste. Unless I can hunt around on
google and find the original post to paste into I am forced
to "start a new thread." None of you have given me any
method to do any different. You have all _only_ given
me instructions for replying on-line (which I am doing
right now)!
> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Alex McDonald
Which appears, on Google so far, to work a treat; this message is
correctly threaded.
--
Regards
Alex McDonald
bobja...@juno.com
Of course! since it was done online. But that's the problem.
I am not able to do it online all the time, and you haven't
suggested an alternative.
Bob Jaffray
Marc Olschok
Actually, the above formula is only of theoretical interest insofar,
as it describes the solutions in the general case.
Given a particular equation one should however take advantage of
the special form the given equation might have.
I have seen people using the above formula for equations like
x^2+1 = 0 etc. This should not happen.
Depending on the intended use of the results, it may also
be helpful, not to evaluate too much and just stop after
rewriting the equation as
a(x+b/(2a))^2 + (4ac - b^2)/(4a)) = 0
which keeps more information about the associated inequalities as well.
Of course, all this is unrelated to the original syntax question,
but I think that a Forth solution would perhaps pay attention
to the actual use of the required results and take advantage
of the special features of the input instead of solving a more
general problem than needed.
More to the point, the first step towards factoring would probably be
: monic ( c b a -- c/a b/a ) tuck / >r / r> ;
which of course corresponds to considering the equivalent equation
x^2+px+q = 0 (where p=b/a and q=c/a)
the next step could be
: elim_lin ( q p -- p/2 q (p/2)^2 ) 2/ tuck dup * ;
which corresponds to rewriting x^2+px+q as
(x+q/2)^2 + q - (p/2)^2
It is easy to take up from there, depending on the actual form
of the required result.
>
> (I should point out that I'm not actually trying to solve *this* problem.
> I'm just presenting this as an example of a class of problems.)
That is ok. I hope that I could still convey the idea that
"plug in mathematical formulae" is perhaps a rare strategy
within Forth.
Marc
ward mcfarland
> Which appears, on Google so far, to work a treat; this message is
> correctly threaded.
for me as well
bobja...@juno.com
John Passaniti wrote:
> Jeff Fox wrote:
(cut)
> > But in this case John and I seem to agree that we
> > both understand Forth well enough to understand that
> > the logic behind Forth starts with the idea that
> > Forth is factoring facilitated by a parameter stack
> > for unnamed items. Everyone says, throw that and
> > you are throwing out Forth and doing something
> > totally different.
>
> Not exactly. I don't agree that "Forth is factoring." Statements like
> that are good if you want to express an idea in vague and useless koans,
> but as an engineer, they don't do much for me. And I bet they certainly
> won't do much for Bob Jaffrey or PagCal.
Right.
> I've worked with enough
> different languages and methodologies over the years to know that *all*
> worthwhile programming is factoring, and that is completely independent
> of language.
> What I do see in Forth is a set of facilities that allow and encourage
> factoring to occur at a lower level than most other languages. But I
> don't believe that makes Forth superior in terms of factoring.
Right again.
> Sometimes the higher-level factoring that can be done in other languages
> leads to solutions that are intensely satisfying and elegant.
> A good example of this comes from the interest, research, and tools used
> to "refactor" code. While the Forth community talks a lot about
> factoring, it is usually not much more than general and often vague
> statements that apply specifically to Forth.
It relates mainly to ease in development, not whether the
resulting product is superior or not. The same thing could
be done without factoring. The question is whether doing
it that way would result in more efficient code. And the
reason there is less attention to how the parameters get
processed.
(cut)
> But back to Forth, I do agree that the kind of factoring that happens in
> Forth is greatly facilitated by unnamed items on a stack. And there is
> no great mystery there-- a fundamental and distinguishing feature that
> defines Forth is a programmer-visible stack. If you don't have that,
> you don't have Forth.
Despite all the insinuations to the contrary that I don't understand
this, I agree entirely. The whole idea of converting named stack
items entirely to stack operations is to retain the stack and
its visibility to the programmer during development. What I
have seen of the discussion of locals and their use seems to
me to obscure this.
> Named stack items and automatically generated code from C-style
> expressions serve to do the exact opposite; they insulate the programmer
> from the stack.
I see it as only partially doing this, and in a way that
should enhance overall development. Contrary to criticisms
the idea of named stack items should foster better use of
the stack rather than the opposite. That is because
the generated stack operations will be fully visible
during testing. There is no intent to insulate the
programmer from the stack. Named stack items should
function both to self-document source and to aid
development.
> And worse, in both Bob's and PagCal's descriptions they
> don't even do that completely enough.
I think PagCal's description leaves the objection.
I deny that mine does. But I admit that to use named
stack items in any reasonable way it would have to be
done with a decompiler to make the stack more visible.
And that ought to go without saying. But I aver that
even without a decompiler one who uses named stack
items a lot will be able to see the stack effects in
the source.
> There is still a jarring
> transition between the programmer having to be aware of and responsible
> for the stack, and abstraction to insulate the programmer from the stack.
> > He was saying that he thinks that you haven't given the
> > idea of a stack, of Forth, a fair evaluation and that you
> > can't give it a fair evaluation until you understand it.
> > He was saying that you are premature in throwing out
> > the Forth from Forth to make it more like C.
>
> Mostly. Whenever these discussions come up, you tediously lump
> everything that isn't Forth as being "like C." Maybe it's because I
> work with some many languages, but I can think of a variety of
> abstractions that programming languages use to hide parameter passing
> that aren't anything like the semantics of C.
>
> In other words, Bob's idea to add named stack items doesn't make Forth
> "like C" unless your threshold for "like C" is absurdly low. I don't
> consider named stack items to be "like C" at all, especially considering
> that syntactically, he doesn't try to use infix expressions.
Moreover I have insisted that named stack items ought
to look in there declaration exactly like a stack comment.
It is about as close to normal Forth as you can get and
use names. And by converting these to usual Forth stack
operations it is internally identical to Forth and complete
non-C in character.
> It's PagCal's ideas that are more "like C," but ironically he seems to
> have come up with a hybrid that ignores the unique benefits of both
> languages and blends them into a mess that I can't imagine would be
> compelling to any programmer.
My view too. I applaud his efforts, but believe that they
are entirely misguided in helping people to get into Forth,
but rather would do the opposite.
> He cites the ability to incorporate the
> wealth of C code in the world-- after tediously wrapping it in
> c-expressions, c-statements, and apparently other constructs. Not
> answered is what benefit the programmer gains by taking perfectly good C
> code, wrapping and decorating it with some Forth syntax, and then having
> to deal with the impedance mismatch between the mental models the
> languages provide.
I agree that a very lot of explaining would be needed
to see the value.
> It would be far simpler to recognize the strengths
> of both languages and provide a sensible call interface between the two.
He says he includes that too.
> > And it is well worth the admission price when you
> > tell John that he doesn't understand your idea
> > because he is a Forth purist. (It's an old joke
> > don't worry about it.) John is very open to
> > the idea of experimentation with new ideas in
> > programming and to mixing ideas to get something
> > new. I don't think he is too locked in to Forth
> > purism. I might be. But so far I am with John
> > on this one.
>
> I understand both Bob's and PagCal's idea. I reject them not because
> I'm a Forth purist, but because when I objectively evaluate them, I
> can't see the benefit in either. I might warm to Bob's named stack
> items if he could actually define the semantics clearly and fully, but
> he doesn't do that. And that's why I reject the idea. I've brought up
> real problems and concerns with the idea that Bob tosses away with vague
> statements about how the compiler automagically figures out how to
> address items on the stack. Sorry, not good enough.
I don't think it is really all the vague. But I admit that
the hard part will be how to "backtrack" to remove extra
stack copying, or maybe "backtrack" to add copying where
necessary.
> PagCal's idea I reject because C and Forth are perfectly good languages
> by themselves, but make little sense blended together in the way he
> proposes.
I think there might be value in his idea _if_ he were
to show how he can convert C-like source into Forth-like
words.
> And I reject it on philosophical grounds: He hasn't yet
> figured out how language shapes thought; how the idioms and abstractions
> provided by languages don't all reduce down to the same thing at the
> conceptual level. And that I gather is because he either hasn't yet
> been exposed to radically different models for computation, or he has
> but is considering them only superficially.
That may be. He claims to have done quite a bit already.
The question is what the compilation from the C-syntax
produces. If it is C-like, then all he has done is produce
C in Forth. If it is Forth-like, then he is succeeding
to convert C source _to_ Forth. At this point this is all
unclear. I suspect he just has a hybrid C/Forth which
is sometimes just C and other times just Forth.
Bob Jaffray
(reply online from Google, but my online time is running out)
David Given
Hash: SHA1
bobja...@juno.com wrote:
[...]
> Of course! since it was done online. But that's the problem.
> I am not able to do it online all the time, and you haven't
> suggested an alternative.
You might want to check out the USENET section of this:
http://www.faqs.org/faqs/internet-services/access-via-email/
The key to making sure that threads are preserved is to ensure that your
References: headers are set correctly. I'm not sure how you'd do it
manually.
Probably your best bet, though, is to run something like Hamster
(http://www.elfden.co.uk/hamster/index.html). This is a local news server;
you can dial up, synchronise against your upstream news server, disconnect,
and then browse and reply to posts at your leisure. Once finished, you dial
up and synchronise again, and it will forward on your posts.
- --
+- David Given --McQ-+ "What appears to be a sloppy or meaningless use of
| d...@cowlark.com | words may well be a completely correct use of words
| (d...@tao-group.com) | to express sloppy or meaningless ideas." ---
+- www.cowlark.com --+ Anonymous Diplomat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFC+Odyf9E0noFvlzgRAt24AJ48KxdEjTg6tt/g/n0/5LWCTT/4PgCdHfj6
8tfY5tUu4xwGUdKPJC2yebo=
=8eAF
-----END PGP SIGNATURE-----
Elizabeth D Rather
news:1123603997.9...@f14g2000cwb.googlegroups.com...
Alex McDonald wrote:
> bobja...@juno.com wrote:
> > Jerry Avins wrote:
> > > ward mcfarland wrote:
> > > > Alex McDonald <alex...@btopenworld.com> wrote:
> > > >
> > > >
> > > >>Will you please find out how to use a newsreader properly. Your
> > > >>credibility on any subject to do with computers is now accelerating
> > > >>towards zero due to your inability to handle something as simple as
> > > >>a
> > > >>set of reply buttons on a Google newsreader.
...
Of course! since it was done online. But that's the problem.
I am not able to do it online all the time, and you haven't
suggested an alternative.
If what you're looking for is a way to do your thinking and composing
off-line, may I suggest that you put together your response however works
for you, using Notepad or whatever, then go on line, find the message you
wish to respond to, hit the Reply button, and then paste in your text.
After all, you have to be on line to post a message... the more you can do
on line the better your presentation will be and the more helpful we can be
for you.
Andrew Haley
> John Passaniti wrote:
>> But back to Forth, I do agree that the kind of factoring that
>> happens in Forth is greatly facilitated by unnamed items on a
>> stack. And there is no great mystery there-- a fundamental and
>> distinguishing feature that defines Forth is a programmer-visible
>> stack. If you don't have that, you don't have Forth.
> Despite all the insinuations to the contrary that I don't understand
> this, I agree entirely. The whole idea of converting named stack
> items entirely to stack operations is to retain the stack and its
> visibility to the programmer during development.
No, you don't understand. The idea of using named stack items serves
to obscure the stack operations. In Forth, the idea is for the
programmer to use the stack explicitly without any additional
syntactic sugar.
> What I have seen of the discussion of locals and their use seems to
> me to obscure this.
> That is because the generated stack operations will be fully visible
> during testing.
Not every Forth is decompilable, and besides who wants to look at
decompiled code during development?
> There is no intent to insulate the programmer from the stack. Named
> stack items should function both to self-document source and to aid
> development.
>> And worse, in both Bob's and PagCal's descriptions they
>> don't even do that completely enough.
> I think PagCal's description leaves the objection. I deny that mine
> does. But I admit that to use named stack items in any reasonable
> way it would have to be done with a decompiler to make the stack
> more visible. And that ought to go without saying.
Why would anyone want to use a Forth decompiler for anything? I've
never used one.
> Moreover I have insisted that named stack items ought to look in
> there declaration exactly like a stack comment. It is about as
> close to normal Forth as you can get and use names.
That's true, but it would be even closer to normal Forth if you didn't
use names!
>> And I reject it on philosophical grounds: He hasn't yet figured out
>> how language shapes thought; how the idioms and abstractions
>> provided by languages don't all reduce down to the same thing at
>> the conceptual level. And that I gather is because he either
>> hasn't yet been exposed to radically different models for
>> computation, or he has but is considering them only superficially.
> That may be.
This applies to you too.
If you learn to use Forth in the way that it was intended, you might
find that he's right. But, for some reason, you're resistant to doing
so.
Andrew.
Stephen Pelc
<bobja...@juno.com> wrote:
>Of course! since it was done online. But that's the problem.
>I am not able to do it online all the time, and you haven't
>suggested an alternative.
Presumably your ISP (juno?) has a news server - probably
news.juno.com.
Install a real newsreader such as Free Agent from
http://www.forteinc.com
Configure it as required (tedious but doable) and it will
do everything you need. If your ISP does not give you news
access, then try another ISP.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
bobja...@juno.com
>
>From: Andrew Haley
>
>bobja...@juno.com <bobja...@juno.com> wrote:
>
>>>TOPIC: 'C' Expression Parsing in Forth?
>
>>>Date: Sat 6 Aug 2005 09:51
>>>From: "Elizabeth D Rather"
>>>
>>><bobja...@juno.com> wrote in message
>>>news:1123344939....@z14g2000cwz.googlegroups.com...
>>>> ...
>>>> This is your fundamental objection, John. It is not so much
>>>> that you object to implementing named stack items because
>>>> of innumerable objections that you can pick on, but that
>>>> you are really _attached_ to nameless stack items as a
>>>> fundamental value in Forth.
>>>
>>>Bingo.
>
>> The fundamental value in Forth is the fact of data items
>> on a data stack handled off the stack, not whether or
>> not they are named in the source code.
>
>No, that's not true. The fact that items are passed on the stack is
>of fundamental importance.
I have been saying this all along. The stack is central,
and other implementations including use of the return
stack and secondary stacks, if they are not part of
machine architecture, are secondary. And it is not that
they are passed on the stack that the only thing central,
but how they are used too. If parametes are passed on
the data stack as a stack frame there is additional
overhead cleaning up the stack afterward, though
probably less extra copying than with the use of the
return stack.
(cut)
>> That may be true for PagCal's development, but not with what I
>> proposed. I deny it. When used with a decompiler and debugger it is
>> identical to your Forth. When used without a decompiler and debugger
>> it is identical to your Forth.
>
>No it isn't: the source form is different.
The source form and the operation of the stack are
so close that this is not relevant, and anyone using
named stack items should be able to see the connection
easily without much effort. On the other hand PagCal's
proposal really does obscure the stack because of his
use of stack frames.
>> The only difference is if you don't use source code.
>
>No, we're talking about source. To repeat: the simplicity and
>modularity of Forth is facilitated by the explicit use of the stack
>*in Forth source code*.
>Andrew.
The whole idea of named stack items is to make explicit
use of the stack in the source, but as named items.
The declaration of the names indicates the stack,
just as ordinary stack diagrams do. The only difference
is if you don't compile from source, as I said,
where you don't have a stack diagram and it is
only in your head because you are working
interactively. To look at your "source" in that
case you decompile, and there is no stack diagram.
Since F83 doesn't have locals I do not know what
decompiled words with locals look like. With the
use of named stack items decompiled words should look
just like yours.
Bob Jaffray
(copy & paste to reply at bottom of post, but difficult to find
hunting through the thread)
Jerry Avins
...
> The source form and the operation of the stack are
> so close that this is not relevant, and anyone using
> named stack items should be able to see the connection
> easily without much effort.
Translation: it's only obscured a little bit.
> On the other hand PagCal's
> proposal really does obscure the stack because of his
> use of stack frames.
>
>
>>>The only difference is if you don't use source code.
>>
>>No, we're talking about source. To repeat: the simplicity and
>>modularity of Forth is facilitated by the explicit use of the stack
>>*in Forth source code*.
>
>
>>Andrew.
>
>
> The whole idea of named stack items is to make explicit
> use of the stack in the source, but as named items.
Generally, Forth words consume their arguments. With named stack items,
the consumption process is hidden, therefore also the difference between
efficient ans inefficient stack order.
> The declaration of the names indicates the stack,
> just as ordinary stack diagrams do. The only difference
> is if you don't compile from source, as I said,
> where you don't have a stack diagram and it is
> only in your head because you are working
> interactively. To look at your "source" in that
> case you decompile, and there is no stack diagram.
With few exceptions, it's whacko to decompile what you've just written
by noodling at the console. Any code worth thought is worth writing out.
> Since F83 doesn't have locals I do not know what
> decompiled words with locals look like. With the
> use of named stack items decompiled words should look
> just like yours.
F83 is a lovely relic. To move forward, start in the present.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
george...@yahoo.co.uk
How do you compile code without source; have a compiler that reads
minds? (I don't think AI is that advanced yet) If you're referring to
typing definitions on the command line then there's still source code,
and most Forth's have ways to see it, such as using scroll bars to go
back to the definition or a history buffer (ColorForth is an exception
but according to Jeff Fox it doesn't allow compiling direct from the
keyboard but only from blocks). Generally when developing source code
for a program IMO most programmers will use a File or block. Short
throw away definitions for test purposes may be done at the command
line but that's about all. The value of the command line is to be able
to interactively test words w/o having to create a load of stubs,
calling functions to set up parameters and an executable.
>
> Since F83 doesn't have locals I do not know what
> decompiled words with locals look like. With the
> use of named stack items decompiled words should look
> just like yours.
Why not download an ANSI forth and try it. There are many that you
could (You don't specify what machine/OS you use so it's not easy to
say which).
>
> Bob Jaffray
>
> (copy & paste to reply at bottom of post, but difficult to find
> hunting through the thread)
No I just used Google as it was easier.
George Hubert
bobja...@juno.com
Jerry Avins wrote:
> bobja...@juno.com wrote:
>
> ...
>
> > The source form and the operation of the stack are
> > so close that this is not relevant, and anyone using
> > named stack items should be able to see the connection
> > easily without much effort.
>
> Translation: it's only obscured a little bit.
Yup. And even then it is readily available.
> > The whole idea of named stack items is to make explicit
> > use of the stack in the source, but as named items.
>
> Generally, Forth words consume their arguments. With named stack items,
> the consumption process is hidden, therefore also the difference between
> efficient ans inefficient stack order.
Not really, since I expect it to be readily apparent
during development and testing. I think you will object
even to that because you are accustomed to writing
without incremental testing.
> > The declaration of the names indicates the stack,
> > just as ordinary stack diagrams do. The only difference
> > is if you don't compile from source, as I said,
> > where you don't have a stack diagram and it is
> > only in your head because you are working
> > interactively. To look at your "source" in that
> > case you decompile, and there is no stack diagram.
>
> With few exceptions, it's whacko to decompile what you've just written
> by noodling at the console. Any code worth thought is worth writing out.
I agree. So working interactively generally occurs
mainly during testing.
(cut)
Bob Jaffray
bobja...@juno.com
That's right. As Jerry said, if it is not worth writing down
into source, it is not worth typing. And I responded that
interactive mode is mainly of value in testing.
> > Since F83 doesn't have locals I do not know what
> > decompiled words with locals look like. With the
> > use of named stack items decompiled words should look
> > just like yours.
> Why not download an ANSI forth and try it. There are many that you
> could (You don't specify what machine/OS you use so it's not easy to
> say which).
I am still in 16-bit mode with an old Intel 486. I
have asked repeatedly a recommendation for a public
domain ANS Forth, preferrably written in Forth.
> >
> > Bob Jaffray
> >
> > (copy & paste to reply at bottom of post, but difficult to find
> > hunting through the thread)
>
> No I just used Google as it was easier.
>
> George Hubert
I am doing that now, but my ISP has dropped me
three times while doing it. I have to work offline
more of the time.
Bob Jaffray
Jerry Avins
> Jerry Avins wrote:
>
>>bobja...@juno.com wrote:
>>
>> ...
>>
>>
>>>The source form and the operation of the stack are
>>>so close that this is not relevant, and anyone using
>>>named stack items should be able to see the connection
>>>easily without much effort.
>>
>>Translation: it's only obscured a little bit.
>
>
> Yup.
Nuff said!
> ... And even then it is readily available.
>
>>>The whole idea of named stack items is to make explicit
>>>use of the stack in the source, but as named items.
>>
>>Generally, Forth words consume their arguments. With named stack items,
>>the consumption process is hidden, therefore also the difference between
>>efficient ans inefficient stack order.
>
>
> Not really, since I expect it to be readily apparent
> during development and testing. I think you will object
> even to that because you are accustomed to writing
> without incremental testing.
Wherever did you come by that idea? I test each word as I write it,
trying to think up "edge" cases. If I find one, I either rewrite or
document it with line comments. (POLYforth's > and < took $8000, i.e.
MININT, to be a positive number. I could live with that for a while, so
I did. After that while, I rewrote them and recompiled the kernel.)
>>>The declaration of the names indicates the stack,
>>>just as ordinary stack diagrams do. The only difference
>>>is if you don't compile from source, as I said,
>>>where you don't have a stack diagram and it is
There are always stack diagrams in my source. They should be in your
source, too. If the word serves its purpose perfectly but the stack
diagram is wrong, that's just another kind of bug.
>>>only in your head because you are working
>>>interactively. To look at your "source" in that
>>>case you decompile, and there is no stack diagram.
>>
>>With few exceptions, it's whacko to decompile what you've just written
>>by noodling at the console. Any code worth thought is worth writing out.
>
>
> I agree. So working interactively generally occurs
> mainly during testing.
Writing code and testing are a unary exercise for me.
george...@yahoo.co.uk
Jerry said it after I did (perhaps you should check the time and date
on messages) so I couldn't have known he was going to say it.
> > > Since F83 doesn't have locals I do not know what
> > > decompiled words with locals look like. With the
> > > use of named stack items decompiled words should look
> > > just like yours.
>
> > Why not download an ANSI forth and try it. There are many that you
> > could (You don't specify what machine/OS you use so it's not easy to
> > say which).
>
> I am still in 16-bit mode with an old Intel 486. I
> have asked repeatedly a recommendation for a public
> domain ANS Forth, preferrably written in Forth.
>
Why? A 486 can run WIN98, assuming you have >8Megs of memory. Every
time you've asked you specified subroutine threading as well. Why PD ?
GPL comes with source as well so would IMO be just as suitable.
George Hubert
Stephen Pelc
<bobja...@juno.com> wrote:
>I am still in 16-bit mode with an old Intel 486. I
>have asked repeatedly a recommendation for a public
>domain ANS Forth, preferrably written in Forth.
At www.forth.org look for Rick van Norman's 0S2/DPMI
Forth. It works under DOS as well.
bobja...@juno.com
>
>TOPIC: 'C' Expression Parsing in Forth?
>
>
> 1 of 1
>Date: Thurs 11 Aug 2005 16:41
>From: Jerry Avins
>>>>use of the stack in the source, but as named items.
>>>Generally, Forth words consume their arguments. With named stack items,
>>>the consumption process is hidden, therefore also the difference between
>>>efficient ans inefficient stack order.
>> Not really, since I expect it to be readily apparent
>> during development and testing. I think you will object
>> even to that because you are accustomed to writing
>> without incremental testing.
>
>Wherever did you come by that idea? I test each word as I write it,
>trying to think up "edge" cases. If I find one, I either rewrite or
>document it with line comments. (POLYforth's > and < took $8000, i.e.
>MININT, to be a positive number. I could live with that for a while, so
>I did. After that while, I rewrote them and recompiled the kernel.)
So then, in contradiction to what you said previously that
the consumption process is hidden, it really isn't because
you see it in the process of development and testing - if
are doing it effortlessly with a minimum of additional
tools. You just don't want to do anything at all different
that you have been doing and expect some new feature to
fit that, instead of what is reasonable to use sensible
and proper tools in connection with the new feature.
>>>>The declaration of the names indicates the stack,
>>>>just as ordinary stack diagrams do. The only difference
>>>>is if you don't compile from source, as I said,
>>>>where you don't have a stack diagram and it is
>There are always stack diagrams in my source. They should be in your
>source, too.
You bet! And my declarations of named stack items _is_
a stack diagram of the input parameters. I have gone
through all that before, but Andrew suggests yet another
couple of examples which emphasize the point. See
my response to him.
>If the word serves its purpose perfectly but the stack
>diagram is wrong, that's just another kind of bug.
And with named stack items it would show up immeditely.
>>>>only in your head because you are working
>>>>interactively. To look at your "source" in that
>>>>case you decompile, and there is no stack diagram.
>>>With few exceptions, it's whacko to decompile what you've just written
>>>by noodling at the console. Any code worth thought is worth writing out.
>> I agree. So working interactively generally occurs
>> mainly during testing.
>Writing code and testing are a unary exercise for me.
That is exactly what I would expect, but it seemed
to be contradicted by your objections.
Bob Jaffray
Jerry Avins
There's no contradiction. The code should be transparent to anyone who
reads it, whenever it is read. You must have done very little
programming to believe that code that you wrote a year ago will be more
transparent to you that code written by a stranger.
>>>>>The declaration of the names indicates the stack,
>>>>>just as ordinary stack diagrams do. The only difference
>>>>>is if you don't compile from source, as I said,
>>>>>where you don't have a stack diagram and it is
>
>
>>There are always stack diagrams in my source. They should be in your
>>source, too.
>
>
> You bet! And my declarations of named stack items _is_
> a stack diagram of the input parameters. I have gone
> through all that before, but Andrew suggests yet another
> couple of examples which emphasize the point. See
> my response to him.
There are no named stack items in in your working code. They don't exist
for you in reality. As far as I know, you can't run Jan Coombs' code
because you don't have a Forth to run it on, and you haven't written
your own.
>>If the word serves its purpose perfectly but the stack
>>diagram is wrong, that's just another kind of bug.
>
>
> And with named stack items it would show up immeditely.
>
>
>>>>>only in your head because you are working
>>>>>interactively. To look at your "source" in that
>>>>>case you decompile, and there is no stack diagram.
>
>
>>>>With few exceptions, it's whacko to decompile what you've just written
>>>>by noodling at the console. Any code worth thought is worth writing out.
>
>
>>>I agree. So working interactively generally occurs
>>>mainly during testing.
>
>
>>Writing code and testing are a unary exercise for me.
>
>
> That is exactly what I would expect, but it seemed
> to be contradicted by your objections.
My point about opacity is that even what you write should be clear to me
without my having to load and decompile it. If the system doesn't
provide that, my own code won't be clear to me in a few months time.
Dave Thompson
wrote:
> Jerry Avins <j...@ieee.org> wrote:
>
> > But the solution has _two_ roots, so this is only half right even if it
> > works.
>
> and does not deal with the case of imaginary roots, nor with scaling
> issues if done with integer math.
>
> Writing the algorithm in C would also have these issues, and might need
> some way to return two imaginary values (four numbers). So the
> protoytpe would need 7 arguments - 3 for the coeff's and pointers to
> each of the real and imaginary results.
>
C99 has complex (in the core language) so it would probably be more
natural to point to two complex's, or even to one array (or struct)
containing such. Alternatively it is possible to _return_ a struct
but then you have to store the result before (nontrivially) unpacking
it; or a pointer to an array (but not an actual array) but then you
have to deal with managing allocation somehow.
C++, which is more widely implemented than C99 but not as widely as
C90 or earlier, has template complex<T> in the standard library.
- David.Thompson1 at worldnet.att.net