【问题标题】:Why does Clojure lack user defined reader macros?为什么 Clojure 缺少用户定义的阅读器宏?
【发布时间】:2015-12-03 20:37:04
【问题描述】:

据我了解,Clojure 不会公开阅读器宏表或允许用户定义阅读器宏。

来自http://clojure.org/reader

The read table is currently not accessible to user programs.

我只是想知道是否有明确或明确的声明(可能来自 Rich Hickey)说明将它们排除在 Clojure 之外的理由。

注意,我不是询问 Clojure 缺少用户定义的阅读器宏是好事还是坏事。只是想知道为什么。

【问题讨论】:

标签: clojure language-design reader-macro


【解决方案1】:

来自 matt 的 cmets 中的 link,引用 Clojure 的作者 Rich Hickey 的回答:

我不相信 Clojure 需要读取器宏 时间。它们大大降低了使用它们的代码的可读性(通过 了解 Clojure 的人),鼓励不兼容的自定义 mini- 语言和方言(与命名空间分区的宏相比),以及 复杂的加载和评估。

在我愿意满足不同的共同需求的范围内 我自己的(例如正则表达式),我认为很多东西本来会有 强迫人们阅读宏可能最终会出现在 Clojure 中,每个人都在这里 可以从一个共同的方法中受益。

Clojure 可以说是一种非常简单的语言,并且在这种简单性中 存在着一种不同的力量。

我现在要继续追求这个,

丰富

【讨论】:

    【解决方案2】:

    直言不讳,Tagged Literals 允许您指定如何处理下一个表单。例如,您可以添加

    {to/u clojure.string/upper-case}
    

    data_readers.clj(请参阅文档)并写下这样的内容:

    testapp.core> #to/u "asd"
    "ASD"
    

    但它没有完全支持阅读器宏那么强大,至少是因为 The data reader function is invoked on the form AFTER it has been read as a normal Clojure data structure by the reader.

    我找到了这个旧日志(不要问我是怎么找到的) http://clojure-log.n01se.net/date/2008-11-06.html

    这里讨论了 Rich Hickey 关于阅读器宏的想法。

    【讨论】:

      猜你喜欢
      • 2011-09-19
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2010-11-21
      • 1970-01-01
      • 1970-01-01
      • 2017-10-22
      • 2014-02-17
      相关资源
      最近更新 更多