blocks|key|1105354|text|APL早在文件系统和文本编辑器广泛提供之前就发明了。因此，它提供了自己的工具来存储和编辑代码(函数)和数据，即工作区和组件文件。今天的大多数商用APL系统仍然提供它们，以便与现有的安装和开发人员的专业知识保持连续性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1105355|但这些设施可以追溯到半个世纪前，是为当时的硬件和接口(大型机和电传)设计的，与现代硬件一样，手摇电话也适用于智能手机。|1105356|现在，大多数开发人员都认为代码最好保存在(UTF-8编码的)文本文件中，用选择的文本编辑器编辑，并使用分布式版本控制系统进行管理。我当然同意这个看法。|offset|length|1105357|一些经典的APL供应商在这方面保持了他们的最新报价，并提供了处理源代码文件的工具，希望不要太脱离工作空间。Dyalog有这样一个名为SALT+-简单APL库工具包的库。|1105358|但事实是，大多数APL系统没有一个简单的命令或函数来加载源文件，因为它在实践中根本没有使用。APL开发人员认为他们的APL系统是一个IDE，几乎是一个操作系统。它们将所有内容保存在工作空间中，只使用系统提供的编辑窗口。|1105359|IMHO较新的APL实现(如GNU+APL和其他实现)最终将拒绝工作区的概念，并与“现代”实践保持一致。但这只是我的观点，大多数APL程序员肯定不认同这个观点。问他们中的任何一个，你就会听到类似这样的消息：≪，当你从我冰冷、死气沉沉的手指上撬开它们时，你可以得到我的工作空间和组件文件。|1105360|entityMap|0|LINK|mutability|MUTABLE|url|http://www.sublimetext.com/|1|http://docs.dyalog.com/12.1/SALT.pdf|2|https://www.gnu.org/software/apl/^0|0|0|11|8|0|0|1U|F|1|0|0|E|7|2|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@$F|12|G|13|1|14]]|A|$]]|$1|H|3|I|5|6|7|15|8|@]|9|@$F|16|G|17|1|18]]|A|$]]|$1|J|3|K|5|6|7|19|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1A|8|@]|9|@$F|1B|G|1C|1|1D]]|A|$]]|$1|N|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]|V|$5|Q|R|S|A|$T|W]]|X|$5|Q|R|S|A|$T|Y]]]]

APL was invented well before the widespread availability of file systems and text editors. Therefore it provided its own facilities to store and edit code (functions) and data, namely Workspaces and Component files. Most commercial APL systems of today still provide them, for continuity with existing installations and with developer expertise.

But those facilities date back to half a century ago and were designed for the hardware and interfaces of the time (mainframes and teletypes) which are to modern hardware as hand crank telephones are to smartphones.

Nowadays most developers would argue that code is best kept in (UTF-8 encoded) text files, edited with <a href="http://www.sublimetext.com/" rel="nofollow">one's text editor of choice</a>, and managed with a distributed version control system. I certainly subscribe to this view.

Some of the classical APL vendors have kept their offers "up to date" in this regard and provide facilities to deal with source code files, in a manner hopefully not too disjoint from workspaces. Dyalog APL has such a library called <a href="http://docs.dyalog.com/12.1/SALT.pdf" rel="nofollow">SALT - Simple APL Library Toolkit</a>.

But the truth is, most APL systems don't have an easy command or function to load a source file because it's simply not used in practice. APL developers regard their APL system as an IDE, almost an OS. They keep everything inside workspaces and just use the editing windows provided by the system.

IMHO newer APL implementations (such as <a href="https://www.gnu.org/software/apl/" rel="nofollow">GNU APL</a> and others) will eventually reject the concept of workspaces and align themselves with "modern" practices. But this is just my view, which is certainly not shared by the majority of APL programmers. Ask any of them about it and you will hear something along the lines of: ≪You can have my workspaces and component files when you pry them from my cold, dead fingers.≫

