From: Robert D. <rob...@ya...> - 2008-09-27 23:04:55
|
Hello, See below for foobar.lisp. Interpreted: (foobar) => HELLO 1 NIL Compiled: (foobar) => HELLO 1 HELLO 2 T I'm no expert on the CL spec so I don't know which is correct. But I think Maxima expects the behavior shown by interpreted code here. Thanks for your attention to this. Robert Dodier PS. $ cat foobar.lisp (defun blurf () nil) (defun foobar () (prog (x y z) (declare (ignore x y z)) ((lambda (a b) (declare (ignore a b)) (format t "HELLO 1~%") (cond ((not (blurf)) (return nil)))) nil nil) (format t "HELLO 2~%") (return t))) |
From: Ville V. <vil...@gm...> - 2008-09-28 08:02:07
|
On Sun, Sep 28, 2008 at 2:04 AM, Robert Dodier <rob...@ya...> wrote: > Hello, > Interpreted: > (foobar) > => > HELLO 1 > NIL > Compiled: > (foobar) > => > HELLO 1 > HELLO 2 > T > I'm no expert on the CL spec so I don't know which is correct. > But I think Maxima expects the behavior shown by interpreted code here. Well, clisp, cmucl, sbcl and abcl interpreter all work the same way. The spec says (not very clearly) that lambda doesn't generate a block (because lambda is a low-level part of a block-generating form, such as defun). Therefore the compiler is incorrect and needs to be fixed. I have as of yet no idea where to fix this, but we need to investigate. -VJV- |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-11-05 21:26:11
|
Thanks! I've filed this as issue #23. Bye, Erik. On Sun, Sep 28, 2008 at 12:04 AM, Robert Dodier <rob...@ya...> wrote: > Hello, > > See below for foobar.lisp. > > Interpreted: > (foobar) > => > HELLO 1 > NIL > > > Compiled: > (foobar) > => > HELLO 1 > HELLO 2 > T > > > I'm no expert on the CL spec so I don't know which is correct. > But I think Maxima expects the behavior shown by interpreted code here. > > Thanks for your attention to this. > > Robert Dodier > > PS. > $ cat foobar.lisp > (defun blurf () nil) > > (defun foobar () > (prog (x y z) > (declare (ignore x y z)) > ((lambda (a b) > (declare (ignore a b)) > (format t "HELLO 1~%") > (cond ((not (blurf)) (return nil)))) > nil nil) > (format t "HELLO 2~%") > (return t))) > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel > |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-11-24 10:51:49
|
On Wed, Nov 5, 2008 at 10:26 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > Thanks! I've filed this as issue #23. I've also found the cause: in jvm.lisp, there's a function P1-FUNCTION which wraps the body of an anonymous lambda in a BLOCK. The problem is that this block should propably be nameless, but actually is called NIL... (which of course interferes with the implied block created by PROG). I think it would be best to gensym the name of the block, or name it 'jvm::technically-required-block or something alike and unlikely to be used by any program. Bye, Erik. |
From: Ville V. <vil...@gm...> - 2008-11-24 11:41:47
|
On Mon, Nov 24, 2008 at 12:51 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > I've also found the cause: in jvm.lisp, there's a function P1-FUNCTION > which wraps the body of an anonymous lambda in a BLOCK. The problem is > that this block should propably be nameless, but actually is called > NIL... (which of course interferes with the implied block created by > PROG). Would there be any chance to avoid this block-wrapping? I fear it may cause other problems. The standard forbids wrapping a lambda body in a block, although it's not explicit about the issue. > I think it would be best to gensym the name of the block, or name it > 'jvm::technically-required-block or something alike and unlikely to be > used by any program. If we do this, I'd say we should at least gensym the name. The other solution sounds hackish and may bite us later, and will be very annoying to debug. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-11-24 11:58:15
|
On Mon, Nov 24, 2008 at 12:30 PM, Ville Voutilainen <vil...@gm...> wrote: > On Mon, Nov 24, 2008 at 12:51 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: >> I've also found the cause: in jvm.lisp, there's a function P1-FUNCTION >> which wraps the body of an anonymous lambda in a BLOCK. The problem is >> that this block should propably be nameless, but actually is called >> NIL... (which of course interferes with the implied block created by >> PROG). > > Would there be any chance to avoid this block-wrapping? I fear it may cause > other problems. The standard forbids wrapping a lambda body in a block, > although it's not explicit about the issue. > >> I think it would be best to gensym the name of the block, or name it >> 'jvm::technically-required-block or something alike and unlikely to be >> used by any program. > > If we do this, I'd say we should at least gensym the name. The other solution > sounds hackish and may bite us later, and will be very annoying to debug. Well, I'd like to fix the immediate problem, to have some air/time to fix the block-wrapping in general. I must say that my current understanding of the compiler does not allow me to estimate the ripple effects of eliminating the block: it could be an assumption that every function (including lambdas) have a wrapping block - technically [for example just because a block struct carries around some function oriented fields or something]. A definite solution could be to extend the block struct with a marker which will eliminate the actual block in the generated code - or something like it. But.. I agree, it's not nice to have the block where it's not explicitly or implicitly required. Bye, Erik. |
From: Ville V. <vil...@gm...> - 2008-11-24 12:26:29
|
On Mon, Nov 24, 2008 at 1:58 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > Well, I'd like to fix the immediate problem, to have some air/time to Sure, if this fixes the code by gensym:ing the block inside a lambda, I have no objection for that. The block generation is there to begin with, so we'll not break anything that's not broken already. > effects of eliminating the block: it could be an assumption that every > function (including lambdas) have a wrapping block - technically [for > example just because a block struct carries around some function > oriented fields or something]. A definite solution could be to extend A very plausible explanation. I think you can just commit a gensym fix for the current code, we'll have to postpone other more drastic measures. -VJV- |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-12-07 10:30:06
|
On Mon, Nov 24, 2008 at 1:26 PM, Ville Voutilainen <vil...@gm...> wrote: > On Mon, Nov 24, 2008 at 1:58 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: >> Well, I'd like to fix the immediate problem, to have some air/time to > > Sure, if this fixes the code by gensym:ing the block inside a lambda, > I have no objection for that. The block generation is there to begin with, > so we'll not break anything that's not broken already. > >> effects of eliminating the block: it could be an assumption that every >> function (including lambdas) have a wrapping block - technically [for >> example just because a block struct carries around some function >> oriented fields or something]. A definite solution could be to extend > > A very plausible explanation. I think you can just commit a gensym > fix for the current code, we'll have to postpone other more drastic > measures. Just for general information: this issue has been fixed on trunk now. Bye, Erik. |