理由
根据我自己的经验和观察Slack中的新手频道，对于初学者来说最常见的一个错误是他们想知道如何将字符串解析为整数。
这出错了有多种方式
- 人们发现了
int函数，其文档字符串为转换为整数 —— 当传入一个字符串时抛出异常。
- 有人建议使用
Integer/parseInt，它可以完成这项工作，但不能用作(map Integer/parseInt coll-of-strings) —— 这是令人惊讶的，因为他们是第一次体验Java互操作。
- 有人建议使用
#(Integer/parseInt %)，它执行预期的操作，但其语法对于您的Clojure最初的10分钟来说可能有点多。
- 有时人们建议使用
#(Integer. %)，这在Java 11中已弃用。
- 人们在ClojureScript中也经历了相同的流程，并必须选择不同的互操作方式来完成此操作。
提议1
考虑在Clojure中添加一个parse-*函数族，它是Java互操作的薄包装。请参见附录中可能的列表。
提议2
考虑将clojure.lang.LispReader.matchNumber暴露为parse-number。
人们可以使用各种转换函数来获取所需精度。这可能更适合这个条目的理性，即使非常常见的“玩具程序”操作对初学者来说更加顺畅，并且与Reader的行为匹配将是做事最不会令人惊讶的事情。
对于性能比较敏感的人应该已经了解了JVM上装箱算术的复杂之处。这也非常平台无关，CLJS可以暴露match-number。
问题/替代方案
- 函数应该返回原始值还是装箱值？
- 对于像〈code>"0xff"〈/code>这样的字符串应该怎么处理？
parseFoo函数族的函数拒绝这些，但是〈code>0xff〈/code>可以被Clojure读取器读取。
- 另一方面，《code>decode〈/code>函数族处理某些前缀，但它们返回装箱值。但它们也接受诸如〈code>#10〈/code>这样的无效Clojure字面量。
附录
以下是（截至JVM 8）的一个希望完整的返回原始值的函数列表
name args ret-value
parse-int s int
parse-int s, radix int
parse-uint s int
parse-uint s, radix int
parse-long s long
parse-long s, radix long
parse-ulong s long
parse-ulong s, radix long
parse-short s short
parse-short s, radix short
parse-byte s byte
parse-byte s, radix byte
parse-float s float
parse-double s double
无符号功能是在Java 8中添加的，因此可以在较新的Clojure版本中安全使用。较新的JVM版本添加了对解析CharacterSequence部分的支援。
