Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #37427 > unrolled thread

8 queens problem in Oforth

Back to article view | Back to comp.lang.forth

Contents

  8 queens problem in Oforth "WJ" <w_a_x_man@yahoo.com> - 2015-03-19 07:53 +0000
    Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-19 08:58 -0700
      Re: 8 queens problem in Oforth Doug Hoffman <glidedog@gmail.com> - 2015-03-20 08:16 -0400
        Re: 8 queens problem in Oforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-21 10:11 +0000
          Re: 8 queens problem in Oforth franck.bensusan@gmail.com - 2015-03-21 03:45 -0700
            Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-21 14:14 -0700
              Re: 8 queens problem in Oforth franck.bensusan@gmail.com - 2015-03-21 14:28 -0700
                Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-21 14:38 -0700
                  Re: 8 queens problem in Oforth franck.bensusan@gmail.com - 2015-03-21 15:15 -0700
                    Re: 8 queens problem in Oforth hughaguilar96@gmail.com - 2015-03-21 18:23 -0700
                      Re: 8 queens problem in Oforth franck.bensusan@gmail.com - 2015-03-22 03:03 -0700
                        Re: 8 queens problem in Oforth hughaguilar96@gmail.com - 2015-03-22 14:04 -0700
                          Re: 8 queens problem in Oforth franck.bensusan@gmail.com - 2015-03-22 16:34 -0700
                            Re: 8 queens problem in Oforth hughaguilar96@gmail.com - 2015-03-22 21:49 -0700
                              Re: 8 queens problem in Oforth Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-03-23 00:05 -0700
                                Re: 8 queens problem in Oforth hughaguilar96@gmail.com - 2015-03-23 21:43 -0700
                                  Re: 8 queens problem in Oforth franck.bensusan@gmail.com - 2015-03-24 04:13 -0700
                              Re: 8 queens problem in Oforth franck.bensusan@gmail.com - 2015-03-23 00:17 -0700
                    Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-21 19:47 -0700
                      Re: 8 queens problem in Oforth franck.bensusan@gmail.com - 2015-03-22 08:41 -0700
                        Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-22 13:37 -0700
                      Re: 8 queens problem in Oforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-22 18:13 +0100
                        Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-22 13:55 -0700
                          Re: 8 queens problem in Oforth "Alex McDonald" <blog@rivadpm.com> - 2015-03-22 21:08 +0000
                            Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-22 14:39 -0700
                              Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-22 14:50 -0700
                              Re: 8 queens problem in Oforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-22 22:58 +0100
                                Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-22 15:13 -0700
                                  Re: 8 queens problem in Oforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-23 01:03 +0100
                                    Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-22 17:33 -0700
                                      Re: 8 queens problem in Oforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-23 02:37 +0100
                                        Re: 8 queens problem in Oforth hughaguilar96@gmail.com - 2015-03-22 20:53 -0700
                                        Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-22 21:11 -0700
                                          Re: 8 queens problem in Oforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-23 11:34 +0000
                                            Re: 8 queens problem in Oforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-23 19:31 +0000
                                            Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-23 15:56 -0700
                                              Re: 8 queens problem in Oforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-24 00:38 +0100
                                                Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-23 19:08 -0700
                                                Re: 8 queens problem in Oforth hughaguilar96@gmail.com - 2015-03-30 05:02 -0700
                                                  Re: 8 queens problem in Oforth hughaguilar96@gmail.com - 2015-03-30 05:08 -0700
                                                    Re: 8 queens problem in Oforth "Alex McDonald" <blog@rivadpm.com> - 2015-03-30 15:36 +0100
                                          Re: 8 queens problem in Oforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-23 16:46 +0100
                                            Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-23 15:32 -0700
                                              Re: 8 queens problem in Oforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-23 23:48 +0100
                                                Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-23 16:14 -0700
                                    Re: 8 queens problem in Oforth hughaguilar96@gmail.com - 2015-03-22 17:54 -0700
                              Re: 8 queens problem in Oforth "Alex McDonald" <blog@rivadpm.com> - 2015-03-22 23:09 +0000
                          Re: 8 queens problem in Oforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-22 22:11 +0100
                            Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-22 14:48 -0700
                              Re: 8 queens problem in Oforth hughaguilar96@gmail.com - 2015-03-22 15:11 -0700
                              Re: 8 queens problem in Oforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-23 11:29 +0000
                                Re: 8 queens problem in Oforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-23 12:20 +0000
                          Re: 8 queens problem in Oforth hughaguilar96@gmail.com - 2015-03-22 14:21 -0700
                          Re: 8 queens problem in Oforth Coos Haak <chforth@hccnet.nl> - 2015-03-22 22:30 +0100
              Re: 8 queens problem in Oforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-23 14:45 +0000
                Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-23 14:53 -0700
                  Re: 8 queens problem in Oforth "Elizabeth D. Rather" <erather@forth.com> - 2015-03-24 09:16 -1000
                    Re: 8 queens problem in Oforth Paul Rubin <no.email@nospam.invalid> - 2015-03-24 12:40 -0700
                    Re: 8 queens problem in Oforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-30 12:24 +0000
            Re: 8 queens problem in Oforth Coos Haak <chforth@hccnet.nl> - 2015-03-21 22:27 +0100
    Re: 8 queens problem in Oforth "WJ" <w_a_x_man@yahoo.com> - 2015-03-19 20:31 +0000
    Re: 8 queens problem in Oforth "WJ" <w_a_x_man@yahoo.com> - 2015-03-19 20:35 +0000
    Re: 8 queens problem in Oforth "WJ" <w_a_x_man@yahoo.com> - 2015-03-21 17:31 +0000
      Re: 8 queens problem in Oforth "WJ" <w_a_x_man@yahoo.com> - 2015-03-21 20:50 +0000
      Re: 8 queens problem in Oforth "WJ" <w_a_x_man@yahoo.com> - 2015-03-21 21:52 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#37756

