What is the type of user input?

What is the type of user input?

[Hattuari]

The following code demonstrates the problem I'm having:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; create a property list and use it to map long strings
;; to short strings
(setq paste-gl-type-map ())

(setq paste-gl-type-map (plist-put paste-gl-type-map 'GLbyte     'b))
(setq paste-gl-type-map (plist-put paste-gl-type-map 'GLshort    's))
(setq paste-gl-type-map (plist-put paste-gl-type-map 'GLint      'i))

;;...

(plist-get paste-gl-type-map 'GLbyte) ;; test function call


(defun paste-gl-array(gl-type gl-components gl-vector)
  "Map OpenGL types to corresponding sufixes.(GL\'type\' )"
  (interactive "sType: \nnNumber 1 to 4: \nsVector: ")
  (message " gl-type=%s, gl-components=%d, gl-vector=%s , suffix=%s"
           gl-type gl-components gl-vector
           (plist-get paste-gl-type-map gl-type))
  
  )
;; end of application code
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

When I use the code by first `M-x eval-buffer' and then `M-x
paste-gl-array<RET>GLbyte<RET>4<RET>v<RET>', the result is a message
displayed in the echo area as follows:

gl-type=GLbyte, gl-components=4, gl-vector=v , suffix=nil

Notice that gl-type is displayed with the value I entered in the minibuffer
when it is passed to the first %s in the message string.  It seems not to
be treated as a string when passed to plist-get, hence the 'suffix=nil'.

OTOH, when I evaluate this expression in an emacs-lisp buffer
(paste-gl-array 'GLbyte 4 'v), I see the following in the echo area:

gl-type=GLbyte, gl-components=4, gl-vector=v , suffix=b

That is the desired result.  Why is this not the result of calling the
function as an interactive command as described above?

I will continue to look for an answer in the documentation, but any help
from someone who knows the answer would be appreciated.
-- 
p->m == (*p).m == p[0].m

Re: What is the type of user input?

[Kevin Rodgers]

Hattuari wrote:
 > The following code demonstrates the problem I'm having:
 > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 > ;; create a property list and use it to map long strings
 > ;; to short strings
 > (setq paste-gl-type-map ())
 >
 > (setq paste-gl-type-map (plist-put paste-gl-type-map 'GLbyte     'b))
 > (setq paste-gl-type-map (plist-put paste-gl-type-map 'GLshort    's))
 > (setq paste-gl-type-map (plist-put paste-gl-type-map 'GLint      'i))
 > ;;...
 >
 > (plist-get paste-gl-type-map 'GLbyte) ;; test function call
 >
 >
 > (defun paste-gl-array(gl-type gl-components gl-vector)
 >   "Map OpenGL types to corresponding sufixes.(GL\'type\' )"
 >   (interactive "sType: \nnNumber 1 to 4: \nsVector: ")
 >   (message " gl-type=%s, gl-components=%d, gl-vector=%s , suffix=%s"
 >            gl-type gl-components gl-vector
 >            (plist-get paste-gl-type-map gl-type))
 >
 >   )
 > ;; end of application code
 > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 >
 > When I use the code by first `M-x eval-buffer' and then `M-x
 > paste-gl-array<RET>GLbyte<RET>4<RET>v<RET>', the result is a message
 > displayed in the echo area as follows:
 >
 > gl-type=GLbyte, gl-components=4, gl-vector=v , suffix=nil
 >
 > Notice that gl-type is displayed with the value I entered in the 
minibuffer
 > when it is passed to the first %s in the message string.  It seems not to
 > be treated as a string when passed to plist-get, hence the 'suffix=nil'.

gl-type is a string.  Since the paste-gl-type-map property list is keyed
by symbols, plist-get returns nil.  The %s message specifier can be
applied to any Lisp object, and symbols and strings are formatted the
same.

The solution is to either (1) read gl-type with the %S code or (2) call
plist-get with (intern gl-type).

 > OTOH, when I evaluate this expression in an emacs-lisp buffer
 > (paste-gl-array 'GLbyte 4 'v), I see the following in the echo area:
 >
 > gl-type=GLbyte, gl-components=4, gl-vector=v , suffix=b
 >
 > That is the desired result.  Why is this not the result of calling the
 > function as an interactive command as described above?
 >
 > I will continue to look for an answer in the documentation, but any help
 > from someone who knows the answer would be appreciated.

It's not that hard to find:

`C-h f message' has a link to the doc string for `format', which has a
link to the doc string for `princ' in its description of %s:

,----[ C-h f princ RET ]
| princ is a built-in function.
| (princ OBJECT &optional PRINTCHARFUN)
|
| Output the printed representation of OBJECT, any Lisp object.
| No quoting characters are used; no delimiters are printed around
| the contents of strings.
|
| OBJECT is any of the Lisp data types: a number, a string, a symbol,
| a list, a buffer, a window, a frame, etc.
|
| A printed representation of an object is text which describes that object.
...`----

-- 
Kevin Rodgers

Re: What is the type of user input?

[Hattuari]

Kevin Rodgers wrote:

> Hattuari wrote:
>  > The following code demonstrates the problem I'm having:
>  > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>  > ;; create a property list and use it to map long strings
>  > ;; to short strings
>  > (setq paste-gl-ty
...
> gl-type is a string.  Since the paste-gl-type-map property list is keyed
> by symbols, plist-get returns nil. 

That's what I was missing.  I was assuming that 'symbol-name implicitly
meant symbol would evaluate to a string.  Now that I've read the first
several chapters of the Elisp Reference Manual, I have a better idea of
what's going on.

> The %s message specifier can be 
> applied to any Lisp object, and symbols and strings are formatted the
> same.
> 
> The solution is to either (1) read gl-type with the %S code or (2) call
> plist-get with (intern gl-type).

I opted for trying an association array, which also worked.  I will try your
suggestion of using (intern gl-type).  As for reading gl-type with %S, I'm
not sure what that would do for me.  The only use I know for that is to use
it in a string format.

>  > OTOH, when I evaluate this expression in an emacs-lisp buffer
>  > (paste-gl-array 'GLbyte 4 'v), I see the following in the echo area:
>  >
>  > gl-type=GLbyte, gl-components=4, gl-vector=v , suffix=b
>  >
>  > That is the desired result.  Why is this not the result of calling the
>  > function as an interactive command as described above?
>  >
>  > I will continue to look for an answer in the documentation, but any
>  > help from someone who knows the answer would be appreciated.
> 
> It's not that hard to find:
> 
> `C-h f message' has a link to the doc string for `format', which has a
> link to the doc string for `princ' in its description of %s:
> 
> ,----[ C-h f princ RET ]
> | princ is a built-in function.
> | (princ OBJECT &optional PRINTCHARFUN)
> |
> | Output the printed representation of OBJECT, any Lisp object.
> | No quoting characters are used; no delimiters are printed around
> | the contents of strings.
> |
> | OBJECT is any of the Lisp data types: a number, a string, a symbol,
> | a list, a buffer, a window, a frame, etc.
> |
> | A printed representation of an object is text which describes that
> | object.
> ...`----

That doesn't tell me anything that I see as addressing my problem. Can you
explain how that answers my question as to why the two symbols were not
comparing as I had expected?

 (type-of gl-type) was what showed me what I was doing wrong.  I tried to
post back to the newsgroup, but my ISP was down.

-- 
p->m == (*p).m == p[0].m

Re: What is the type of user input?

[Kevin Rodgers]

Hattuari wrote:
 > Kevin Rodgers wrote:
 >>gl-type is a string.  Since the paste-gl-type-map property list is keyed
 >>by symbols, plist-get returns nil.
 >
 > That's what I was missing.  I was assuming that 'symbol-name implicitly
 > meant symbol would evaluate to a string.  Now that I've read the first
 > several chapters of the Elisp Reference Manual, I have a better idea of
 > what's going on.

'foo is equivalent to (quote foo), which is the symbol whose name is
"foo".

The symbol-name name function takes a symbol and returns its name
string, and the intern function takes a string and returns the symbol
with that name.

 >>The %s message specifier can be
 >>applied to any Lisp object, and symbols and strings are formatted the
 >>same.
 >>
 >>The solution is to either (1) read gl-type with the %S code or (2) call
 >>plist-get with (intern gl-type).
 >
 > I opted for trying an association array, which also worked.

I assume you mean association list.  But whether you have a (KEY-1
VALUE-1 ... KEY-N VALUE-N) property list where they keys are by
definition symbols or a ((KEY-1 . VALUE-1) ... (KEY-N . VALUE-N)) alist
where the keys can be arbitrary lisp objects, you still have to make
sure that you pass a key of the correct type to plist-get or assoc,
respectively.

 > I will try your suggestion of using (intern gl-type).  As for reading
 > gl-type with %S, I'm not sure what that would do for me.  The only use
 > I know for that is to use it in a string format.

Oops, I meant S.  (You used s in the interactive spec to read gl-type as
a string; using S would bind gl-type to the intern'ed symbol.)

 >> > OTOH, when I evaluate this expression in an emacs-lisp buffer
 >> > (paste-gl-array 'GLbyte 4 'v), I see the following in the echo area:
 >> >
 >> > gl-type=GLbyte, gl-components=4, gl-vector=v , suffix=b
 >> >
 >> > That is the desired result.  Why is this not the result of calling the
 >> > function as an interactive command as described above?
 >> >
 >> > I will continue to look for an answer in the documentation, but any
 >> > help from someone who knows the answer would be appreciated.
 >>
 >>It's not that hard to find:
 >>
 >>`C-h f message' has a link to the doc string for `format', which has a
 >>link to the doc string for `princ' in its description of %s:
 >>
 >>,----[ C-h f princ RET ]
 >>| princ is a built-in function.
 >>| (princ OBJECT &optional PRINTCHARFUN)
 >>|
 >>| Output the printed representation of OBJECT, any Lisp object.
 >>| No quoting characters are used; no delimiters are printed around
 >>| the contents of strings.
 >>|
 >>| OBJECT is any of the Lisp data types: a number, a string, a symbol,
 >>| a list, a buffer, a window, a frame, etc.
 >>|
 >>| A printed representation of an object is text which describes that
 >>| object.
 >>...`----
 >
 >
 > That doesn't tell me anything that I see as addressing my problem. 
Can you
 > explain how that answers my question as to why the two symbols were not
 > comparing as I had expected?

You assumed that since the symbol and the string looked the same when
displayed in the echo area by (message "%s" ...), that they were
actually the same.  The message -> format -> princ doc strings explain
that a symbol and its name string will be displayed the same by (message
"%s"), even though they are different objects of different types.

 >  (type-of gl-type) was what showed me what I was doing wrong.  I tried to
 > post back to the newsgroup, but my ISP was down.

-- 
Kevin Rodgers

Re: What is the type of user input?

[Hattuari]

Kevin Rodgers wrote:

> Hattuari wrote:
>  > Kevin Rodgers wrote:
>  >>gl-type is a string.  Since the paste-gl-type-map property list is
>  >>keyed by symbols, plist-get returns nil.
>  >
>  > That's what I was missing.  I was assuming that 'symbol-name implicitly
>  > meant symbol would evaluate to a string.  Now that I've read the first
>  > several chapters of the Elisp Reference Manual, I have a better idea of
>  > what's going on.
> 
> 'foo is equivalent to (quote foo), which is the symbol whose name is
> "foo".

That's what the book says.

>  > I opted for trying an association array, which also worked.
> 
> I assume you mean association list. 

Yes.  I'm accustomed to thinking in terms of associative arrays, and I guess
force of habit got the better of me.

> But whether you have a (KEY-1 
> VALUE-1 ... KEY-N VALUE-N) property list where they keys are by
> definition symbols or a ((KEY-1 . VALUE-1) ... (KEY-N . VALUE-N)) alist
> where the keys can be arbitrary lisp objects, 

Actually, according to the documentation the key can be  


,----[ §8.4 Property Lists ]
|  The property names and values in a property list can be any Lisp
|  objects, but the names are usually symbols.
`----

> you still have to make
> sure that you pass a key of the correct type to plist-get or assoc,
> respectively.

In the case of plists I guess that's a direct consequence of the requirement
that the key used for lookup has to be the actual object used as the key in
the plist.

>  > I will try your suggestion of using (intern gl-type).  As for reading
>  > gl-type with %S, I'm not sure what that would do for me.  The only use
>  > I know for that is to use it in a string format.
> 
> Oops, I meant S.  (You used s in the interactive spec to read gl-type as
> a string; using S would bind gl-type to the intern'ed symbol.)

Can you provide a reference in the documentation where this use of 'S' is
described?  The only places I'm aware of where 'S' is used as a means of
handling data associated with interactive forms is in formatting strings.
>  > That doesn't tell me anything that I see as addressing my problem.
> Can you
>  > explain how that answers my question as to why the two symbols were not
>  > comparing as I had expected?
> 
> You assumed that since the symbol and the string looked the same when
> displayed in the echo area by (message "%s" ...), that they were
> actually the same. 

No.  What I assumed is that a quoted symbol would evaluate to a string when
looking for keys in a plist. 

-- 
p->m == (*p).m == p[0].m

Re: What is the type of user input?

[Johan Bockgård]

Hattuari <susudata@setidava.kushan.aa> writes:

> Kevin Rodgers wrote:

>> Oops, I meant S. (You used s in the interactive spec to read
>> gl-type as a string; using S would bind gl-type to the intern'ed
>> symbol.)
>
> Can you provide a reference in the documentation where this use of
> 'S' is described? The only places I'm aware of where 'S' is used as
> a means of handling data associated with interactive forms is in
> formatting strings.

C-h f interactive
or at (info "(elisp)Interactive Codes")

-- 
Johan Bockgård