Re: Add nested-function support in a language the based on a stack-machine

On Sat, 17 Feb 2018 16:13:10 +0000 (UTC), Kaz Kylheku
<217-679-0842@kylheku.com> wrote:


>On 2018-02-15, George Neuner <gneuner2@comcast.net> 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 <gneuner2@comcast.net> 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

Return to the comp.compilers page.
Search the comp.compilers archives again.