blocks|key|103140|text|@Tobia在总体上已经给出了一个很好的答案，但是我想补充一些关于GNU+APL和埃马克斯可以做什么的细节。使用GNU+APL模式+for+Emacs+(我是此模式的作者)，您可以将APL代码保存在源文件中(具有.apl扩展名)，并直接从文件执行代码。还有一些基本的代码导航功能(M-.移动到定义函数的位置)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|103141|仍然有工作要做，以改善的事情，但我希望得到评论，哪些功能，人们会希望看到补充。|103142|entityMap|0|LINK|mutability|MUTABLE|url|http://www.gnu.org/software/apl/|1|http://www.gnu.org/software/emacs/|2|https://github.com/lokedhs/gnu-apl-mode^0|2Y|4|3W|3|X|7|0|15|4|1|1K|9|2|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@$9|Y|A|Z|1|10]|$9|11|A|12|1|13]|$9|14|A|15|1|16]]|E|$]]|$1|F|3|G|5|6|7|17|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|18|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]|P|$5|K|L|M|E|$N|Q]]|R|$5|K|L|M|E|$N|S]]]]

@Tobia already gave a good answer regarding APL in general, but I would like to add some details concering what you can do with <a href="http://www.gnu.org/software/apl/" rel="noreferrer">GNU APL</a> and <a href="http://www.gnu.org/software/emacs/" rel="noreferrer">Emacs</a>. With the <a href="https://github.com/lokedhs/gnu-apl-mode" rel="noreferrer">GNU APL mode</a> for Emacs (I am the author of this mode) you can keep APL code in source files (with the <code>.apl</code> extension) and execute code directly from the files. There is also some basic code navigation features (<code>M-.</code> moves to the location where a function was defined).

There is still work to be done to improve things but I would love to get comments as to what features people would want to see added.

blocks|key|103148|text|Dyalog+14.0为脚本提供了命令行选项。在类似Unix的平台上，可执行脚本文件的第一行可以是|type|unstyled|depth|inlineStyleRanges|entityRanges|data|103149|#!/path/to/dyalog+-script|code-block|syntax|javascript|103150|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Dyalog 14.0 has a command line option for scripts. On a Unix-like platform the first line of an executable script file could be

<pre><code>#!/path/to/dyalog -script
</code></pre>

blocks|key|1105562|text|不，APL工作区从来没有一个文件类型。APL过去和现在都非常依赖于供应商--每个供应商都有自己的内部格式和工作空间的文件扩展名。一些扩展是.DWS、.W3、.WS，仅举几个例子。撇开APL语言特性不谈，各厂商使用的专有内部格式有很大的不同，而且非常不兼容。此外，较新的APL解释器可能无法打开超过某个年份的旧工作区，例如，较新的Dyalog+16.0解释器将无法打开Dyalog版本8.0保存的工作区。APL%2B2000也是如此。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1105563|顺便说一句，对于同一个供应商的工作区，我能想到的唯一的系统级兼容性是大型机IBM+APL2中的)MCOPY命令，其中APL2可以直接读取旧的VSAPL工作区。否则，就会有很多优秀的APL迁移软件来处理这个问题。|1105564|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

No, there was never a single file type for APL workspaces. APL was always and still is very vendor-dependent - each vendor had its own internal format and file extensions for workspaces. Some extensions were .DWS, .W3, .WS, just to name a few. APL language features aside, the proprietary internal formats used by the various vendors were profoundly different and wildly incompatible. Further, a newer APL interpreter might be unable to open an older workspace past a certain vintage, for example, a newer Dyalog 16.0 interpreter would be unable to open a workspaces saved with Dyalog Version 8.0. The same was true with APL+2000.

Offhand, the only system-level compatibility I can think of for workspaces from the same vendor was the )MCOPY command in Mainframe IBM APL2, where APL2 could directly read the older VSAPL workspaces. Otherwise, there was plenty of good APL migration software to handle this.

Is there a way to open up a text editor, type up some APL code, save it as a file, and then open it in Dyalog or MicroAPLX to execute the code? Or is that what workspaces are?

Is there a file type for APL programs?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

是否有方法打开文本编辑器，键入一些APL代码，将其保存为文件，然后在Dyalog或MicroAPLX中打开它以执行代码？或者这就是工作空间？

问APL程序有文件类型吗？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问APL程序有文件类型吗？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问APL程序有文件类型吗？
EN