In elisp, symbols serve as fundamental data structures that are more foundational compared to strings. This distinction often caused confusion for me until my encounter with the read function.
~ $ (type-of (read))
symbol
The fact that the read function yields symbols instead of strings from user-input was a delightful revelation. This discovery convinces me that the fundamental nature of symbols in elisp when compared to strings.
(read)returns whatever the type of its input was. If you enter a string literal it returns a string, if you enter a symbol literal it returns a symbol, if you enter a numeric literal it returns a number, etc.Interesting. It’s intelligent capability to discern and identify numbers, strings, and symbols. What I tried is to feed to minibuffer word string.
So you have called:
You have just created a temporary symbol named “string”. You can try this to see for yourself:
If you want a string object out of “string”, you will have to quote it in the minibuffer too:
I think you should have not downvoted /u/lispm below (or whomever it was); he has given a few very good questions to get you going on in exploring those things on your own.
Etc, etc…
The lisp reader reads text and it produces lisp objects of various types (which might later be evaluated as code).
I assume the read function initially reads the input as a symbol type, and subsequently, during the evaluation process, converts it into the corresponding data type. This two-step process involves reading the input as a symbol and then evaluating it to obtain the appropriate type.
Not necessarily. If any group of things are the fundamental data types, it’s probably “streams” and “code”.
(read) still reads the input character by character, just like any other language. The difference in Lisp languages is that, rather than simply collecting those characters into a vector and calling it a “string”, it’s incrementally parsing the input as code through the language compiler while reading it in.
The default mode of the compiler is to interpret code as lists (as in the list data type) of either lists or symbols (this is, obviously, a massive oversimplification of the details). So (read), which treats input as code, by default interprets a single-word normal text input as a symbol.
On the other hand, in the case of strings, the Lisp reader reads in a ‘“‘, which triggers a ”string mode” (a reader macro, if you’re familiar with Lisp terminology) that collects characters until the next ‘“‘ character and then stores them in a vector wrapped in a String object. Similarly, if a ‘word’ in the input is purely made of digits, then instead of making a symbol most Lisp interpreters (including Emacs Lisp) convert it into a number object of some sort.
So besides being the default, symbols and lists aren’t necessarily special. What is special is that all instances of (read) involve a text input (a stream of characters) being parsed into a data structure in code.
The fact that this is the behavior of the default reading function (there are other functions if you want to get just string input) is an instance of the fundamental nature of all Lisps: there is no difference between data and code, and so we should be able to treat data as code and code as data without friction. This is one of the key features of all Lisp languages, and an inherent advantage of their structure in comparison to other modern forms of human-computer interaction.
Why would you assume that?
That’s not correct.
Does that mean whatever revelation OP might’ve had was misunderstanding?