Custom Query (1630 matches)

This ticket is a follow-up to the ​email thread I posted about this issue.

I'm running chicken 2bb09388cff32b7ecb49f39df0692e2d4db7a0bf (silly link case problems, tiring) from the experimental branch. I'm on OpenBSD 4.8 running in a VMWare virtual machine.

This bug refers to the ​genturfa'i egg.

For this bug, please check out r21827 from the egg repository, apply the patches attached to this e-mail, and build the egg:

svn co -r21827 https://code.call-cc.org/svn/chicken-eggs/release/4/genturfahi/trunk
cd trunk
patch -p1 < patch-conf    # enable full debugging
patch -p1 < patch-memoize # the do-nothing memoizer
chicken-install -s

Run the genturfahi command-line program after installing the egg:

$ genturfahi

Error: stack overflow

        Call history:

        nunjavni.scm:176: nunjavni-*      
        nunjavni.scm:140: venunjmina-rodanunvalsi         
        morji.scm:47: hash-table-exists?          
        bootstrap.scm:369: genturfahi#morji-nunjavni-valsi        
        morji.scm:47: hash-table-exists?          
        morji.scm:48: hash-table-set!     
        bootstrap.scm:366: genturfahi#morji-nunjavni-je   
        nunjavni.scm:245: venunjmina-rodanunvalsi         
        nunjavni.scm:247: filter          
        morji.scm:47: hash-table-exists?                <--

This error is happening while genturfahi is initializing, the most outward relevant line being bootstrap.scm:366.

If you comment out morji.scm:47 and morji.scm:48, run chicken-install -s, the program will run without producing any output (which is expected.)

I would expect to be able to leave morji.scm:47 and morji.scm:48 uncommented in the code and run genturfahi without generating a stack overflow error.

This problem *also* exists when running the code from csi, without compiling it:

# This command may give an error if csi is an alias that includes
# command-line arguments, as in: alias csi='csi -quiet'.  Run csi 
# without command-line arguments.
#
$ csi chicken-csi.scm

Error: stack overflow

        Call history:

        <eval>    [morji-nunjavni] (not (hash-table-exists? morji sumti))
        <eval>    [morji-nunjavni] (hash-table-exists? morji sumti)
        <eval>    [morji-nunjavni] (hash-table-set! morji sumti javni)
        <eval>    [morji-nunjavni] (apply nunjavni sumti)
        <eval>    [nunjavni-+] (##sys#get-keyword (quote cmene:) tmp268)
        <eval>    [nunjavni-+] (nunjavni-* javni cmene: cmene)
        <eval>    [nunjavni-*] (##sys#get-keyword (quote cmene:) tmp241)
        <eval>    [nunjavni-*] (venunjmina-rodanunvalsi cmene)
        <eval>    [morji-nunjavni] (not (hash-table-exists? morji sumti))
        <eval>    [morji-nunjavni] (hash-table-exists? morji sumti)     <--

This error also goes away if you comment out morji.scm:47 and morji.scm:48.

Run the following program through csi with the test egg installed.

I've tried to group these tests such that if one in a group succeeds, all of them should. It appears that #!rest and #!key are not self-consistent, following separate rules in conceptually identical situations.

the separation of (foo ...) and (apply foo ...) shows that these tests aren't affected by (apply ...), so the (foo ...) vs (apply foo ...) difference is not essential to this issue.

The main observations:

1) #!rest affects where #!key args must be placed. 2) sometimes #!key args in the middle of an argument list work, and sometimes they don't.

I'm not trying to point out a specific test as being wrong, but that the set of these tests should be consistent and aren't.

(use test)

;; "initial" fails and "initial+rest" succeeds.  I would expect that,
;; given the "initial" test failure, that "initial+rest" would also fail.
;;
;; "end" succeeds and "end+rest" fails.  I would expect that, since
;; "end" succeeds "end+rest" would also succeed.
;;
;; Even if either of these expectations is false:
;;
;; #!key args must be in the initial position if you're calling
;; a function that also uses #!rest, but must be in the terminal
;; position if the function does not use rest.  I would expect one
;; or the other of these (or both) to succeed, but I least expected
;; the failure condition to be the opposite of the "initial" and
;; "initial+rest" cases.
;;
;; I would expect, if only one position (front or back) works, that
;; the same  position works regardless of whether the function also
;; accepts #!rest arguments.
;;
;; All of the "middle(+rest)*" tests fail *except* "middle+rest (2)".
;; I consider it strange that this test succeeds where all of the
;; remaining tests fail.
;;
;; It seems as if they should all fail or all succeed.
;;

(define (fn x y z #!key k)
  `((,x ,y ,z) ,k))

(define (fn-rest #!rest r #!key k)
  `(,r ,k))

;;; initial position
;;;

;; Here we *do not* match #!key k, unless we have a #!rest.
;;
(test-group "initial"
  (test '((0 1 2) 3) (fn k: 3 0 1 2))
  (test '((0 1 2) 3) (apply fn '(k: 3 0 1 2))))

(test-group "initial+rest"
  (test '((k: 3 0 1 2) 3) (fn-rest k: 3 0 1 2))
  (test '((k: 3 0 1 2) 3) (apply fn-rest '(k: 3 0 1 2))))


;;; middle position
;;;

;; both of these fail
;;
(test-group "middle"
  (test '((0 1 2) 3) (fn 0 k: 3 1 2))
  (test '((0 1 2) 3) (apply fn '(0 k: 3 1 2))))

(test-group "middle+rest"
  (test '((0 k: 3 1 2) 3) (fn-rest 0 k: 3 1 2))
  (test '((0 k: 3 1 2) 3) (apply fn-rest '(0 k: 3 1 2))))


;; The "middle+rest (2)" succeeds, where I would expect it to fail
;; with everything else (or better, I expect all of the middle
;; groups to succeed.)
;;
(test-group "middle (2)"
  (test '((0 1 2) 3) (fn 0 1 k: 3 2))
  (test '((0 1 2) 3) (apply fn '(0 1 k: 3 2))))

(test-group "middle+rest (2)"
  (test '((0 1 k: 3 2) 3) (fn-rest 0 1 k: 3 2))
  (test '((0 1 k: 3 2) 3) (apply fn-rest '(0 1 k: 3 2))))


;;; end position
;;;

;; here we *do* match #!key k, unless we have a #!rest.  Opposite of
;; the "initial" tests.  I would expect the success/failure pattern
;; to match the "initial" tests, rather than being opposite of them.
;;
(test-group "end"
  (test '((0 1 2) 3) (fn 0 1 2 k: 3))
  (test '((0 1 2) 3) (apply fn '(0 1 2 k: 3))))

(test-group "end+rest"
  (test '((0 1 2 k: 3) 3) (fn-rest 0 1 2 k: 3))
  (test '((0 1 2 k: 3) 3) (apply fn-rest '(0 1 2 k: 3))))

(test-exit)

The following program:

(define-values (foo bar)
  (values
    (lambda () 0)
    (lambda () 1)))

When compiled with 'csc -d2 -o define-values define-values.scm'

Gives the following warning:

Note: local assignment to unused variable `foo' may be unintended

Note: local assignment to unused variable `bar' may be unintended

I would expect to get no warning in this case, and instead have two top-level definitions, 'foo' and 'bar' after calling define-values.

This warning only happens with '-d2'.