---
source: arxiv
url: https://arxiv.org/abs/2605.13896v1
published_at: '2026-05-12T12:11:33'
authors:
- Abdulrahman Ramadan
- Hanen Borchani
- Iben Lilholm
- Mikkel Almind
- Allan Peter Engsig-Karup
topics:
- code-translation
- legacy-code
- apl-to-csharp
- code-intelligence
- llm-fine-tuning
- program-repair
relevance_score: 0.86
run_id: materialize-outputs
language_code: zh-CN
---

# Neural Code Translation of Legacy Code: APL to C#

## Summary
## 摘要
本文研究用大语言模型把遗留 APL 代码翻译成 C#。主要贡献是一个专门的 APL 到 C# 数据集、几种引导式翻译方法，以及一个通过编译和运行来检查功能正确性的评估流水线。

## 问题
- APL 语法简洁、面向数组、动态类型，且符号很多；C# 是静态类型，表达更冗长。直接翻译时，通常需要处理类型映射、重载、循环、边界检查，以及把 APL 的 1 基索引转换成 C# 的 0 基索引。
- 随着 APL 专家的减少，遗留 APL 系统越来越难维护，因此需要可靠的自动化方法，把遗留代码迁移到现代编程语言，以减少人工重写工作。
- APL 到 C# 的公开平行语料很少，这限制了有监督训练和标准基准评估。

## 方法
- 作者比较了直接微调的 APL 到 C# 翻译与三种引导式方法：自然语言描述中介、检索增强翻译，以及利用编译器和测试反馈进行迭代修复。
- 他们构建了对齐的 APL 和 C# 数据集：800 对整理过的基础样本、143 个来自生产代码的工具函数、320 对 Rosetta Code 样本，以及 45 个 APL 惯用法。
- 他们用 LoRA 和 8 位量化微调开源权重模型，使用 1,066 个训练样本和 2,048 个 token 的序列长度。
- 他们用一个 F# 工具解析 APL 标头，生成 C# 方法签名，然后把这些签名放进提示词里，帮助模型处理 C# 类型。
- 评估时先编译生成的 C#，再用输入输出测试运行；迭代方法最多重试 5 次，输入中包含编译错误、期望输出、实际输出和之前的尝试。

## 结果
- 这段摘录没有给出主任务 APL 到 C# 的定量翻译准确率、编译通过率或运行通过率。
- 论文报告了数据集规模：数据集 A 有 800 对样本，数据集 B 有 143 个来自生产代码的函数，数据集 C 有 320 对 Rosetta Code 样本，数据集 I 有 45 个惯用法，训练语料有 1,066 个样本。
- 面向生产的测试使用数据集 B 的测试集，样本数为 49。
- 分词器分析显示，Qwen3-32B 的 APL 单 token 比率为 0.715，平均每个符号 1.284 个 token，平均每个样本 262.274 个 token，循环往返失败 0 次。
- Gemma-4-31b-it 的 APL 单 token 比率为 0.671，平均每个符号 1.656 个 token，平均每个样本 277.475 个 token，循环往返失败 1 次；Deepseek-Coder-6.7b-Instruct 因为处理不好 APL 的除号，循环往返失败 61 次。
- 摘要声称，加入更多上下文和引导会比直接翻译提升模型表现，但摘录里没有给出衡量这种提升所需的准确率数字。

## Problem

## Approach

## Results

## Link
- [https://arxiv.org/abs/2605.13896v1](https://arxiv.org/abs/2605.13896v1)