@MSGID: <20230922075713.867@kylheku.com> 9db239c3
@REPLY:
a8b0df96
@REPLYADDR Kaz Kylheku <864-117-4973@kylheku.com>
@REPLYTO 2:5075/128 Kaz Kylheku
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: <20230922075713.867@kylheku.com>
@RFC-References:
<20230921065214.723@kylheku.com>

@TZUTC: -0000
@PID: slrn/pre1.0.4-9 (Linux)
@TID: FIDOGATE-5.12-ge4e8b94
On 2023-09-22, albert@cherry.(none) (albert)  wrote:
> In article <20230921065214.723@kylheku.com>,
> Kaz Kylheku  <864-117-4973@kylheku.com> wrote:
>>On 2023-09-21, albert@cherry.(none) (albert)  wrote:
>>> (apply symbol? (list (quote two))
>>> We arrive at the list to be evaluated
>>> (<#4623388> ) where  #4623388 is the actual function symbol? refers to.
>>>
>>> This is an abstract structure tree: a list consisting of a a function
>>> and a symbol.
>>>
>>> Now we are supposed to evaluate this list.
>>
>>No, that would be a double evaluation.
>
> That clears up nothing to me.
> lisp does double evaluations all the time.

Actually, no, not implicitly. If something is multiply evaluated, it`s
because you coded extra evaluations into it.

> Suppose you have `fx a user defined function.
> (fx 1 2)
> The first item of the list is not a function, we are not happy thus:
> step 1 evaluate fx, the result is a list.
> The first item of the list is not a function, we are not happy thus:
> step 2 evaluate the list, the result is a function
> Now we are in a position to tackle (#111 1 2)
> Is that not a third evaluation then what is it?

While that is possible, I don`t know of any Lisp dialect which
does this kind of iteration.

The second and subsequent rounds of evaluation would be working
with run-time data: whatever value is pulled out of the fx binding.

Evaluating that would be a possible security issue.

Lisps are compiled languages; only the first evaluation round could be
compiled, unless the compiler can deduce the value of fx. Otherwise the
subsequent evaluation rounds would have to be promoted to run-time.

>>
>>In a Lisp-1 dialect,
>>
>>  (apply fun (list a b c))
>>
>>is the same as
>>
>>  (fun a b c)
>>
>>You`re talking about:
>>
>>  ((eval fun) (eval (list a b c)))
>>
>>apply is an ordinary function. After evaluating the arguments
>>we have these items
>
> fun is a symbol. It *got* to be evaluated, if we want the underlying
> function. What am I missing here?

That once that takes place, the resulting #<4623388> object isn`t
evaluated any more.

>
>>
>> (#<4580123> #<4623388> (two))
>>   ^         ^
>>   apply     symbol?
>>
>>we are now ready to call the function: we call #<4580123>,
>>which is apply, passing it #<4623388> and (two).
>>
>>apply doesn`t eval anything: apply takes the list (two) and spreads
>>it into individual arguments, which are passed to #<4623388>.
>
> I managed to
> (apply symbol? (list (quote two)))
> to succeed giving true,
> passing the symbol `two to the now disembodied symbol?
> by relying on functions in the underlying implementation language.
>
> That is no solution, you can`t pass arguments in lisp!

Well, that`s right; you can pass arguments in the implementation of
Lisp, such as inside primitive procedures like apply and funcall.

The classic description of Lisp eval in Lisp itself assumes that a
primitive procedure apply is available, which doesn`t have to be
written.

That description itself is evalued somehow, by an existing
primitive eval. That eval somehow knows how to perform the function
calls that occur in the syntax of the eval-in-Lisp source code.

That eval-in-Lisp code itself knows how to to do the same thing,
via the apply helper function.

> You can only evaluate lists, or more precisely you got to put
> the function and arguments into a list
> The following tests now fails:
> ;; Testing apply function with user functions
> (apply (fn* (a b) (+ a b)) (list 2 3))
> You can abstract the fn* in a disembodied function #1222
> but it is supposed to be in a list, such as
> (#1222 3 4) otherwise the function can not find its arguments
> to fill it in on the places a and b.
> Now the story goes on. #1222 doesn`t know better better than to
> evaluate its arguments and the problem only shifts.

#1222 should only need to access its arguments. In the body (+ a b), a
and b are just local variables that have been given values in by the
application of that function. Evaluating a just means retrieving the
value of a, not evaluating the original expression.

In a purely interpreted Lisp, a function`s representation retains
the source code pieces, like the names of the arguments and the body
as-is (usually after macro-expansion).

The apply procedure, when it sees such an interpreted function, has to
perform the binding: extract the function object`s list of parameter
names, and create an environment which binds them to the argument
values. Then it evaluates the body in that environment using an
evaluator. (That evaluator is not necessarily the one you are writing!)
If the funtion is compiled, or written in a lower level language by
hand, such as C or assembly, then the process of calling it may
be quite different. Apply has to generate a function call in that
language. It may involve pushing values on the stack, or preparing
them in registers, and getting a result value  or values in a certain
way like from certain registers or on the stack.


-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don`t see you, unless you`re whitelisted.
--- slrn/pre1.0.4-9 (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