Re: How to tame compiler?

[Jean Louis <bugs@gnu.support>]

* 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

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://stallmansupport.org/
https://rms-support-letter.github.io/