[M3devel] [modula3/cm3] Quake scoping issue (#19)

[Rodney M. Bates]

On 08/25/2017 07:55 PM, JC Chu wrote:
> I understand from §7.2 and your comment that, when “m3makefile2” is included, it is interpreted inside the local scope created when `map_proc` is called, where `list` is not bound to a procedure.  In fact, even if “m3makefile2” didn’t define `list` itself, the same error would still occur.  (That said, if procedures can only be defined in the global scope, shouldn’t they only be searched there as well?)
>

Well, I am not trying to justify or defend this language design, just understand what it is.
This is indeed unusual.  I don't recall ever seeing a language where the scope an indentifier
is declared in is different from the scope the declaring code is located in.  In fact, I find
it very difficult to articulate this clearly, and I don't think the foregoing sentence does it
very well.

> However, by the same argument, the behavior of the following makefile is a bit unexpected to me.
>
>     test_var = 0
>     readonly proc call (f, test_var) is return f() end
>     readonly proc write_test_var () is
>       write(format("test_var = %s\n"), test_var)
>     end
>     readonly proc eval (_) is end
>     eval(call(write_test_var, 123))
>
> Here, `write_test_var` is evaluated in its own scope, which is inside the scope of `call`, where `test_var` = 123.  The actual output, though, is 0.
>

This makes complete sense to me, after a rather intense reading session.  'call' is called
with 'write_test_var' and 123 as actual parameters corresponding to 'call's formals 'f'
and 'test_var'.  But 'call's body makes no reference to its formal 'test_var', so the 123 value
is just lost.  When execution gets into 'write_test_var', its containing scope is the global
scope, where the global 'test_var' is the one found.

Note that this is static scoping, not dynamic, which means the containing scope of 'write_test_var'
is not the scope of its caller, but is determined by its textual location within the code,
specifically, it is immediately inside the global scope.

Dynamic scoping, e.g., in lisp, has turned out to be a source of intriguing puzzles, but far
too confusing to be helpful to programming in general.  It makes it too easy for something to
change meaning unexpectedly, as result of being called from some place unknown to the writer
of the procedure.

> — JC
>
> -----Original Message-----
> From: Rodney M. Bates [mailto:rbatesjk at lcwb.coop]
> Sent: Friday, August 25, 2017 23:40
> To: reply+00655cb4faee270b469769c158f8bcd114e2942747144a0292cf0000000115b6154992a169ce0f0c9468 at reply.github.com; m3devel <m3devel at elegosoft.com>; jcchu >> JC Chu <jcchu at acm.org>
> Subject: Re: [modula3/cm3] Quake scoping issue (#19)
>
> According to Quake, 7.3, "Procedures may be defined in the global scope only".
> Apparently, from experiment, this means that, although the procedure definition
> itself can be located inside a local scope, its name is declared in the global
> scope.
>
> So, if you don't import libm3, your 'list' declaration is not a duplicate, thus
> produces no error, and becomes declared in the global scope.  But the call on
> 'list' resolves to the formal parameter 'list', of 'map_proc', which is found
> in the local scope, and whose value is the list '[ m3makefile2 ]', not a
> procedure, and thus not callable.
>
> Any suitable renaming of either the parameter or the procedure, so that the two
> meanings of 'list' have different names, works as expected.
>
> I'll grant that having a procedure declaration located in a local scope but
> declaring its name in the global one is peculiar, and this is a peculiar
> effect of that rule.
>
> I have made a note to explain this better in the Quake documentation.
>
> On 08/23/2017 11:17 PM, jcchu wrote:
>> See demo.zip <https://github.com/modula3/cm3/files/1247702/demo.zip>.
>>
>> —
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly, view it on GitHub <https://github.com/modula3/cm3/issues/19>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGVctCYptEcKU12OG82H67xEwMAkKPkNks5sbPlJgaJpZM4PA3zO>.
>>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org