From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: RE: Obsoleting end-user-functions [was: turn-on-* type functions] Date: Tue, 06 Apr 2010 15:41:11 +0900 Message-ID: <87ochxozg8.fsf@uwakimon.sk.tsukuba.ac.jp> References: <50365.130.55.132.97.1270318658.squirrel@webmail.lanl.gov> <622A6B6A-AC87-4229-B40D-CCD28A3B5C25@mit.edu> <7BC79A0C-3709-4FD4-A678-0F235B789213@mit.edu> <87r5mupr6l.fsf@uwakimon.sk.tsukuba.ac.jp> <4BB954E9.7050805@censorshipresearch.org> <7B36874B0D264894B3D8954FC67ADADC@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1270537791 16197 80.91.229.12 (6 Apr 2010 07:09:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 6 Apr 2010 07:09:51 +0000 (UTC) Cc: 'Chad Brown' , emacs-devel@gnu.org, 'Daniel Colascione' , 'Stefan Monnier' To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 06 09:09:46 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nz2ut-0004bo-L7 for ged-emacs-devel@m.gmane.org; Tue, 06 Apr 2010 09:09:43 +0200 Original-Received: from localhost ([127.0.0.1]:47159 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nz2ut-0000pP-3R for ged-emacs-devel@m.gmane.org; Tue, 06 Apr 2010 03:09:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nz2uN-0000bG-EI for emacs-devel@gnu.org; Tue, 06 Apr 2010 03:09:11 -0400 Original-Received: from [140.186.70.92] (port=50172 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nz2uL-0000ZU-2j for emacs-devel@gnu.org; Tue, 06 Apr 2010 03:09:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nz2uJ-0004Zr-0U for emacs-devel@gnu.org; Tue, 06 Apr 2010 03:09:08 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:51652) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nz2uI-0004XF-77 for emacs-devel@gnu.org; Tue, 06 Apr 2010 03:09:06 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id B5772820F; Tue, 6 Apr 2010 15:41:47 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 524A11270EF; Tue, 6 Apr 2010 15:41:11 +0900 (JST) In-Reply-To: <7B36874B0D264894B3D8954FC67ADADC@us.oracle.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" a03421eb562b XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:123248 Archived-At: Drew Adams writes: > > > A harder, invasive idea: get rid of explicit byte-compilation, > > > by default. > > What do you mean "by default"? I mean that you should not ever need to run byte-compile-file in the normal use of Emacs, even if you code a lot of Lisp. > > > If Emacs always byte-compiles out-of-date > > > libraries at load time, the warnings would be generated. > > If load implies byte-compile, then, again, what did you mean by "by default"? To be precise, "load" wouldn't imply byte-compile. It would be a cache fetch, which would check for freshness, and if not, regenerate the bytecode for the library. > When would non-compiled code be used - just by explicit eval (e.g. `C-x C-e') > instead of load? I said nothing about eval. As Daniel pointed out, some Lisps have never had a Lisp interpreter, they always (byte-)compile. Python (and IIRC, Perl) use a similar strategy of executing only compiled code. Code would be interpreted directly only when byte-compiling was inhibited, by binding an appropriate variable (and if so, there would presumably be a command-line flag to allow either global interpretation or interpretation of the uncompiled user code only). > > I've been using byte-code-cache.el for years. It reimplements > > load in lisp, byte-compiling files and automatically caching the > > results. > > Maybe I'm misunderstanding... Are you suggesting that every load > would load byte-compiled code? Unless explicitly inhibited, and maybe even that would be disallowed. > So to use the debugger I would need to explicitly eval stuff > (e.g. whole libraries)? Surely you don't mean for users to debug > using byte-compiled code? Why not? Making that transparent is why I characterized this as "harder" (a small understatement) and "invasive". But it's not that hard. Python does it fine. You need to remember that there are bytecodes for only a very small (< 256) number of functions, and that variable references are by symbol, not by address. That means that in most cases it is fairly easy to unambiguously reconstruct the source. Only in the case of compiled (and therefore pre-expanded) macros would there be a problem. But in that case it should be possible to use the same source-level debuggers and other techniques we use today.