Custom Query (1630 matches)

Set Up

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

I'm running chicken from the experimental branch, version 04af68b541adab8dcaa24dd0915c7e68de6eb7ed. [fixed bug in ##sys#halt (thanks to Jeronimo Pellegrini)]

I'm running OpenBSD 4.8 on i386 in a VMWare virtual machine.

This bug refers to the ​genturfa'i egg.

For this bug, please check out r21579 from the egg repository and build the egg:

svn co -r21579 https://code.call-cc.org/svn/chicken-eggs/release/4/genturfahi/trunk
cd trunk
chicken-install -s -test

This revision of the egg should pass all of its tests.

Expected vs Actual Result

The problem that I'm having is that the routine test-samselpla-re​ does not get it's #!key argument (|gerna|) assigned in all cases in which it is called, even though the #!key name is passed as a parameter to the function each time.

This routine is called in three ways:

1. By directly including the parser​ in the test.
2. By parsing re.peg​ using the bootstrap compiler​, writing the output of the compiler to a port​, and reading the port back and calling eval on the result.
3. By parsing re.peg​ using the bootstrap compiler​, and calling eval directly on the results​. Note that this is the same compiler (bootstrap.scm) compiling the same input file (tests/re.peg) as option #2.

option #1 and #2 work as expected. Option #3 does not assign #!key arguments, through the same argument list is passed to test-samselpla-re in each of the three cases.

option #3 is currently commented out, and will need to be uncommented to see this bug. Each option is grouped at the bottom of the tests/re.scm file​.

I would expect option #3 to work like option #1 and option #2, passing the test suite for this PEG grammar.

Detailed Debugging Information

Because the volume of code for this bug is so large, I provide here pointers to the relevant sections.

The runtime system for the compiler is responsible for calling test-samselpla-re. That call is performed by the function generated by nunjavni-samselpla​.

That routine generates the parse tree by calling the variable nunjavni, filtering out any result without an associated name (called cmene or cme), and creating the argument list by appending the key/value pairs, which are then applied to the supplied routine.

Looking at the inlined compiler output in option #1, you can see that nunjavni-samselpla is called with test-samselpla-re as one of it's arguments. This is done again in option #2 and option #3.

You can see the output produced by the parser by running the following command from the svn checkout:

genturfahi-peg tests/re.peg

It compiles tests/re.peg:

gerna <- #gerna: (digit / alpha)* FAhO {test-samselpla-re}
digit <- [:digit:]+
alpha <- [:alpha:]+
FAhO  <- !.

Into the following scheme code, which is the code being evaluated in option #2 and option #3:

(letrec ((gerna (nunjavni-morji
                  (nunjavni-samselpla
                    test-samselpla-re
                    (nunjavni-je
                      (nunjavni-*
                        (nunjavni-jonai
                          (nunjavni-cmene
                            (nunjavni-naselci digit)
                            cmene:
                            'digit:)
                          (nunjavni-cmene
                            (nunjavni-naselci alpha)
                            cmene:
                            'alpha:))
                        cmene:
                        'gerna:)
                      (nunjavni-cmene
                        (nunjavni-naselci FAhO)
                        cmene:
                        'FAhO:)))))
         (digit (nunjavni-morji (nunjavni-re "[[:digit:]]+")))
         (alpha (nunjavni-morji (nunjavni-re "[[:alpha:]]+")))
         (FAhO (nunjavni-morji (nunjavni-fanmo))))
  gerna)

The test-samselpla-re routine is attached to the grammar rule |gerna| in order to return only the grammar, but not the end of input token.

Conclusion

I'm sorry that I have not been able to make this test case simpler. I know that there is a lot of code involved in recreating this problem, and I'm not certain I'm even seeing a bug.

If I have forgotten a useful piece of information, please ask me for clarification, as I obviously understand this code better than anyone else and can likely save time in determining what is going on.

Chicken Scheme uses DSSSL style lambda lists, as an extension to standard scheme:

​http://wiki.call-cc.org/man/4/Extensions%20to%20the%20standard

Optional parameters are permitted to have an initializer, and the documentation states:

"The corresponding <initializer> is evaluated in an environment in which all previous parameters have been bound."

I would expect the following to work (note that a1 is being bound to the value of a0):

(define (foo #!optional a0 (a1 a0))

(list a0 a1))

(foo) => (#f #f) (foo 0) => (0 0)

However, I instead get the following error:

Note: the following toplevel variables are referenced but unbound:

a0 (in def-a123)

I've attached a test case for #!optional parameters testing additional cases.

I'm running chicken scheme from git, commit cd19d7e077f0a6b53c3c804c972ec3738683e9ab.

My platform is OpenBSD 4.8-snapshot.

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)