on 30/03/2015 13:08:41, hogh wrote:

> 
> I'm being generous when I say that Bernd has written a "handful" of
> higher- order functions --- afaik, TRAVERSE-WORDLIST is the only one
> he has ever wr itten --- he trots out this same example every time the
> subject comes up.
> 

I wrote the RfD for TRAVERSE-WORDLIST, there was a vote and the stds
committee refined & added it to the spec.

[toc] | [prev] | [next] | [standalone]

#37591

Paul Rubin wrote:

>> For cases like higher order functions, you don't need the dynamic
>> generation at run-time.  In Forth, the quotation shares the stack with
>> the quotation caller, which can be functionally identical to the
>> Scheme situation where the quotation shares the environment.
> 
> The quotation doesn't know if it might be called more than once or what
> else might want to use its args, against the usual convention that
> functions should consume their parameters.  Maybe it's ok to expect
> quotations in this situation to ignore that convention and leave the
> stack alone.  And you're left with the situation like "derivative"
> above, where the HOF wants to return, leaving a callable xt behind.

No, the quotation knows exactly how it is called.  And that it can use the 
stack, and leave stuff its next invocation is going to use.

Of course, the higher oder function can do anything with the stack it likes 
after it has called it's xts.

You probably wouldn't want to create a derivative function, but rather just 
use a higher order function if you want to pass many different functions 
into it:

0.00001e Fconstant h
: derivative ( f1 h xt -- f2 )  >r
  ftuck fover f+ r@ execute fswap r> execute f- fswap f/ ;
