Nп/п : 41 из 93
 От   : Kaz Kylheku                         2:5075/128        22 авг 23 16:56:09
 К    : none) (albert                                         22 авг 23 19:57:06
 Тема : Re: MAL : closures and recursion
----------------------------------------------------------------------------------
                                                                                 
@MSGID: <20230822094606.629@kylheku.com> 3861f49d
@REPLY:
0200ea67
@REPLYADDR Kaz Kylheku <864-117-4973@kylheku.com>
@REPLYTO 2:5075/128 Kaz Kylheku
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: <20230822094606.629@kylheku.com>
@RFC-References:

@TZUTC: -0000
@PID: slrn/1.0.3 (Linux)
@TID: FIDOGATE-5.12-ge4e8b94
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.

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

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.

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.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- slrn/1.0.3 (Linux)
 * Origin: A noiseless patient Spider (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



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх