Re: Where is Emacs Lisp taught ?

[Gene <gene.sullivan@gmail.com>]

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