GNU logs - #16363, boring messages

Message sent to bug-guile@HIDDEN:

Subject: bug#16363: interactive use subject to compiler limitations
Resent-From: Zefram <zefram@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sun, 05 Jan 2014 23:45:14 +0000
Resent-Message-ID: <handler.16363.B.138896546619202 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 16363 <at> debbugs.gnu.org
Date: Sun, 5 Jan 2014 23:17:59 +0000
From: Zefram <zefram@HIDDEN>
Message-ID: <20140105231759.GH30283@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

guile-2.0.9's compiler has some inconvenient restrictions, relative to
its interpreter.  Where the compiler is automatically applied to scripts,
the restrictions aren't a serious problem, because if compilation fails
then guile falls back to interpreting the script.  But in an interactive
REPL session, by default each form entered by the user is passed through
the compiler, and if compilation fails then the error is signalled,
with no fallback to interpretation.

As a test case, consider a form in which a procedure object appears.
The compiler can't handle forms that directly reference a wide variety of
object types, including procedures (both primitive and user-defined) and
GOOPS objects.  In the interpreter these objects simply self-evaluate,
and it can be useful to reference them without the usual indirection
through a named variable.  Here I'll show what happens to such a form
in a script and interactively, in guile 1.8 and 2.0:

$ cat t2
(cond-expand
  (guile-2
    (eval-when (compile load eval)
      (fluid-set! read-eval? #t)))
  (else
    (fluid-set! read-eval? #t)))
(define (p x y) (#.+ x y))
(write (p 2 3))
(newline)
$ guile-1.8 t2
5
$ guile-2.0 --no-auto-compile t2
5
$ guile-2.0 t2
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t2
;;; WARNING: compilation of /home/zefram/usr/guile/t2 failed:
;;; ERROR: build-constant-store: unrecognized object #<procedure + (#:optional _ _ . _)>
5
$ guile-1.8
guile> (fluid-set! read-eval? #t)
guile> (define (p x y) (#.+ x y))
guile> (p 2 3)
5
guile> ^D
$ guile-2.0
GNU Guile 2.0.9-deb+1-1
Copyright (C) 1995-2013 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (fluid-set! read-eval? #t)
scheme@(guile-user)> (define (p x y) (#.+ x y))
While compiling expression:
ERROR: build-constant-store: unrecognized object #<procedure + (#:optional _ _ . _)>
scheme@(guile-user)> (p 2 3)
<unnamed port>:3:0: In procedure #<procedure 12bc9e0 at <current input>:3:0 ()>:
<unnamed port>:3:0: In procedure #<procedure 12bc9e0 at <current input>:3:0 ()>: Unbound variable: p

There is a workaround for this problem: the REPL's "interp" option
controls whether forms go through the compiler or the interpreter.  Hence:

scheme@(guile-user)> (fluid-set! read-eval? #t)
scheme@(guile-user)> (#.+ 2 3)
While compiling expression:
ERROR: build-constant-store: unrecognized object #<procedure + (#:optional _ _ . _)>
scheme@(guile-user)> ,o interp #t
scheme@(guile-user)> (#.+ 2 3)
$1 = 5

So the problem is merely that the REPL is broken *by default*.
It should either default to the working mechanism, or fall back to it
when compilation fails (as the file auto-compilation does).

Debian incarnation of this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734108

-zefram

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Zefram <zefram@HIDDEN>
Subject: bug#16363: Acknowledgement (interactive use subject to compiler
 limitations)
Message-ID: <handler.16363.B.138896546619202.ack <at> debbugs.gnu.org>
References: <20140105231759.GH30283@HIDDEN>
X-Gnu-PR-Message: ack 16363
X-Gnu-PR-Package: guile
Reply-To: 16363 <at> debbugs.gnu.org
Date: Sun, 05 Jan 2014 23:45:15 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guile@HIDDEN

If you wish to submit further information on this problem, please
send it to 16363 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
16363: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D16363
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guile@HIDDEN:

Subject: bug#16363: interactive use subject to compiler limitations
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Wed, 15 Jan 2014 20:06:01 +0000
Resent-Message-ID: <handler.16363.B16363.138981635319231 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Zefram <zefram@HIDDEN>
Cc: 16363 <at> debbugs.gnu.org, request <at> debbugs.gnu.org
From: Mark H Weaver <mhw@HIDDEN>
References: <20140105231759.GH30283@HIDDEN>
Date: Wed, 15 Jan 2014 15:03:29 -0500
In-Reply-To: <20140105231759.GH30283@HIDDEN> (zefram@HIDDEN's message of
 "Sun, 5 Jan 2014 23:17:59 +0000")
Message-ID: <87ppntt3la.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

tags 16363 notabug
thanks

Zefram <zefram@HIDDEN> writes:

> guile-2.0.9's compiler has some inconvenient restrictions, relative to
> its interpreter.  Where the compiler is automatically applied to scripts,
> the restrictions aren't a serious problem, because if compilation fails
> then guile falls back to interpreting the script.  But in an interactive
> REPL session, by default each form entered by the user is passed through
> the compiler, and if compilation fails then the error is signalled,
> with no fallback to interpretation.
>
> As a test case, consider a form in which a procedure object appears.
> The compiler can't handle forms that directly reference a wide variety of
> object types, including procedures (both primitive and user-defined) and
> GOOPS objects.  In the interpreter these objects simply self-evaluate,
> and it can be useful to reference them without the usual indirection
> through a named variable.

Scheme does not allow arbitrary user objects to be embedded directly
into the source code.  It worked by accident in Guile 1.8, but in a
system with ahead-of-time compilation to object files, which requires
that all code and literals be serialized, there's no sane way to support
the semantics you seem to want.

     Regards,
       Mark

Message received at request <at> debbugs.gnu.org:

Received: (at request) by debbugs.gnu.org; 15 Jan 2014 20:05:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 15:05:53 2014
Received: from localhost ([127.0.0.1]:52382 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1W3Wim-0004zz-Or
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2014 15:05:53 -0500
Received: from world.peace.net ([96.39.62.75]:50083)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <mhw@HIDDEN>)
 id 1W3Wil-0004zo-Ik; Wed, 15 Jan 2014 15:05:51 -0500
Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com
 ([209.6.91.212] helo=yeeloong)
 by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16)
 (Exim 4.72) (envelope-from <mhw@HIDDEN>)
 id 1W3Wif-0004Hi-FB; Wed, 15 Jan 2014 15:05:45 -0500
From: Mark H Weaver <mhw@HIDDEN>
To: Zefram <zefram@HIDDEN>
Subject: Re: bug#16363: interactive use subject to compiler limitations
References: <20140105231759.GH30283@HIDDEN>
Date: Wed, 15 Jan 2014 15:03:29 -0500
In-Reply-To: <20140105231759.GH30283@HIDDEN> (zefram@HIDDEN's message of
 "Sun, 5 Jan 2014 23:17:59 +0000")
Message-ID: <87ppntt3la.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: request
Cc: 16363 <at> debbugs.gnu.org, request <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

tags 16363 notabug
thanks

Zefram <zefram@HIDDEN> writes:

> guile-2.0.9's compiler has some inconvenient restrictions, relative to
> its interpreter.  Where the compiler is automatically applied to scripts,
> the restrictions aren't a serious problem, because if compilation fails
> then guile falls back to interpreting the script.  But in an interactive
> REPL session, by default each form entered by the user is passed through
> the compiler, and if compilation fails then the error is signalled,
> with no fallback to interpretation.
>
> As a test case, consider a form in which a procedure object appears.
> The compiler can't handle forms that directly reference a wide variety of
> object types, including procedures (both primitive and user-defined) and
> GOOPS objects.  In the interpreter these objects simply self-evaluate,
> and it can be useful to reference them without the usual indirection
> through a named variable.

Scheme does not allow arbitrary user objects to be embedded directly
into the source code.  It worked by accident in Guile 1.8, but in a
system with ahead-of-time compilation to object files, which requires
that all code and literals be serialized, there's no sane way to support
the semantics you seem to want.

     Regards,
       Mark

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16363: interactive use subject to compiler limitations
Resent-From: Zefram <zefram@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Wed, 15 Jan 2014 21:27:02 +0000
Resent-Message-ID: <handler.16363.B16363.13898211969344 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16363
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: notabug
To: Mark H Weaver <mhw@HIDDEN>
Cc: 16363 <at> debbugs.gnu.org
Received: via spool by 16363-submit <at> debbugs.gnu.org id=B16363.13898211969344
          (code B ref 16363); Wed, 15 Jan 2014 21:27:02 +0000
Received: (at 16363) by debbugs.gnu.org; 15 Jan 2014 21:26:36 +0000
Received: from localhost ([127.0.0.1]:52501 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1W3Xyt-0002Qe-TX
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2014 16:26:36 -0500
Received: from river.fysh.org ([5.135.154.127]:45191)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <zefram@HIDDEN>) id 1W3Xyq-0002QV-Lp
 for 16363 <at> debbugs.gnu.org; Wed, 15 Jan 2014 16:26:33 -0500
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
Date: Wed, 15 Jan 2014 21:26:29 +0000
From: Zefram <zefram@HIDDEN>
Message-ID: <20140115212629.GZ21945@HIDDEN>
References: <20140105231759.GH30283@HIDDEN>
 <87ppntt3la.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87ppntt3la.fsf@HIDDEN>
X-Spam-Score: -0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.3 (/)

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

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.