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

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

Re: "Forth is Sudoku for programmers"

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 14:56 -0700
    Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 15:02 -0700
    Re: "Forth is Sudoku for programmers" Doug Hoffman <glidedog@gmail.com> - 2016-08-12 22:05 -0400
      Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-12 21:05 -0700
        Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 22:15 -0700
          Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-12 23:39 -0700
            Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-13 00:03 -0700
            Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-13 00:07 -0700
              Re: "Forth is Sudoku for programmers" Doug Hoffman <glidedog@gmail.com> - 2016-08-13 07:35 -0400
                Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-13 17:17 -0700
                  Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-13 20:04 -0700
                    Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-13 20:38 -0700
                      Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-13 20:46 -0700
                      Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-14 06:02 -0700
                        Re: "Forth is Sudoku for programmers" Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-08-14 23:04 +0100
                          Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-14 16:01 -0700
                    Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-13 21:53 -0700
                      Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-14 07:45 -0700
                        Re: "Forth is Sudoku for programmers" franck.bensusan@gmail.com - 2016-08-15 06:44 -0700
                      Re: "Forth is Sudoku for programmers" Melzzzzz <mel@zzzzz.com> - 2016-08-14 19:57 +0200
                        Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-14 11:17 -0700
                          Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-14 13:59 -0700
                            Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-14 14:09 -0700
                              Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-14 15:48 -0700
                                Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-14 18:34 -0700
                                  Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 02:24 -0700
                                    Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-20 19:26 -0700
                                      Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-21 14:58 -0700
                                        Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-21 15:51 -0700
                                          Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-21 15:52 -0700
                                          Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-24 16:35 -0700
                  Re: "Forth is Sudoku for programmers" jim.brakefield@ieee.org - 2016-08-14 10:32 -0700
                    Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-14 13:55 -0700
              Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 21:37 +0200
                Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-28 15:25 -0700
                  Re: "Forth is Sudoku for programmers" jim.brakefield@ieee.org - 2016-08-28 16:16 -0700
                  Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-28 16:44 -0700
            Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-13 20:00 -0700
              Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-13 20:39 -0700
      Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-12 22:11 -1000
        Re: "Forth is Sudoku for programmers" dhoffman888@gmail.com - 2016-08-13 03:39 -0700
    Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-12 20:18 -0700
      Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 22:35 -0700
      Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 22:52 -0700
        Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-12 22:55 -0700
          Re: "Forth is Sudoku for programmers" Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-08-13 11:31 +0100
    Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-15 11:47 +1000
      Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-15 12:05 +1000

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

#50092

Melzzzzz <mel@zzzzz.com> writes:
>> lock the whole interpreter (the infamous Global Interpreter Lock or
>> GIL) when executing bytecodes.
>
> Classic GC either have to lock whole program or to synchronize on every
> pointer access as well...

Classic GC only has to lock the program -during garbage collection-.
The Python GIL has to lock the interpreter essentially -all the time-.
That means your program is always running on a single cpu core even if
you use multiple threads.  That was ok when most cpus were single core,
but it's a significant source of frustration now.

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

#50099

On Monday, August 15, 2016 at 6:17:21 AM UTC+12, Paul Rubin wrote:
> The Python GIL has to lock the interpreter essentially -all the time-.
> That means your program is always running on a single cpu core even if
> you use multiple threads.  That was ok when most cpus were single core,
> but it's a significant source of frustration now.

That may apply to pure Python code, but it doesn’t need to apply to extension modules written in C. In these, you can release the GIL during the CPU-intensive parts, allowing them to be multithreaded, then reacquire it for returning results back to Python.

I used this technique here <https://github.com/ldo/grainypy/blob/master/grainyx.c>--look for the sequences bracketed by Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS.

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

#50101

lawrencedo99@gmail.com writes:
> That may apply to pure Python code, but it doesn’t need to apply to
> extension modules written in C. In these, you can release the GIL

Yes, I know about that, and it helps some of the time (I think numpy
does that).  I meant the interpreter has to hold the GIL while running
Python code.  For occasional CPU-intensive stuff I do in Python, I can
usually split up the problem and run multiple Python instances on
different cores, but the GIL is still a big wart on Python.  

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

#50108

On Monday, August 15, 2016 at 9:09:32 AM UTC+12, Paul Rubin wrote:

> I meant the interpreter has to hold the GIL while running
> Python code.

If you want speed, you’re going to recode that bit in C, not Python, anyway. That’s why the GIL hasn’t been seen as a big problem.

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

#50112

lawrencedo99@gmail.com writes:
> If you want speed, you’re going to recode that bit in C, not Python,

No really, that's considered a somewhat drastic step.  It's generally
preferable to run separate python instances, or use the multiprocessing
module, or wait the extra time for the python program to run.  

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

