你写过自己深奥的（或没有）语言吗？它看起来像什么？
我看到了一些关于 stackoverflow 用户最喜欢的深奥（或不是）编程语言的问题。还有关于语言实施的问题。然而，我很好奇你们中是否有人真正编写过自己的编程语言（无论是否深奥），而且我也想知道它是什么样的。
我喜欢阅读并尝试学习新的、有创意的语言，所以我认为看到 stackoverflow 社区提供的内容会很高兴。 :)
几年前，我为了好玩而写了一篇。
I've seen a few question regarding stackoverflow users' favorite esoteric (or not) programming languages. There are also questions regarding the implementation of languages. However, I was curious to see if any of you have actually written your own programming language (be it esoteric or not) and I also wanted to know what it looks like.
I enjoy reading about and trying to learn new and inventive languages, so I thought it would be nice to see what the stackoverflow community has to offer. :)
I wrote one for fun a few years ago.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我编写了一套 7 种“微”语言用于教学。每一种语言都旨在说明以下完整编程语言之一的关键思想：
这些语言故意看起来彼此非常相似，以便学生只能看到本质区别，而永远不会看到无偿的。我想做另外两个，基于 Haskell 和 CLU。
Sam Kamin 提出了最初的想法，并为设计提供了很多帮助。
I have written a set of 7 "micro" languages for teaching. Each one is meant to illustrate the key ideas of one of the following full programming languages:
The languages deliberately look very much one like the other, so that students see only essential differences, never gratuitous ones. I want to do two more, based on Haskell and CLU.
Sam Kamin had the original idea and helped a lot with the design.
当然，我的蟒蛇细菌的操作码
The opcodes of my pythonic bacteria, of course
我一直在断断续续地研究 DIFL，它的目的是作为一种声明性文本冒险语言，但随着时间的推移，声明性变得越来越弱。其主要特点是非常松散的对象系统和基于多方法的动作系统。 （好吧，它的主要特点是，假设我完成了它。）
I've been working off and on on DIFL, intended as a declarative text adventure language, but becoming less declarative over time. Its main features are a very loose object system and an action system based on multimethods. (Well, its main features will be, assuming I ever finish it.)
我尝试编写的第一种语言是 MIDI 文件汇编语言。您可以定义速度和乐器库，然后定义许多音符线（音符名称、当前小节的起始节拍、持续时间、可选重音），并用小节线（“meas\n”）标点，以及动态（ppp、pp、p、mp、mf、f、ff、fff）。
如果没有宏语言来重复序列、更改频道和铺设新曲目，它就无法真正使用。这需要我的第一个哈希表，以及对 qsort 的狡猾的交叉手指调用，以按时间顺序交错通道（由每个音符打开/音符关闭事件隐式携带）。
一年后当我再次看到它时，它已经成为位腐烂的受害者。经过一番努力，我重新发现排序和输出所有内容函数是由显式 EOF 代码触发的。一首宏观扩展的歌曲很容易就有 20,000 行，其中关键的 EOF 行，因此，当试图找出到底出了什么问题时，有 1/20000 的机会被发现！
我有点高兴的是，所有证据都安全地藏在微波炉车下方的死 CPU 中。恐怖！！
编辑：经过进一步思考，MIDI 格式有一些有趣的事情。它具有可变长度整数类型（IIRC 使用符号位来表示最后一个字节）。它是面向字节的，设计用于在 9 条并行线上运行；它有一些我从未理解的疯狂的时间同步功能。但我所关心的是 Windows95 媒体播放器可以解释输出（它甚至可以使用声卡内置的 8 位通用 MIDI 音调库；铙钹的失真效果非常好）。
One of the first languages I tried to write was a MIDI-file assembly language. You'd define tempo and instrument bank and then lots of note lines (Note-name, starting-beat-of-the-current-measure, duration, optional accent), punctuated by bar lines ("meas\n"), and dynamics (ppp,pp,p,mp,mf,f,ff,fff).
It wasn't really usable without a macro language to repeat sequences, change channels, and lay down new tracks. That required my first hash table, and a tricksy cross-your-fingers call to qsort to interleave the channels by time-sequence (implicitly carried by each Note-On/Note-Off event).
When I came back to it a year later, it had fallen victim to bit-rot. After no small struggle I rediscovered that the sort-and-output-everything function was triggered by an explicit EOF code. A macro-expanded song was easily 20,000 lines with that crucial EOF line having, therefore, 1/20000th of a chance to be spotted when trying to figure out just what in the heck is going wrong!
I am somewhat pleased that all the evidence is safely tucked away in a dead CPU underneath the microwave cart. The horrors!!
Edit: Upon further reflection there are some interesting things about the MIDI format. It has a variable-length integer type (IIRC using the sign bit to signal the last byte). It's byte-oriented, being designed to run over 9 parallel wires; and it has some crazy time-synchronization thing I never understood. But all I cared about was that the Windows95 media player could interpret the output (it could even use the 8bit General MIDI tone bank built into the sound card; the cymbals were gloriously distorted).