[Crossposted to comp.lang.lisp, where this may be of more interest.
I'd really appreciate any corrections on this.]
Stephen Illingworth wrote:
> Jeremy Yallop wrote:
>
>> Stephen Illingworth wrote:
>>> Jeremy Yallop wrote:
>>>
>>>> Stephen Illingworth wrote:
>>>>> jonathan wrote:
>>>>>
>>>>>> I was wondering if there was a way to do anonymous (lambda) functions
>>>>>> in C.. Its frustrating having to use function pointers all of the
>>>>>> time, I'd rather make functions like:
>>>>>>
>>>>>> int (*myfunc)(int, int) = function(int a, int b) { return(a + b) }
>>>>>
>>>>> That's not a lambda function as you've given it a name.
>>>>
>>>> I think that he's suggesting `function' as a lambda operator.
>>>
>>> I know that, I was referring to the "myFunc".
>>
>> The function itself is still anonymous, in the same way that malloc()
>> returns a pointer to an anonymous object or a string literal is an
>> anonymous array. The `myfunc' above is just a reference to an
>> anonymous object.
>
> Yes. You're quite right. I was hopelessly confused by the fact that the
> function pointer was involved at all. So long as the function pointer
> isn't required, then it is a lambda function.
>
>> [...] C doesn't have dynamic scope. Variables in C either have lexical
>> (block) scope or are "global".
>
> It depends on what you mean by dynamic scope I suppose and I would
> say C does have dynamic scope (in the Lisp sense of the word anyway
> (which would seem appropriate since where talking about the
> implementation of a Lisp feature)).
I'm no expert, but I understand dynamic scope to refer to the name
lookup mechanism for Lisp's `special variables'. The object to which
a name resolves depends on bindings which may be established at
runtime, and those bindings exist only while execution is in the block
where they are established. For example,
(defvar *special-variable* 0)
(defun one ()
(two)
(let ((*special-variable* "one"))
(two))
(two))
(defun two ()
(print *special-variable*))
The object to which *special-variable* in `two' refers is determined
dynamically according to the bindings in effect at the time of call.
Thus, the first time `two' is called the top level binding is in
effect and called will print `0'. The second call takes place while
the `let' binding is in effect and so "one" is printed. Control then
exits the `let' block and `two' sees the top-level binding again
during the final call.
There's nothing like this in C. The object to which an identifier
refers is determined at compilation time according to the declaration
which is in scope (although its value can, of course, be changed).
> In C an object with some name can be "overridden" with a different
> object of the same name in some other block. To my mind that's
> dynamic scope -- which object is actually being referred to differs
> depending on which object is in scope at the time of reference.
Something like this?
extern int x;
void func()
{
{
int x = 3;
printf("%d\n", x);
}
printf("%d\n", x);
}
This is just name shadowing, a natural part of lexical scope. The `x'
in the inner block shadows the global `x', so that any occurrences of
the identifier `x' within the textual block refer to the local
variable. Note that the shadowing only has effect within the
*textual* region enclosed by the block; in any functions called within
the scope of the shadowing variable the file-scope `x' will be
visible, not the local `x'.
In Lisp `let' can also establish lexical bindings, which are not
visible to functions called within the scope of the `let'.
> With lexical scope the object being referred to is that object which
> was in scope at the time the function (or whatever) making the
> referrence was defined. Which doesn't happen in C.
??? This seems to me exactly what happens in C. All references must
be resolved according to the declaration in scope at the time of
definition since objects cannot be referred to by name at runtime.
>> The problem is not scope but extent.
>
> Agreed. I was using terminology appropriate to Lisp where scope and
> extent are much the same thing.
They're related concepts but not at all the same thing. Chapter 3 of
"Common Lisp the Language 2" is a good reference for this.
http://www.supelec.fr/docs/cltl/clm/node43.html
Jeremy.
Jeremy Yallop wrote:
> Stephen Illingworth wrote:
>
>> With lexical scope the object being referred to is that object which
>> was in scope at the time the function (or whatever) making the
>> referrence was defined. Which doesn't happen in C.
>
> ??? This seems to me exactly what happens in C. All references must
> be resolved according to the declaration in scope at the time of
> definition since objects cannot be referred to by name at runtime.
Do you know something Jeremy? I was completely and utterly wrong, C
does have lexical scope. [hangs head in shame].
>>> The problem is not scope but extent.
>>
>> Agreed. I was using terminology appropriate to Lisp where scope and
>> extent are much the same thing.
>
> They're related concepts but not at all the same thing. Chapter 3 of
> "Common Lisp the Language 2" is a good reference for this.
>
> http://www.supelec.fr/docs/cltl/clm/node43.html
Good link. Now, I've got some hard reading to do right after I've written
out "I am a tool" a hundred times :-)