It's symbols not strings are fundamental data type, an insight from read.
It's symbols not strings are fundamental data type, an insight from read.
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.
You're viewing a single thread.
(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.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.
Interesting. It’s intelligent capability to discern and identify numbers, strings, and symbols. What I tried is to feed to minibuffer word string.