Red 1.0 开发路线图
Red 语言最近公布了关于 1.0 的开发路线图。
团队认为他们过去几个月(甚至是过去几年)在整体上的进展有所放缓,主要原因之一是他们将有限的资源分散在不同的目标上,而在核心语言功能上却进展甚微。
近几周,团队一直在讨论如何改变当前的状态。现在,他们表示唯一的重点将是完成核心语言功能,并发布期待已久的 1.0 版本。鉴于完成 Red 语言并带来一个可以在现代 64 位平台上运行的实现所涉及的复杂性,团队设计了一个两阶段的计划。
阶段一:升级当前的 32 位 Red 实现
语言规范
清理一些语义规则并解决所有可能的边缘情况,这将有助于实现语言健壮性和稳定性的目标。团队表示,写下完整的语言规范的过程将会导致删除目前拥有的一些功能,这些功能最终会出现问题或不一致。不过另一方面,他们会添加一些需要在 1.0 中实现的新功能。
模块
团队认为,他们需要一个合适的模块系统来实现可扩展性,还需要有一个合适的包管理系统,该系统将绑定到一个中央仓库,这样就可以在里面收集第三方库。此功能需启用模块化/增量编译(或封装),很可能在自托管工具链中得到支持。
并发
为了利用多核架构,需要一个合适的并发执行模型。团队将定义一个并在 32 位版本中实现原型。
工具链
在开始开发新工具链之前,团队将对现有版本进行一些更改,以便为过渡做准备。其中最大的变化是删除 Red 编译器。未来它只会充当(智能)封装器的角色。例程和 #system 仍将支持指令,但可能有一些限制。Red 预处理器也可能会有相关变化。这一变化意味着 Red 将只有一个执行模型,而不是目前的两个。
这一举措不仅会通过消除一些极端情况问题带来更高的稳定性,而且还会将工具链的大小减少近 25%,这将有助于减少新工具链中支持的功能数量。
运行时环境库
针对 Red 运行时环境库的改进,其中包括:
- 统一 Red evaluation stack
- 统一 node! management
- 改进路径调用处理
- 改进 object! 语义
所有这些更改旨在简化、减少运行时环境库代码,并解决一些系统性问题(例如堆栈管理问题和 GC 节点泄漏)。
文档
针对 Red 核心语言功能提供适当、详尽、面向用户的文档。这是必须完成并做好才能更广泛被采用的强制性任务之一。
阶段二:完成 64 位版本的自托管 (Self-hosted) Red 语言
工具链
团队表示,为了发布 64 位版本,必须完全放弃当前基于 Rebol2 的工具链代码,并用 Red 本身的更新架构进行重写。
新的工具链将包含:
- 带有插件模型的新编译管道
- IR 层
- 一个或多个优化层
- 支持模块化/增量编译
- x64、AArch64 和 WASM 后端
- 支持 Big 3 OS 的 64 位可执行文件格式的链接器
- 支持链接第三方静态库
1.0 将不支持 32 位后端,但未来的版本可能会重新添加支持。
运行时环境库
当前用 R/S 编写的 Red 运行时环境库将被保留,并且需要进行一些调整以完全兼容 64 位环境(例如将所有导入的 OS API 更新到其 64 位版本)。
视图引擎 (View Engine) 不会成为 1.0 升级的一部分,但会在 1.1 版本中完成,1.0 优先考虑 Red/Core。
路线图
- v0.7 : Full I/O with async support.
- v1.0b : (beta) completed self-hosted Red with 64-bit support.
- v1.0r : (release) first official stable and complete Red/Core language release.
- v1.1 : View 64-bit release.
- v1.2 : Android backend and toolchain release.
- v1.3 : Red/C3 release.
- v1.4 : Web backend for View release.
- v2.0 : Red JIT-compiler release.
- v3.0 : Red/...
上述计划中没有提到主流平台 iOS。团队认为,鉴于该平台的封闭性,他们需要制定一个具体的计划来支持,因为它不支持交叉编译(需要一台 Mac 计算机),也可能在某些时候不依赖 Xcode 就无法生成 iOS 应用程序(甚至 AppStore 还有对动态代码的限制),这是 Red 需要首先克服的复杂层次……所以目前,对该平台的支持不在他们的优先级中。
Red 编程语言是一门简单易学的编程语言,受到了 REBOL 很大的启发,由于它有本地代码编译器,Red 的应用领域更加广泛 —— 下到系统编程上到高级脚本,同时提供了对现代的多核 CPU 并发编程的支持。相信 Red 语言能让你体会到编程的乐趣。
特性
支持函数式,命令式和符号化编程
基于 Prototype 的对象系统
Homoiconic(同像性,也就是说数据的表现形式和代码的语法是一样的,数据可以是代码,代码也可以是数据)
支持静态编译和 JIT 编译
支持并发和并行编程(actors,并行容器)
通过内建的低级编程语言(Red/System)支持系统级编程
支持脚本化和 REPL 交互环境
高可嵌入性(类似 Lua)
低内存使用量,支持垃圾回收
极小的运行环境(1MB)

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Fedora 迈出第一步,禁止 CC0 许可的软件
Fedora 项目近日公开的信息显示,Fedora 计划不再包含基于 CC0 许可的软件。 CC0 为作者提供了一种 "在法律允许的范围内放弃其作品中所有版权和相关权利" 的方法,也就是说采取了 CC0 协议的作品,表示著作权人已将该其贡献至公有领域,在法律允许的范围,放弃所有在全世界范围内基于著作权法对作品享有的权利。但 CC0 也特别明确了,CC0 是不涉及著作权⼈所拥有的商标权或专利权,上述权利不会因本声明⽽被放弃、让渡、授权或者受到其它影响。 这对自由和开源软件(FOSS)来说是一个潜在问题。这意味着,如果你在你的项目中使用 CC0 许可的代码,而该代码的作者后来声称你的项目侵犯了他持有的与该代码有关的专利,你或你的项目将面临潜在的法律诉讼以及赔偿等。 专利是对开源软件用户和开发者的持续威胁,使用 CC0 许可的代码只是说有潜在的风险,并非一定会影响你的项目。但这些专利对你项目的影响一般会在多年以后才浮现出来,因此对于一个发展多年的成熟项目来说,这一影响可能会十分严重,尤其是那些商业性使用开源软件的用户。 红帽的专利顾问 Richard Fontana(也是 GPLv3 许可证...
- 下一篇
APaaS低代码平台(一) | 把复杂留给自己,把简单留给用户
当前软件开发仍存在开发成本高、定制化能力差、效率低、迭代周期长等痛点,长期低效率项目交付难以满足企业应对快速变化的市场,导致行业数字化进程缓慢,企业无法真正实现降本增效,因而对零代码/低代码开发方式的需求更为迫切。 APaaS低代码平台新风向 APaaS,做企业数字化推进中“最靓的仔”。你可以把APaaS理解为PaaS的一种子形式。APaaS的全称是Application Platform as a Service,即应用程序平台即服务。Gartner对其所下的定义是:“这是基于PaaS(平台即服务)的一种解决方案,支持应用程序在云端的开发、部署和运行,提供软件开发中的基础工具给用户,包括数据对象、权限管理、用户界面等。” APaaS和PaaS的区别是什么? APaaS和PaaS都可以完成软件的开发和部署,都支持云端访问。而两者的差异主要体现在用户人群和使用环境不一样: ● PaaS包含所有平台级别的服务,需要技术人员在本地完成应用程序的开发和数据提供,然后部署到PaaS平台上,再分发给用户使用。 ●APaaS是PaaS的一种子形式,在APaaS模式下,非技术人员可以直接在云端完成...
相关文章
文章评论
共有0条评论来说两句吧...