@MSGID:
d69f9988
@REPLY: <20230822094606.629@kylheku.com> 3861f49d
@REPLYADDR none) (albert
@REPLYTO 2:5075/128 none) (albert
@CHRS: CP866 2
@RFC: 1 0
@RFC-References:

<20230822094606.629@kylheku.com>
@RFC-Message-ID:

@TZUTC: 0200
@TID: FIDOGATE-5.12-ge4e8b94
In article <20230822094606.629@kylheku.com>,
Kaz Kylheku  <864-117-4973@kylheku.com> wrote:
>On 2023-08-22, albert@cherry.(none) (albert)  wrote:
>> In article ,
>> none) (albert  wrote:
>>>https://github.com/kanaka/mal/
>>>
>>>I`m trying to Make Another Lisp using ciforth lina/wina/xina.
>>>
>>>I run in a bit of trouble in the interaction between closures and recursion.
>>>
>>>( ( (fn* (a) (fn* (fn* (b) (+ a b))) 5) 7)   ... I
>>>In lisp we have
>>>(fn* (fn* (b) (+ a b))) 5)
>>>
>>>(def! sumdown (fn* (N) (if (> N 0) (+ N (sumdown  (- N 1))) 0)))  ...I
>>
>> The above now passes the test of MAL.
>> This is what I do.
>> Assuming MAL is intended to be lexical, first look up symbols
>> in the parameter mapping,
>> then in the environment stored in the
>> closure, then in the environment where the call is made.
>> All environments can recursively refer to outer environments,
>> not the parameter mapping.
>
>If "environment where the call is made" in the last step there
>refers to the lexical environment within the calling function,
>you have a mistake.
>
>Under lexical scope, an invoked function must not see variables
>in the caller.

Thank you for clearing that up. The git site is guiding you
through implementation but is short of background.

>
>If an identifier is not found in the lexical scope, you can have a
>fallback on a pervasive scope (for finding global variables).

I assume that functions as + * / etc are present in this
pervasive scope. That makes sense and it is much easier
to implement.
>
>If you`re seeing locals in parent functions, you have dynamic
>scope; and if taht is combined with closures that capture
>environments, you have something that can be called "dynamic closurees".
>
>It`s a valid implementation choice; it`s just not to be confused with
>lexical scope.

>
>If you have dynamic closures, then some test cases for lexical scope
>will pass.
>
>What will not pass are tests which tests for these things:
>
>- error checking: validate that a free variable references
>  in a function which has the same name as a local variable
>  in a caller is diagnosed as an undefined reference,
>  rather than referring to the parent.
>
>- interference: validate that if a callee assigns to a variable
>  x which happens to be a local variable in the caller,
>  it doesn`t clobber the caller`s variable.

I`m adding to the mal tests. These are test are candidates.

>
>Part of the motivation for lexical scope is encapsulation.
>All accesses to a lexical variable are possible only from
>the scope where it is visible, and nowhere else.

Tanks for clearing that up. As MAL is supposed to be a Clojure
derivative, I will simply following the lexical closure paradigm.
This clears up some remarks I found puzzling in the MAL git
site about tail call optimisation.

>Mastodon: @Kazinator@mstdn.ca

Groetjes Albert
-- 
Don`t praise the day before the evening. One swallow doesn`t make spring.
You must not say "hey" before you have crossed the bridge. Don`t sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning.            - the Wise from Antrim -
--- trn 4.0-test77 (Sep 1, 2010)
 * Origin: KPN B.V. (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441