From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Zefram Newsgroups: gmane.lisp.guile.bugs Subject: bug#16363: interactive use subject to compiler limitations Date: Wed, 15 Jan 2014 21:26:29 +0000 Message-ID: <20140115212629.GZ21945@fysh.org> References: <20140105231759.GH30283@fysh.org> <87ppntt3la.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1389821242 9426 80.91.229.3 (15 Jan 2014 21:27:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Jan 2014 21:27:22 +0000 (UTC) Cc: 16363@debbugs.gnu.org To: Mark H Weaver Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Wed Jan 15 22:27:24 2014 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W3Xzc-0002bw-WA for guile-bugs@m.gmane.org; Wed, 15 Jan 2014 22:27:21 +0100 Original-Received: from localhost ([::1]:57290 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3Xzc-0007Yh-IV for guile-bugs@m.gmane.org; Wed, 15 Jan 2014 16:27:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34507) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3XzR-0007Qf-9b for bug-guile@gnu.org; Wed, 15 Jan 2014 16:27:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3XzL-0003YM-A2 for bug-guile@gnu.org; Wed, 15 Jan 2014 16:27:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38482) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3XzL-0003YI-70 for bug-guile@gnu.org; Wed, 15 Jan 2014 16:27:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W3XzK-0002RT-Bu for bug-guile@gnu.org; Wed, 15 Jan 2014 16:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Zefram Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 15 Jan 2014 21:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16363 X-GNU-PR-Package: guile X-GNU-PR-Keywords: notabug Original-Received: via spool by 16363-submit@debbugs.gnu.org id=B16363.13898211969344 (code B ref 16363); Wed, 15 Jan 2014 21:27:02 +0000 Original-Received: (at 16363) by debbugs.gnu.org; 15 Jan 2014 21:26:36 +0000 Original-Received: from localhost ([127.0.0.1]:52501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3Xyt-0002Qe-TX for submit@debbugs.gnu.org; Wed, 15 Jan 2014 16:26:36 -0500 Original-Received: from river.fysh.org ([5.135.154.127]:45191) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3Xyq-0002QV-Lp for 16363@debbugs.gnu.org; Wed, 15 Jan 2014 16:26:33 -0500 Original-Received: from zefram by river.fysh.org with local (Exim 4.80 #2 (Debian)) id 1W3Xyn-0004vT-4G; Wed, 15 Jan 2014 21:26:29 +0000 Content-Disposition: inline In-Reply-To: <87ppntt3la.fsf@netris.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:7389 Archived-At: Mark H Weaver wrote: >that all code and literals be serialized, there's no sane way to support >the semantics you seem to want. We've addressed the semantics themselves on the other ticket, #16362. Accepting that the compiler semantics are preferred, there's still a problem in the scope of my intent for this ticket #16363: that interactive behaviour doesn't match the behaviour of a script. The mismatch is a problem for development regardless of which set of semantics is correct. As I mentioned in passing on the other ticket, you could fix this by enforcing the compiler restrictions in interpreting situations. A start on this would be for read-eval to refuse to accept any object without a readable print form, such as the procedure in my example on this ticket. For objects that do have a readable print form, such as the pair in #16362, it could break the referential identity by copying the object, as if by printing it to characters and reading it back. If, on the other hand, you actually intend for the compiler and interpreter to have visibly different semantics, there's still the problem that the REPL approaches that difference in a different way from script execution. In that case, either the REPL should perform the same fallback that script execution does (as I originally suggested on this ticket), or script execution should not perform the fallback. -zefram