preface
I have been thinking about how to understand or translate a pure English document for Native Chinese speakers, or what are the obstacles in reading English documents? Vocabulary? We have dao. Grammar? Unlike some literary works, English documents do not have a particularly complex syntax, because recently I wanted to build a code parser and needed a parser to help. I saw the project Acorn in webpack dependency, not to mention the later project on code analysis using Acorn. I tried translating the README and found some problems 😑
Acorn.js/readme.md translate content
Introduction to the
Acorn is a slick and efficient JavaScript syntax parser written entirely in JavaScript
A Tiny, fast JavaScript Parser, written Completely in JavaScript. The direct translation is “a small, fast JavaScript parser, written entirely in JavaScript.” I don’t know how foreigners feel about the original text
Package structure
There are three main packages in the repository
- Acorn: Primary parser
- Acorn-loose: An error-tolerant parser
- Acorn-walk: Walker & Worker for syntax trees
This part of the question is mainly the interpretation of acorn-loose error-tolerant.
As for the acorn-walk walker, you can’t find the specific meaning of this word in Chinese translation. If explained in Chinese, this walker operates on each node of the syntax tree, recursively or iteratively, just like walking along the tree, with the meaning of traversal. But it also lacks the meaning of “work”, so the Chinese is difficult to understand… I can only think about it in English
Plug-in development pattern
First translation
Acorn is designed to support plugins which can, within reasonable bounds, redefine the way the parser works. Plugins can add new token types and new tokenizer contexts (if necessary), and extend methods in the parser object. This is not a clean, Elegant API — Using it requires an understanding of Acorn’s internals, and plugins are likely to break whenever those internals are significantly changed. But still, it is possible, in this way, to create parsers for JavaScript dialects without forking all of Acorn. And in principle it is even possible to combine such plugins, so that if you have, for example, a plugin for parsing types and a plugin for parsing JSX-style XML literals, you could load them both and parse code with both JSX tags and types.
Acorn is designed to support the definition of plug-ins to the extent that it is reasonable to redefine how parsers work. Plugins can add new lexics and lexers (if necessary), and extend new methods on parser objects. This doesn’t sound like a clean and elegant API. To use it, you have to know the internals of Acorn very well, and plugins are likely to crash whenever those internals change significantly. But even so, I think it’s a very effective way of doing this, where when we want to create a parser for a dialect of JavaScript, we don’t have to copy the whole Acorn, and in principle, we can even put together a couple of plug-ins, if you will, For example, if you have a plug-in for parsing types and another plug-in for parsing JSX-style XML tags, you can read them both and parse them into JSX tags and types
This part is more interesting, the first translation down, I think I completely follow the content of the original, but read through will feel very uncomfortable, always feel like a robot… Maybe that’s the nature of the machine, no emotion, no soul
Acorn used plug-ins to redefine the way the parser worked. With plug-ins, we could add new lexicographical and lexical parsers, and we could add methods to extend the parser as we wanted, but this was done through a less-clean and elegant API. This means that it is necessary for developers to be aware of the internal implementation of Acorn and be prepared for plug-ins to become unavailable, especially if the internal implementation changes significantly. In this way we can flexibly combine plug-ins to implement a JavaScript DSL parser, such as two plug-ins for JSX and Types.
So I reorganized the above Chinese content to make it sound like a person
Then I tried to translate the second paragraph with Youdao Translation and the result was like this
A plugin is a function from a parser class to an extended parser class. Plugins can be used by simply applying them to the Parser class (or a version of that already extended by another plugin). But because that gets a little awkward, syntactically, when you are using multiple plugins, the static method Parser.extend can be called with any number of plugin values as arguments to create a Parser class extended by all those plugins. You’ll usually want to create such an extended class only once, and then repeatedly call parse on it, to avoid needlessly confusing the JavaScript engine’s optimizer.
Then I found another problem, that is, the same Chinese language is similar to machine translation without emotion. When I look at the content of My translation, I feel that it is word by word, but when I look at the content of Youdao translation, all these contents are a picture in my mind, similar to a block of unrelated words
This self test, let me realize hand by hand or typed words left traces in the brain or less the same, but in line with the unfeeling machine turned his dry efficiency is too low, so I want to do another experiment, if direct the restructuring youdao translation of words I could understand what influence the original English to me?
So I tried to understand the results of Youdao translation in depth, em…. , and do fine tuning for the machine
A plug-in is a function that extends the parser class from the parser class. You can use a plug-in by simply applying it to a parser class (or an extended version of another plug-in). But this is a little awkward, syntactically speaking, when you use multiple plug-ins, Parser.extend This static method may be called with any number of plug-in values as arguments to create a Parser class that is extended by these plug-ins. You should usually create such an extension class once and parse it repeatedly. To avoid unnecessary interference with the JavaScript engine optimizer
As always, there is no emotion, but I really do not understand the first sentence, so I combined the following example to restructure
const {Parser} = require("acorn")
const MyParser = Parser.extend(
require("acorn-jsx") (the),require("acorn-bigint"))console.log(MyParser.parse("// Some bigint + JSX code"))
Copy the code
module.exports = function noisyReadToken(Parser) {
return class extends Parser {
readToken(code) {
console.log("Reading a token!")
super.readToken(code)
}
}
}
Copy the code
A plugin is a function that contains a class inherited from Parser. It’s very easy to use a plugin. You can use the parser. extend method to integrate all the plugins you need. It is recommended that related plug-ins be merged together to avoid unnecessary interference with the JavaScript engine optimizer
There’s a bit of confusion here, but I think I need to dig a little deeper into the source code to understand what the authors are trying to do with the parser. extend proposal
The latter
I tried to summarize the process of reading technical documents in English
- Original text → machine translation (if the machine translation is not human flesh needs to be corrected manually)
- Machine translation → readable text (readable not necessarily understandable)
- Readable text → understandable text (some of the questionable readable content needs a deeper understanding, so as to rearrange the programmatically understandable content)
This process is very different from what we usually think of as dyslexia, which is reading technical documents in English
- vocabulary
- grammar
- English comprehensive level
But in fact
- Machine translation can solve the vocabulary problem, provide efficient machine translation, even if your English level is very high, still need to first machine translation and understanding, considering the English level of most people, the efficiency of the dictionary machine translation is much higher than your own, so vocabulary is not an obstacle
- As for syntax, syntax in documents is generally not complex enough to be solved by machine translation, so it is not a barrier
- English comprehensive level, with professional English level of people can not translate these content, read a lot of translation books should have this experience.
So, true dyslexia
- Degree of vocabulary accumulation of technical concepts
- The ability to quickly correct text by machine
- For machine translation language refining ability, refining to readable and understandable ability
Therefore, it is not your English level that prevents you from reading English technical documents, but your natural fear of English plus poor Chinese organization skills. Overcome the fear and practice Chinese writing. Most mute English patients can read English technical documents smoothly.