Re: Where is Emacs Lisp taught ?

[Gene]

On Saturday, October 27, 2018 at 9:16:13 PM UTC-4, Jean-Christophe Helary wrote:
>> On Oct 28, 2018, at 9:27, Garreau, Alexandre wrote:
>> 
>> On 2018-10-27 at 09:54, Jean-Christophe Helary wrote:
>>> Gene,
>>> 
>>> Thank you for this remark. I totally agree with you. elisp should be
>>> considered a domain specific language and not be compared to general
>>> purpose languages in general.

 
>> emacs lisp *can* and *is* used as a general purpose language.
> 
> If you consider Emacs as a virtual lisp machine, yes. 
> If you consider Emacs as a text editor, much less so.
> 
> Teaching elisp as strictly a lisp dialect, 
> removes it from its utility as being Emacs extension language.

Isn't this the problem with any/every narrow-scoped portrayal of any and every 
would-be `subject' in a given Universe of Discourse?

When anything is beheld from only one Point-of-View, one worldview, one 
prejudicing lens the necessarily subjective observer learns the prejudicial 
cognitive framework along with the material/subject portrayed as figural ONLY 
in the contextual backdrop in which it was contrasted.

As a text processor it might behoove one to meditate on the fundamentals of 
tickertapes of characters.

If one has been biased by other languages supporting `strings' one might 
project that bias upon 1D vectors/arrays/strings which can be thought-of-as or 
ALSO-thought-of-as said vectors or arrays ... all of which can be dealt with a 
`sequences' which elisp supports, but perhaps not common lisp, scheme, GIMP's 
script-fu, or AutoCAD's autolisp or visual lisp, etc, 

And what about `rectangles'?
What's up with rectangles of text?
One might not encounter them with sed, ed, nano, pico, gedit, or any given word 
processor.

Which features of elisp lend support to various major modes, programming 
language syntaxes, screen scraping, computational linguistics, boilerplate 
generation, data entry ... whatever is of interest to YOU?


Which features of elisp allow it to outsource processing via faster programming 
languages?

When would one want to enclose elisp in a ".el" file ... and when might it be 
better to include elisp source in an org-mode code block, perhaps along with 
source code from those faster, `sucks less', presumably *better* programming 
languages?

How can elisp allow an emacs user to splice-together `code' from several 
programming languages, launch apps and/or processes which generate `text' which 
is subsequently inserted in one-or-more buffers?

These seem the kinds of questions one might ask oneself pursuant to exploiting 
emacs as both a work shop of interoperable tools AND an artist studio.

FWIW