this post was submitted on 17 Oct 2023
3 points (100.0% liked)
Emacs
314 readers
2 users here now
A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!
Get Emacs
Rules
- Posts should be emacs related
- Be kind please
- Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.
Emacs Resources
Emacs Tutorials
- Beginner’s Guide to Emacs
- Absolute Beginner's Guide to Emacs
- How to Learn Emacs: A Hand-drawn One-pager for Beginners
Useful Emacs configuration files and distributions
Quick pain-saver tip
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
(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.Does that mean whatever revelation OP might've had was misunderstanding?
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.
That’s not correct.
Why would you assume that?
Interesting. It’s intelligent capability to discern and identify numbers, strings, and symbols. What I tried is to feed to minibuffer word string.
Etc, etc...
The lisp reader reads text and it produces lisp objects of various types (which might later be evaluated as code).
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.