#50243

On Monday, August 15, 2016 at 1:34:23 PM UTC+12, Paul Rubin wrote:
>
> Lawrence D’Oliveiro writes:
>
>> If you want speed, you’re going to recode that bit in C, not Python,
> 
> No really, that's considered a somewhat drastic step.

By whom? Python programmers are not scared of C code, you know. Or even C++. NumPy <http://www.numpy.org/> gets its speed from being written in C. And you will note it directly supports user-written C/C++ code.

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

#50302

lawrencedo99@gmail.com writes:
> By whom? Python programmers are not scared of C code, you know. Or
> even C++. NumPy <http://www.numpy.org/> gets its speed 

People use Python for lots of other things besides numerics.  Yes part
of Python programming is using the existing C libraries to your
advantage.  But actually writing C modules as part of a Python
application is not that common, and yes it does scare people.

When you do need to run C code, it's often ok to launch it in a separate
process rather than loading it into the Python interpreter.  That's
simpler and safer in many ways.

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

#50362

On Sunday, August 21, 2016 at 2:26:48 PM UTC+12, Paul Rubin wrote:
> But actually writing C modules as part of a Python
> application is not that common, and yes it does scare people.

So you keep insisting, in spite of all the evidence to the contrary. The question is--why?

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

#50363

lawrencedo99@gmail.com writes:
> So you keep insisting, in spite of all the evidence to the
> contrary. The question is--why?

I've worked on lots of Python projects in the real world and know what
they're like.  Do you?  I don't remember ever seeing you on
comp.lang.python.  I know C pretty well and have dealt with Python's C
API a few times, but most people involved in those projects have never
seen C.

I'm working on something right now that's part Python and part C++.  It
doesn't use the API.  The parts run in separate processes and
communicate through pipes and files.  Sometimes you have to use the API
but it's typically easier and safer not to.  E.g.

   stuff = os.popen("./foobar thingy23").read()

is way less hassle than studying all those Python C macros again,
debugging reference count errors, etc.  It's mostly a matter of whether
you can deal with the overhead of launching the new process.

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

#50364

Paul Rubin <no.email@nospam.invalid> writes:
> I don't remember ever seeing you on comp.lang.python.

Oh heh, yes I do.  You use a different From: header over there.

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

#50455

On Monday, August 22, 2016 at 10:51:09 AM UTC+12, Paul Rubin wrote:
>
>    stuff = os.popen("./foobar thingy23").read()
> 
> is way less hassle than studying all those Python C macros again,
> debugging reference count errors, etc.

There are ways to manage that. For example: <https://github.com/ldo/dvd_menu_animator/blob/master/spuhelper.c> illustrates the structured-programming technique I use.

The trickiest case I have encountered so far is doing allocations inside a loop. For example, around line 490. But even there, you can see that, no matter what error might occur, whichever control path it might take, the code will always correctly clean up after itself.

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

#50090

On Saturday, August 13, 2016 at 7:17:11 PM UTC-5, lawren...@gmail.com wrote:
> On Saturday, August 13, 2016 at 11:35:06 PM UTC+12, Doug Hoffman wrote:
> > Downside is it takes more memory than a GC...
> 
> Python, like Perl, does both reference-counting and garbage collection. Reference-counting takes care of all the cases where there are no reference cycles. Then, for the stubborn cases, it resorts to garbage collection.
> 
> Best of both worlds--speed and convenience.

Another choice is for the calling procedure to provide the work space and room for results to the called procedure.  Works well for scientific computing.

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

#50097

On Monday, August 15, 2016 at 5:32:33 AM UTC+12, jim.bra...@ieee.org wrote:
> Another choice is for the calling procedure to provide the work space and
> room for results to the called procedure.  Works well for scientific
> computing.

Interestingly, Python is popular for that, too <http://www.scipy.org/>.

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

#50521

In article <878tw1xi2y.fsf@jester.gateway.pace.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>lawrencedo99@gmail.com writes:
>> In order for this to work properly, call frames need to be allocated
>> on the heap.  This way an inner function can continue to refer to the
>> outer environment even after the outer function has exited.
>
>In Forth without garbage collection, the best I see as feasible is to
>allocate those closures on the locals or return stack, so they go away
>when the outer function cleans up and returns.

This is c-thinking: "keep your locals with the return address
because we've only one stack"

Data belongs on the data stack. I get annoyed when the first
thought is locals (no way!) or the return stack (limited size,
except on gforth for Those Who Know The Ways). Store temporary
data on the data stack. Unless.

