From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.help Subject: Re: How to tame compiler? Date: Mon, 3 May 2021 02:14:35 +0300 Message-ID: References: <875z03th9b.fsf@web.de> <87v981wv3f.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21879"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0.6 (2021-03-06) Cc: help-gnu-emacs@gnu.org To: Stefan Monnier Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 03 01:32:01 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ldLZB-0005aY-2N for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 03 May 2021 01:32:01 +0200 Original-Received: from localhost ([::1]:45516 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ldLZA-0000jI-5e for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 02 May 2021 19:32:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37554) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldLRM-0006Vo-1k for help-gnu-emacs@gnu.org; Sun, 02 May 2021 19:23:56 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:40661) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldLRJ-0005bX-PF for help-gnu-emacs@gnu.org; Sun, 02 May 2021 19:23:55 -0400 Original-Received: from localhost ([::ffff:154.226.104.226]) (AUTH: PLAIN securesender, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000046165.00000000608F3486.0000394B; Sun, 02 May 2021 16:23:50 -0700 Mail-Followup-To: Stefan Monnier , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:129352 Archived-At: * Stefan Monnier [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/