The concepts described in Chapter 6 of "On Lisp" seem extremely
counterproductive to the flexible dynamic nature of Lisp programming.
Using closures to represent data structures solidifies the actions that
can be performed because you can no longer access the actions separate
from the data.
What would the advantage of structuring logic in such a way be? I'm
assuming that there's some obvious application I'm overlooking.
-- MJF
M Jared Finder <·····@hpalace.com> writes:
> The concepts described in Chapter 6 of "On Lisp" seem extremely
> counterproductive to the flexible dynamic nature of Lisp
> programming. Using closures to represent data structures solidifies
> the actions that can be performed because you can no longer access the
> actions separate from the data.
>
> What would the advantage of structuring logic in such a way be? I'm
> assuming that there's some obvious application I'm overlooking.
It depends on how you want to structure your software. You can use
closure to encapsulate capacities. Modules that don't know a password
can't get the secret data.
It may be interesting to have internal boundaries, to be able to
execute securely foreign code.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
M Jared Finder <·····@hpalace.com> writes:
> The concepts described in Chapter 6 of "On Lisp" seem extremely
> counterproductive to the flexible dynamic nature of Lisp programming.
> Using closures to represent data structures solidifies the actions that
> can be performed because you can no longer access the actions separate
> from the data.
>
> What would the advantage of structuring logic in such a way be? I'm
> assuming that there's some obvious application I'm overlooking.
Say you have a data structure, and some operations you can perform on
it. For example, in a full-text search module, you might have a data
structure representing a fairly complex query. You can view this
search structure as a specification for a program that performs the
search. Looking at things this way, your search module is an
interpreter. If instead you choose to represent your search with
closures, you'll have a module that takes the user's search request,
and compiles it to a program to perform that search. If your compiler
is even halfway clever, your compiled searches will be much faster
than their interpreted counterparts. This is the approach that
CL-PPCRE takes, for example, and it outperforms Perl's regexp engine
because of it.
Thomas F. Burdick wrote:
> M Jared Finder <·····@hpalace.com> writes:
>
>
>>The concepts described in Chapter 6 of "On Lisp" seem extremely
>>counterproductive to the flexible dynamic nature of Lisp programming.
>>Using closures to represent data structures solidifies the actions that
>>can be performed because you can no longer access the actions separate
>>from the data.
>>
>>What would the advantage of structuring logic in such a way be? I'm
>>assuming that there's some obvious application I'm overlooking.
>
>
> Say you have a data structure, and some operations you can perform on
> it. For example, in a full-text search module, you might have a data
> structure representing a fairly complex query. You can view this
> search structure as a specification for a program that performs the
> search. Looking at things this way, your search module is an
> interpreter. If instead you choose to represent your search with
> closures, you'll have a module that takes the user's search request,
> and compiles it to a program to perform that search. If your compiler
> is even halfway clever, your compiled searches will be much faster
> than their interpreted counterparts. This is the approach that
> CL-PPCRE takes, for example, and it outperforms Perl's regexp engine
> because of it.
That's what I was missing. If you want to view your "data structure" as
representing code, then it makes perfect sense to compile the data
structure into a closure.
Thank you for pointing that out.
-- MJF