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

[Jeff Dalton <jeff@aiai.edinburgh.ac.uk>]

> JD writes (re: READ and PRINT)
> >However, their usefulness is not confined to "command-line"
> >interfaces.
> 
> Well, I would say that read probably is only useful for this. 

That's certainly not the only thing _I_ use it for.  READ is useful
whenever I have a stream or sequence of characters and want the
corresponding Lisp object.  The characters don't have to come from a
command-line interface.  On the other hand, I don't expecially mind
if they do.  I use Unix (cough, spit, gasp).

> read is positively dangerous to deliver as it will make Lisp parsing so
> easy that my favourite word processor will want me to enter styles in
> parentheses! 

I like Lisp's syntax.  And, in any case, having READ in the language
(or, rather, the I/O library) doesn't mean applications will use it
as part of their user interface.  

> print I
> have no real problems with, although if read is not going to be delivered
> printing will change as the read-print equivalence is not so important. 

> eval is a totally separate issue. Personally, I can't see much justification
> for it, as apply is good enough for most purposes. 

I hardly ever use EVAL, and I don't mind using a Lisp dialect that
omits it.  On the other hand, I think the backlash against EVAL that
we've seen in recent years has been a bit excessive.

> What I was trying to get at is that the traditional streamy Lisp IO is a
> development environment thing, like MPW and the UNIX shell.

What do you mean?  That in a different _development_ env, you wouldn't
have PRINT and READ?  I don't think that's so.  You might have _no_
development env and still have PRINT and READ, for instance.

> Users want something different, like "no" instead of #f. Similarly, on 
> input, people don't necessarily want "1/1" to be interpreted as a rational,
> they may just want to use it as a name. Doing IO yourself (say using a
> custom parser) is the only safe way, although print and read may be (and
> are!) great for development. 

This is an argument against using PRINT and READ when they're not
appropriate, not an argument for eliminating them altogether.

Of course, if what you want is for a language to be useful for a
fairly narrow range of applications and nothing else, then all sorts
of restrictions start making more sense.

-- jd