Paul Graham's accumulator generator
Roman Pavlyuk
I think many of you know Paul Grahmam's accumulator generator task -
http://store.yahoo.com/paulgraham/accgen.html . And you probably know
that Forth is not represented there. As Paul Graham writes in
accgensub.html, "I can't tell yet if you can write the program in
Forth. I've had several Forth submissions and I'm still trying to
puzzle out whether they're correct".
I was one of the sumbitters, but I got a reply since Forth does not
create "dynamic" function then it's not a right solution. I did not
find an argument then, and did not have time to do this actually (last
summer), but now I think that xt, returned by :noname is a very good
and dynamic function representation.
I just tried to implement this now - please see below. Is there anyone
who is willing to persuade Paul Graham that Forth is good for
everything, including his task?
2 usage examples - seems to be working fine in Gforth and SPF 3.75. I
think should be working in other ANS-94-compatible systems. Sorry if
the solution is not optimal - I'm an old FORTH-83 standard lover. And
ColorForth promoter :). Everything's upcase because due to some
considerations SPF is case-sensitive :(
----
GForth 0.5.0, Copyright (C) 1995-2000 Free Software Foundation, Inc.
GForth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
: acc> CREATE , DOES> @ >R :NONAME R> POSTPONE LITERAL POSTPONE +
POSTPONE ; ; ok
3 acc> 3+ ok
10 3+ execute . 13 ok
.s <0> ok
----
SP-Forth 3.75 (20.Nov.2000) ANS FORTH 94 for Win95/98/NT/2000
Copyright (C) 1992-2000 A.Cherezov http://www.forth.org.ru/
: acc> CREATE , DOES> @ >R :NONAME R> POSTPONE LITERAL POSTPONE +
POSTPONE ; ;
Ok
3 acc> 3+
Ok
10 3+ EXECUTE .
13 Ok
?STACK
Ok
----
Stack dump is included to make sure no junk is left.
Your comments?
Elko Tchernev
>
> I think many of you know Paul Grahmam's accumulator generator task -
> http://store.yahoo.com/paulgraham/accgen.html . And you probably know
> that Forth is not represented there. As Paul Graham writes in
> accgensub.html, "I can't tell yet if you can write the program in
> Forth. I've had several Forth submissions and I'm still trying to
> puzzle out whether they're correct".
>
> I was one of the sumbitters, but I got a reply since Forth does not
> create "dynamic" function then it's not a right solution. I did not
> find an argument then, and did not have time to do this actually (last
> summer), but now I think that xt, returned by :noname is a very good
> and dynamic function representation.
>
You are on the right track, and you don't even need CREATE. With
:noname one can create a truly functional function - a word that returns
an executable xt, and no need for a name. Like this:
: adder ( n -- xt )
>R :NONAME R> POSTPONE LITERAL POSTPONE + POSTPONE ;
;
You can even create a function, where the action itself is an argument -
like this:
: actor ( n action -- xt )
>R >R
:NONAME
R> POSTPONE LITERAL
R> POSTPONE LITERAL
POSTPONE EXECUTE POSTPONE ;
;
This can be used thus:
11 ' + ACTOR ok
5 swap execute . 16 ok
As I understand, a real submission must handle both integers and
FP, but DEPTH and FDEPTH can be used to see what kind of argument it
got. I think this is OK, since the example Mozart program on that page
explicitly checks to see what kind of arguments it got.
This Paul Graham guy disappoints - how can he not tell whether the
Forth submissions are correct or not? And I wonder what "incrementing" a
FP number by some other number would mean, if not addition?
--
I want to be a nothing-knower, Elko Tchernev
a little ant on any hill; etc...@cs.umbc.edu
for time is dead, the sun is over www.gl.umbc.edu/~etcher1
and there is nothing left to kill.
Stephen J. Bevan
> This Paul Graham guy disappoints - how can he not tell whether
> the Forth submissions are correct or not? And I wonder what
> "incrementing" a FP number by some other number would mean, if not
> addition?
It does mean addition, but it also mean you must update the variable
with the sum of the two values. Granted I didn't get that from the
English description. I got that from looking at the various accepted
solutions.
Stephen J. Bevan
> I think many of you know Paul Grahmam's accumulator generator task -
> http://store.yahoo.com/paulgraham/accgen.html . And you probably know
> that Forth is not represented there. As Paul Graham writes in
> accgensub.html, "I can't tell yet if you can write the program in
> Forth. I've had several Forth submissions and I'm still trying to
> puzzle out whether they're correct".
> I just tried to implement this now - please see below. Is there anyone
> who is willing to persuade Paul Graham that Forth is good for
> everything, including his task?
The requirements from the page are :-
The problem: Write a function foo that takes a number n and
returns a function that takes a number i, and returns n
incremented by i.
Note: (a) that's number, not integer, (b) that's incremented
by, not plus.
Your program only works for integers and so does not satisfy (a).
Your program does not update the CREATed value with the sum of itself
and the argument and so it doesn't satisfy (b).
Leo Wong
: f, ( r -- ) HERE 1 FLOATS ALLOT F! ;
: f+! ( r a -- ) DUP >R F@ F+ R> F! ;
: fin ( -- r ) BL WORD COUNT >FLOAT 0= ABORT" fin failed" ;
: foo CREATE ( r -- ) fin f, DOES> fin f+! ;
: print ( -- ) ' >BODY F@ F. ;
foo x 1
x 5
x 2.3
print x
John Passaniti
"Elko Tchernev" <etch...@acm.org> wrote in message
news:3E6934A8...@acm.org...
> This Paul Graham guy disappoints - how can he
> not tell whether the Forth submissions are correct
> or not?
Why does he disappoint? Because he doesn't know Forth? Look again at the
URL that was provided (http://store.yahoo.com/paulgraham/accgen.html) and
tell me if you understand *all* of the languages listed there well enough to
say for sure if the programs do exactly what he specified. I seriously
doubt anyone here has enough experience with *all* of the languages listed
to say for sure. Sounds to me like Paul is simply admitting that he doesn't
have experience with Forth to know if the submission did what he specified.
Additionally, at that URL read the essay "Revenge of the Nerds" to
understand the point of the problem.
> And I wonder what "incrementing" a FP number by
> some other number would mean, if not addition?
Reading "Revenge of the Nerds" gives a clue:
"That's incremented by, not plus. An accumulator has to accumulate."
In other words, the function that is returned has to maintain a unique value
(the accumulator) for each instance of the function.
Elko Tchernev
>> Forth submissions are correct or not?
>
>
> Why does he disappoint? Because he doesn't know Forth? Look again
> at the URL that was provided
> (http://store.yahoo.com/paulgraham/accgen.html) and tell me if you
> understand *all* of the languages listed there well enough to say for
> sure if the programs do exactly what he specified. I seriously doubt
> anyone here has enough experience with *all* of the languages listed
> to say for sure. Sounds to me like Paul is simply admitting that he
> doesn't have experience with Forth to know if the submission did what
> he specified.
>
Duh... He could have simply asked here on c.l.f. He has gone into
all the trouble of setting up a page, making submission forms etc.;
surely he could have scanned the newsgroup tree and posted a question to
clarify code in a language he doesn't get. That's what I would do if I
were in his situation. And don't tell me he's never heard of Usenet.
Roman Pavlyuk
> The requirements from the page are :-
>
> The problem: Write a function foo that takes a number n and
> returns a function that takes a number i, and returns n
> incremented by i.
>
> Note: (a) that's number, not integer, (b) that's incremented
> by, not plus.
>
> Your program only works for integers and so does not satisfy (a).
> Your program does not update the CREATed value with the sum of itself
> and the argument and so it doesn't satisfy (b).
Hm, it was a bit hard for me to grok the above at 2:30 AM, but I think
I did, and I think I disagree.
First, please open http://store.yahoo.com/paulgraham/accgen.html - I'm
not copying big parts from there.
(a) What is number?
Integer? - it's _natural_ for Forth
Float? - List has built-in support for FP, good for it, but
Complex? Will Paul Graham's _valid_ List sample work for complex
_numbers_ ? Please check. Oh, you have to choose representation of
complex numbers. But you have to choose representation of FP numbers
in Forth. It does not come automatically in Lisp this time, as it did
not one step back in Forth. Same for VB sample, and Perl, right?
Quaternions? A good canidate for numbers. Increment can be defined
on quaternions. Does Paul Graham's Lisp code handle this now?
Any non-commutative algebra can be used for defining "increment on
it". Does that List code work for it?
Not everything is as straightforward, would you agree?
(b) Increment by
Let's look at the samples. Say, VB sample, since it _explicitly_
contains what I want to emphasize on. Do you see a line
Set bar = New acc
It means that "n" will be "incremented" is a copy -- actually, a new
_instance_ of "n" is created, and then incremented.
Im my Froth example _new_ _instance_ of "n" is created, when LITERAL
puts the value of "n" onto stack.
Can you see the difference between a _valid_ VB sample and _invalid_
Forth sample? Same in other cases, just in VB this "new" operator is
so easy to notice.
Let's go to round 2 ? :)
BR,
Roman
Roman Pavlyuk
> : adder ( n -- xt )
> >R :NONAME R> POSTPONE LITERAL POSTPONE + POSTPONE ;
> ;
>
10 3 adder EXECUTE
Funny, but it works, tested with SPF 3.75
I agree with you, I just love CREATE DOES>.
I think the solution should noy only solve the proble, but be natural,
canonical and minimal.
Also, Paul Graham might disagree that we create _static_ function in
dictionary. Yes, Forth does not have gc for granted, but if you want
it to be a _dynamic_ function, just do this:
: adder ( n -- xt )
HERE >R MY-DYNAMIC-GC-AWARE-AREA-FOR-DYNAMIC-FUNCTIONS @ HERE!
>R :NONAME R> POSTPONE LITERAL POSTPONE + POSTPONE ;
HERE MY-DYNAMIC-GC-AWARE-AREA-FOR-DYNAMIC-FUNCTIONS !
R> HERE!
;
What do you think? Also, what do you think about my arguments re
Steven's arguments re whether this implementation satisfies
requirements?
Thanks,
Roman
Marcel Hendrix
[..]
>> : adder ( n -- xt )
>> >R :NONAME R> POSTPONE LITERAL POSTPONE + POSTPONE ;
>> ;
> And usage example can be
> 10 3 adder EXECUTE
> Funny, but it works, tested with SPF 3.75
> I agree with you, I just love CREATE DOES>.
^--- but [? --mhx]
> I think the solution should noy only solve the proble, but be natural,
> canonical and minimal.
Natural to whom? None of the examples on Paul Graham's page read
natural to me. The above Forth code I can read without problems (it doesn't
do what is requested by Mr. Graham), but "natural?" It is not natural
with respect to how I would solve this (insufficiently specified) problem
in Forth. Indeed, I (think I) agree with you that CREATE DOES> is the natural
way in Forth.
The argument for "minimal" is also ambiguous. The article says it is NOT to be
the shortest amount of source code, but more a count of NOT re-usable statements.
(If there is a high amount of re-usable code the language is not helping
the programmer enough?)
> Also, Paul Graham might disagree that we create _static_ function in
> dictionary. Yes, Forth does not have gc for granted, but if you want
> it to be a _dynamic_ function, just do this:
If he does not agree, he must respecify what he wants more clearly.
If I understand you correctly, we have a statically allocated acumulator,
but you want the code to act on it compiled from scratch each time it is needed?
Natural way:- : accumulator create 0 , does> +! ;
Silly way:- : inc >r :noname r> postpone literal postpone +! postpone ; ;
: accumulator create 0 , does> here -rot inc execute cp ! ;
( what, you wanted silly STANDARD code? )
: accumulator create 0 , does> inc execute ;
FORTH> accumulator aa ' aa >body ? 0 ok
FORTH> 5 aa ' aa >body ? 5 ok
FORTH> 11 aa ' aa >body ? 16 ok
( scan-ahead) : accu create 0e F, does> bl <word> >float 0= throw F+! ;
FORTH> accu aa ok
FORTH> aa 5 ' aa >body f@ f. 5.000000 ok
FORTH> aa 15 ' aa >body f@ f. 20.000000 ok
FORTH> aa 3.1459e ' aa >body f@ f. 23.145900 ok
FORTH> aa 3.1459d1 ' aa >body f@ f. 54.604900 ok
[..]
> What do you think? Also, what do you think about my arguments re
> Steven's arguments re whether this implementation satisfies
> requirements?
It is unclear how the finished code should be tested, and what the tests
should be. E.g. Leo Wong's code includes words to actually create and use
the accumulator, input values, and print the result. The examples on PG's
page do not.
What happens if I want to input a binary, octal or base 17 (integer) number
in, say, Lisp or VB?
Paul Graham's challenge is just to promote Lisp. I think Lisp is a nice
language, but let's hope Mr. Graham codes better than he specifies a
challenge :-)
-marcel
Anton Ertl
>Ladies and Gentlemen,
>
>I think many of you know Paul Grahmam's accumulator generator task -
>http://store.yahoo.com/paulgraham/accgen.html . And you probably know
>that Forth is not represented there. As Paul Graham writes in
>accgensub.html, "I can't tell yet if you can write the program in
>Forth. I've had several Forth submissions and I'm still trying to
>puzzle out whether they're correct".
>
>I was one of the sumbitters, but I got a reply since Forth does not
>create "dynamic" function then it's not a right solution.
Ignoring the requirement for "number, not integer" for now, a Forth
solution would be:
: accgen ( n "name" -- )
create ,
does> ( i -- m )
tuck +! @ ;
If Paul Graham does not like the parsing nature of accgen (which makes
it hard, but not impossible, to use dynamically), he can wrap it in
"noname ... lastxt" in Gforth, or define it in ANS Forth like this:
: accgen ( n -- xt ) ( xt execution: i -- m )
here swap ,
>r :noname r>
POSTPONE literal
POSTPONE tuck
POSTPONE +!
POSTPONE @
POSTPONE ;
;
Concerning the "numbers, not integers" requirement, one way to satisfy
it would be to use my objects.fs package
<http://www.complang.tuwien.ac.at/forth/objects.zip> and define an
interface for numbers (in particular, the selector n+) and then define
accgen with that. Then anyone can define classes that implement that
interface and use accgen with that. I.e.,
s" objects.fs" included
interface
selector n+ ( number1 number2 -- number )
selector number-copy ( number1 -- number2 )
end-interface number
: accgen ( number "name" -- )
create number-copy ,
does> ( numberi -- numberacc )
tuck @ n+ dup rot ! ;
However, that's not very idiomatic, so I think it misses Paul Graham's
original point: that language matters. This example emphasizes two of
the strengths of Lisp (closures and dynamic types), and Forth has only
one of them. Similarly, we could give a Forth example (say, mini-oof
<http://www.jwdt.com/~paysan/screenful.html>) and reject any Lisp
emulation of it because Lisp lacks address arithmetic.
All examples untested.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
Samuel Tardieu
integers:
: adder ( n -- xt ) here >r , :noname r> postpone literal postpone tuck
postpone +! postpone @ postpone ; ;
Sam
--
Samuel Tardieu -- s...@rfc1149.net -- http://www.rfc1149.net/sam
Samuel Tardieu
function, so it has to be embedded with an execute.
I'll submit this:
: adder ( n "name" -- )
here >r , :noname r>
postpone literal postpone tuck
postpone +! postpone @ postpone ;
create , does> @ execute
Leo Wong
: f, ( r -- ) HERE 1 FLOATS ALLOT F! ;
: f+! ( r a -- R ) DUP >R F@ F+ R> F! ;
: fin ( -- r ) BL WORD COUNT >FLOAT 0= ABORT" fin failed" ;
: foo CREATE ( r -- ) fin f, DOES> DUP fin f+! F@ ;
foo x 1
x 5 FDROP
x 2.3 F.
David N. Williams
> Perhaps closer to the example:
>
> : f, ( r -- ) HERE 1 FLOATS ALLOT F! ;
> : f+! ( r a -- R ) DUP >R F@ F+ R> F! ;
> : fin ( -- r ) BL WORD COUNT >FLOAT 0= ABORT" fin failed" ;
> : foo CREATE ( r -- ) fin f, DOES> DUP fin f+! F@ ;
How about:
: f, ( r -- ) FALIGN HERE 1 FLOATS ALLOT F! ;
: foo CREATE ( r -- ) fin f, DOES> FALIGNED DUP fin f+! F@ ;
I've been bitten by this "problem" with CREATE a couple of
times. :-)
-- David
Leo Wong
"David N. Williams" <David.N....@umich.edu> wrote in message
news:3E6A062...@umich.edu...
> ...
> : f, ( r -- ) FALIGN HERE 1 FLOATS ALLOT F! ;
> : foo CREATE ( r -- ) fin f, DOES> FALIGNED DUP fin f+! F@ ;
That's my "home" version, which I didn't want strangers to see.
As regards this thread, I agree with Brodie's _Thinking Forth_:
<quote>
You shouldn't write any serious application in Forth; as a
language it's simply not powerful enough. What you
_should_ do is write your own language in Forth (lexicons) to model
your understanding of the problem, in which you elegantly
describe its solution.
</quote>
I haven't read Graham's articles, just the example. What's his problem?
Thanks,
Stephen J. Bevan
> First, please open http://store.yahoo.com/paulgraham/accgen.html - I'm
> not copying big parts from there.
>
> (a) What is number?
> Integer? - it's _natural_ for Forth
> Float? - List has built-in support for FP, good for it, but
> Complex? Will Paul Graham's _valid_ List sample work for complex
> _numbers_ ? Please check.
If by "List" you meant "Lisp" then yes the Lisp example does work for
complex numbers. Whether support for complex numbers is a requirement
is unclear. I think the intent is that the function should work for
all numeric types that are natively supported by the language. If the
language only supports integers then that simplifies the problem. If
the language supports integers and floating point numbers then the
solution must work for both integer and floating point numbers. I'm
inferring this from the examples and passages such as integer only
Java version in http://store.yahoo.com/paulgraham/icad.html about
which he writes :-
This falls short of the spec because it only works for integers.
If you disagree with my interpretation, ask Graham to clarify what he
means.
> Quaternions? A good canidate for numbers. Increment can be defined
> on quaternions. Does Paul Graham's Lisp code handle this now?
Quaternions are not a native numeric type in Lisp and so I don't
believe they are required to work. I'm basing this on the fact he has
accepted a Scheme solution which would not work if you passed it a
quaternion as provided by a third party quaternion library. However,
the Common Lisp code given should work for quaternions as long as the
quaternion library includes a definition of "+" (incf is a macro which
when used like "(incf x y)" expands to something like
"(setq x (+ x y))" and so makes use of "+" as defined on the types in
question).
> Any non-commutative algebra can be used for defining "increment on
> it". Does that List code work for it?
Yes. For example, one could define an algebra where "+" is string
concatenation. If you then ran the given Common Lisp code it would
would concatenate two strings, store the concatentation and also
return it.
>
> (b) Increment by
> Let's look at the samples. Say, VB sample, since it _explicitly_
I know nothing about VB and so cannot judge whether or not it
satisfies what I believe to be the requirements. I'm looking at the
the Scheme, Common Lisp and Smalltalk programs, all of which update
the variable. Given that Graham elsewhere wrote :-
"That's incremented by, not plus. An accumulator has to accumulate."
I believe the intention is that the variable is updated, not copied.
I may be wrong. Ask Graham for a clarification if you think there is
some ambiguity.
Stephen J. Bevan
> It is unclear how the finished code should be tested, and what the tests
> should be. E.g. Leo Wong's code includes words to actually create and use
> the accumulator, input values, and print the result. The examples on PG's
> page do not.
Perhaps because he assumes it is obvious. Here are some examples in
Common Lisp :-
* (defun foo (n) (lambda (i) (incf n i)))
Define the solution.
* (setf foo10 (foo 10))
Create a function called foo10 that initialises its accumulator to 10.
* (funcall foo10 5)
15
Call foo10 with the argument 5, the result 15 is returned. To show it
actually updated the accumulator, call the function again this time
with 3 :-
* (funcall foo10 3)
18
The correct value of 18 is returned. To show that there isn't just
one global accumulator, define another one this time initialised with
5 :-
* (setf foo5 (foo 5))
and then call it with 4 :-
* (funcall foo5 4)
9
Now call the previous accumulator to show that there is no conflict :-
* (funcall foo10 6)
24
followed by the new one :-
* (funcall foo5 3)
12
> What happens if I want to input a binary, octal or base 17 (integer) number
> in, say, Lisp or VB?
In Lisp the code works whether you input, binary, octal, base 17, ... etc.
For example, the following calls the foo5 accumulator with 16 in hex :-
* (funcall foo5 #x16)
34
As to VB, I have no idea.
Leo Wong
GForth 0.5.0, Copyright (C) 1995-2000 Free Software Foundation, Inc.
GForth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
foo foo10 10 ok
foo10 5 f. 15. ok
foo10 3 f. 18. ok
foo foo5 5 ok
foo5 4 f. 9. ok
foo10 6 f. 24. ok
foo5 3 f. 12. ok
There must be something more to Mr. Graham's problem.
In any case, Mr. Bevan knows enough about Forth and List to tell us if
a Forth solution is possible, and if so, what it is, and if not, why not.
"Stephen J. Bevan" <ste...@dino.dnsalias.com> wrote in message
news:m38yvpz...@dino.dnsalias.com...
Stephen J. Bevan
> C:\DOCUME~1\Leo\Forth\acc>c:\progra~1\gforth\gforth.exe
> GForth 0.5.0, Copyright (C) 1995-2000 Free Software Foundation, Inc.
> GForth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
> s" acc.f" included redefined f, ok
> foo foo10 10 ok
> foo10 5 f. 15. ok
> foo10 3 f. 18. ok
> foo foo5 5 ok
> foo5 4 f. 9. ok
> foo10 6 f. 24. ok
> foo5 3 f. 12. ok
>
> There must be something more to Mr. Graham's problem.
>
> In any case, Mr. Bevan knows enough about Forth and List to tell us if
> a Forth solution is possible, and if so, what it is, and if not, why not.
As you noted before, your solution involves using words which parse
their input rather than take them from the stack. Only Graham can say
whether he accepts that approach as a solution. If he does not and
insists that the words have to take their arguments from the stack --
the natural location for the arguments to a Forth word -- then I don't
think the problem is solvable in Forth as stated since it is biased
towards languages with built-in (numeric) polymorphism (either static
or dynamic).
Leo Wong
> ...
> As you noted before, your solution involves using words which parse
> their input rather than take them from the stack. Only Graham can say
> whether he accepts that approach as a solution. If he does not and
> insists that the words have to take their arguments from the stack --
> the natural location for the arguments to a Forth word -- then I don't
> think the problem is solvable in Forth as stated since it is biased
> towards languages with built-in (numeric) polymorphism (either static
> or dynamic).
A very reasonable response, if it means that my solution did solve the
problem --
something I still doubt.
It would be interesting if Mr. Graham insisted that a Forth solution be
Forthlike. I'd
be stumped for a Forth function that _adds_ two "numbers", though I dare say
Bernd
or Anton could write one.
A truly Forthlike solution wouldn't meet Mr. Graham's stated requirements.
: s>f ( n -- ) ( -- r ) S>D D>F ;
: f, ( r -- ) HERE 1 FLOATS ALLOT F! ;
: f+! ( r a -- r ) DUP >R F@ F+ R> F! ;
: foo CREATE ( r -- ) f, DOES> DUP f+! F@ ;
1 s>f foo x ok
5 s>f x f. 6. ok
2.3e x f. 8.3 ok
I'm grateful for your remarks,
Mark Slicker
> I just tried to implement this now - please see below. Is there anyone
> who is willing to persuade Paul Graham that Forth is good for
> everything, including his task?
I think if you turned Forth into Lisp he might be persuaded. It is a
bit of silly comparison to begin with. Really it is an issue of
semantics rather than notation. Of course the languages with fixed
syntax and semantics which don't happen to fit the task will fall on
their face as expected. And in Forth we have extensible notation[1]
and semantics, but sometimes little to start with.
I've done the top level of this concept in colorForth, I think
colorForth can describe this concept sufficiently. The idea is to
build a word which has a state, and return the address of that word.
: acc swap over +! @ ;
: agen ref here swap [lit] acc :@ [:, ;] ;
acc (i a -- n) the accumulator
agen (n -- a) the generator
ref (n -- a) puts n in the dictionary and gives its word address
lit (n -- ) macro to compile a literal
:@ (-- a) macro to compile the address of the preceding word
:, (a --) macro to compile a call to address a
The [] in colorForth mean cyan. When a green word is encountered which
is a macro it is executed. A cyan word is always a compiled call. This
sugests to me an addition to colorForth to make this particular
concept easier to express. When a cyan word is encountered which is
not a macro, compile code which compiles a call to that word. Thus we
would have:
: acc swap over +! @ ;
: agen ref here swap [lit acc ;] ;
Mark
[1] I say notation, because syntax implies a fixed structure imposed
on the program. Forth is syntax free with a turing complete
interpreter.
Marcel Hendrix
> A truly Forthlike solution wouldn't meet Mr. Graham's stated requirements.
[..]
> 1 s>f foo x ok
> 5 s>f x f. 6. ok
> 2.3e x f. 8.3 ok
Well, the Lisp notation is incredibly verbose for a Forth person and would
probably not be at all acceptable either:
ste...@dino.dnsalias.com (Stephen J. Bevan) wrote:
> Create a function called foo10 that initialises its accumulator to 10.
> * (funcall foo10 5)
> 15
funcall would be considered redundant and ugly.
[..]
> * (funcall foo5 #x16)
> 34
IMHO, if it is necessary and allowed to signal HEX explicitly the reason
NOT to explicitly specify a FP number becomes questionable. And if the
reply is that the argument could come from another function we would reply
that in Forth the result of a STANDARD word ( say >FLOAT ) always has
a fixed and known type.
-marcel
Bill Bouma
> Ignoring the requirement for "number, not integer" for now, a Forth
> solution would be:
>
> : accgen ( n "name" -- )
> create ,
> does> ( i -- m )
> tuck +! @ ;
>
> If Paul Graham does not like the parsing nature of accgen (which makes
> it hard, but not impossible, to use dynamically), he can wrap it in
> "noname ... lastxt" in Gforth, or define it in ANS Forth like this:
I don't think he is allowed to reject it on such an arbitrary
basis. Anton's example meets his requirement exactly for integer
arguments. Forth cannot meet his requirement for multiple
types of arguments. So he can reject the Forth example on that
legitimate basis. But who cares and why? Some people seem pretty
upset about his rejection of Forth. The only thing you can do
about it is write a new dynamically typed Forth. I am doing that.
My dynamically typed Forth-like can handle this problem as follows:
: accgen create! does var +! lit ;
This does essentially the same thing as above, but +! is polymorphic.
I believe this example does meet all of Graham's criterion.
Bill
Stephen J. Bevan
> > A truly Forthlike solution wouldn't meet Mr. Graham's stated requirements.
>
> [..]
>
> > 1 s>f foo x ok
> > 5 s>f x f. 6. ok
> > 2.3e x f. 8.3 ok
>
> Well, the Lisp notation is incredibly verbose for a Forth person and would
> probably not be at all acceptable either:
>
> ste...@dino.dnsalias.com (Stephen J. Bevan) wrote:
>
> > Create a function called foo10 that initialises its accumulator to 10.
>
> > * (funcall foo10 5)
> > 15
>
> funcall would be considered redundant and ugly.
Common Lisp separates functions and values into two separate
environments. Some people like this and some don't. Those that don't
may or may not prefer Scheme which does not split bindings in this way
and so in Scheme it would be written as :-
* (foo10 5)
> > * (funcall foo5 #x16)
> > 34
>
> IMHO, if it is necessary and allowed to signal HEX explicitly the reason
> NOT to explicitly specify a FP number becomes questionable. And if the
> reply is that the argument could come from another function we would reply
> that in Forth the result of a STANDARD word ( say >FLOAT ) always has
> a fixed and known type.
Perhaps this is being distorted too much by the use of literal values.
I believe the intent is you can do things like :-
* (setf foo-random-int (foo (random 50)))
Here foo-random-int is initialised with a random integer in the range [0,50)
* (setf foo-random-float (foo (random 50.0)))
Here foo-random-float is initialised with a random floating point in
the range [0,50). Note the fact that random is polymorphic isn't
important it would be fine if there was an integer random routine and
a floating point random routine. What is important is that foo (or
accgen in the Forth version) take a number and make an accumulator of
the correct type out of it (i.e. give it an integer and it accumulates
integers, give it a float and it accumulates floats). Hence
converting the number using >FLOAT is not acceptable since that is not
polymorphic, it always makes a floating point accumulator even if the
argument was an integer. I'm assuming that type of solution is not
acceptable based on the fact that if it was then Graham would have
accepted a Java version that worked on floats that required users to
throw in (float) cast before calling it with any other (numeric) type.
Roman Pavlyuk
"That's incremented by, not plus. An accumulator has to accumulate."
This is what I've overlooked, shame on me. Anyway, I think the
finalist would be something close to what you and Samuel Tardieu have
submitted, for instance:
: adder ( n -- xt )
here >r ,
:noname ( i -- {n i +!} )
r> postpone literal postpone tuck postpone +! postpone @
postpone ;
;
Here I eliminated one SWAP - probably it's unnecessary. Maybe, it's
reasonable to change TUCK to SWAP OVER - more verbose, but more clear
- I did not remember what TUCK meant.
There was a moment of sweet nostalgie for COMPILE and [COMPILE] - at
least then it was clear which work is immediate :)
I think no code should go w/o testing, so here I'm using Stephen
Beven's sample - I think it's a good one.
* 10 adder constant foo10
* 5 foo10 execute .
15 ok
* 3 foo10 execute .
18 ok
* 5 adder constant foo5
* 4 foo5 execute .
9 ok
* 6 foo10 execute .
24 ok
* 3 foo5 execute .
12 ok
I would add a bit of syntactic sugar:
* : setf create , does> @ execute ;
* 10 adder setf foo10 redefined foo10 ok
* 5 foo10 . 15 ok
* 3 foo10 ok
* 5 adder setf foo5 redefined foo5 ok
* 4 foo5 . 9 ok
* 6 foo10 . 24 ok
* 3 foo5 . 12 ok
As for me, this is more elegant. Specially I name the word "setf". Can
you tell this from Lisp now ? :)
I see no problems with hex, octal and other bases:
* base @ 16 base ! ff foo5 swap base ! . 267 ok
Here I use only Forth-natural "numbers".... Well, let me make this
post again quite long -- you can skip the philosophizing below, the
solution is above :)
STOICAL, the now-seems-to-be-dead-forthlike-language, supported data
types in a manner it's supported in Window's VARIANT - one 'cell'
contains both value and type information. Well then, who told that we
have to use all 32 bits (for instance) for storing value, we can use,
say, 21 bit for values and other 11 for type information. so, + will
look like : + ?type-check $1FFFF and swap $1FFFF and + $1FFFF and ;,
all other words alike.
Who will tell that this will not be Forth? Not sure about whether it
will be ANS-94 compliant. So, we have 11 bits for types, it's a bit
too much, there can be int, float, string, complex, and one, last,
called "object". For object type the value (21 lsb) will be a pointer
to what in FORTH-83 was called PFA. And theer can be a polymorphic
either compile-time FIND, which will find appropriate +, or run-time
implementation of +, which will lookup corresponding implementation,
and, maybe, will do some type conversions. I do not see anything
impossible and hard.
What I wanted to say by this passage, is:
Integer numbers is a natural solution for traditional Forth, object
numbers will be natural for the Forth described above. Both are Forth.
Let's stick to traditional, and know that it's possible to implement
polymorphic types (functions?), at some expense.
Next, though CREATE DOES> is also natural, Forth can live w/o it in
this case -- please enjoy setf implementation above. Forth is
flexible. So, I eliminated CREATE DOES> from Samuel Tardieu's
implementation.
Probably, we will be able to prepare a submission soon. Just a few
words about why I touched this topic. I have to fly a litle bit over
the US last summer, and Orbitz _sometimes_ offered better deals than
expedia. So, at least one of Paul Graham's creatures needs due
respect. After that I read a few articles, and ANSI Common Lisp twice.
Also, as far as I now from ColorForth site, Chuck Moore knows List.
Why wouldn't Paul Graham learn some Forth then ? :) Also, I was
offended that the languages much less powerful are listed (Perl ! VB
!), and Forth is not.
Thanks to everyone,
Roman
Mark Slicker
> > Ignoring the requirement for "number, not integer" for now, a Forth
> > solution would be:
> >
> > : accgen ( n "name" -- )
> > create ,
> > does> ( i -- m )
> > tuck +! @ ;
> >
> > If Paul Graham does not like the parsing nature of accgen (which makes
> > it hard, but not impossible, to use dynamically), he can wrap it in
> > "noname ... lastxt" in Gforth, or define it in ANS Forth like this:
>
> I don't think he is allowed to reject it on such an arbitrary
> basis. Anton's example meets his requirement exactly for integer
> arguments. Forth cannot meet his requirement for multiple
> types of arguments. So he can reject the Forth example on that
> legitimate basis. But who cares and why? Some people seem pretty
> upset about his rejection of Forth. The only thing you can do
> about it is write a new dynamically typed Forth.
You could do this, or you could change the rules of the game. If a
language is judged based on how closely it matches Lisp's semantics,
it is obvious what language will be judged superiour.
A constant theme within the Forth community is appeasement. In what
way can Forth meet the expectations of person X, where person X is a C
programmer, a Lisp programmer, a Perl programmer, a "Literate
programming" programmer, a standards accepting programmer, a Y library
using programmer, ect. The list is never ending, and Forth will
forever come in second so long as trys to be *like* something else.
I sugest to the Forth community, this is a purely a distraction from
exploring Forth's true strengths. The power of Forth lies not in an
isolated example, but in a whole application. What we truely need is
real applications in tiny amounts code. Chuck Moore's 500 line CAD
would be an excelent example were it not proprietary to Chuck. What
about a Forth email client? Forth web browser? Forth operating system?
Not only would these be useful, they could truely demonstrate the
power of Forth to anyone interested in a unique way of programming.
Mark
Geoffrey Summerhayes
"Roman Pavlyuk" <jo...@eleks.lviv.ua> wrote in message news:ac4a01c6.03030...@posting.google.com...
>
> (a) What is number?
> Integer? - it's _natural_ for Forth
> Float? - List has built-in support for FP, good for it, but
> Complex? Will Paul Graham's _valid_ List sample work for complex
> _numbers_ ? Please check. Oh, you have to choose representation of
> complex numbers.
While I agree with your argument, the Common Lisp standard provides
integers, reals, floats, and complex numbers.
: (defun adder (n) (lambda (i) (incf n i)))
ADDER
: (funcall (adder #c(3 1/2)) 3.4)
#c(6.4 0.5)
I'd add the following to his challenge:
- the resulting closure must be able to be passed to anything
expecting a callable function of one argument. i.e. EXECUTE
- number polymorphism is not a requirement. (I believe this
follows some of the examples on the site, some of these
languages are very strongly typed. IIRC Haskell wouldn't
allow an int closure to work on a float.)
- the closure must be capable of being assigned to a variable
for later or repeated use
- the closure is discardable without affecting other generated
closures (memory reclamation)
This disallows the C++ example, it fails the first clause.
The last clause is important if you create a lot of temporary
functions.
--
Geoff
Elko Tchernev
>
> Perhaps this is being distorted too much by the use of literal values.
> I believe the intent is you can do things like :-
>
> * (setf foo-random-int (foo (random 50)))
>
> Here foo-random-int is initialised with a random integer in the range [0,50)
>
> * (setf foo-random-float (foo (random 50.0)))
>
> Here foo-random-float is initialised with a random floating point in
> the range [0,50). Note the fact that random is polymorphic isn't
> important it would be fine if there was an integer random routine and
> a floating point random routine. What is important is that foo (or
> accgen in the Forth version) take a number and make an accumulator of
> the correct type out of it (i.e. give it an integer and it accumulates
> integers, give it a float and it accumulates floats). Hence
> converting the number using >FLOAT is not acceptable since that is not
> polymorphic, it always makes a floating point accumulator even if the
> argument was an integer.
I still don't quite understand Paul Graham's requirements, or your
explanation, or both ;) Suppose we created foo-random-int as per your
example above; this would be an integer accumulator, right? Then we
invoke it, but pass a floating point argument to the integer
accumulator. Now, as per your understanding of PG's requirements, what
should happen:
- the return value is integer or FP?
- accumulate what - the int portion of the FP, or change the
storage type to become FP, even if it was integer before?
Cheers,
Leo Wong
"Mark Slicker" <masl...@oakland.edu> wrote in message
news:4c45abad.03030...@posting.google.com...
>
> ... If a
> language is judged based on how closely it matches Lisp's semantics,
> it is obvious what language will be judged superiour.
>
> A constant theme within the Forth community is appeasement. In what
> way can Forth meet the expectations of person X, where person X is a C
> programmer, a Lisp programmer, a Perl programmer, a "Literate
> programming" programmer, a standards accepting programmer, a Y library
> using programmer, ect. The list is never ending, and Forth will
> forever come in second so long as trys to be *like* something else.
>
It is often fun to see how flexible Forth can be. In this case, the
accumulator part was trivial, while the "numbers" part contrary to Forth
philosophy, so the problem was perhaps not very interesting -- to us.
Health, joy, peace,
Leo Wong, ColdFusion Programmer
he...@albany.net
http://www.albany.net/~hello/
Stephen J. Bevan
> I still don't quite understand Paul Graham's requirements, or
> your explanation, or both ;)
Graham's explanation is quite short, I'm inferring what I believe to
be the boundary conditions based on the solutions he has already
accepted as valid.
> Suppose we created foo-random-int as per
> your example above; this would be an integer accumulator, right?
Yes.
> Then we invoke it, but pass a floating point argument to the integer
> accumulator. Now, as per your understanding of PG's requirements, what
> should happen:
> - the return value is integer or FP?
> - accumulate what - the int portion of the FP, or change the
> storage type to become FP, even if it was integer before?
The Common Lisp, Smalltalk and Scheme implementations would all return
an FP result and the accumulator would have morphed from an integer
accumulator to a floating point accumulator. That is not true for the
C++ version which would reject at compile time the attempt to pass a
floating point value to an integer accumulator (unless there was an
explicit cast). Since the C++ version has been accepted I infer from
this that an acceptable solution is not required to accept a floating
point value passed to an integer accumulator.
Roman Pavlyuk
> forever come in second so long as trys to be *like* something else.
I do not think itcomes second in this game.
> I sugest to the Forth community, this is a purely a distraction from
> exploring Forth's true strengths. The power of Forth lies not in an
> isolated example, but in a whole application. What we truely need is
I agree that every solution is to be considered within a task's scope.
I see no reson in a solution isolated from a task, in this case
human's brain sophistication can bring us far away in interesting yet
wrong direction. I do not like to solve assigmnents w/o knowing the
problem. Maybe the problem for which Paul Graham wants a polymorphic
adder need not be solved that way :)
> real applications in tiny amounts code. Chuck Moore's 500 line CAD
> would be an excelent example were it not proprietary to Chuck. What
> about a Forth email client? Forth web browser? Forth operating system?
Compete with MS? Try to render outdated HTML/DHTML/XHTML when there is
XHTML 2.0, which is now much more elegant? (Btw, jff, please read it
-- http://www.w3.org/TR/xhtml2/ , and specially XForms --
http://www.w3.org/TR/xforms/ -- it's really close to what web should
have been)
Always running behind the leader? Trying to prove that Forth _also_
can be used? Trying to support standards that become outdated? Do you
enjoy backward compatibility support (= old junk)? Are you fond or
playing by someone else's rules? There are two factors that make me do
what I do during my work time - actually, working on commercial
projects -- commitment to promises given to clients and colleagues,
and money (which gives some freedom sometimes). But I cannot tell I
enjoy it to the extent I would spend my spare time for my main job,
too :)
> Not only would these be useful, they could truely demonstrate the
> power of Forth to anyone interested in a unique way of programming.
The project like iTV is something interesting, it was innovative. I
think it might be revived. I wonder what Jeff Fox thinks.
Do you enjoy industrial style software production? Forth is mind
amplifier, it can be used in research. For me it's more power of
expression, maybe for Chuck it's power of expressing his minimalistic
desires, for someone else it gives power to express other their ideas.
I do not agree with Chuck there's only one right way. Well, maybe,
there is only one straight right way, but you not always go straight
ahead.
Forth is not frustrating, it can be fully understood, and you do not
have to guess and be afraid that something will happen and you will
know what to do with this (something crashed somewhere, _maybe_ it's
our bug, maybe not, restart it, oh, you don' use the latest version --
don't you participate in writing this kind of software? I do.)
Well, my posts tend to be long. Google is also an expressionists' tool
:)
About unique projects -- have you heard about this?
http://webs.cs.berkeley.edu/ -- please follow Mate and TinyOS links. I
think you'll enjoy the tasks people try to solve (just started reading
myself, cannot tel much). Unfortunately, Forth is not there.
Fortunately, there's innovation. And it'd be more interesting to me to
discuss this project that endless files vs blocks and whether ANS
standard is ethernal evil.
> Mark
Everything written above is to involve you into discussion, not to
offend by any means :)
BR,
Roman
Roman Pavlyuk
>
> While I agree with your argument, the Common Lisp standard provides
> integers, reals, floats, and complex numbers.
> #c(6.4 0.5)
Well, Paul Graham's point in all this game is "language matters". He
wants to show that different languages have different capabilities.
I'd say that power of language has to be measured against given task,
not against "everything" (read "nothing")
While Lisp has possibiliy to overload "+" for any possible data type,
I would refer you to Joel Spolsky's "The Law of Leaky Abstraction"
http://www.joelonsoftware.com/articles/LeakyAbstractions.html , which
(please read the article first) can be summarized as "Duck is a very
abstract bird. It can do everything - fly, run and swim. Everything
equally bad."
I admire polymorphism and abstraction, please don't think I'm this
"hardcode it fast" kind of guys. Yet, we have to be careful when
building polymorhhic frameworks for tasks that would never need the
hidden and unused power. Everything that is not used actively tends to
degrade. Have you heard the phrase "rotten code"? Have you written
lots of it? I did. Maybe, I was a bad programmer.
Is type polymorphism the best and required solution for Paul Graham's
task? I doubt. Though, if there was a requirement "input parameter's
type has to be identified as integer, real or complex number, and
corresponding implementation has to be called" - then yes, I'd agree.
Otherwise, I would not overcomplicate the solution.
One more passage -- I think I grok Chuck Moore's method during the
last busy night (customer support !). It's simple. He just beats 80/20
rule -- he avoids solving the last 20% of task that require 80%
efforts. He rethinks the problem, requirements and implementation of
the first 80% of the task to beat this rule.
Well, I just wanted to write a follow-up to my previous letter, to
look at Paul Graham's requirements and see if the solution offered
satisfies them.
http://store.yahoo.com/paulgraham/accgensub.html
* 1. Takes, and returns functions that take, exactly one argument.
It does.
* 2. Works for any numeric type-- i.e. can take both ints and floats
and returns functions that can take both ints and floats.
As you remember, there were no floats in FORTH-83 standard, you could
use a custom implementation of scaled integer representation. Current
solution can be rewritten using double numbers which are one of
natural float representation in Forth. I'd say here "Language matters,
don't impose artificial restrictions"
* 3. Generates functions that return the sum of every number ever
passed to them, not just the most recent.
It does
* 4. Returns a real function, meaning something that you can use
wherever you could use a function you had defined in the ordinary way
in the text of your program.
It does, I'd like to illustrate it with one more example here.
* 10 adder ok
* 5 over execute . 3 over execute . 15 18 ok
* drop ok
I'd like to show that Forth does not require a name for the function
-- this was not clear from my previous posting.
* 5. Doesn't store the accumulated value or the returned functions in
a way that could cause them to be inadvertantly modified by other
code.
Implementation is hidden from the user. It cannot be modified
inadvertedly.
So, I'd say it stisfies the requirements.
> I'd add the following to his challenge:
>
> - the resulting closure must be able to be passed to anything
> expecting a callable function of one argument. i.e. EXECUTE
This sample illustrates this explicitly. Later sample illustrated this
implicitly :)
> - number polymorphism is not a requirement. (I believe this
> follows some of the examples on the site, some of these
> languages are very strongly typed. IIRC Haskell wouldn't
> allow an int closure to work on a float.)
I agree
> - the closure must be capable of being assigned to a variable
> for later or repeated use
I think it is. Also in FORTH-83 and ColorForth it can be compiled into
arbitrary place in memory - HERE is assignable (not sure about ANS)
> - the closure is discardable without affecting other generated
> closures (memory reclamation)
It is.
So, looks like we are on the same page :)
BR,
Roman
Roman Pavlyuk
> colorForth can describe this concept sufficiently.
I think I've done low-level implementation :)
> The idea is to
> build a word which has a state, and return the address of that word.
Full implementation is here -- http://www.geocities.com/eleks_76/ -- I
finally spent 15 mins to make it look as a home page.
It is not as simple as yours, but what is most funny -- it works (see
the picture). It required several helper words, though. I do not like
a few things in ColorForth, first is that Leo Brodie did not write
"Starting ColorForth", and second -- it does not contain sufficient
set of words to feel as comfortable as I felt with FORTH-83. So, I has
to write some helpers (in ColorForth, I did not modify the kernel) to
make it ColorForth. Full source code in colors you can find at the url
above, here I will describe it briefly.
> : acc swap over +! @ ;
> : agen ref here swap [lit] acc :@ [:, ;] ;
>
> acc (i a -- n) the accumulator
> agen (n -- a) the generator
> ref (n -- a) puts n in the dictionary and gives its word address
> lit (n -- ) macro to compile a literal
> :@ (-- a) macro to compile the address of the preceding word
> :, (a --) macro to compile a call to address a
---- Implementation
: acc ( i a -- n ) swap over +! @ ;
: adder ( n -- xt ) align4 here 2/ 2/ swap , here swap [literal]
compile acc [;] ;
Here acc is the same as yours. The words in brackets are cyan macros,
everything else is green.
[literal] does exectly what [compile] literal would do in FORTH-83,
and "compile" also corresponds to that standard -- during execution
compiles the next into current definition.
I wished there were built-in words to do this; helpers are larger than
the solution itself. Well, some things above deserve explanation.
align4 and 2/ are necessary, because ColorForth user word addresses,
not byte addresses, i. e, @ is implemented as 'mov eax, [eax*4]'.
"here"" returns byte address, and we have to make sure that it's 2 lsb
are 0's, otherwise we'd lose several bytes during /4*4 operation.
---- helpers macro
: literal [?dup] b8 1, , ;
: ba@ 8b 2, ;
: execute d88b 2, [drop] d3ff 2, ; forth
: compile pop dup dup 1 + ba@ e8 1, + here - + 2 + , 5 + push ;
: align4 here 3 and - 5 + for 90 1, next ;
Here "literal" compiles 'dup; mov eax, n'
ba@ stands for "byte address fetch", implemented as 'mov eax, [eax]'.
It's used in "compile". An alterntive would be to align4, subtract 1,
and then compile the call. I found it easier to do it this way.
"compile" is trivial. It assumes that the call comes next. Some
address arithmetic.
Align4 is trivial, but not optimal, and I now know that 0 for executes
FFFFFFFF+1 times. Hm, and I see the word "align" in block 26 which
does the same. Too late.
Execute is used in test, it is implemented as 'mov ebx, eax; drop;
call ebx'. I wish it was there in kernel.
The test -- actually the same numbers Stephen Bevan used in Lisp
sample -- shows the same results.
> is a macro it is executed. A cyan word is always a compiled call. This
> sugests to me an addition to colorForth to make this particular
> concept easier to express. When a cyan word is encountered which is
> not a macro, compile code which compiles a call to that word. Thus we
I agree with you. I would also like to be able to make a variable cyan
-- i.e., not to play with 'here 2/ 2/ ,', but to declare a macro to
compile a variable for storing temporary result.
And, once again, what I did not like that 70% of time I spent on
machine code programming and fighting with alignments, not the task
itself.
Anyway, thank you for mentioning ColorForth in this thread.
BR,
Roman
Mark Slicker
> [ I wrote: ]
> > real applications in tiny amounts code. Chuck Moore's 500 line CAD
> > would be an excelent example were it not proprietary to Chuck. What
> > about a Forth email client? Forth web browser? Forth operating system?
>
> Compete with MS?
Does Chuck Moore compete with the commercial CAD products? These
applications will be created if they satisfy wants which no existing
applications satisfy, just as Chuck Moore's CAD was born from
frustration with all existing CAD tools. And just as Chuck takes
unconventional aproaches, I would expect no less creativity from
anyone taking up this challenge. A web browser in Forth is the
opportunity to make a unique statement, and create something wholly
useful in the process.
> Forth is mind amplifier, it can be used in research.
All programming languages are machine languages, and so a programming
language is a tool, a means to an end. The tool does not care what you
do with it. Research is equivalent to any other task from the tools
point of view. Forth is extensible, it can be used for any purpose the
machine is capable of.
Mark
Albert van der Horst
Elko Tchernev <etch...@acm.org> wrote:
<SNIP>
> As I understand, a real submission must handle both integers and
>FP, but DEPTH and FDEPTH can be used to see what kind of argument it
>got. I think this is OK, since the example Mozart program on that page
>explicitly checks to see what kind of arguments it got.
> This Paul Graham guy disappoints - how can he not tell whether the
>Forth submissions are correct or not? And I wonder what "incrementing" a
>FP number by some other number would mean, if not addition?
+TO applied to F-VALUE 's.
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
Q.: Where is Bin? A.: With his ma. Q.: That makes the Saudi's
terrorists, then? A.: No, George already owns their oil.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Samuel Tardieu
>> I've done the top level of this concept in colorForth, I think
>> colorForth can describe this concept sufficiently.
Roman> I think I've done low-level implementation :)
Btw, I was able to start your ColorForth for Windows on FreeBSD under
Wine (which was quite expected as you don't use fancy calls to Windows).
andr...@littlepinkcloud.invalid
> Oh no, I overlookeed the issue, it must be callable as with any other
> function, so it has to be embedded with an execute.
> I'll submit this:
> : adder ( n "name" -- )
> here >r , :noname r>
> postpone literal postpone tuck
> postpone +! postpone @ postpone ;
> create , does> @ execute
> ;
Surely
: adder ( n - a) s" create z , :noname z +! z @ ; " evaluate ;
meets the spec, is simpler, easier to understand, and more idiomatic.
Andrew.
Mark Slicker
[ ... ]
Ok, I'll give it another try. A risk in posting code, is that you
might post bad code and influence in a negative way. In the case of
this task there is a more natural way to express this in colorForth.
In full this time (untested):
macro
: lit [?dup] b8 1, , ;
: acc [swap over +! @] ; forth
: here4 here 3 ? if 1, here4 ; then 2/ 2/ ;
: ref here4 swap , ;
: agen ref here swap [lit acc ;] ;
This time 'acc' is inlined instead of compiled. Perhaps calls should
stay out of machine code generation? In any case it beats fighting the
ways of colorForth. Again it comes down to what semantics are built
in, not the notation. I do think the top level 'agen' is comparable to
the lisp ones. Although honestly I don't think this is at all Forth
style programming. Really I'm suprised such techiniques are popular
with the lisp community, is runs counter to referential transparency
(programming without state) which is one the key ideas of functional
programming. Of course Common Lisp from afar looks suspiciously like
C++ so maybe the lisp community is quite divorced from the functional
programming community in general.
Mark
Stephen J. Bevan
> Really I'm suprised such techiniques are popular
> with the lisp community, is runs counter to referential transparency
> (programming without state) which is one the key ideas of functional
> programming. Of course Common Lisp from afar looks suspiciously like
> C++ so maybe the lisp community is quite divorced from the functional
> programming community in general.
Common Lisp is is chock full of stuff that can manipulate state, its
object system (CLOS) relies on this. It also chock full of stuff that
lets you program in a referentially transparent manner if you so
choose. However, people who are interested in referential
transparency usually opt to program in other languages such as Haskell
or Clean where it is enforced.
Jeff Fox
A very clear and educational explanation of some details
involved in the discussion.
Thanks very much,
Jeff Fox
Stephen J. Bevan
> Well, I just wanted to write a follow-up to my previous letter, to
> look at Paul Graham's requirements and see if the solution offered
> satisfies them.
> * 2. Works for any numeric type-- i.e. can take both ints and floats
> and returns functions that can take both ints and floats.
> As you remember, there were no floats in FORTH-83 standard, you could
> use a custom implementation of scaled integer representation. Current
> solution can be rewritten using double numbers which are one of
> natural float representation in Forth. I'd say here "Language matters,
> don't impose artificial restrictions"
The test is explicitly designed in order to show highlight certain
features, one of which is a particular kind of polymorphism. It is
the above requirement that rules out a solution in Java, SML and
O'Caml since in none of them is it possible to write the function that
takes integers or floating point numbers (at leat not without
explicitly tagging them as such which Graham has ruled out).
Consequently I'd be surprised if Graham accepted a Forth solution that
only worked for integers or only worked for floats but not both as per
the other accepted solutions, irrespective of whether that dialect of
Forth only had integers or only had floats. There is no shame in
Forth not being able to solve the problem as stated since it requires
a feature that Forth explicitly and quite deliberately does not support.
jmdrake
> "Elko Tchernev" <etch...@acm.org> wrote in message
> news:3E6934A8...@acm.org...
> > This Paul Graham guy disappoints - how can he
> > not tell whether the Forth submissions are correct
> > or not?
>
> URL that was provided (http://store.yahoo.com/paulgraham/accgen.html) and
> tell me if you understand *all* of the languages listed there well enough to
> say for sure if the programs do exactly what he specified. I seriously
> doubt anyone here has enough experience with *all* of the languages listed
> to say for sure. Sounds to me like Paul is simply admitting that he doesn't
> have experience with Forth to know if the submission did what he specified.
I'm willing to bet that he doesn't know all of the languages listed
either, but is willing to accept the given solutions because he knows
enough to realize that they are functional (except C++) and should
theoretically be able to handle the problem. Regardless if you put
up a "write this in any language" challenge then you should expect
that SOMEBODY would send a submission in a language that you weren't
familair with. And there are enough free Forths out there that he
could download one and test the code if he wished. The least he
could do would be to post the Forth entries with a disclamier "I'm
not familair enough with Forth to verify if these entries are
correct."
Regards,
John M. Drake
Julian V. Noble
>
> jo...@eleks.lviv.ua (Roman Pavlyuk) writes:
> >Ladies and Gentlemen,
> >
> >I think many of you know Paul Grahmam's accumulator generator task -
> >http://store.yahoo.com/paulgraham/accgen.html . And you probably know
> >that Forth is not represented there. As Paul Graham writes in
> >accgensub.html, "I can't tell yet if you can write the program in
> >Forth. I've had several Forth submissions and I'm still trying to
> >puzzle out whether they're correct".
> >
> >I was one of the sumbitters, but I got a reply since Forth does not
> >create "dynamic" function then it's not a right solution.
>
> Ignoring the requirement for "number, not integer" for now, a Forth
> solution would be:
>
> : accgen ( n "name" -- )
> create ,
> does> ( i -- m )
> tuck +! @ ;
>
> If Paul Graham does not like the parsing nature of accgen (which makes
> it hard, but not impossible, to use dynamically), he can wrap it in
> "noname ... lastxt" in Gforth, or define it in ANS Forth like this:
>
> here swap ,
> >r :noname r>
> POSTPONE literal
> POSTPONE tuck
> POSTPONE +!
> POSTPONE @
> POSTPONE ;
> ;
>
> Concerning the "numbers, not integers" requirement, one way to satisfy
> it would be to use my objects.fs package
> <http://www.complang.tuwien.ac.at/forth/objects.zip> and define an
> interface for numbers (in particular, the selector n+) and then define
> accgen with that. Then anyone can define classes that implement that
> interface and use accgen with that. I.e.,
>
> s" objects.fs" included
>
> interface
> selector n+ ( number1 number2 -- number )
> selector number-copy ( number1 -- number2 )
> end-interface number
>
> : accgen ( number "name" -- )
> create number-copy ,
> does> ( numberi -- numberacc )
> tuck @ n+ dup rot ! ;
>
> However, that's not very idiomatic, so I think it misses Paul Graham's
> original point: that language matters. This example emphasizes two of
> the strengths of Lisp (closures and dynamic types), and Forth has only
> one of them. Similarly, we could give a Forth example (say, mini-oof
> <http://www.jwdt.com/~paysan/screenful.html>) and reject any Lisp
> emulation of it because Lisp lacks address arithmetic.
>
> All examples untested.
>
> - anton
> --
> M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
Here's a simple version that does integers _or_ fp#'s. Assumes a separate fp
stack, uses F+! (defined in some Forths, not in others)
: F+! DUP F@ F+ F! ; \ if needed
: get# BL WORD COUNT >FLOAT INVERT ABORT" Not a number!" ;
: accumulator
get# CREATE F, DOES> get# DUP F+! F@ F. ;
accumulator -5e0 acc-5 ok
acc-5 22 17.0000 ok
acc-5 3A
Error: acc-5 Not a number!
accumulator 5EA acc5
Error: 5EA Not a number!
--
Julian V. Noble
Professor of Physics
j...@virginia.edu
"Science knows only one commandment: contribute to science."
-- Bertolt Brecht, "Galileo".
Roman Pavlyuk
>
> : adder ( n - a) s" create z , :noname z +! z @ ; " evaluate ;
>
> meets the spec, is simpler, easier to understand, and more idiomatic.
>
Or you are really serious? :)
Just think of Forth application as:
a) a metasystem
b) a space rocket which burns mother missle after a take off.
Specially for b) you might need some files, buffered i/o, BL WORD and
other j... stuff, but after the metasystem starts, it's
self-sufficient.
I'm going to express my thoughts more clearly some time later, and,
hopefully, not at 5:20 AM
> Andrew.
BR,
Roman
Roman Pavlyuk
> > Compete with MS?
>
> Does Chuck Moore compete with the commercial CAD products? These
> applications will be created if they satisfy wants which no existing
> applications satisfy, just as Chuck Moore's CAD was born from
> frustration with all existing CAD tools. And just as Chuck takes
> unconventional aproaches,
Does Chuck support VHDL? Even Verilog? (Btw, I was surprised that in
VHDL you have to write a cycle to implement reduction :-\...)
I would expect no less creativity from
> anyone taking up this challenge. A web browser in Forth is the
> opportunity to make a unique statement, and create something wholly
> useful in the process.
Please read what you've written above. How "creativity" can be matched
with "web browser"? Hold on, let me explain my point -- actually I
tried to explain it in the second, more emotional part of my previous
posting, which was skipped.
Do you know this classic's phrase? "It is not the consciousness of men
that determines their being, but, on the contrary, their social being
determines their consciousness" Karl Marx.
HTTP, specially when it comes to proxy support (have you played long
enough with that, specially security, load balancing, corporate
firewalls etc?); HTML (think of Java Script support, it's mandatory)
-- there is such a load of old junk that will take so much of time and
health to support. Even Jeff Fox says that the hardest part in iTV
project was the web browser, and I trust him.
> > Forth is mind amplifier, it can be used in research.
>
> All programming languages are machine languages, and so a programming
> language is a tool, a means to an end. The tool does not care what you
> do with it. Research is equivalent to any other task from the tools
Please re-read the classic's phrase. I disagree with you completely.
If you work in a junkyard, and you have to deal with junk daily, your
brain turns into junk -- I'm telling this about myself and the job I
do for money, not to offent anyone here. Yet it's profitable and I'm
amazed about the way the client does sales -- there really is
something to learn about.
> point of view. Forth is extensible, it can be used for any purpose the
> machine is capable of.
To summarize.
Paul Graham's point is "Language matters"
My point "What you do matters" (job, lifestyle, freinds, environment,
enemies, ...)
And Latins said "Talis hominibus horacio, qualis vita". <-- Funny,
this expresses what I've told above only in 5 words !!!
> Mark
With respect,
Roman
andr...@littlepinkcloud.invalid
> andr...@littlepinkcloud.invalid wrote in message news:<v6ou8ml...@news.supernews.com>...
>>
>> : adder ( n - a) s" create z , :noname z +! z @ ; " evaluate ;
>>
>> meets the spec, is simpler, easier to understand, and more idiomatic.
>>
> I think you've missed a smiley :)
> Or you are really serious? :)
Totally, although of course this isn't a very serious challenge.
> Just think of Forth application as:
> a) a metasystem
> b) a space rocket which burns mother missle after a take off.
> Specially for b) you might need some files, buffered i/o, BL WORD and
> other j... stuff, but after the metasystem starts, it's
> self-sufficient.
> I'm going to express my thoughts more clearly some time later, and,
> hopefully, not at 5:20 AM
Indeed. When you do so, please explain whether in your opinion my
version meets the spec and if it does what else might be wrong with
it?
[ Please ignore the issue of floating-point. I already know about
that. ]
Andrew.
Roman Pavlyuk
> Forth not being able to solve the problem as stated since it requires
> a feature that Forth explicitly and quite deliberately does not support.
I don't agree with you -- my argument is in my post of Mar, 9, Google
shows it as #38, passage starting with the word "STIOCAL".
Will you agree with this?
BR,
Roman
Bernd Paysan
> Does Chuck support VHDL? Even Verilog?
Not at all. His system allows you to write ColorForth words which generate
logic. It comes with simple gates defined. You can write Forth words for
more complex logic if you like, but this is your own job. The project
"data" is ColorForth source that generates the necessary logic.
Chuck supports GDS2 (as output, not as input), because that's the common
back-end for all foundries. Also, the logic simulation provides accuracy
only for timing digital circuits. Don't expect it to work for analog
circuits. This is clearly following Chucks approach to solve *only* the
problem at hand, not a general problem.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Roman Pavlyuk
> Wine (which was quite expected as you don't use fancy calls to Windows).
a perversed way his ColorForth is used ! :)
More seriously, I think, it's good that we can run ColorForth in our
_natural_ environments (too much discussion about the word "natural"
in this thread).
Mine is Windows at the moment, yours, as I can see, is FreeBSD. Using
Windows for me had one advantage -- I could trace many parts of CF in
a debugger and grok some things. Unfortunately, many old good DOS
debuggers, including our BD, don't support Pentium/386 protected mode.
And under Windows it's easier to browser internet, read mail when
using ColorForth at the same time.
> Sam
BR,
Roman
Roman Pavlyuk
> : lit [?dup] b8 1, , ;
> : acc [swap over +! @] ; forth
> : here4 here 3 ? if 1, here4 ; then 2/ 2/ ;
> : ref here4 swap , ;
> : agen ref here swap [lit acc ;] ;
>
> This time 'acc' is inlined instead of compiled. Perhaps calls should
> stay out of machine code generation? In any case it beats fighting the
> ways of colorForth. Again it comes down to what semantics are built
Your here4 is great, it's really ColorForth way, I appreciate it.
Everything else is 99.6% like mine.
I have to check yet whether cyan non-macro is equivalent to compile --
you told it _would_ be nice if ColorForth supported this. Does it? I
agree that it'd be nice and natural. Also, your ref would be nice to
implement as a cyan variable -- unfortunately it's not there.
Next, w/a "execute"? Is there a natural way to do this in ColorForth?
> in, not the notation. I do think the top level 'agen' is comparable to
> the lisp ones. Although honestly I don't think this is at all Forth
> style programming.
Why not? Based on some "optimization criteria" you compile code which
executes fast for your task. I think everything that is fast, is Forth
style :)
Really I'm suprised such techiniques are popular
> with the lisp community, is runs counter to referential transparency
If you read Paul Graham's article about Orbitz and what techniques
were used there, I think you would agree with him. At least Orbitz is
a real working application which you can try (I do not like many
things -- specially when they say theres a ticket for $200, but you
have to contact airline directly, and when you contact 'em they say
they have only for $2,000, but this has little to do with Lisp. Or,
maybe, it does ? :)
> (programming without state) which is one the key ideas of functional
> programming. Of course Common Lisp from afar looks suspiciously like
> C++
Common Lisp also gives you choice, as Forth does. That's why I
actually started this thread -- I think there's much more common than
different, and I'd like more understanding to be there between the two
communities. I think it's _possible_ to understand Paul Graham's way,
and I'd like him to understand our (or only my?) way.
> so maybe the lisp community is quite divorced from the functional
> programming community in general.
I can't tell much on the topic. What I see from "ANSI Common Lisp"
book, it is not so innocent.
> Mark
BR,
Roman
Stephen J. Bevan
I've no idea what #38 means in reference to Google. In the end I
tracked it down, the unique references is the Message ID of
<ac4a01c6.03030...@posting.google.com>
> Will you agree with this?
It doesn't matter whether I would agree with a solution that took that
approach or not, that decision is up to Graham. However, should it be
possible to implement it, it is going to take re-defining quite a few
things for the solution to be consistent -- you can't just redefine +,
! and NUMBER otherwise it would break if I call it with the result of
some other computation. That is going to make quite a long solution,
if it is possible at all. So if it went up on Graham's page people
would see two line versions in some languages compared to ?? lines of
code to redefine all manner of things followed by a 3-4 line solution
of the actual problem. That would show that Forth can solve the
problem, but it would also strongly make Graham's point that "language
matters". So you have to weigh up whether it is better for Forth to
be in the category of languages which can't do it (like Java, SML and
O'Caml) or in the category that can but have the longest solution by far.
Mark Slicker
> > [ I wrote: ]
> > I would expect no less creativity from
> > anyone taking up this challenge. A web browser in Forth is the
> > opportunity to make a unique statement, and create something wholly
> > useful in the process.
>
> Please read what you've written above. How "creativity" can be matched
> with "web browser"? Hold on, let me explain my point -- actually I
> tried to explain it in the second, more emotional part of my previous
> posting, which was skipped.
>
> Do you know this classic's phrase? "It is not the consciousness of men
> that determines their being, but, on the contrary, their social being
> determines their consciousness" Karl Marx.
I think this is very relevant to your thinking. From your use of web
browsers, you have a very fixed conception of what a web browser is. I
see in web browsers a brilliant idea trapped in a serverly damaged
implementation. The idea of instantaneous exchange of documents
connected in a world wide network of information is very powerful.
There are always ways that this system can be improved, and I think
creativity is a basic requirement for improvement.
> HTTP, specially when it comes to proxy support (have you played long
> enough with that, specially security, load balancing, corporate
> firewalls etc?); HTML (think of Java Script support, it's mandatory)
> -- there is such a load of old junk that will take so much of time and
> health to support. Even Jeff Fox says that the hardest part in iTV
> project was the web browser, and I trust him.
Please read the chat with Chuck Moore:
http://www.ultratechnology.com/chatlog.htm
He talks of FML, a forth language to take the place of html in a Forth
system. FML would be a much simpler form of communication. It is most
likely that a subset of the web will be supported. A subset can be
easy to support, it is when your browser is expected to do everything
that Mozilla or IE do, to support every standard that exists and the
ones still in the pipeline, that true problems set in. Will this
browser be severly limited? It can't said in advance, I think it would
evolve with the sites people visit, and the features they find
important.
>
> > > Forth is mind amplifier, it can be used in research.
> >
> > All programming languages are machine languages, and so a programming
> > language is a tool, a means to an end. The tool does not care what you
> > do with it. Research is equivalent to any other task from the tools
>
> Please re-read the classic's phrase. I disagree with you completely.
> If you work in a junkyard, and you have to deal with junk daily, your
> brain turns into junk -- I'm telling this about myself and the job I
> do for money, not to offent anyone here. Yet it's profitable and I'm
> amazed about the way the client does sales -- there really is
> something to learn about.
Sure there are different qualities of work. I didn't think that
entered the picture. Also Research is not as glamourous as it may seem
from afar. Professional researchers must churn out papers just as
programmers are forced to churn out code. I think the determining
factor for quality of work is who is in control. When you can set your
own goals, and have a semblence of positive impact on the greater
society, I think you can take pride in your work. I could work at
junkyard only if I could somehow improve the process, if I could
utilize to the fullest my training and natural talents. Maybe set up a
better recycling program, maybe work with others to see how society
can generate less junk to begin with. I don't think there is anything
degrading in working in a junkyard. Junk is a part of human society,
it is not seperate from human society. I think as whole we should
strive to create less junk, because the junk we create today will just
have to be dealt with by future generations. More generally the
ammount of junk produced is a direct reflection of the wastefulness
and reckless use of resources inherent in our society.
Mark
Mark Slicker
> > macro
> > : lit [?dup] b8 1, , ;
> > : acc [swap over +! @] ; forth
> > : here4 here 3 ? if 1, here4 ; then 2/ 2/ ;
> > : ref here4 swap , ;
> > : agen ref here swap [lit acc ;] ;
> >
> > This time 'acc' is inlined instead of compiled. Perhaps calls should
> > stay out of machine code generation? In any case it beats fighting the
> > ways of colorForth. Again it comes down to what semantics are built
>
> Your here4 is great, it's really ColorForth way, I appreciate it.
> Everything else is 99.6% like mine.
>
> I have to check yet whether cyan non-macro is equivalent to compile --
> you told it _would_ be nice if ColorForth supported this. Does it?
No, that is why I have inlined it instead.
> I
> agree that it'd be nice and natural. Also, your ref would be nice to
> implement as a cyan variable -- unfortunately it's not there.
I don't know what you mean by cyan variable. Variables come in one
form and are placed in the forth and macro dictionaries. I think 'ref'
is a good factorization.
>
> Next, w/a "execute"? Is there a natural way to do this in ColorForth?
Sure:
: execute push ;
> > in, not the notation. I do think the top level 'agen' is comparable to
> > the lisp ones. Although honestly I don't think this is at all Forth
> > style programming.
> Why not? Based on some "optimization criteria" you compile code which
> executes fast for your task. I think everything that is fast, is Forth
> style :)
With the practice of early binding, this code would surely be rare in
a real Forth program addressing a real problem.
> Really I'm suprised such techiniques are popular
> > with the lisp community, is runs counter to referential transparency
>
> If you read Paul Graham's article about Orbitz and what techniques
> were used there, I think you would agree with him. At least Orbitz is
> a real working application which you can try (I do not like many
> things -- specially when they say theres a ticket for $200, but you
> have to contact airline directly, and when you contact 'em they say
> they have only for $2,000, but this has little to do with Lisp. Or,
> maybe, it does ? :)
Graham is so long winded, he uses so many words to make a point of so
little relative importance. Honestly, I don't think I've ever made it
through one of his essays.
> > (programming without state) which is one the key ideas of functional
> > programming. Of course Common Lisp from afar looks suspiciously like
> > C++
>
> Common Lisp also gives you choice, as Forth does. That's why I
> actually started this thread -- I think there's much more common than
> different, and I'd like more understanding to be there between the two
> communities. I think it's _possible_ to understand Paul Graham's way,
> and I'd like him to understand our (or only my?) way.
Common Lisp is a bloated language. It has committee written all over
it. Perhaps the ANS Forth programmers have some common experience with
the Common Lisp programmers in this respect. At a more fundemental
level Lisp and Forth have much in common. Both have a simple syntax, a
few primitive concepts, simple models of computation. It is fair to
say both are classic language designs. It is hard for me to say what
can be shared between Lisp programmers and Forth programmers, as I
haven't written many Lisp programs. Lisp programmers could learn how
to factor the problem as Forth programers do, if they haven't already
done so. From Lisp, Forth programmers could learn the benefits of more
flexiable and dynamic data structures. This could enable rapid
prototyping in Forth, instead of the very carful design required
currently. Also from Lisp and other functional languages, Forth
programmers could learn the benfits of the functional style of
programming rather than the C style of programming used by some.
colorForth encourages a functional style programming.
Mark
Leo Wong
news:m3y93kw...@dino.dnsalias.com...
> ... So you have to weigh up whether it is better for Forth to
> be in the category of languages which can't do it (like Java, SML and
> O'Caml) or in the category that can but have the longest solution by far.
Forth is in the category of 0-operand stack machines -- the programmer had
better ensure that the proper arguments are passed to the routines.
Roman Pavlyuk
> It doesn't matter whether I would agree with a solution that took that
> approach or not, that decision is up to Graham.
I think it matters -- if you think that you are right, you can
persuade others, if you know you are wrong - you can't. I think people
here sometimes want to do something to improve recognition of Forth;
Paul Graham is one of recognized industry experts, and, if he groks
the strength of Forth, I think it will be a plus (pardon, increment,
not plus :). I do not think his mind is too closed and blinded by "the
only true way".
> However, should it be
> possible to implement it, it is going to take re-defining quite a few
> things for the solution to be consistent -- you can't just redefine +,
> ! and NUMBER otherwise it would break if I call it with the result of
> some other computation. That is going to make quite a long solution,
> if it is possible at all.
I argee with you partiailly, but I did not mean redefining plus in a
standard Forth (even ANS), though it's possible - create "typed
numbers extension", as there is "floating-pount numbers extension".
Another solution is to use "typed Forth", which, as to me, is also
Forth, 'cause Forth is not a standard, it's a philosophy.
> So if it went up on Graham's page people
> would see two line versions in some languages compared to ?? lines of
> code to redefine all manner of things followed by a 3-4 line solution
> of the actual problem. That would show that Forth can solve the
> problem, but it would also strongly make Graham's point that "language
> matters". So you have to weigh up whether it is better for Forth to
> be in the category of languages which can't do it (like Java, SML and
> O'Caml) or in the category that can but have the longest solution by far.
No, in all my previous posts I voted for a "natural" solution. I think
naturality is a good excuse for lack of some features. Lisp solution
is natural in this case. I do not think it's reasonable to start
"language war" and devise a counter-example, which would be elegant in
Forth and ugly or impossible in Lisp. I, once again, would love if we
appreciated what Paul Graham is doing, and if he appreciated what we
are doing.
BR,
Roman
Roman Pavlyuk
> browsers, you have a very fixed conception of what a web browser is. I
> see in web browsers a brilliant idea trapped in a serverly damaged
> implementation.
Now I must agree with you. That's why I've included XForms and XHTML
2.0 links - I think these are very nice and clean standard drafts.
I thought you think it's a very good to supporth all junk just to
compete with IE; I must apologize for misunderstanding.
> The idea of instantaneous exchange of documents
> connected in a world wide network of information is very powerful.
> There are always ways that this system can be improved, and I think
> creativity is a basic requirement for improvement.
Yes, sure, I agree. I just would not call it "web browser". But there
is another thing -- will many sites provide content in FML ?
>
> Please read the chat with Chuck Moore:
> http://www.ultratechnology.com/chatlog.htm
>
> He talks of FML, a forth language to take the place of html in a Forth
> system. FML would be a much simpler form of communication. It is most
> likely that a subset of the web will be supported.
Yes, I've just re-read it again. It could become a reality. If iTV
project was successful, and there were millions of users, who could
run some FML P2P applications. Unfortunately, reality is a bit
different.
> A subset can be
> easy to support, it is when your browser is expected to do everything
> that Mozilla or IE do, to support every standard that exists and the
> ones still in the pipeline, that true problems set in. Will this
> browser be severly limited? It can't said in advance, I think it would
> evolve with the sites people visit, and the features they find
> important.
Peolpe visit sites because thise sites do something useful for them. I
visit: Yahoo, Google (and wherever I go from there :), www.itc.ua,
Amazon, my banks' on-line services, and that's pretty much it. This is
how I use Internet. Well, email mainly, terminal services in addition.
If this Forth browser does not support these sites (or sites don't
support this browser), I'll have to use another one.
I do not think this niche of market is free. It has _good_enough_
solution, and it's ok for mass market. Forth is unique in the sense
that it can ve used where other would not work, for instance, please
check my posting titled "Berkeley WEBS". It's going to be a big
market, it's the right time to try to enter. And I'm afraid, there
will be one more good enuf solution, not the best one.
> Sure there are different qualities of work. I didn't think that
> entered the picture. Also Research is not as glamourous as it may seem
> from afar. Professional researchers must churn out papers just as
Yes, I agree parrially -- each kind of job can be done well or not
well; but I anyway think that the work you like you do the best, and
it's easy for you to do it well, and you enjoy it, and you can
outperform averages (Paul Graham was talking something about beating
averages). And you can do the work you do not like well, it's the
matter of attitude, professionalism, commitment, but anyway it leads
to stresses, dissatisfaction, depression. Each person is unique, with
unique advantages, preferences. If you make a good painter do
programmer's work, will it be anything good? If you ask 9-to-5
helpdesk support person work on design, will it work? Maybe, people
usually work better when doing more creatve job.
> programmers are forced to churn out code. I think the determining
> factor for quality of work is who is in control. When you can set your
> own goals, and have a semblence of positive impact on the greater
> society, I think you can take pride in your work. I could work at
Yes, work done well always brings satisfaction. Any work. But
sometimes you think you could do other work, what you like more, what
is more natural to you. Life is short, isn't it?
> junkyard only if I could somehow improve the process, if I could
> utilize to the fullest my training and natural talents. Maybe set up a
> better recycling program, maybe work with others to see how society
> can generate less junk to begin with. I don't think there is anything
> degrading in working in a junkyard.
Well, why don't you leave you current job and start working in
junkyard? (I dont mean the programmer, or manager, or researcher; a
person who moves trash cans and related stuff) The sociery needs it.
I'm asking you absolutely seriously.
Junk is a part of human society,
> it is not seperate from human society. I think as whole we should
> strive to create less junk, because the junk we create today will just
> have to be dealt with by future generations. More generally the
> ammount of junk produced is a direct reflection of the wastefulness
> and reckless use of resources inherent in our society.
Yes, I would agree, partially. Have you by any chance read Arthur
Hailey's "Overload" ("Airport" is his most famous novel, but there are
others)? In this book power industry is described, there are two
characters -- a man, manager of a power island, and a woman from the
ogranization like Green Peace. One of ideas is that, yes, power plants
pollute environment, and this is nothing good, but if we shut down
power plants, cities will not survive more that 2 day -- water supply,
healthcare, plumbing -- all that stuff depends on power. Well, the
idea is that this is present the state of civillization.
It can be cchanged, I think. But USA is not much interested in this.
USA does not want to adopt Tokio convention re CO2 emissions; in
Germany, for instance, there are separate trash cans for grass, paper,
plastic and other (4 kinds as far as I remember), it facilitates
handling of junk. I was shocked how dirty 42nd st is in New York. New
York is as dirty as Calcutta (I've been there, too). USA does not seem
to be the most poor country in the world. Just noone cares -- this is
"good enough" philosophy. I cannot say other countries are much
better, specially Soviet Union has built lots of terrible chemical
plants, leave alone nuclear pollution. But this was the Empire of
Evil, and US is the Outpost of Democracy. Municipal budgets are cut;
yes, we need money for war with Iraq (I will not express what I think
about this; too much offtopic in this thread :). It's ok, it's good
enough, we are happy to live in this the best country in the world (In
SU schools children also were taught that SU is the best country in
the world). It's good enough, we do not need it to be better. People
cannot get out of the box, they cannot imagine that everything can be
better, they do not believe in it, current level of comForth is good
enough.
Many people have mind closed because they did not have with what to
compare. I think Forth is a good tool for opening one's mind, because
it if _so_ different from what is good enough.
Sorry, it's a bit too emotional and offtopic, but you also wrote about
problems of civillization :)
> Mark
BR,
Roman
Roman Pavlyuk
> > > : lit [?dup] b8 1, , ;
> > > : acc [swap over +! @] ; forth
> > > : here4 here 3 ? if 1, here4 ; then 2/ 2/ ;
> > > : ref here4 swap , ;
> > > : agen ref here swap [lit acc ;] ;
It tried it, and it works! Your solution is much better than mine, and
this is more ColorForth than assembler, I must admit.
I've put this new version to http://www.geocities.com/eleks_76/ ,
block 114 (and a copy in block 60).
> > agree that it'd be nice and natural. Also, your ref would be nice to
> > implement as a cyan variable -- unfortunately it's not there.
>
> I don't know what you mean by cyan variable. Variables come in one
> form and are placed in the forth and macro dictionaries. I think 'ref'
> is a good factorization.
Yes, my "cyan variable" is your ref.
> > Next, w/a "execute"? Is there a natural way to do this in ColorForth?
> : execute push ;
Do you see how work at a junkyard cam damare brain ? :) Actually this
is how it was implemented in Forth-83 : EXECUTE >R ; , and I did
replace a jump with push/ret in assembler many times. Maybe, the only
excuse can be several years at a junkyard and late hour :(
> > > in, not the notation. I do think the top level 'agen' is comparable to
> > > the lisp ones. Although honestly I don't think this is at all Forth
> > > style programming.
> With the practice of early binding, this code would surely be rare in
> a real Forth program addressing a real problem.
Yes, but agen need not necessarily be dymamic, it can be defined at
compile time, and it's bormal in ColorForth to recompile on demand.
How recompiling on demand is much different from dynamic compilation
in Lisp? This is just another approach to gc. Btw, Forth's
FORGET/EMPTY is quite close to the approach to gc, described in
http://citeseer.nj.nec.com/tofte97regionbased.html (there was a
postion about this, from Samuel A. Favlo II, 2003-02-23 14:23:33 PST)
> Graham is so long winded, he uses so many words to make a point of so
> little relative importance. Honestly, I don't think I've ever made it
> through one of his essays.
A bit too wordy, but it helps to bring the message to the reader. Good
if you grok it from a few words, some people might need more words
(your implementation in CF is shorter than mine, so you need less
words, I already told I appreciate it)
> Common Lisp is a bloated language. It has committee written all over
This is also my impression after reading the book.
> it. Perhaps the ANS Forth programmers have some common experience with
> the Common Lisp programmers in this respect. At a more fundemental
Perhaps. I'm not ANS Forth programmer :) What I admire in Forth that
it is a metasystem, and metasystems are self-descriptive. I like small
beautiful elegant things, I don't like bloated ones. Maybe I don't
have enuf brainpower to handle big bloated things. That's why I do not
like working in a junkyard and handle lots of junk, usually in
parallel. I like work which requires consentration on finding optimal
solution.
> level Lisp and Forth have much in common. Both have a simple syntax, a
> few primitive concepts, simple models of computation. It is fair to
> say both are classic language designs.
Well, we kknow that Forth is better :)
> It is hard for me to say what
> can be shared between Lisp programmers and Forth programmers, as I
> haven't written many Lisp programs. Lisp programmers could learn how
> to factor the problem as Forth programers do, if they haven't already
> done so. From Lisp, Forth programmers could learn the benefits of more
> flexiable and dynamic data structures. This could enable rapid
> prototyping in Forth, instead of the very carful design required
> currently. Also from Lisp and other functional languages, Forth
> programmers could learn the benfits of the functional style of
> programming rather than the C style of programming used by some.
> colorForth encourages a functional style programming.
There are good things in both worlds. Even in C/C++ or VB -- I've seen
really beautiful C code (actually I do not like C). Take what's good,
share the good you have. Improve what's bad.
> Mark
BR,
Roman
Roman Pavlyuk
>
> Not at all. His system allows you to write ColorForth words which generate
> circuits. This is clearly following Chucks approach to solve *only* the
> problem at hand, not a general problem.
It was a rhetorical question.
I just wanted to argue that I do not see the reason in rewritting IE
in Forth and implement full DHTML 4/XHMTL 1.0 in Forth, as Chuck Moore
does not implement VHDL, he does exclusive and elegant solution, and
this is what Forth is the best for.
Well, Mark Slicker then in his next post told that he did not mean
implemnting IE in Forth.
I do not like idea of writing one more ICQ or IE in Forth. Well, there
is quite an interesting project EServ -- http://www.eserv.ru/ -- Mail,
News, Web, FTP and Proxy Servers written in Forth. But for server
applications you always have more freedom of choice.
BR,
Roman
Roman Pavlyuk
ColorForth solutions (my opinion, someone thinks we do not have one),
and there are no radical alternatives, what do you think -- if it
reasonable (necessary, politically correct -- whatever, choose one) --
to prepare a letter to Paul Graham and ask him to consider this
solution, as one which c.l.f community seems to be the correct one?
Thanks,
Roman
Stephen J. Bevan
> > It doesn't matter whether I would agree with a solution that took that
> > approach or not, that decision is up to Graham.
>
> I think it matters -- if you think that you are right, you can
> persuade others, if you know you are wrong - you can't.
Perhaps but I'm not out to persuade you one way or the other. I've
stated my understanding of Graham's rules but I've always cautioned
you to check with Graham since he is the final arbiter.
> I think people here sometimes want to do something to improve
> recognition of Forth; Paul Graham is one of recognized industry
> experts, and, if he groks the strength of Forth, I think it will be
> a plus (pardon, increment, not plus :). I do not think his mind is
> too closed and blinded by "the only true way".
If your intent is to make Graham "grock the strength of Forth", then I
think you need to use a problem that Graham cares about and which
shows Forth strengths. IMHO the problem that Graham posed only
statisfies the former, it doesn't show Forth's strengths.
> I argee with you partiailly, but I did not mean redefining plus in a
> standard Forth (even ANS), though it's possible - create "typed
> numbers extension", as there is "floating-pount numbers extension".
If you didn't mean redefining plus then I'm not sure what you are
proposing. To solve answer Graham's problem in the spirit he intended
you either have to re-define +, -, *, NUMBER, ... etc. or you have to
build a Forth from scratch which has a numeric tower and overloaded
operators like various Lisps. I'm not entirely convinced it is
possible to do the former and satisfy ANS semantics, though it is
clearly possible to do it if one doesn't require adherence to the
standard or one builds a completely new dynamically typed dialect of
Forth. I've no problem with anyone doing that and submitting a
solution in that language, I would just question whether it should be
presented as a Forth solution rather than say a RomanForth solution or
whatever specific name is chosen to describe that dialect of Forth.
> Another solution is to use "typed Forth", which, as to me, is also
> Forth, 'cause Forth is not a standard, it's a philosophy.
The same can be said about Lisp but on that page there isn't a "Lisp"
solution, there are Common Lisp, Scheme, Goo and Arc solutions
(there's also Dylan which some consider to be a Lisp even though it
abandoned the traditional syntax). The point being while each shares
some Lisp heritage, they are different enough to be considered
separate and aren't just presented as Lisp solutions.
Geoffrey Summerhayes
"Roman Pavlyuk" <jo...@eleks.lviv.ua> wrote in message news:ac4a01c6.03031...@posting.google.com...
>
> "Mark Slicker" <masl...@oakland.edu> wrote in message news:4c45abad.03031...@posting.google.com...
Matter of perspective, I guess. The standard only defines 978 symbols in the
CL package. That includes things like ... , +++, and /// that refer to previous
interactions with the listener, apropos, describe, etc. (introspective tools),
and the car to cddddr set. But you get built in support for bignums, fixnums,
rationals, floats, complex, strings, characters, arrays, hashtables, lists,
structs, classes, support for functional and declarative programming styles,
one of the best macro systems, etc.
Scheme has a lot less, a trimmed down version of older lisps, but a lot of code
goes to recreating built-in functions in Lisp.
ANS Forth defines, by my count, some 375 words CORE+EXT+FLOAT+..., it's nice
and compact but doesn't have all the bells and whistles. Best language for
refactoring though.
Now, if you had called C++ bloated...it has to have more defined functions and
operators than either with less flexibility.
Then there's *shudder* J-a-v-a...
I love programming, languages are just tools to do that, remember
"Real Programmers Use FORTRAN"? :-)
--
Geoff
andr...@littlepinkcloud.invalid
> Since the discussing is slowly drawing to a close, we have a Forth and
> ColorForth solutions (my opinion, someone thinks we do not have one),
> and there are no radical alternatives,
Yes there are -- mine. What's wrong with it?
Andrew.
John R. Strohm
news:n_Wba.6245$VT.7...@news20.bellglobal.com...
> I love programming, languages are just tools to do that, remember
> "Real Programmers Use FORTRAN"? :-)
Not necessarily.
A simulation group at Texas Instruments did an experiment back in the 1980s.
Instead of writing a sim in FORTRAN, the way all the previous sims had been
written, they wrote it in PASCAL. Over the life of that project, they
observed significantly higher programmer productivity and significantly
lower bug rates, which translated into real dollar savings. When I talked
with them, their business plan called for doing ALL subsequent sims in
PASCAL. I never heard whether they converted to Ada or not.
Geoffrey Summerhayes
"John R. Strohm" <str...@airmail.net> wrote in message news:3E5966E729452765.2BA86C06...@lp.airnews.net...
The source of the quote was titled "Real Programmers Don't Use Pascal"
and this group used Pascal, obviously these guys were quiche eaters.
Probably none of them were named Mel either...
--
Geoff
Mark Slicker
> > [ I wrote: ]
> > The idea of instantaneous exchange of documents
> > connected in a world wide network of information is very powerful.
> > There are always ways that this system can be improved, and I think
> > creativity is a basic requirement for improvement.
> Yes, sure, I agree. I just would not call it "web browser". But there
> is another thing -- will many sites provide content in FML ?
It would be initially a standard amoung colorForth users. Will it
catch on in the mainstream? That is anyones guess. It should be a
useful system for its users.
> I do not think this niche of market is free. It has _good_enough_
> solution, and it's ok for mass market. Forth is unique in the sense
> that it can ve used where other would not work, for instance, please
> check my posting titled "Berkeley WEBS". It's going to be a big
> market, it's the right time to try to enter. And I'm afraid, there
> will be one more good enuf solution, not the best one.
What is done in the market seems largely out of my reach. If Chuck
Moore, one of the most brilliant chip/language designers cannot
succeed, what hope to do have? I have neither the credentials nor
expreience of Chuck Moore, to me it is a hopeless proposition.
> yes, we need money for war with Iraq (I will not express what I think
> about this; too much offtopic in this thread :).
I think Iraq happens to be the best demonstration of my point. Leaving
behind all official politics for a moment, why are going to Iraq? The
most obvious reason is to control the vast oil resources found there.
2/3 of U.S oil consumption is for transporation. Mass transportation
in the United States has been systematically neglected. Perhaps this
because we are such a vast country and it is cheaper to build outward
rather than upward. The ecomonics of the market have not valued
preservation, sustainability, quality of life, or enviromental
quality. These are simply facts that can't be denied. The typical
position of government has been to regulate the market so that long
term interests are considered. This has not happened in the United
States. When the presential cabinent consists of former executives and
ceo's (some from the oil industry), it leaves little question as to
why.
Mark
Roman Pavlyuk
>
> Yes there are -- mine. What's wrong with it?
Nothing wrong :) Almost.
Paul Graham's solution was:
* (defun foo (n) (lambda (i) (incf n i)))
Your is equivalent to Lisp:
* (setf foo (eval (car (read-from-string (format nil "(~A)" "( defun
foo ( n ) ( lambda ( i ) ( incf n i ) ) )" )) )))
* (setf foo5 (foo 5))
9
* (funcall foo5 4)
13
Which works fine, for sure. And there is nothing wrong, but you can
easy notice the difference, right?
I do not mind, we can prepare a collection of different Forth
solutions, I do not say that mine is the only and right. Just it
_seems_ to _me_ that mine is a bit more natural and close to author's
solution :)
BR,
Roman
John R. Strohm
I recognized the quote. I'm pointing out that it isn't necessarily true. I
don't know whether those guys were quiche eaters, but I do know that those
were SHARP. They KNEW what they were doing.
> Probably none of them were named Mel either...
Fifteen years later, I don't remember their names.
andr...@littlepinkcloud.invalid
>> > and there are no radical alternatives,
>>
>> Yes there are -- mine. What's wrong with it?
> Nothing wrong :) Almost.
> Paul Graham's solution was:
> * (defun foo (n) (lambda (i) (incf n i)))
> Your is equivalent to Lisp:
> * (setf foo (eval (car (read-from-string (format nil "(~A)" "( defun
> foo ( n ) ( lambda ( i ) ( incf n i ) ) )" )) )))
I don't think so, although lisp is not my metier. My version didn't
define a named function but returned a reference to an unnamed one, so
that defun doesn't look right to me. The specification required a
function which takes an integer N and returns another function which
increments by N.
If the Forth solution has to pretend to be lisp, it'll do it badly.
Rather than bad lisp, let's have good Forth. Interpreting at run-time
is a very Forth way to solve a problem. It's much more Forthlike IMO
than all this messing about with POSTPONE and stack juggling.
> * (setf foo5 (foo 5))
> 9
> * (funcall foo5 4)
> 13
> Which works fine, for sure. And there is nothing wrong, but you can
> easy notice the difference, right?
> I do not mind, we can prepare a collection of different Forth
> solutions, I do not say that mine is the only and right. Just it
> _seems_ to _me_ that mine is a bit more natural and close to author's
> solution :)
It is closer to the author's solution, sure. But Forth is different:
let each language play to its strengths.
Rather than just doing what the author of the puzzle did in his own
langauge, say "OK, let's pretend this is a real problem in a real
application. Let's pretend I'm being paid to do this and I want to go
home and eat with my family instead of sitting before this keyboard.
What should I do?" That's how I came up with my answer.
Andrew.
Stephen J. Bevan
> Roman Pavlyuk <jo...@eleks.lviv.ua> wrote:
> > Paul Graham's solution was:
> > * (defun foo (n) (lambda (i) (incf n i)))
>
> > Your is equivalent to Lisp:
>
> > * (setf foo (eval (car (read-from-string (format nil "(~A)" "( defun
> > foo ( n ) ( lambda ( i ) ( incf n i ) ) )" )) )))
>
> I don't think so, although lisp is not my metier. My version didn't
> define a named function but returned a reference to an unnamed one, so
> that defun doesn't look right to me.
Indeed it does not. A more literal translation of your Forth to
Common Lisp would be :-
(setf accgen (eval (read-from-string "(lambda (n) (lambda (i) (incf n i)))")))
or even the following :-
(setf accgen (eval '(lambda (n) (lambda (i) (incf n i)))))
since in Common Lisp there is no need to use a string to represent the
code to evaluate. Either would be used like :-
(setf foo10 (funcall accgen 10))
(funcall foo10 3)
13
or if we want to ensure that accgen is bound as a function then :-
(setf (symbol-function 'accgen) (eval (read-from-string "(lambda (n) (lambda (i) (incf n i)))")))
(setf foo10 (accgen 10))
(funcall foo10 3)
13
> The specification required a function which takes an integer N and
> returns another function which increments by N.
Graham's specification requires that a function take a number, not
just an integer. If the problem is restricted to just integers then
simple solutions are possible in languages which are currently listed
as being unable to solve the more general problem (e.g. SML, O'Caml
and Java). However, Graham chose number rather than integer
deliberately to emphasise his point that "language matters", or more
specifically this particular feature of languages matters to Graham.
That doesn't necessarily mean the feature has to matter to anyone
else, especially if they work in completely different domains.
Roman Pavlyuk
I made a small conceptual mistake in my prev. reply, will try to
correct it here.
Paul Graham's version ...
* (defun foo (n) (lambda (i) (incf n i)))
... slowly evolves into ...
* (defun foo (n) (lambda (i) (eval `(eval ,(incf n i))))))
Check it, funny, but it still works, if you define foo5 and foo10, you
will get two different variables. Well, you had that "create z ,"
withing the string, you didn't just compile the increment itself...
Let's see...
* (defun foo (z) (funcall (eval (read-from-string (format nil "(~A)"
"lambda ( n ) ( lambda ( i ) ( incf n i ) ) " ))) z))
* (setf foo5 (foo 5))
* (funcall foo5 4)
9
* (funcall foo5 4)
13
* (setf foo10 (foo 10))
* (funcall foo10 4)
14
* (funcall foo5 4)
17
It works. And I think this is quite a close Lisp analog to your
: adder ( n - a) s" create z , :noname z +! z @ ; " evaluate ;
I wanted to try to create Forth analog closer to Paul Graham one's
BR,
Roman
P.S. Do you think it was easy to devise this Lisp sample? :)
Roman Pavlyuk
> Common Lisp would be :-
>
> (setf accgen (eval (read-from-string "(lambda (n) (lambda (i) (incf n i)))")))
>
this one.
> or even the following :-
>
> (setf accgen (eval '(lambda (n) (lambda (i) (incf n i)))))
I used a string literal to match S" ..." EVALUATE :)
> since in Common Lisp there is no need to use a string to represent the
> code to evaluate. Either would be used like :-
Yes, and in Forth there is no need to use a string to represent code
-- this was my point.
>
> Graham's specification requires that a function take a number, not
> just an integer. If the problem is restricted to just integers then
[skipped]
> That doesn't necessarily mean the feature has to matter to anyone
> else, especially if they work in completely different domains.
I think the reason is in a different thing -- in CLisp, as in VB (OLE
:), .NET and other environments values carry information about data
type. In Forth you cannot determine type, given binary representation.
Well, one can define an extension dictionary that works with such
numbers, very much like there is an extension that works with floats,
but this is not a required feature, you can do it in Forth if you
need, and you need not do it if you don't want it.
BR,
Roman
andr...@littlepinkcloud.invalid
>> The specification required a function which takes an integer N and
>> returns another function which increments by N.
> Graham's specification requires that a function take a number, not
> just an integer.
True, true. My error.
> If the problem is restricted to just integers then simple solutions
> are possible in languages which are currently listed as being unable
> to solve the more general problem (e.g. SML, O'Caml and Java).
Well, fair enough. But as far as Forth is concerned, integers _are_
numbers. All else is profane. So there... :-P
Andrew.
Bernd Paysan
> I think the reason is in a different thing -- in CLisp, as in VB (OLE
> :), .NET and other environments values carry information about data
> type. In Forth you cannot determine type, given binary representation.
> Well, one can define an extension dictionary that works with such
> numbers, very much like there is an extension that works with floats,
> but this is not a required feature, you can do it in Forth if you
> need, and you need not do it if you don't want it.
People should also understand that integers and FP numbers can't be
interchanged at will. Example: The difference between two adjacent square
numbers is 2n+1. Check it:
: check-squares ( n -- diff ) dup 1+ dup * swap dup * - ;
1000000000 check-squares . 2000000001 ok
Now the same with floating point:
: fcheck-squares ( f -- diff ) fdup 1e f+ fdup f* fswap fdup f* f- ;
1000000000e fcheck-squares f. 2000000000. ok
1000000023e fcheck-squares f. 2000000000. ok
1000000024e fcheck-squares f. 2000000128. ok
Oops, wrong. Therefore, it's the programmer who better decides
representation, not the programming system.
Leo Wong
> ...
> People should ... understand that integers and FP numbers can't be
> interchanged at will....
Indeed, when would a programmer in any language not want to know what
data types are passed to functions?
Marcel Hendrix
[..]
> People should also understand that integers and FP numbers can't be
> interchanged at will. Example: The difference between two adjacent square
> numbers is 2n+1. Check it:
> : check-squares ( n -- diff ) dup 1+ dup * swap dup * - ;
> 1000000000 check-squares . 2000000001 ok
FORTH> 10000000000 check-squares . -1474836479
Oops, wrong.
> Now the same with floating point:
> : fcheck-squares ( f -- diff ) fdup 1e f+ fdup f* fswap fdup f* f- ;
> 1000000000e fcheck-squares f. 2000000000. ok
> 1000000023e fcheck-squares f. 2000000000. ok
> 1000000024e fcheck-squares f. 2000000128. ok
> Oops, wrong. Therefore, it's the programmer who better decides
> representation, not the programming system.
[..]
FORTH> 10000000e fcheck-squares e. 2.0000001e7 ok
FORTH> 10000023e fcheck-squares e. 2.0000047e7 ok
FORTH> 10000024e fcheck-squares e. 2.0000049e7 ok
What's your problem :-)
-marcel
Roman Pavlyuk
> People should also understand that integers and FP numbers can't be
> interchanged at will. Example: The difference between two adjacent square
> Oops, wrong. Therefore, it's the programmer who better decides
> representation, not the programming system.
Great argument and sample, I admire it. (Though Marcel Hendrix below
does not agree, and he also has a point).
Btw, I recall one more exaplle and agrument. If MONEY a NUMBER for Mr.
Graham? Does Lisp handle rounding correctly? How does it handle the
problem of "lost penny"? Has he even met this problem? W/a .5 up and
.5 down rounding? W/a significant digits, currency rate precision? Can
this Lisp accumulator be used for handling, say, money on a bank
account (consider accrual rules)? There's so much fun stuff in the
world, I doubt whether Lisp handles it w/o extra eforts. So why treat
Forth defective because it does not handle floats? Float is quite a
complex beast, too, there can be so many representations that serve
different purposes and have different characteristics, so I'd not dare
talking about floating-points in general. Yes, itegers can also be
different - consider integer which overflows to zero and one that
saturates - are these integers? Is first more integer than the second?
Vice versa?
It illustrates Joel's "Law of Leaky Abstractions", and shows dark side
of polymorphism. I don't quite agree that abstraction and polymorphism
are bad, some time ago I was thinking these were the best things in
programming. But they can be dangerous, and you cannot abstract by
just neglecting, you have to abstract for making things simple and
clear, and have mechanisms for handling "leaks".
What I like in Chuck Moore's approach (as I grok it) that he focuses
on the task and he tries to understand it completely (and not to take
and use a library that almost solves it), and the solution addresses
all the task's subtleties, which would be omited by someone less
meticulous.
BR,
Roman
Roman Pavlyuk
> > > connected in a world wide network of information is very powerful.
>
> catch on in the mainstream? That is anyones guess. It should be a
> useful system for its users.
You touched a very interesting topic - ColorForth users. Let us look
at this from two perspectives.
* ColorForth availability - as it is now
Many people were unable (actually, they did not want it too much) to
use CF because it did not run on their hardware and/or it required
additional dedicated computer.
Just for fun, to prove myself that I can do smth more that just read
and write mails (well, it's called managing big project and providing
customer support), to look at latest Chuck Moore's creature, and, yes,
to provoke c.l.f. community a bit, I managed to publish ColorForth
that runs under Windows. I tried to keep changes as minimal as
possible in order not to disrupt the idea. (It as fun to get to know
that Samuel Tardieu runs it under Wine under FreeBSD) I think now
everyone who _wants_ can try it w/o mach initial effort. Well, you
still need much effort to grok it, but many "I did not see it but I
know I don't like it" people now do not have an excuse for not trying
it.
You are talking about ColorForth users. Well, how many ColorForth for
Windows users are there? I doubt whether more than 5. Ok, add
ColorForth for Raw Iron -- let us assume it totals to 100. It looks
like this is an interesting toy, ok, construct, which can be learnt
and explored, a tool for changing mind and expanding horizons, but
it's not a mass market thing even within Forth community. I think it
was marketed poorly -- no documentation and hard to install. There are
good and great ideas buried in it, but there was (is) no smth like Leo
Brodie's Starting Forth for involving people -- many people turned
away from ColorForth because they couldn't run it, and even if they
could, they were unable to do smth -- larning curve is too steep,
people are too busy. Maybe, there are 10-13 year kids who master it
now -- I hope so, but our generation is too busy, specially these
days.
* ColorForth availability - as it might have been, as it can be
One of cynical but true phrases about current state is "public eats
what it is fed". People consume some products not because they are
good, but because they are available, and alternatives are not
available, and people even don't think that there can be alternatives
at all - it's good enough (see my previous post).
PCs are a good thing, good enough. Though, they are expensive,
specially for many poor countries. And I think there can be a really
cheap alternative to PCs and PDAs, really cheap means, say, $5-20. And
I think ColorForth users community can be built around a mobile, cheap
and functional device that can be convenient in use. As for me,
ColorForth has no chances to succeed in PC/Windows/Linux environment,
but, hey, PC is not where evolution ends.
Another opportunity can be projects like Berkeley WEBS -- for some
reason my post has generated no interest, maybe everyone knows all
that and consider it not worth attention. Maybe.
> > I do not think this niche of market is free. It has _good_enough_
> > solution, and it's ok for mass market. Forth is unique in the sense
> > that it can ve used where other would not work, for instance, please
> > check my posting titled "Berkeley WEBS". It's going to be a big
> > market, it's the right time to try to enter. And I'm afraid, there
> > will be one more good enuf solution, not the best one.
>
> What is done in the market seems largely out of my reach. If Chuck
> Moore, one of the most brilliant chip/language designers cannot
> succeed, what hope to do have? I have neither the credentials nor
> expreience of Chuck Moore, to me it is a hopeless proposition.
Product cannot sell itself. I don't think Chuck Moore is a brilliant
salesman. If you want to change something, you have to be more active.
If you want to do it, you'll be looking for a way to do it. If you
don't want to do it, you'll be looking for excuses.
>
> > yes, we need money for war with Iraq (I will not express what I think
> > about this; too much offtopic in this thread :).
>
> I think Iraq happens to be the best demonstration of my point. Leaving
> behind all official politics for a moment, why are going to Iraq? The
> most obvious reason is to control the vast oil resources found there.
> 2/3 of U.S oil consumption is for transporation. Mass transportation
Yes, US is quite different from Europe in this aspect, I was a bit
surprised. Europe relies on trains, commuter and intercity, French
trains are really nice.
US relies on cars and planes. I was surprised that a) many americans
have never seen a train in their lives, b) many people were shocked
when I told 'em I got from NY to Boston by a _bus_ - they were looking
at me as at exotic animal, they presented me as "Roman, who was riding
a bus from Ney York to Boston". I'm not kidding !
Now, recall that gas in Europe is 4 times more expensive than in US.
Only in metro and urban areas people get to work by a subway/train,
but people prefer living in villages/towns (I understand them, cities
are quite dirty), so all US ecomony relies on cars and gas --
otherwise people just would not get to work, distances are large. Yes,
living in a village is luxury in USA, but it does not come at no cost.
I don't think the reason of the war against Iraq is only oil, but it
is one of key factors. I do not want to express all my thoughts on
this topic here.
> in the United States has been systematically neglected. Perhaps this
> because we are such a vast country and it is cheaper to build outward
> rather than upward. The ecomonics of the market have not valued
I think that, yes, distances play big role. And it is not a very bad
choice - highway system in US is really good, when compared with other
countries.
What surprises me, that bikes are not so popular here as in Germany
(don't now about Japan, have not been there yet) -- it could solve
transportation problem a bit, 'cause it takes me 30 mins to get to the
nearest T station by feet, and I'm lucky there is T station in my
village at all. In German cities and towns there are many bike roads,
and in US you typically will not find even sidewalks.
> preservation, sustainability, quality of life, or enviromental
> quality. These are simply facts that can't be denied. The typical
Environment here is still better that in ex-SU -- I can feel it.
Soviet military and industry machine managed to pollute environment to
terrible extent. I don't say about cities - they are very dirty in US,
when compared to Germany (can't say anything about Singapore), so I
understand people who live in villages.
To readers: these are my private thoughts and impressions, "eyes of a
stranger", "traveller's observations", and they probably are not
"politically correct". I do not say that US is bad, and Germany is
good. There are many good things (I can prepare a list if someone is
interested), though, there are many bad things, which can be changed.
Well, at least discussed.
> position of government has been to regulate the market so that long
> term interests are considered. This has not happened in the United
> States. When the presential cabinent consists of former executives and
> ceo's (some from the oil industry), it leaves little question as to
> why.
US economy is another interesting topic to discuss. There's a saying -
"The business of United States is business" :). And an interesting
subtopic here is "venture capital". But this would be too much for
this posting.
> Mark
BR,
Roman
Stephen J. Bevan
> Btw, I recall one more exaplle and agrument. If MONEY a NUMBER for Mr.
> Graham? Does Lisp handle rounding correctly? How does it handle the
> problem of "lost penny"? Has he even met this problem? W/a .5 up and
> .5 down rounding? W/a significant digits, currency rate precision? Can
> this Lisp accumulator be used for handling, say, money on a bank
> account (consider accrual rules)?
If you define a money class that internaly contains an integer,
big-num, floating point value as you see fit, write an appropriate
definition of "+" that takes into account the rounding you want then
the Lisp accumulator code would use that definition of "+" and do the
appropriate rounding. If instead the desired rouding rules cannot be
defined in terms of two numbers but instead must operate over a list
of numbers then the Lisp accumulator code would not work.
> There's so much fun stuff in the world, I doubt whether Lisp handles
> it w/o extra eforts.
Like most (but not all) languages, there is no money type in Common
Lisp, you have to define the type and the operations you want on it.
> So why treat Forth defective because it does not handle floats?
There are an infinite number of problems that can be created to show
one feature or another of languages. Graham chose one problem that
highlights a couple of features. Forth, like Java, O'Caml and SML
cannot solve the problem exactly as stated. Whether that means the
languages are defective depends whether you are interested in solving
that problem. It is not difficult to choose other problems which
Forth can easily solve but which would be difficult or impossible for
Common Lisp to solve. Again whether that makes Common Lisp defective
depends on whether you are interested in solving those problems.
Geoffrey Summerhayes
> "Geoffrey Summerhayes" <sumNOS...@hotmail.com> wrote in message
> news:Qj1ca.117$qc4....@news20.bellglobal.com...
> >
> > and this group used Pascal, obviously these guys were quiche eaters.
>
> I recognized the quote. I'm pointing out that it isn't necessarily true. I
> don't know whether those guys were quiche eaters, but I do know that those
> were SHARP. They KNEW what they were doing.
When was the last time you read it?
http://www.ee.ryerson.ca:8080/~elf/hack/realmen.html
You sound as if you took the article,and this conversation, as serious
commentaries.
> > Probably none of them were named Mel either...
>
> Fifteen years later, I don't remember their names.
>
"The story of Mel" was a reply to the article, you can find it here
http://www.catb.org/~esr/jargon/html/The-Story-of-Mel.html
--
Geoff
Mark Slicker
> Just for fun, to prove myself that I can do smth more that just read
> and write mails (well, it's called managing big project and providing
> customer support), to look at latest Chuck Moore's creature, and, yes,
> to provoke c.l.f. community a bit, I managed to publish ColorForth
> that runs under Windows. I tried to keep changes as minimal as
> possible in order not to disrupt the idea. (It as fun to get to know
> that Samuel Tardieu runs it under Wine under FreeBSD) I think now
> everyone who _wants_ can try it w/o mach initial effort. Well, you
> still need much effort to grok it, but many "I did not see it but I
> know I don't like it" people now do not have an excuse for not trying
> it.
When I tried it, it crashed for no good reason when loading a program.
That is a feature not in the original. One aspect of colorForth that
needs to be maintained is the intellectual rigor in the approach. The
approach demands zero bugs in the implementation. It is one of the
risks in building ontop of an operating system, is that you simply
can't know with precision what your code is doing.
At the same time, I think it is a good idea to port to operating
systems to give a larger audience a taste of what colorForth is all
about. Inspired by your work, I'm working on a version for X windows.
It is small C file implementing graphics and input, and a striped down
color.com. There are some issues with relocation, if anyone reading
this can help, I would apreciate it.
> You are talking about ColorForth users. Well, how many ColorForth for
> Windows users are there? I doubt whether more than 5. Ok, add
> ColorForth for Raw Iron -- let us assume it totals to 100. It looks
> like this is an interesting toy, ok, construct, which can be learnt
> and explored, a tool for changing mind and expanding horizons, but
> it's not a mass market thing even within Forth community.
Linux was once a "toy" too, with just a single user. Yet Linux defies
conventional marketing and has grown to millions of users. The key to
success, without elaborate marketing, is to solve useful problems. If
colorForth is treated simply as a toy, it will not generate much
interest.
> I think it
> was marketed poorly -- no documentation and hard to install.
See www.colorforth.com for documentation. Compare with the situation
with Linux, initially Linux supported minimal hardware as well, and
the consistent documentation policy with Linux is "see the source
code".
In comparing colorForth to Linux, I don't seek to make a technical
comparison. Technically they are worlds apart in implementation and
general philosophy. If the amount of labour and code needed to support
each were compared, colorForth would be a tiny fraction of that
required for Linux. Socially colorForth is a tiny fraction of the
investment, yet the gains in the approach are immeasurable.
> PCs are a good thing, good enough. Though, they are expensive,
> specially for many poor countries. And I think there can be a really
> cheap alternative to PCs and PDAs, really cheap means, say, $5-20. And
> I think ColorForth users community can be built around a mobile, cheap
> and functional device that can be convenient in use. As for me,
> ColorForth has no chances to succeed in PC/Windows/Linux environment,
> but, hey, PC is not where evolution ends.
I would like to pursue this as well, but the market is unpredictable.
We may end up with another iTV, a revolutionary product locked in a
vault somewhere. Software can at least survive the trends in the
market. The saying "You can't put all your eggs in one basket." is
relevant.
> Product cannot sell itself. I don't think Chuck Moore is a brilliant
> salesman. If you want to change something, you have to be more active.
I don't know if he is or isn't a brilliant salesman. Yet if he was a
brilliant salesman he probably wouldn't be selling Forth.
I agree with your observation on transporation, and you are right
about Iraq. It is not purely for oil or to satisfy our appetite for
oil. There are certainly domestic and geo-strategic issues at work.
Probably best to leave it at that.
Mark
Bernd Paysan
> FORTH> 10000000000 check-squares . -1474836479
>
> Oops, wrong.
Your 10000000000 was wrong before you checked:
10000000000 dup u. check-squares u. 1410065408 2820130817 ok
So check-squares itself is right.
> FORTH> 10000000e fcheck-squares e. 2.0000001e7 ok
> FORTH> 10000023e fcheck-squares e. 2.0000047e7 ok
> FORTH> 10000024e fcheck-squares e. 2.0000049e7 ok
>
> What's your problem :-)
No 80 bit FP numbers everywhere ;-)
Anton Ertl
>If you define a money class that internaly contains an integer,
>big-num, floating point value as you see fit, write an appropriate
>definition of "+" that takes into account the rounding you want then
>the Lisp accumulator code would use that definition of "+" and do the
>appropriate rounding. If instead the desired rouding rules cannot be
>defined in terms of two numbers but instead must operate over a list
>of numbers then the Lisp accumulator code would not work.
> Forth, like Java, O'Caml and SML
>cannot solve the problem exactly as stated.
Such a money class would require explicitly calling a constructor to
generate a "money" value, right? If this is acceptable in the
challenge, then Forth can certainly solve the problem, by using a
generic number class (or interface, like I presented), and using
explicit constructors for boxing different kinds of numbers.
The accepted C++ version (at least as far as I understand it) inspires
another approach: have an accgen generator that takes some xts
specific to the type and generates an accgen for the type; then we can
use that accgen to generate the accumulator; something like
: accgengen ( xt1 xt2 xt3 u "name" -- )
\ left as exercise for the reader :-)
... ;
' + ' @ ' ! 1 cells accgengen naccgen
' f+ ' f@ ' f! 1 floats accgengen faccgen
' d+ ' 2@ ' 2! 2 cells accgengen daccgen
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
Stephen J. Bevan
> ste...@dino.dnsalias.com (Stephen J. Bevan) writes:
> >If you define a money class that internaly contains an integer,
> >big-num, floating point value as you see fit, write an appropriate
> >definition of "+" that takes into account the rounding you want then
> >the Lisp accumulator code would use that definition of "+" and do the
> >appropriate rounding. If instead the desired rouding rules cannot be
> >defined in terms of two numbers but instead must operate over a list
> >of numbers then the Lisp accumulator code would not work.
> ...
> > Forth, like Java, O'Caml and SML
> >cannot solve the problem exactly as stated.
>
> Such a money class would require explicitly calling a constructor to
> generate a "money" value, right? If this is acceptable in the
I interpreted the question as: would the Common Lisp accgen could
calculate the correct answer if one passed it some type that
represented money? The answer is yes. Some of the other languages
with accepted solutions could not do this (e.g. Scheme). I infer from
this that being able to operate on a money type is not a requirement
of Graham's challenge. Of course this can always be added to the
requirements and we can call it say, Pavlyuk's challenge. That extra
requirement in Pavlyuk's challenge would winnow out a number of the
languages accepted by Graham for his challenge.
John Doty
wrote:
> I interpreted the question as: would the Common Lisp accgen could
> calculate the correct answer if one passed it some type that represented
> money? The answer is yes. Some of the other languages with accepted
> solutions could not do this (e.g. Scheme). I infer from this that being
> able to operate on a money type is not a requirement of Graham's
> challenge. Of course this can always be added to the requirements and
> we can call it say, Pavlyuk's challenge. That extra requirement in
> Pavlyuk's challenge would winnow out a number of the languages accepted
> by Graham for his challenge.
To my thinking, Graham's challenge is impossible, since computers don't
handle "numbers" in the vague sense he seems to want to use. Computers
implement imperfect models of arithmetic on finite subsets of the infinite
set, "numbers". The "accepted" examples differ wildly in how they choose a
model and what subset they can apply it to.
--
| John Doty "You can't confuse me, that's my job."
| Home: j...@w-d.org
| Work: j...@space.mit.edu
Stephen J. Bevan
> To my thinking, Graham's challenge is impossible, since computers don't
> handle "numbers" in the vague sense he seems to want to use.
The challenge appears to be quite simple as evidenced by the number of
two and three line solutions that he has accepted. What isn't
necessarily so simple is inferring the boundaries/limits of the
challenge based on his description. I resorted to looking at existing
solutions in order to try and infer the boundaries. The other option,
of course, is simply to ask Graham.
Roman Pavlyuk
> > know I don't like it" people now do not have an excuse for not trying
> > it.
>
> When I tried it, it crashed for no good reason when loading a program.
> That is a feature not in the original. One aspect of colorForth that
fact that block 0 starts at 0 offset in memory - I cannot make this
true under Windows; b) I cannot turn off memory protection under
Windows; c) and there could be bugs, because of a) and b).
> needs to be maintained is the intellectual rigor in the approach. The
To the extent it's possible.
> approach demands zero bugs in the implementation. It is one of the
> risks in building ontop of an operating system, is that you simply
> can't know with precision what your code is doing.
I agree, usually when you have possibility, it's better to build 100%
custom solution. Unfortunately it's not always possible.
>
> At the same time, I think it is a good idea to port to operating
> systems to give a larger audience a taste of what colorForth is all
> about. Inspired by your work, I'm working on a version for X windows.
> It is small C file implementing graphics and input, and a striped down
> color.com. There are some issues with relocation, if anyone reading
> this can help, I would apreciate it.
I was thinking of trying this under Solaris. But is this is color.com
(.asm?) then probably it's Intel-dependent. When I find a possibility,
I'll try to check it out.
>
> > You are talking about ColorForth users. Well, how many ColorForth for
> > Windows users are there? I doubt whether more than 5. Ok, add
> > ColorForth for Raw Iron -- let us assume it totals to 100. It looks
> > like this is an interesting toy, ok, construct, which can be learnt
> > and explored, a tool for changing mind and expanding horizons, but
> > it's not a mass market thing even within Forth community.
>
> Linux was once a "toy" too, with just a single user. Yet Linux defies
> conventional marketing and has grown to millions of users. The key to
> success, without elaborate marketing, is to solve useful problems. If
> colorForth is treated simply as a toy, it will not generate much
> interest.
Do you have any constructive ideas in this direction?
>
> > I think it
> > was marketed poorly -- no documentation and hard to install.
>
> See www.colorforth.com for documentation. Compare with the situation
> with Linux, initially Linux supported minimal hardware as well, and
> the consistent documentation policy with Linux is "see the source
> code".
>
What worked once not necessarily works the next time. Forth itself
always had good documrntation. Well, at least since Leo Brodie.
> required for Linux. Socially colorForth is a tiny fraction of the
> investment, yet the gains in the approach are immeasurable.
So, how do you see helping ColorForth repeat success of Linux? Linux
was an alternative to Windows, all the "marketing" was built on the
fact that this was not M$. Do you see analogies here? iTV could be a
good driver, but it's not there.
> > Product cannot sell itself. I don't think Chuck Moore is a brilliant
> > salesman. If you want to change something, you have to be more active.
>
> I don't know if he is or isn't a brilliant salesman. Yet if he was a
> brilliant salesman he probably wouldn't be selling Forth.
Yes, Dunkin' Donuts sell better. For a good salesman there's no
difference what to sell. For Chuck I think there is a big difference.
> Probably best to leave it at that.
At least for this thread :)
>
> Mark
Roman
Mark Slicker
> > That is a feature not in the original. One aspect of colorForth that
> Yes, there can be a few reasons - a) the program was relying on the
> fact that block 0 starts at 0 offset in memory - I cannot make this
> true under Windows; b) I cannot turn off memory protection under
> Windows; c) and there could be bugs, because of a) and b).
I tried an earlier version, you may have fixed by now. If 'colors',
'icons', and 'edit' don't work, surely there are bugs in your port.
> I was thinking of trying this under Solaris. But is this is color.com
> (.asm?) then probably it's Intel-dependent. When I find a possibility,
> I'll try to check it out.
It it the same colorForth with minimal changes to make work under X
windows.
> > Linux was once a "toy" too, with just a single user. Yet Linux defies
> > conventional marketing and has grown to millions of users. The key to
> > success, without elaborate marketing, is to solve useful problems. If
> > colorForth is treated simply as a toy, it will not generate much
> > interest.
>
> Do you have any constructive ideas in this direction?
Applications. It need not be anything I listed, just be creative and
create a unique colorForth inspired solution. Create something that's
never been created, and do it in an elegant way. People will take
notice.
> > See www.colorforth.com for documentation. Compare with the situation
> > with Linux, initially Linux supported minimal hardware as well, and
> > the consistent documentation policy with Linux is "see the source
> > code".
> >
> What worked once not necessarily works the next time. Forth itself
> always had good documrntation. Well, at least since Leo Brodie.
Yes, I think there is a need for a "Starting ColorForth". I've thought
of writing something like this. A classic language deserves a classic
book. Just to note, I've not read Starting Forth.
> > required for Linux. Socially colorForth is a tiny fraction of the
> > investment, yet the gains in the approach are immeasurable.
>
> So, how do you see helping ColorForth repeat success of Linux? Linux
> was an alternative to Windows, all the "marketing" was built on the
> fact that this was not M$. Do you see analogies here? iTV could be a
> good driver, but it's not there.
Linux is a revolution of software, there can be no mistake. Freedom is
the underlying principle. I see it as freedom vs. anti-freedom, not
non-Windows vs. Windows. Maybe freedom from Microsoft's grip.
I see colorForth as the next revolution, built on the previous
revolution of Linux. It is well known among developers of Linux the
complexity inherent in the system, but things are put up with largely
because of the perceived cost of starting over. Some have no
understanding of the system and therefore think the complexity is
justified just becasue a group of elite is developing the core of it.
colorForth offers a way out, solutions to complex problems in minimal
ammounts of code, simple computer interfaces, and minimal social
investment. The message is this: not only is our software free, it is
simple, it is elegant, it makes good use of scarce resources.
The ultimate goal in individual empowerment, Linux can be seen as a
step down this path, colorForth takes many more steps. Mass market
forth hardware takes the idea even further.
Mark