🚀 go-pugleaf

i'm using defstruct from xlisp2.1d to make a structure like this:

(defstruct
   lr1item production lookahead
   (tail (production-string production)))

which creates a function make-lr1item that (i thought) would initialise
tail to a value derived from one of the other fields, unless explicitly
given a value...
	(make-lr1item :production x :lookahead '(a))
would use the default value (a field within x's value), and 
	(make-lr1item :production x :tail '(x Y z) :lookahead '(a))
would set tail explicitly.

but... it doesn't do that.  defstruct builds make-lr1item in such
a way that i get an unbound symbol error on production in the
default case.  the given production (another structure) has not
bound to the symbol production at the time the expression is evaled.

i can get around this in this way:

(defstruct lr1item production lookahead tail)
(defun make-lr1item
	(&key production lookahead (tail (production-string production)))
	(#.#'make-lr1item :production production :tail tail :lookahead lookahead))

i.e., let defstruct make a non-defaulting version of make-lr1item,
and use it to make a defaulting one.  this form works.

i guess i have a number of questions, somewhat xlisp-related.

1. am i trying to do it in an evil way, with either the original plan
   or the fix?  e.g.: i'm assuming that all explicit key arguments
   will be bound before defaulting is done on unspecified ones... is
   that risky?

2. if you look at the lambda-expression generated by defstruct for
   make-lr1item, the default expression for item has been made into
   a closure... is there any particular reason for doing it that way?
   i assume the closure is delaying or making invisible the binding
   of production in this case...

3. (getting away from the focus)  how stable can i expect %make-struct
   and the other undocumented kernel structure-support functions?  (is
   kernel the word?)  i used them once to make a more general equalp,
   that would work with structures...  is that fragile?