Re: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)

[cfry@MIT.EDU (Christopher Fry)]

I want to second Jeff Dalton's remarks to Scott Dyer.
Here's a few more bits:

Scot writes:
>>  I don't think they will be of interest to Dylan
>> developers because Apple has made quite an effort to emphasize that
>> Dylan is for application programming, not AI.  I for one am hard
>> pressed to find uses for eval that 'conventional' programmers would
>> want.  Eval is simply not conventional.

Fry: If you could manage to come up with a definitive description of
what an "AI" program is and what an "application" program is [which I doubt] then 
I'd say this: Yesterday's "AI" program is today's "conventional" program.

Scot:
>>   frankly I don't think the people at Apple are that
>> interested in fixing all of LISPs problems as much as making Dylan
>> palatable to those just being weened from 'C.'

Jeff:
>But dynamic languages aren't "conventional".  If the aim is to
>appeal to C programmer without departing from the conventional,
>then Dylan isn't what you want.

If the aim is simply to appeal to C programmer's then just give them C.
If a C programmer doesn't have to stretch and learn any new concepts 
to become a good Dylan programmer, then why should they bother to
learn Dylan at all? If fact, why bother to develop Dylan in the first
place?

Eval is useful in a lot more places than read-eval-print loops, just as
are read and print. If your model of eval is that REP is the only significant
use of eval, then I'd say you have some old, limited model of lisp.

I'd also say that my quess is beginning lisp programmers don't use eval.
They use + and aref. When they get beyond the "conventional" part of
lisp, THEN they start using EVAL.

Whether eval & read are part of a "library" or not I don't really care.
I do care that I'm able to easily have a consistent LARGE functionality in
my development environment [including eval and read] and that I can easily
include them in a application if I like. Its also nice to make the
application small and if the stand-alone-app generator notices that
eval and read aren't used, it should feel free to cut them out [as with
any other unused functions]. [But provide me with a way to
force their inclusion just in case I want to give the user the ability to
call a fn that's not used elsewhere in the program.]

In the past, libraries have been a major source of inconsistencies, ie
I'm using Mcl2.0.3 but lib:foo.lisp only works for mcl2.0.4. I trust the folks
at Apple are concerned about this issue and will come up with something clever
to mitigate these problems that lesser languages/environments have.