Re: POSIX and lists question
Re: POSIX and lists question
- Subject: Re: POSIX and lists question
- From: has <email@hidden>
- Date: Sat, 13 Aug 2005 12:26:25 +0100
Mark J Reed wrote:
>OK, just finally sat down and looked at has's counter-closure examples...
>
>
>script a
> property x : 2
>
> on foo()
> return x
> end foo
>end script
>
>script b
> property z : 0
>
> property foo : a's foo
>end script
>
>b's foo() --> 0
>
>
>
>That's the most straightforward of your examples, but it's still a little weird. It most resembles somehow casting an object to a class it has no relationship with,
I think you're getting confused. AppleScript doesn't have classes, and a cast would be instantly recognisable by the presence of an 'as' keyword. All the above code shows is a simple assignment of the handler object stored in a's 'foo' slot to b's 'foo' slot, followed by an invocation of the handler object in b's 'foo' slot. It demonstrates that AS handlers aren't closures because they don't retain any connection to their lexical context; if they did, that call would have returned '2', not nonsense as it has (the value of an unrelated slot, b's 'z').
>and then calling a method of that class on that object which looks for instance variables that don't exist.
Variable 'x' does exist - in the environment in which the handler was originally defined. Were the handler a closure, it would know how to find this environment even when it's moved to another one, and return '2' as expected.
>But this bit of code seems to demonstrate that closures do exist:
>
>on makeAdder(addend)
> script adder
> on add(y)
> return (addend + y)
> end add
> end script
> return adder
>end makeAdder
>
>set x to makeAdder(5)
>set y to makeAdder(10)
>
>set addend to 15
>
>tell x to display dialog add(4) -- 9
>tell y to display dialog add(6) -- 16
(That's pretty much the example I initially gave.)
>Even without creating any properties on the script object inside makeAddr, its handler nevertheless remembers the value of the parameter "addend" when called later
No, variable 'addend' is captured by the _script object_ ('adder'), not by the handler object. Significantly, this is a true capture of the newObj environment, it's not merely grabbing the last known values of its local variables (as, e.g., Python's partial closures do) but retaining the variables themselves:
on newObj(x)
script o
on foo()
return x
end foo
end script
script p
on inc()
set x to x + 10 -- modify variable x
return
end inc
end script
return {o, p}
end newObj
set {y, z} to newObj(4)
log y's foo() --> 4
z's inc()
log y's foo() --> 14 -- correct!
AppleScript handlers, on the other hand, are dumb as rocks and simply assume that their current container is the same script object as the one they were declared in. (Which is why they throw a wobbly when it isn't.)
Now, the _combination_ of lexical environment-capturing script object and enclosed environment-ignorant handler object is largely analgous to the closures you find in functional languages, Smalltalk, etc. So I'd call this closure-like behaviour,or describe AS as having partial closure support (quite a few languages fall into this category for various reasons), but I wouldn't call it a true closure because the definitions I've seen that are specific about implementation describe a closure as a _function_ that captures its lexical environment, which this obviously isn't.
It's a bit of a messy situation, but an extremely minor SNAFU by AppleScript's usual standards and the least of your typical ASer's worries, so I don't suggest losing any sleep over it. Just file it under "Tiny Hints of What Might Have Been" and move on to bigger and jucier nasties, of which there is no shortage. ;)
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden