Re: How to tame compiler?

[Eduardo Ochs <eduardoochs@gmail.com>]

On Sun, 2 May 2021 at 20:32, Jean Louis <bugs@gnu.support> wrote:
>
> * Stefan Monnier <monnier@iro.umontreal.ca> [2021-05-03 01:30]:
> > >> I know I sound like a broken clock, but [...]
> > > I think you would sound more like an unbroken clock if you would shortly
> > > tell the disadvantages of using `eval', then people would be more open
> > > to alternatives.
> >
> > Code always starts in the form of a string somewhere, i.e. data, and
> > somewhere along the lines it gets transformed into something that can be
> > executed, i.e. code.
> >
> > `eval` is one way to do that, but it's a quite restrictive, because it
> > doesn't give any opportunity to do something useful with the data
> > representation of the code before we run it.  I.e. it makes it hard to
> > compile the code to make it more efficient, it makes it virtually
> > impossible to give feedback about problems in the code (except for those
> > problems which lead to "hard errors"), and for the same reason it makes
> > it hard to provide any other kind of help in writing the code (like code
> > completion).
> >
> > In the current context of Emacs, places that use `eval` tend to presume
> > that variables have names and that those names are significant,
> > i.e. they presume dynamic scoping, and for the same reason that it's
> > hard to provide feedback about problems in code that is passed to `eval`
> > it's very hard (both for tools and for humans) to figure out what needs
> > to be done in order for the code to work correctly in the lexical-scoped
> > dialect of ELisp.
> >
> >
> >         Stefan
>
> Thank you. I agree with compiler issues.
>
> In the context of template expansion, would there be some larger
> program and they are in background somewhat larger, those programs or
> functions may and do reside in packages with lexical scoping, rather
> for verification of the code. When certain function runs well, they
> are proven and they may be then embedded into the text. It could be as
> simple as:
>
> ⟦ (sql "SELECT count(1) FROM people") ⟧
>
> or
>
> ⟦ (clisp-macro (princ (format nil "~R" (expt 2 50)))) ⟧
>
> Those are usually smaller snippets that are verified outside of the
> text template beforehand, and previewed before publishing. If anything
> goes wrong, they may evaluate to empty string and continue with
> parsing of the text. Previewer may decide if function works or not,
> basically, if the text is ready to be published or not.
>
> Would there be larger or more complex code, then such can be invoked
> beforehand in form of a report, or file, and its result could be
> included into the page by one of the methods. In general the embedded
> Emacs Lisp will never be used or installed as a package, neither byte
> compiled or otherwise verified for correctness as how we usually do it
> with Emacs Lisp files.
>
> It is one of multiple programming paradigms of Lisp.
>
>
>
> --
> Jean


Hi Jean-Louis,

just as a curiosity, here is how eev implements template
interpolation:

  http://angg.twu.net/eev-current/eev-template0.el.html
  http://angg.twu.net/eev-current/eev-template0.el

I tried several other implementations of template interpolation
functions before that one, and from time to time I would find another
way that would be both simpler and more powerful than the previous
one... the one above is so simple that in one of the times that I gave
a minicourse on LaTeX and Emacs I followed the code of `ee-template0'
with the students in the third day of the minicourse - one day after
teaching them briefly how to understand code with `defun's and `let's.

My trick to handle lexical binding was to tell the students that
dynamic binding is much easier to understand than lexical binding, and
that they should treat dynamic binding as an advanced topic that would
make more sense when they had at least one week of experience with
Emacs - and my minicourse was only five days long, from monday to
friday... but the students in that minicourse were mathematicians with
little experience in programming, not compsci people who would see
immediately that dynamic binding is "wrong".

  Cheers =),
    Eduardo Ochs
    http://angg.twu.net/#eev