read, eval, and damaged languages

[zilla@ccrl.nj.nec.com (John Lewis)]

Most large programs eventually need to have an input language.
In my opinion this is where read and eval are useful outside
of AI (isn't it?).

This goes not just for emacs and autocad, with extension languages
that are explicitly lisp, but also for Microsoft Word and Excel.
In Unix it seems that each major program has its own input language, 
and each such language is incompatible with the others and poorly designed.  

I would think that input languages should be implemented
using read, eval, and lisp macros, and a small amount of programming.
This would provide greater consistency and power for (advanced) users 
and eliminate the continual reinvention of parsers and evaluators 
for ad hoc languages.

People would object to the lisp-like syntax of these input languages,
but Dylan's alternate syntax might address this.

It would be ironic if Dylan were used to implement a damaged language
like Make/Awk/Perl, when Dylan itself is 'hiding' a much better language.

Is this thinking incorrect?  I am not used to Lisp without read and eval!

I favor Dylan with *optional* eval and read, so that 'large'
implementations can provide these features without including them
as implementation-specific (and incompatible) extensions.  
Of course, ideally, applications that do not use them should not 
pay the size price.