A large number of solutions to Euler problems testify that
it is quite practical to store factorisations, continued fractions
and whatnot on the data stack, if they are to be discarded in
a last in first out fashion.
>
>C++ allocates closures on the stack, and has a way to copy them to the
>heap (std::function), where those copied closures (IIUC) are freed
>automatically when their surrounding scope exits.  I think there are
>some mechanisms for transferring their ownership from one scope to
>another if they have to last beyond the current scope, but I don't
>completely understand this feature at the moment.
>
>I think it wouldn't be practical to use the std::function approach in
>Forth, since it relies on C++'s concept of scopes and running object
>destructors when a scope exits.  You could free them manually, but
>overall if you want to program in Scheme then you should download one of
>the many fine Scheme implementations and use it ;-).
>
>I find that extensive use of closures and HOFs gets confusing in Scheme
>or Python even though their automatic gc takes care of reclaiming
>storage.  It's easy to lose track of how many levels of nested calls you
>are in, In Haskell, the compile-time type system tracks that for you, so
>the compiler squawks at you if you make a mistake.  In Scheme or Python
>the runtime checks will usually give you an error condition with a stack
>dump as soon as the erroneous code is executed.  But in Forth you're
>likely to get garbage results that take effort to debug.

The punishment for making things more complicated than needed.

Groetjes Albert
-- 
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]

#50529

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>In Forth without garbage collection, the best I see as feasible is to
>>allocate those closures on the locals or return stack, so they go away
>>when the outer function cleans up and returns.
>
> This is c-thinking: "keep your locals with the return address because
> we've only one stack". ..  Data belongs on the data stack. I get
> annoyed when the first thought is locals (no way!) or the return stack
> (limited size, except on gforth for Those Who Know The Ways). Store
> temporary data on the data stack. Unless.

We were talking how to deal with quotations (closures) that capture
locals from the parent scope.  So locals are already in play.  The idea
of a quotation is that it puts an xt on the data stack and doesn't leave
other stuff there.  So the captured locals have to go someplace else.
Some Forths use the return stack to hold locals, so in such systems the
return stack is a reasonable place for the closure enrivonment.  Gforth
has a separate locals stack, so that's another place to put it.

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

#50530

On Sunday, August 28, 2016 at 5:25:51 PM UTC-5, Paul Rubin wrote:
> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> >>In Forth without garbage collection, the best I see as feasible is to
> >>allocate those closures on the locals or return stack, so they go away
> >>when the outer function cleans up and returns.
> >
> > This is c-thinking: "keep your locals with the return address because
> > we've only one stack". ..  Data belongs on the data stack. I get
> > annoyed when the first thought is locals (no way!) or the return stack
> > (limited size, except on gforth for Those Who Know The Ways). Store
> > temporary data on the data stack. Unless.
> 
> We were talking how to deal with quotations (closures) that capture
> locals from the parent scope.  So locals are already in play.  The idea
> of a quotation is that it puts an xt on the data stack and doesn't leave
> other stuff there.  So the captured locals have to go someplace else.
> Some Forths use the return stack to hold locals, so in such systems the
> return stack is a reasonable place for the closure enrivonment.  Gforth
> has a separate locals stack, so that's another place to put it.

]>So the captured locals have to go someplace else.
IMHO, and that of a not full time Forth programmer:
Since the number of return values is usually much smaller than the number of parameters and locals, keep the parameters where they are (on the data stack) and append locals.  Have a bunch of words that provide direct access to them.  Overwrite with the results and trim the data stack on return.  Works easiest if there is a frame pointer which is stacked on the return stack along with the return address.  Words not using locals use the return stack as normal.

Also in favor of treating loop counters as locals.
If the compiler can keep track of what's on the data stack, then there may not always be a need for a frame pointer as "pick" and its dual will work?  

Should accommodate quotation references? 

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

#50532

On Sunday, August 28, 2016 at 3:25:51 PM UTC-7, Paul Rubin wrote:
> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> >>In Forth without garbage collection, the best I see as feasible is to
> >>allocate those closures on the locals or return stack, so they go away
> >>when the outer function cleans up and returns.
> >
> > This is c-thinking: "keep your locals with the return address because
> > we've only one stack". ..  Data belongs on the data stack. I get
> > annoyed when the first thought is locals (no way!) or the return stack
> > (limited size, except on gforth for Those Who Know The Ways). Store
> > temporary data on the data stack. Unless.
> 
> We were talking how to deal with quotations (closures) that capture
> locals from the parent scope.  So locals are already in play.  The idea
> of a quotation is that it puts an xt on the data stack and doesn't leave
> other stuff there.  So the captured locals have to go someplace else.
> Some Forths use the return stack to hold locals, so in such systems the
> return stack is a reasonable place for the closure enrivonment.  Gforth
> has a separate locals stack, so that's another place to put it.

