Paul Graham's accumulator generator

51 views
Skip to first unread message

Roman Pavlyuk

unread,
Mar 7, 2003, 5:55:14 PM3/7/03
to
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. 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

unread,
Mar 7, 2003, 7:06:22 PM3/7/03
to
Roman Pavlyuk wrote:
>
> 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.
>
> Your comments?

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

unread,
Mar 7, 2003, 9:14:26 PM3/7/03
to
Elko Tchernev <etch...@acm.org> writes:
> 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

unread,
Mar 7, 2003, 9:18:44 PM3/7/03
to
jo...@eleks.lviv.ua (Roman Pavlyuk) writes:
> 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".
[snip]

> 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

unread,
Mar 8, 2003, 12:22:43 AM3/8/03
to
I wouldn't call this Forth:

: 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


Leo Wong he...@albany.net
http://www.albany.net/~hello/

John Passaniti

unread,
Mar 8, 2003, 12:44:26 AM3/8/03
to

"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

unread,
Mar 8, 2003, 2:57:06 AM3/8/03
to
John Passaniti wrote:
> "Elko Tchernev" <etch...@acm.org> wrote in message
>
>> 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.
>

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

unread,
Mar 8, 2003, 2:57:58 AM3/8/03
to
>
> 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

unread,
Mar 8, 2003, 3:09:41 AM3/8/03
to
>
> : 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>.

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

unread,
Mar 8, 2003, 5:18:58 AM3/8/03
to
jo...@eleks.lviv.ua (Roman Pavlyuk) writes Re: Paul Graham's accumulator generator

[..]

>> : 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

unread,
Mar 8, 2003, 4:49:58 AM3/8/03
to
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:

: 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

unread,
Mar 8, 2003, 5:53:21 AM3/8/03
to
It looks like this one works, the only "natural" type in Forth being
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

unread,
Mar 8, 2003, 6:01:15 AM3/8/03
to s...@rfc1149.net
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

Leo Wong

unread,
Mar 8, 2003, 9:03:39 AM3/8/03
to
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@ ;

foo x 1
x 5 FDROP
x 2.3 F.

David N. Williams

unread,
Mar 8, 2003, 10:03:03 AM3/8/03
to
Leo Wong wrote:
> 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

unread,
Mar 8, 2003, 11:42:45 AM3/8/03
to

"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

unread,
Mar 8, 2003, 11:49:07 AM3/8/03
to
jo...@eleks.lviv.ua (Roman Pavlyuk) writes:
> 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

unread,
Mar 8, 2003, 12:14:49 PM3/8/03
to
m...@iae.nl (Marcel Hendrix) writes:
> 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

unread,
Mar 8, 2003, 4:22:02 PM3/8/03
to
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.

"Stephen J. Bevan" <ste...@dino.dnsalias.com> wrote in message
news:m38yvpz...@dino.dnsalias.com...

Stephen J. Bevan

unread,
Mar 8, 2003, 7:34:47 PM3/8/03
to
"Leo Wong" <he...@albany.net> writes:
> 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

unread,
Mar 8, 2003, 10:42:01 PM3/8/03
to
"Stephen J. Bevan" <ste...@dino.dnsalias.com> wrote in message
news:m34r6dz...@dino.dnsalias.com...
> ...

> 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

unread,
Mar 9, 2003, 2:34:54 AM3/9/03
to
jo...@eleks.lviv.ua (Roman Pavlyuk) wrote in message news:<ac4a01c6.0303...@posting.google.com>...

> 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

unread,
Mar 9, 2003, 5:00:21 AM3/9/03
to
"Leo Wong" <he...@albany.net> Re: Paul Graham's accumulator generator

> 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

unread,
Mar 9, 2003, 5:29:22 AM3/9/03
to

> 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

unread,
Mar 9, 2003, 11:51:54 AM3/9/03
to
m...@iae.nl (Marcel Hendrix) writes:

> > 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

unread,
Mar 9, 2003, 1:10:13 PM3/9/03
to
Thanks to John Passatini for

"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

unread,
Mar 9, 2003, 2:27:22 PM3/9/03
to
Bill Bouma <bronc...@yahoo.com> wrote in message news:<3e6b1601_2@newsfeed>...

> > 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

unread,
Mar 9, 2003, 2:45:50 PM3/9/03
to

"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

unread,
Mar 9, 2003, 3:21:26 PM3/9/03
to
Stephen J. Bevan wrote:
>
> 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

unread,
Mar 9, 2003, 3:36:08 PM3/9/03
to

"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