: newton-step ( fx0 fx xt -- fx0' ) >r
  fdup r@ execute fswap h r> derivative f/ f- ;

But certainly, you could

: derivative { h xt -- xt' }
  :noname postpone fdup h fliteral postpone f+ xt compile,
  postpone fswap xt compile, postpone f- h fliteral postpone f/ postpone ; ;

You then would most likely use that derivative function at compile time, not 
at run-time.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

[toc] | [prev] | [next] | [standalone]

#37603

Bernd Paysan <bernd.paysan@gmx.de> writes:
> You probably wouldn't want to create a derivative function...
> : derivative ( f1 h xt -- f2 )  >r
>   ftuck fover f+ r@ execute fswap r> execute f- fswap f/ ;

Sure, this is fine in the Newton step for finding a zero of f, but
suppose then want find the minimum or maximum of f?  You'd like use the
exact same Newton step subroutine to find a zero of the derivative.
E.g.  to find the x that minimizes x**2 - 4x + 5 you could use something
along the lines of
    minimize f = solve (derivative f)
    x1 = minimize (\x -> x**2 - 4x + 5)

This didn't take much thought because the thing that came back from
derivative is a re-usable, first class function.  And there's surely
some approach possible to deal with that too, but it's sure nice to not
have to spend your coding time figuring out such things, if the compiler
can do it for you.

> But certainly, you could
> : derivative { h xt -- xt' }
>   :noname postpone fdup h fliteral postpone f+ xt compile,
>   postpone fswap xt compile, postpone f- h fliteral postpone f/ postpone ; ;
> You then would most likely use that derivative function at compile
> time, not at run-time.

Right, not that great for creating lots of them on the fly, since they
aren't gc'd.

Have you looked at John Hughes' paper "Why functional programming
matters"?

http://www.cse.chalmers.se/~rjmh/Papers/whyfp.pdf

The section with numerical derivative examples starts on page 11, and
then it goes on to numerical integration and is pretty interesting.  It
develops an integration function in a quite natural way that's much
better than the ones usually taught in math class.  Of course the
resulting algorithm could be back-ported into Forth or Fortran (it may
be the same as the traditional Romberg method), but it's much more
natural using the higher-order approach.

[toc] | [prev] | [next] | [standalone]

#37604

Paul Rubin wrote:
>> But certainly, you could
>> : derivative { h xt -- xt' }
>>   :noname postpone fdup h fliteral postpone f+ xt compile,
>>   postpone fswap xt compile, postpone f- h fliteral postpone f/ postpone
>>   ; ;
>> You then would most likely use that derivative function at compile
>> time, not at run-time.
> 
> Right, not that great for creating lots of them on the fly, since they
> aren't gc'd.

You can use marker/forget to explicitely free the memory after use.

> Have you looked at John Hughes' paper "Why functional programming
> matters"?
> 
> http://www.cse.chalmers.se/~rjmh/Papers/whyfp.pdf
> 
> The section with numerical derivative examples starts on page 11, and
> then it goes on to numerical integration and is pretty interesting.  It
> develops an integration function in a quite natural way that's much
> better than the ones usually taught in math class.  Of course the
> resulting algorithm could be back-ported into Forth or Fortran (it may
> be the same as the traditional Romberg method), but it's much more
> natural using the higher-order approach.

I don't understand why you don't get it, even though you see my examples: 
Forth *has* higher-order features.  Fortran doesn't.

What it doesn't have (usually) is GC.  If you really want to allocate many, 
many functions, and not run out of space, you need some more explicit memory 
management in Forth.

Though I'm not at all sure that this integration approach is "more natural".  
After all, this approach requires to compute f() two times on each point of 
the approximated curve.  The classical thing is that when two points aren't 
sufficient, you do more points, and then have (f(x0)/2 + f(x1) + f(x2) +++ 
f(xn)/2)*(xn-x0)/n.

And then the numerical integral is just an ordinary higher order function.  
You still can create a compiled version of it in Forth to be more speed 
efficient.  Typically, you would do so at compile time, not at run time.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

[toc] | [prev] | [next] | [standalone]

#37607

Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Right, not that great for creating lots of them on the fly, since they
>> aren't gc'd.
> You can use marker/forget to explicitely free the memory after use.

That only works if no other stuff is created the same way during the
computation, that needs to be kept around.  This is why GC was invented.

> I don't understand why you don't get it, even though you see my examples: 
> Forth *has* higher-order features.  Fortran doesn't.

I think you can pass something like xt's in Fortran, i.e. you can pass
the name of a function as a parameter, similarly to in C.  I'm not sure
how that's different from Forth's xt-passing style.  What's missing is
"compile," which makes a new callable, but it's still not on an equal
footing with other values like integers, since it consumes memory every
time you make one, that has to be freed manually.  (OK, I guess using
marker/forget for functions is like using the data stack for numbers,
but it seems easier for words to interfere).
>
> What it doesn't have (usually) is GC.  If you really want to allocate
> many, many functions, and not run out of space, you need some more
> explicit memory management in Forth.

Ok, fair enough.

> Though I'm not at all sure that this integration approach is "more
> natural".  After all, this approach requires to compute f() two times
> on each point of the approximated curve.

The integration routine in the Hughes paper?  I don't think it does that
except in the first illustrative example.  See the middle of page 14:

    "Also, (f mid) is evaluated in each recursive call. It is therefore
    preferable to use the following version which never recomputes a
    value of f."

> The classical thing is that when two points aren't sufficient, you do
> more points, and then have (f(x0)/2 + f(x1) + f(x2) +++
> f(xn)/2)*(xn-x0)/n.

That's considerably worse than what the paper does.  The paper's method
amounts to using higher and higher derivatives of the function as you
add more points instead of throwing that info away.  So with two points
you have the trapezoid method (linear approximation of the function);
then you add a third point and instead of a piecewise linear
approximation you get a quadratic approximation (equivalent to Simpson's
rule); then with more points you get even higher order approximations.
I haven't checked carefully but I think this may be equivalent to
Richardson extrapolation: basically you do a polynomial fit to the
sequence of approximations you've done, then extrapolate to find the
polynomial's value if the integration step size is zero.  That
(Romberg's method) is much better than the trapezoid rule, Simpson's
rule, etc.

> And then the numerical integral is just an ordinary higher order
> function.  You still can create a compiled version of it in Forth to
> be more speed efficient.  Typically, you would do so at compile time,
> not at run time.

Yes, for sure, these methods were well-known in numerical analysis long
before Scheme was invented and maybe before computers.  There are plenty
of Fortran implementations and maybe some Forth ones.  It's just
conceptually clearer (at least debatably) to write them the way the
Hughes paper does.

[toc] | [prev] | [next] | [standalone]

#37566

On Sunday, March 22, 2015 at 5:03:05 PM UTC-7, Bernd Paysan wrote:
> Sure, that would be stupid to do it that way.  Forth OOP works different, 
> you allocate a piece of memory for the object's data, and have a vtable (or 
> some other dispatch mechanism) to get from the object pointer to the method 
> you want to call.  That works pretty well within the concepts Forth 
> provides, and doesn't work with the concepts Scheme provides you.

Don't be calling people stupid.

You aren't really the best person to be grandly declaring what "Forth OOP" is --- you are the same one who faked quotations in Forth-200x.

[toc] | [prev] | [next] | [standalone]

#37559

on 22/03/2015 21:39:36, Paul Rubin wrote:
> "Alex McDonald" <blog@rivadpm.com> writes:
>> :noname sin sqrt ; constant sin-sqrt
> 
> No, I asked how to do the composition at runtime. Can you write a word
> "compose" that takes two ARBITRARY xt's (not known at compile time,
> and maybe themselves created by "compose") and makes a new xt that
> when you run it, composes the functions implemented by the two xt's
> that you passed? "compose" or similar words must necessarily allocate
> heap space to store their result.
> 
> I think the style is possible but not all that useful if you don't
> have GC.
> 

Composing XTs at run time can be (a) done at compile time (since the XTs
have to be known in advance) or (b) done using the compiler at run time.
I prefer (a). Here are some alternatives.

This:

defer bar
: foo somecond if ['] xt1 ['] xt2 compose is bar then ; 

might just as well be written (and much more flexibly too, since I can
compose several XTs and include IF ELSE THEN and so on) as

: foo somecond if [: xt1 xt2 ;] is bar then ;

To do this on GC'd storage can't be done portably. 

Or... You might want something like (taken from my Forth)

: iterate ( i*x node iterator -- i*x' ) \ iterate over a linked list of
nodes >r \ the nodes have a next pointer at offset 0
            begin ?dup
            while
              r@ over @
>r >r execute r> \ iterator sees ( i*x node), returns ( i*x'))
            repeat r>drop ;

: link, ( addr -- ) \ build node at here, link to supplied node
            here over @ , swap ! ;

: +chain ( xt chain_address -- ) \ for normal forward chains
    link, , ;

: chain+ ( xt chain_address -- ) \ add chain item at the end
    begin dup @ dup while nip repeat drop
    +chain ;

: chain: ( <name> -- )
    create 0 ,
    ['] noop , ;

: chain-iterate ( chain_address -- ) @ [: cell+ @ execute ;] iterate ;

chain: things-to-do
' xt1 things-to-do +chain
' xt2 things-to-do +chain
\ and so on

things-to-do chain-iterate \ execute the XTs in the chain

Here you could allocate nodes in a chain using ALLOCATE; the example
shown uses ALLOTed storage using comma ",". GC could be used.

Or... Put code in a file and conditionally INCLUDE it. 

[toc] | [prev] | [next] | [standalone]

#37548

Paul Rubin wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Of course Forth has first-class functions.  We call them "xt", execution
>> tokens.  You can pass them as parameters to other words, you can return
>> an xt as result of a word, you can use xts to define higher order
>> functions.
> 
> Hmm, ok, I hadn't thought of xt's as first-class functions but maybe
> they are.  Is it possible to create them at runtime?  I.e. is there an
> ANS portable way to do something like:
> 
>     \ given functions f and g, make a new function that composes them
>     : compose ( xt1 xt2 -- xt3 ) .... ;
> 
> So this should work:
> 
>    ['] sin ['] sqrt compose constant sin-sqrt      => ok
> 
>    2e sin-sqrt execute f.       => 0.9877659459927356 ok
> 
> That number is sin(sqrt(2)).  "Compose" has made a new xt that combines
> the actions of the previous two.  It's like adding two numbers in order
> to create a new number.  I'd say that to call xt's first class
> functions, you have to be able to do this.

Sure, no doubts about that.  So let's do it:

: compose ( xt1 xt2 -- xt3 ) swap >r >r
  :noname r> compile, r> compile, postpone ; ;

Fixing the bugs in your code, to test it:

' fsin ' fsqrt compose constant sin-sqrt  ok
2e sin-sqrt execute f. 0.987765945992736  ok

Are you happy with that?

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

[toc] | [prev] | [next] | [standalone]

#37552

Bernd Paysan <bernd.paysan@gmx.de> writes:
> : compose ( xt1 xt2 -- xt3 ) swap >r >r
>   :noname r> compile, r> compile, postpone ; ;
> Are you happy with that?

Nice!  compile, is the magic wand that makes the new code and I wasn't
thinking of it.

But, the code goes into the dictionary: is there a way to free the
memory when you are done with the new xt?  In the absence of gc I
imagined "compose" would use "allocate".  Maybe you could do some
non-portable hack that uses COMPILE, and then copies the new code into
an allocated buffer and then restores HERE to where it was before you
started.

[toc] | [prev] | [next] | [standalone]

#37555

On Sunday, March 22, 2015 at 2:48:28 PM UTC-7, Paul Rubin wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
> > : compose ( xt1 xt2 -- xt3 ) swap >r >r
> >   :noname r> compile, r> compile, postpone ; ;
> > Are you happy with that?
> 
> Nice!  compile, is the magic wand that makes the new code and I wasn't
> thinking of it.

Notice how both Bernd and I work around the bug in ANS-Forth that causes control-flow data to be on the data-stack, getting in the way of the user's data --- this is why >R was needed --- Bernd knows that the work-around is needed, because he did the work-around himself, but he won't fix the bug in Forth-200x and require the control-flow stack to be distinct from the data-stack.

Bernd wants to avoid shining a spotlight on the bugs of ANS-Forth --- this is what happens when you fix a bug!

> But, the code goes into the dictionary: is there a way to free the
> memory when you are done with the new xt?  In the absence of gc I
> imagined "compose" would use "allocate".  Maybe you could do some
> non-portable hack that uses COMPILE, and then copies the new code into
> an allocated buffer and then restores HERE to where it was before you
> started.

In ANS-Forth, use MARKER and then call that marker later to get rid of the code.

In my language, I will compile into the heap --- so you would use FREE to get rid of words --- but that can't be done in ANS-Forth

You could ALLOCATE some memory for your word, then temporarily set DP to that block of memory in the heap, then reset DP afterward --- but this is highly non-standard.

[toc] | [prev] | [next] | [standalone]

#37583

Paul Rubin <no.email@nospam.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> writes:
>> : compose ( xt1 xt2 -- xt3 ) swap >r >r
>>   :noname r> compile, r> compile, postpone ; ;
>> Are you happy with that?
>
>Nice!  compile, is the magic wand that makes the new code and I wasn't
>thinking of it.
>
>But, the code goes into the dictionary: is there a way to free the
>memory when you are done with the new xt?

MARKER/FORGET

Of course that also frees everything else that has been allocated in
the meantime.

- 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
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#37584

In article <2015Mar23.122946@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Paul Rubin <no.email@nospam.invalid> writes:
>>Bernd Paysan <bernd.paysan@gmx.de> writes:
>>> : compose ( xt1 xt2 -- xt3 ) swap >r >r
>>>   :noname r> compile, r> compile, postpone ; ;
>>> Are you happy with that?
>>
>>Nice!  compile, is the magic wand that makes the new code and I wasn't
>>thinking of it.
>>
>>But, the code goes into the dictionary: is there a way to free the
>>memory when you are done with the new xt?
>
>MARKER/FORGET
>
>Of course that also frees everything else that has been allocated in
>the meantime.

There is no reason where there couldn't be a garbage collect
on the dictionary, under some restrictions, like not assembling
rogue code between definition where jumps to it are kept in the
dark. It would have to be smart, not dumb like MARKER and FORGET
are.

You could also consider this a code compacter.
It would have use as making a Forth turnkey program smaller by
kicking out unused words and buffers. It should be done after
high level in-lining and before low-level inlining and
peep-hole optimisation.
(Low-level inlining in my book removes superfluous headers.)

>
>- anton
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#37549

On Sunday, March 22, 2015 at 1:55:20 PM UTC-7, Paul Rubin wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
> > Of course Forth has first-class functions.  We call them "xt", execution 
> > tokens.  You can pass them as parameters to other words, you can return an 
> > xt as result of a word, you can use xts to define higher order functions.
> 
> Hmm, ok, I hadn't thought of xt's as first-class functions but maybe
> they are.  Is it possible to create them at runtime?  

I did this in my Alien-Alphabet program:
https://groups.google.com/forum/#!searchin/comp.lang.forth/codejam/comp.lang.forth/3Y4w_MdYl0k/IMCaSNvF864J

> I.e. is there an
> ANS portable way to do something like:
> 
>     \ given functions f and g, make a new function that composes them
>     : compose ( xt1 xt2 -- xt3 ) .... ;
> 
> So this should work:
> 
>    ['] sin ['] sqrt compose constant sin-sqrt      => ok
> 
>    2e sin-sqrt execute f.       => 0.9877659459927356 ok
> 
> That number is sin(sqrt(2)).  "Compose" has made a new xt that combines
> the actions of the previous two.  It's like adding two numbers in order
> to create a new number.  I'd say that to call xt's first class
> functions, you have to be able to do this.

This is trivial:

: compose ( xt1 xt2 -- xt3 ) 
    2>r   
    :noname  r> compile,  r> compile,  postpone ; 
    ;  ok
' fsin ' fsqrt compose  constant sin-sqrt  ok
2e sin-sqrt execute f. 0.98776595  ok

[toc] | [prev] | [next] | [standalone]

#37550

Op Sun, 22 Mar 2015 13:55:16 -0700 schreef Paul Rubin:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Of course Forth has first-class functions.  We call them "xt", execution 
>> tokens.  You can pass them as parameters to other words, you can return an 
>> xt as result of a word, you can use xts to define higher order functions.
> 
> Hmm, ok, I hadn't thought of xt's as first-class functions but maybe
> they are.  Is it possible to create them at runtime?  I.e. is there an
> ANS portable way to do something like:
> 
>     \ given functions f and g, make a new function that composes them
>     : compose ( xt1 xt2 -- xt3 ) .... ;
> 
> So this should work:
> 
>    ['] sin ['] sqrt compose constant sin-sqrt      => ok
> 
>    2e sin-sqrt execute f.       => 0.9877659459927356 ok
> 
> That number is sin(sqrt(2)).  "Compose" has made a new xt that combines
> the actions of the previous two.  It's like adding two numbers in order
> to create a new number.  I'd say that to call xt's first class
> functions, you have to be able to do this.

: compose       ( 0 [xt1..] xt2 -- xt3 )
        0 >r
        begin   dup	\ Place xt in the original order
        while   >r
        repeat
        drop :noname
        begin   r> dup
        while   compile,
        repeat
        drop postpone ;
    ;

0
:noname 1 . ;
:noname 2 . ;
:noname 3 . ;
:noname 4 . ;

compose alias digits

:> digits 1 2 3 4 ok

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

[toc] | [prev] | [next] | [standalone]

#37588

Paul Rubin <no.email@nospam.invalid> writes:
>It still seems much different from Forth, whose main characteristic
>(IMHO) is the availability of the input stream to words in the text
>interpreter, i.e. the possibility of user-defined defining words, and
>the possibility of an implementation where almost all of the usual Forth
>words are actually defined that way.

IMO that's the least desirable characteristic of Forth, and one we
should avoid in our programs.  For user-defined defining words, it is
only necessary because the system-defined defining words have that
characteristic; In Gforth we provide ways to avoid this characteristic
for this purpose, e.g.:

: myconst create , does> @ ;

\ NEXTNAME and NONAME work only for defining words
5 s" foo" nextname myconst 
foo .
7 noname myconst
lastxt execute .

\ more general than NEXTNAME
9 s" bar" ' myconst execute-parsing
bar .

The use of global state for NEXTNAME, NONAME, and LASTXT is not
desirable, either.

- 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
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#37602

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Forth, whose main characteristic (IMHO) is the availability of the
>>input stream to words in the text interpreter...
> IMO that's the least desirable characteristic of Forth, and one we
> should avoid in our programs.  

Good point, but I think not necessarily in conflict.  Forth is
traditionally self-hosted and is implemented that way at the system
level, but it's fine to say user programs should avoid that feature.  As
an imperfect analogy, one could also say that a self-hosted Lisp
interpreter needs a way to break the Lisp abstraction and manipulate raw
memory to implement GC.  But of course user programs should not use that
feature either.

[toc] | [prev] | [next] | [standalone]

#37622

On 3/23/15 11:53 AM, Paul Rubin wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> Forth, whose main characteristic (IMHO) is the availability of the
>>> input stream to words in the text interpreter...
>> IMO that's the least desirable characteristic of Forth, and one we
>> should avoid in our programs.
>
> Good point, but I think not necessarily in conflict.  Forth is
> traditionally self-hosted and is implemented that way at the system
> level, but it's fine to say user programs should avoid that feature.

Why?

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#37623

"Elizabeth D. Rather" <erather@forth.com> writes:
>> it's fine to say user programs should avoid that feature.
> Why?

Better talk to Anton about that.  He has written a paper about it.

[toc] | [prev] | [next] | [standalone]

#37753

"Elizabeth D. Rather" <erather@forth.com> writes:
>On 3/23/15 11:53 AM, Paul Rubin wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>> Forth, whose main characteristic (IMHO) is the availability of the
>>>> input stream to words in the text interpreter...
>>> IMO that's the least desirable characteristic of Forth, and one we
>>> should avoid in our programs.
>>
>> Good point, but I think not necessarily in conflict.  Forth is
>> traditionally self-hosted and is implemented that way at the system
>> level, but it's fine to say user programs should avoid that feature.
>
>Why?

Because you can only easily pass literal parameters in the input
stream.  Anything else is cumbersome to do if you need to build on
words that take their parameters from the input stream.  And that's
why we should avoid that everywhere (or at least have companion words
that get the input passed on the stack, too, like INCLUDED and
INCLUDE), not just in our programs.

It only took a few days after the posting for the problem to rear it's
ugly head in this group: Albert van der Horst wants to define a word
that defines a synonym for a word with the same name, but in a
different wordlist
<5517f359$0$23216$e4fe514c@dreader34.news.xs4all.nl>.  This builds on
SYNONYM ( "new" "old" -- ), but the new word should only need one
occurence of the name.  This is cumbersome to implement, even if you
have EXECUTE-PARSING.  If we had

SYNONYMED ( new-a new-u old-a old-u -- )

it would be trivial.

- 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
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#37522

Op Sat, 21 Mar 2015 03:45:24 -0700 (PDT) schreef franck.bensusan@gmail.com:

>>>>> This is a fun language.  ... [snip]
>>>>
>>>> It seems to have almost nothing in common with Forth.
>>>
>>>It appears to be a Forth dialect, IMO, perhaps more along the
>>>lines of 8th though.
>> 
>> From the examples that WJ posted, Oforth looks less close to Forth
>> than Factor or Postscript, at least syntactically.  It has all this
>> stuff that it's doing with the parentheses that does not look like
>> Forth.  Semantically, it seems that the axamples work a lot with
>> higher-order functions, like in functional programming.
>> 
> 
> Oforth interpreter allows use of sugar to handle parameters of functions called. 
> This sugar is not mandatory. It is a programming style.
> 
> If f is a function and a b c are parameters that should be on the stack to call f : 
> 
> c b a f 
> and
> f(a, b, c)
> 
> are the same call. Indeed, interpreter will translate the last one into the first one before performing (or compiling) f call. There is no performance cost to use this sugar.

Someone is fan of the dreaded LOCALS| c b a | syntax.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web