This whole subject has already been discussed thoroughly over here:
https://groups.google.com/forum/#!topic/comp.lang.forth/ohE8mx7tWQU%5B101-125%5D

That thread later got diverted into a discussion of OOP (Doug Hoffman's OOP package in FLAG). There was also a diversion into a discussion of whether or not it was legal for Forth-200x to list me as a contributor to the Paysan-faked quotations even though I had repeatedly said that I didn't want to be listed as a contributor. Whenever I post working code, the thread always gets diverted into some irrelevant topic. I started a new thread discussing OOP:
https://groups.google.com/forum/#!topic/comp.lang.forth/cH-pGXhBCfE
That thread has now been diverted to a discussion of multi-core support, and once again there is no discussion at all of my working code --- c.l.f. seems to be all about fantasy, with no interest at all in working code --- these threads always get diverted as soon as I post working code.

Anyway, I'm not opposed to using the data-stack for communication between quotation and parent function. I have been doing this for many years in the novice-package. Here are a couple of examples (using the PERSON and CHICK classes):

: chick-counter ( head -- chicks ) 
    0
    swap  r[ .gender @  [char] F = if  1+  then  ]r |each ;
    
: macro-chick-counter ( head -- chicks ) 
    0
    swap  each[ .gender @  [char] F = if  1+  then  ]each ;

This is a reasonable technique when there is only one datum (in this case the chick-counter) that needs to be communicated between quotation and parent function.

In other cases this technique is not going to work well because there are too many data to hold them all on the data-stack, so locals are needed. Here is an example:

: test { head | people chicks tens nines eights -- } 
    head r[ 
        1 +to people 
        dup .gender @  [char] F = if  1 +to chicks 
            .hotness @ 
            dup  8 = if  1 +to eights  then 
            dup  9 = if  1 +to nines  then 
            10 = if  1 +to tens  then        \ Yay! We found at least one! 
        else  drop  then 
    ]r |each 
    cr ." total people:    " people . 
    cr ." total chicks:    " chicks . 
    cr ." level 10 chicks: " tens . 
    cr ." level  9 chicks: " nines . 
    cr ." level  8 chicks: " eights . 
    ; 

If we are going to have "C thinking" (Albert v.d.Horst uses this as a derogatory term) then we would use macros like this:

: macro-test { head | people chicks tens nines eights -- } 
    head each[
        1 +to people 
        dup .gender @  [char] F = if  1 +to chicks 
            .hotness @ 
            dup  8 = if  1 +to eights  then 
            dup  9 = if  1 +to nines  then 
            10 = if  1 +to tens  then        \ Yay! We found at least one! 
        else  drop  then 
        ]each    
    cr ." total people:    " people . 
    cr ." total chicks:    " chicks . 
    cr ." level 10 chicks: " tens . 
    cr ." level  9 chicks: " nines . 
    cr ." level  8 chicks: " eights . 
    ; 

This is not a bad technique. I've been doing this in the novice-package for years also. The code is very comparable to the rquotations code in regard to size and readability. The only problem with this technique is that it may not work for all data-structures. You may not be able to write your HOF code as a pair of macros for some of the more complicated data-structures. This is why I think rquotations are best --- they always work --- they are a clean and simple solution that are never complicated or problematic in any way.

Anyway, all of this is irrelevant. The aforementioned thread was titled "3rd RfD: Quotations" --- it was still an RfD meaning that it was still a matter of discussion --- the Paysan-faked quotations have been advanced to CfV now, which means that they are no longer a matter of discussion.

The Paysan-faked quotations were guaranteed to be accepted into Forth-200x from the get-go (they had Leon Wagner's approval, they were written by Bernd Paysan, and they were promoted by Anton Ertl) --- discussion was always irrelevant --- all this pointless discussion is just done for the purpose of faking up Forth-200x as a grassroots effort when it really comes straight from the Forth-200x committee without any concern for what the Forth community is doing.

My working code for rquotations that is obviously in complete contradiction to Anton Ertl's statement in the RfD:
-----------------------------------------------------------------------------
The present proposal does not propose that a quotation can access the 
locals of a containing definition, because the implementation would be 
relatively complex, impose a run-time overhead, and the lifetime of 
the locals would be restricted (unless we are willing to accept 
further complexity).  While there are a number of people who are very 
keen to have such a feature, it is not clear how much it would be 
used.  System implementors are encouraged to provide support for 
accessing outer locals on an experimental basis so that programmers 
can explore the usefulness of this feature, possibly resulting in a 
proposal for this feature in the future. 
-----------------------------------------------------------------------------

Anton Ertl says that my rquotations are "relatively complex" meaning that he couldn't figure out how they worked. He says they can be an: "experimental basis ... possibly resulting in a proposal for this feature in the future." That is ridiculous! When exactly in the future? Ten years? Twenty years? He is basically telling me that my code will be non-standard forever --- this is why I have abandoned Forth-200x --- the Forth-200x committee is forcing me to just write my own standard and ignore them; they have plainly said that they will ignore me forever.

So far, the only person who has commented upon my rquotations was Jenny Brien --- that was just a blunder on her part, as she didn't understand that working code is taboo in the Forth-200x culture --- Forth-200x is the "Committee of Can't" that is totally focused on telling Forth programmers what they can't do, but ignores working code as if it didn't exist.

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

#50072

On Friday, August 12, 2016 at 11:39:10 PM UTC-7, lawren...@gmail.com wrote:
> On Saturday, August 13, 2016 at 5:15:08 PM UTC+12, hughag...@gmail.com wrote:
> > On Friday, August 12, 2016 at 9:05:53 PM UTC-7, Lawrence D’Oliveiro wrote:
> >> Functions as first-class objects can be rather useful, too.
> > 
> > Hasn't Forth always had this? So long as you can obtain the xt with FIND or
> > tick then you have a function as a first-class object. 
> 
> In order for this to work properly, call frames need to be allocated on the heap. This way an inner function can continue to refer to the outer environment even after the outer function has exited. Consider the following Python snippet:
> 
>     def make_counter(prefix) :
>         count = 0
>         def counter() :
>             nonlocal count
>             count += 1
>             print("%s count = %d" % (prefix, count))
>         #end counter
>     #begin make_counter
>         return counter
>     #end make_counter
> 
>     counter1 = make_counter("counter1")
>     counter2 = make_counter("counter2")
>     counter1()
>     counter2()
>     counter1()
>     counter2()
> 
> which produces this output:
> 
>     counter1 count = 1
>     counter2 count = 1
>     counter1 count = 2
>     counter2 count = 2

I don't think that closures are useful, but I may be wrong about this because I've never programmed in Scheme or Python etc., so I don't have any practical experience with closures.

You have a function that returns a closure and it accesses the locals of the function. You can call this function many times and get many closures each with their own set of locals to work with.

This is very similar to having an OOP system and getting an object (the fields in the object are like the locals) and this class of object has one method (the method is like the closure). So, closures are effectively a kind of OOP --- this is a pretty limited kind of OOP though, because the class can only have one method --- normally in OOP systems a class can have several methods.

It is possible for the function to generate more than one closure, and all of them will access the same local-frame from this execution of the function that generated them. This means that the function has multiple return values, rather than just one. Now all of those return values have to be put somewhere, such as in a struct. But if you have a struct with several closures in it, then isn't that a lot like what you would have in OOP, with a struct with several methods? 

All in all, closures seem like a gratuitous complication to me --- it is better to have a good OOP system that allows you to have classes with multiple methods --- the only advantage of closures is that you get to access your fields with the syntax you are accustomed to for accessing local variables, but this advantage is so minor as to be meaningless.

I think rquotations are useful for implementing general-purpose data-structures (in this case the parent is still in scope because it called the HOF and so the rquotation can stuff its locals with data which the parent can use after the HOF exits) --- closures can be used similarly but they are an overkill because they also provide the feature of outliving the parent, but this useless feature comes at a heavy cost (storing a local-frame in the heap is much slower than storing it on the return-stack, and it requires GC) --- of course, when I tried to make this point on comp.lang.lisp, it was treated as blasphemy, as they have elevated the concept of closures to a kind of holiness.

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

#50076

On Sunday, August 14, 2016 at 3:00:30 PM UTC+12, hughag...@gmail.com wrote:
> I don't think that closures are useful, but I may be wrong about this
> because I've never programmed in Scheme or Python etc., so I don't have any
> practical experience with closures.

That was just a toy example. See the anim_framework examples I linked to previously for more non-trivial instances.

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

#50024

On 8/12/16 4:05 PM, Doug Hoffman wrote:
...
>> I think my code is much more readable that the SWOOP code. Anybody
>> using POINT in SWOOP is going to get tired of writing  USING POINT
>
> I don't know SWOOP very well. Is that really a requirement?

May I suggest you get a free evaluation copy of SwiftForth, read the 
manual, and look at the code?

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]

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

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

csiph-web