Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: George Neuner Newsgroups: comp.compilers Subject: Re: Add nested-function support in a language the based on a stack-machine Date: Thu, 1 Mar 2018 13:49:05 -0500 (EST) Organization: A noiseless patient Spider Lines: 66 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <18-03-003@comp.compilers> References: <18-02-009@comp.compilers> <18-02-012@comp.compilers> <18-02-016@comp.compilers> <18-02-018@comp.compilers> <18-02-023@comp.compilers> <18-02-029@comp.compilers> <18-02-032@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="3885"; mail-complaints-to="abuse@iecc.com" Keywords: code, design Posted-Date: 01 Mar 2018 13:49:05 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1967 On Sat, 17 Feb 2018 16:13:10 +0000 (UTC), Kaz Kylheku <217-679-0842@kylheku.com> wrote: >On 2018-02-15, George Neuner wrote: >> On Wed, 14 Feb 2018 18:06:40 +0000 (UTC), Kaz Kylheku >><217-679-0842@kylheku.com> wrote: >> >>>On 2018-02-14, George Neuner wrote: >> ... you're correct that the display needs to be counted >> as part of the thread switch context. But each thread also would be >> using from a separate stack, so having the entire display saved in >> each frame is overkill when all that's needed is a single pointer. > >The address of a local function can be taken. When that function is >called from any context, possibly another thread, it has access to the >locals that were lexically apparent there. You Lisp is showing. IOW, that's language dependent. There are perfectly useable languages that do not allow taking the address of a function ... never mind passing such pointers between threads. Upcalls / callbacks / completion functions, etc. do require the ability to specify the target function, but there isn't any reason for the language to expose that to the programmer. And in such cases the stack environment required by the called function exists at the point where the function is called. >Stack *access* is shared among threads. E.g. a thread can register >a stack object in a shared queue (such as a synchronization wait queue). >As long as it is dequeued before that frame terminates, everything is >cool. Commonly done. Again, language dependent. Your hypothetical stack resident object need not be any kind of "active" object. And if the [shared entity] is provided a callback function [by whatever means the language permits], there is no problem as long as the lexical environment of that function still exists. Have you never used multi-threaded Pascal? >If a downward-only lexical closure is implemented as a pointer into some >threads's stack memory (plus a function) that object can be passed to >another thread and used (as long as the context which created that >closure doesn't terminate). Yes it can. And the result is something akin to co-routine. But there's no reason any particular language should allow it. Many of your arguments are based on the notion of a general purpose language needing to provide full closures and objects ... but in a more restricted domain specific setting there often are perfectly good arguments for NOT providing general purpose features. We really don't know what the OP is trying to do. It is good to point out limitations of an idea and to bring up alternatives where viable, but let's not go too crazy here until we know more. YMMV, George