编译语言可以同音吗？

10 回答

• 0

  机器代码本身是同质的，所以是的 .

  数据或指令只是语义问题（也许是它们所处的内存段） .

  回复于 2024-04-26T04:30:56+08:00
• 1

  问题是许多处理器将指令和数据区分开，并主动阻止程序修改自己的代码 . 这种代码曾被称为“退化代码”，并被认为是一件非常糟糕的事情 .

  解释器（和VM）没有这个问题，因为他们可以将整个程序视为数据，唯一的“代码”是解释器 .

  回复于 2024-04-26T04:30:56+08:00
• 1

  是;你只需要将编译器的副本粘贴到语言运行库中 . Chez Scheme是众多优秀的编译器之一 .

  回复于 2024-04-26T04:30:56+08:00
• 2

  在最文字的形式中，C是同质的 . 您可以使用 &functionName 访问函数的表示，并使用 somePtrCastToFnPtr(SomeArgs) 执行数据 . 然而，这是在机器代码级别，如果没有某种类型的库支持，您将发现很难使用它 . 某种可嵌入的编译器（我似乎记得LLVM可以做到这一点）会使它更实用 .

  回复于 2024-04-26T04:30:56+08:00
• 2

  Lisp通常是编译的 . 已经实现了JIT编译器而不是解释器 .

  因此，没有必要为代码是数据语言提供解释器（在“不是编译器”的意义上） .

  回复于 2024-04-26T04:30:56+08:00
• 1

  对我来说似乎是一个奇怪的问题：

  首先，homoiconic部分是程序员提供的接口 . 语言的要点是它们抽象了一个较低级别的功能，它保留了与更高级别的表示相同的语义（虽然是一种不同的方式） .

  dsm的机器码点是一个好点，但提供：

  • 所呈现的语法和语义是同音的

  • 转换为较低级别的表单（机器代码或解释或其他方式）不会删除任何原始语义然后

  why does the lower level implementation matter here?

  也：

  没有编译时解释器的编译语言

  如果没有一些程序解释它，它将需要是CPU的本机语言，因此CPU的本机语言将需要是homoiconic（或运行代码的VM） .

  没有编译时解释的语言......会受到相当限制......因为它们不会 be compiled at all .

  但我不是专家，也许错过了重点 .

  回复于 2024-04-26T04:30:56+08:00
• 3

  'Homoiconic'是一种模糊的结构 . '代码是数据'有点清楚 .

  无论如何，维基百科的Homoiconic上的第一句话并不那么糟糕 . 它说 the language has to have a source representation using its data structures . 如果我们忘记'strings'作为源代表（那是's trivial and not that helpful to have a useful concept ' homoiconic '), then Lisp has lists, symbols, numbers, strings etc. which are used to represent the source code. The interface of the EVAL function determines what kind of source representation the language is working on. In this case, Lisp, it is not strings. EVAL expects the usual variety of data structures and the evaluation rules of Lisp determine that a string evaluates to itself (and thus will not be interpreted as a program expression, but just string data). A number also evaluates to itself. A list (sin 3.0) is a list of a symbol and a number. The evaluation rules say that this list with a symbol denoting a function as the first object will be evaluated as a function application. There are a few evaluation rules like this for data, special operators, macro applications and function applications. That' s .

  说清楚： in Lisp the function EVAL is defined over Lisp data structures . 它期望数据结构，根据其评估规则对其进行评估并返回结果 - 再次使用其数据结构 .

  这与homoiconic的定义相匹配：源代码使用Lisp的数据类型具有本机表示 .

  现在，有趣的部分是： it does not matter how EVAL is implemented . 重要的是它使用Lisp数据结构接受源代码，它执行代码并返回结果 .

  所以 it is perfectly legal that EVAL uses a compiler .

  (EVAL code)  =  (run (compile-expression code))
  

  这就是几个Lisp系统的工作方式，有些甚至没有解释器 .

  因此，'Homoiconic'表示SOURCE代码具有数据表示 . 它并没有说在运行时必须解释此源代码或执行基于此源代码 .

  If the code is compiled, neither the compiler nor an interpreter is needed at runtime . 只有当程序想要在运行时评估或编译代码时才需要这些 - 这通常是不需要的 .

  Lisp还提供了一个原始函数 READ ，它将数据的外部表示（S-Expressions）转换为数据的内部表示（Lisp数据） . 因此，它还可以用于将源代码的外部表示转换为源代码的内部表示 . Lisp不对源代码使用特殊的解析器 - 因为代码是数据，只有READ .

  回复于 2024-04-26T04:30:56+08:00
• 2

  是 . lisp可以编译为本机二进制文件

  回复于 2024-04-26T04:30:56+08:00
• 35

  编译只是优化的解释 . 解释器接受表示代码的数据，然后“执行”该代码：代码的含义变成执行路径和数据流通过解释器的内容 . 编译器获取相同的数据，将其转换为另一种形式，然后将其传递给另一个解释器：一个在硅（CPU）中实现，或者可能是伪造的（虚拟机） .

  这就是为什么一些Lisp实现不能有解释器 . EVAL函数可以编译代码然后分支到它 . EVAL和COMPILE不必具有不同的操作模式 . （Clozure，Corman Lisp，SBCL是“仅编译器”Lisps的例子 . ）

  开头的数据部分是语言同音的关键，而不是代码的执行是否通过编译进行优化 . "Code is data"表示“源代码是数据" not "可执行代码是数据” . （当然可执行代码是数据，但是数据我们指的是我们想要操作的代码的压倒性优选表示 . ）

  回复于 2024-04-26T04:30:56+08:00
• 8

  构建在VM（.net clr，jre ect）之上的语言可以使用允许快速生成代码的高级技术 . 其中之一是IL编织 . 虽然它不像ECMAScript / Lisp / Scheme等的eval那样清晰，但它可以在某种程度上模仿这种行为 .

  例如，检查Castle DynamicProxy以及更多交互式示例，检查LinqPAD，F＃Interactive，Scala interactive .

  回复于 2024-04-26T04:30:56+08:00