🚀 go-pugleaf

In article <8812301512.AA10827@decwrl.dec.com>, ellis@ultra (David Ellis) writes:
]What I'd like to do is have a function taking an argument that gets
]inserted into a prompt string.  If I call (foo "type A"), I want
]to have a prompt string that looks like
]
]	(This is a type A prompt string) :

If you call foo normally through Lisp, the interactive form is
bypassed, since the arguments are provided.  The interactive form is
only consulted when a function is called interactively (through the
keyboard or with call-interactively).  You can check how a function
has been called with the function interactive-p.

What you can do is have your function check to see if it was called
interactively, and use read-string if it was not.

What if you want a function that looks at some state at run time to
decide how to get its arguments?  You can't do this quite so easily.
However, if the "argument" to interactive is not a string, it is
evaluated to return a list of the arguments to the function.  You can
use read-string to get the arguments, and convert them to the
appropriate types.  This is not as easy as interactive, but it will
work.

]I can do this if I can get the special form "interactive" to take as its
]argument a string-valued expression in place of a specific string, for
]example

I don't think so, but it would be useful.  It wouldn't conflict with
the usage outlined above.  I don't know how feasible it would be,
though, since I don't know whether this information is processed at
run time or definition time.

]	(interactive (format "s(This is a %s prompt string) : " foo-arg))
]
]Unfortunately, GNU Emacs rewards this effort with the error message
]
]	Wrong type argument: listp, "s(This is a Type A prompt string) : "
]
]saying that "interactive" expects a list (huh?) but has been given a string.

If the form interactive is given is not LITERALLY a list, it is
evaluated and must return a list of arguments that will be passed to
the function.  The string you return is not a list from which
arguments can be extracted.

]Trying a macro expansion within the scope of the "interactive" form fails
]in a similar way.

For the same reason.
-- 
harvard >>>>>>  |	Robert Krawitz <rlk@think.com>	245 First St.
bloom-beacon >  |think!rlk	(postmaster)		Cambridge, MA  02141
topaz >>>>>>>>  .	Thinking Machines Corp.		(617)876-1111