unread,
Mar 9, 2003, 6:24:37 PM3/9/03
to
Elko Tchernev <etch...@acm.org> writes:
> 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

unread,
Mar 9, 2003, 8:02:21 PM3/9/03
to
> 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 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

unread,
Mar 9, 2003, 8:36:52 PM3/9/03
to
> > (a) What is number?

>
> While I agree with your argument, the Common Lisp standard provides
> integers, reals, floats, and complex numbers.
> : (funcall (adder #c(3 1/2)) 3.4)
> #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

unread,
Mar 10, 2003, 12:44:21 AM3/10/03
to
> I've done the top level of this concept in colorForth, I think
> 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

unread,
Mar 10, 2003, 12:51:42 AM3/10/03
to
jo...@eleks.lviv.ua (Roman Pavlyuk) wrote in message news:<ac4a01c6.03030...@posting.google.com>...
> [ 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

unread,
Mar 9, 2003, 7:23:18 AM3/9/03
to
In article <3E6934A8...@acm.org>,
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

unread,
Mar 10, 2003, 5:25:11 AM3/10/03
to
>>>>> "Roman" == Roman Pavlyuk <jo...@eleks.lviv.ua> writes:

>> 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

unread,
Mar 10, 2003, 6:37:58 AM3/10/03
to
Samuel Tardieu <s...@rfc1149.net> wrote:
> 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

unread,
Mar 10, 2003, 12:34:35 PM3/10/03
to
jo...@eleks.lviv.ua (Roman Pavlyuk) wrote in message news:<ac4a01c6.03030...@posting.google.com>...
[ ... ]

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

unread,
Mar 10, 2003, 1:38:21 PM3/10/03
to
masl...@oakland.edu (Mark Slicker) writes:
> 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

unread,
Mar 10, 2003, 1:44:42 PM3/10/03
to
"Geoffrey Summerhayes" <sum...@NhOoStPmAaMil.com> wrote in message news:<RRMaa.281$Mz.5...@news20.bellglobal.com>...

A very clear and educational explanation of some details
involved in the discussion.

Thanks very much,
Jeff Fox

Stephen J. Bevan

unread,
Mar 10, 2003, 4:31:01 PM3/10/03
to
jo...@eleks.lviv.ua (Roman Pavlyuk) writes:
> 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.
[snip]

> * 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

unread,
Mar 10, 2003, 5:16:15 PM3/10/03
to
"John Passaniti" <nn...@JapanIsShinto.com> wrote in message news:<_qfaa.14883$lS.1...@twister.nyroc.rr.com>...
> "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.

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

unread,
Mar 10, 2003, 5:25:34 PM3/10/03
to
Anton Ertl wrote:
>
> 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:
>
> : 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

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

unread,
Mar 12, 2003, 5:41:18 AM3/12/03
to
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? :)

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

unread,
Mar 12, 2003, 5:59:09 AM3/12/03
to
> >
> > 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,
^^^^^^^^^^^^^^^^^^^^^^^^^^^---- here is the point!

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

unread,
Mar 12, 2003, 5:59:46 AM3/12/03
to
Roman Pavlyuk <jo...@eleks.lviv.ua> wrote:
> 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

unread,
Mar 12, 2003, 6:06:40 AM3/12/03
to
> 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.

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

unread,
Mar 12, 2003, 6:12:02 AM3/12/03
to
Roman Pavlyuk wrote:
> 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

unread,
Mar 12, 2003, 6:23:08 AM3/12/03
to
> 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).
Wow ! I hope Chuck Moore does not read this and does not know in what
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

unread,
Mar 12, 2003, 6:51:56 AM3/12/03
to
> 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? 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

unread,
Mar 12, 2003, 12:03:59 PM3/12/03
to

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

unread,
Mar 12, 2003, 3:11:15 PM3/12/03
to
jo...@eleks.lviv.ua (Roman Pavlyuk) wrote in message news:<ac4a01c6.03031...@posting.google.com>...
> > [ 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

unread,
Mar 12, 2003, 5:02:06 PM3/12/03
to
jo...@eleks.lviv.ua (Roman Pavlyuk) wrote in message news:<ac4a01c6.03031...@posting.google.com>...

> > 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

unread,
Mar 12, 2003, 5:22:52 PM3/12/03
to
"Stephen J. Bevan" <ste...@dino.dnsalias.com> wrote in message
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.

Leo Wong he...@albany.net
http://www.albany.net/~hello/

Roman Pavlyuk

unread,
Mar 12, 2003, 10:56:07 PM3/12/03
to
>
> 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

unread,
Mar 12, 2003, 11:43:34 PM3/12/03
to
> 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.

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