home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.forth      Forth programmers eat a lot of Bratwurst      117,927 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 117,057 of 117,927   
   dxf to Anton Ertl   
   Re: Back & Forth - Co-routines   
   07 Feb 25 10:36:47   
   
   From: dxforth@gmail.com   
      
   On 7/02/2025 4:20 am, Anton Ertl wrote:   
   > dxf  writes:   
   >> On 7/02/2025 12:59 am, minforth wrote:   
   >>> On Thu, 6 Feb 2025 12:57:12 +0000, Anton Ertl wrote:   
   >> AFAIR 200x nested definitions were justified on the grounds named   
   >> definitions were neither needed nor wanted   
   >   
   > Really?  There's a proposal to eliminate named definitions?  That's   
   > news to me.   
      
   I didn't but clearly those that argued for quotations did.   
      
   > There are cases where you need to pass an xt to some word, and where   
   > the xt does not merit a name, e.g.,   
   > ...   
      
   There's a case for having NONAME: which has no name and must pass an xt.   
   But that's not the same as saying there's a need for definitions without   
   names.   
      
   >> and access to external   
   >> locals not necessary.   
   >   
   > It's more that anything proper is pretty hard to implement and there   
   > was not enough demand for that nor existing practice that anybody   
   > wanted to propose for standardization.   
      
   This only strengthened my view forth quotations had nothing to offer but   
   namelessness.  If want to hide names of definitions I no longer need to   
   reference I have BEHEAD for that.  Such facility has existed in forths   
   long before the idea of quotations popped up on c.l.f.   
      
   >   
   > However, the topic came up repeatedly in discussions, so in 2018 I sat   
   > down to investigate the issue.  After a while I had a paper design,   
   > but had my doubts that it is worth implementing it.  I let Bernd   
   > Paysan read the paper, and he came up with further simplifications and   
   > implemented the result; the changes were so deep that I had to mostly   
   > rewrite the paper, resulting in our EuroForth 2018 paper   
   > [ertl&paysan18].  And Bernd embraced using the resulting closures.   
   >   
   > I still had my doubts about whether one really needs that, as I had   
   > not found a short example that showed a clear advantage over the   
   > alternatives.  I asked Niklaus Wirth, who had kept access to outer   
   > locals in his languages for many decades, but his answer was that he   
   > finally removed that feature from Oberon 07 in 2013, and he did not   
   > provide such an example, either.   
   >   
   > Finally, such a usage was found by Bernd Paysan: He had implemented a   
   > variant of the actor model   
   >  (inspired by Heinz   
   > Schnitter's Open Network Forth):   
   >   
   > One task sends a message consisting of an xt to another task, and the   
   > other task then executes it.  But sending just an xt without any data   
   > is not very useful, so one could also send integers, strings, etc.   
   > The sender would send the data and then the xt, and the receiving task   
   > would push the data on the stack, and then execute the xt.  However,   
   > several tasks can send messages to one task at the same time, so there   
   > was some additional twist to avoid mixing the parts of a message of   
   > one task with the parts of a message of another task.  With closures   
   > that all became unnecessary: The data is part of the passed xt.   
   >   
   > Another development was pure-stack closures.   
   >   
   > But none of this existed when quotations were accepted for   
   > standardization.   
   > ...   
      
   Interesting but what are you saying - that quotations as we have them   
   are little more than a gimmick?   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca