Paul Graham's accumulator generator 
Author Message
 Paul Graham's accumulator generator

Ladies and Gentlemen,

I think many of you know Paul Grahmam's accumulator generator task -
http://www.*-*-*.com/
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

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.*-*-*.com/


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?



Wed, 24 Aug 2005 06:55:14 GMT  
 Paul Graham's accumulator generator

Quote:

> 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

for time is dead, the sun is over            www.gl.umbc.edu/~etcher1
and there is nothing left to kill.



Wed, 24 Aug 2005 08:06:22 GMT  
 Paul Graham's accumulator generator

Quote:

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


Wed, 24 Aug 2005 10:14:26 GMT  
 Paul Graham's accumulator generator

Quote:

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



Wed, 24 Aug 2005 10:18:44 GMT  
 Paul Graham's accumulator generator
I wouldn't call this Forth:

: f,  ( r -- )  HERE  1 FLOATS ALLOT  F! ;

: fin  ( -- r )  BL WORD COUNT >FLOAT 0= ABORT" fin failed" ;
: foo  CREATE  ( r -- )  fin f,  DOES>  fin f+! ;

foo x 1
x 5
x 2.3
print x


http://www.albany.net/~hello/



Wed, 24 Aug 2005 13:22:43 GMT  
 Paul Graham's accumulator generator


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

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



Wed, 24 Aug 2005 13:44:26 GMT  
 Paul Graham's accumulator generator

 >
 >> 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.
--
I want to be a nothing-knower,               Elko Tchernev

for time is dead, the sun is over            www.gl.umbc.edu/~etcher1
and there is nothing left to kill.



Wed, 24 Aug 2005 15:57:06 GMT  
 Paul Graham's accumulator generator

Quote:

> 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



Wed, 24 Aug 2005 15:57:58 GMT  
 Paul Graham's accumulator generator
Quote:

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

     >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



Wed, 24 Aug 2005 16:09:41 GMT  
 Paul Graham's accumulator generator

[..]

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

Quote:
> 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?)

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




[..]

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



Wed, 24 Aug 2005 18:18:58 GMT  
 Paul Graham's accumulator generator

Quote:

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

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

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 )

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



Wed, 24 Aug 2005 17:49:58 GMT  
 Paul Graham's accumulator generator
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

 Sam
--



Wed, 24 Aug 2005 18:53:21 GMT  
 Paul Graham's accumulator generator
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  


;

  Sam
--



Wed, 24 Aug 2005 19:01:15 GMT  
 Paul Graham's accumulator generator
Perhaps closer to the example:

: f,  ( r -- )  HERE  1 FLOATS ALLOT  F! ;

: fin  ( -- r )  BL WORD COUNT >FLOAT 0= ABORT" fin failed" ;

foo x 1
x 5 FDROP
x 2.3 F.


http://www.albany.net/~hello/



Wed, 24 Aug 2005 22:03:39 GMT  
 Paul Graham's accumulator generator

Quote:

> Perhaps closer to the example:

> : f,  ( r -- )  HERE  1 FLOATS ALLOT  F! ;

> : fin  ( -- r )  BL WORD COUNT >FLOAT 0= ABORT" fin failed" ;


How about:

: f,  ( r -- )  FALIGN HERE  1 FLOATS ALLOT  F! ;

I've been bitten by this "problem" with CREATE a couple of
times. :-)

-- David



Wed, 24 Aug 2005 23:03:03 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Alignment of CREATE and DOES>, was Re: Paul Graham's accumulator generator

2. Paul Graham's Arc

3. Looking for Paul Graham's On Lisp

4. Paul Graham's "On Lisp"

5. ANSI CL (Paul Graham's book)

6. Paul Graham's Macros

7. Dylan book by Paul Graham?

8. Paul Graham essay on language popularity

9. Article about Paul Graham on slashdot today

10. Paul Graham on Slashdot: The Hundred-Year Language

11. New Paul Graham Article

12. Wanted: On Lisp by Paul Graham

 

 
Powered by phpBB® Forum Software