Palli
October 7, 2026, 10:07pm
21
I would think you could implement those 200 lines also in Julia with (or without!) AI. And you can already call Julia from R; and with this package it will likely get easier as it already has for Python to call Julia:
opened 12:24PM - 21 May 26 UTC
enhancement
Tracking issue for the two unimplemented language backends.
Matlab is the close… r of the two: `loadlibrary` consumes the `.h` header that `CTarget` already generates, so a Matlab backend is largely a thin `.m` façade generator — and would itself exercise the façade machinery (#13).
R (via `.Call` / Rcpp) is more involved.
R is likely next, and AI has been helping greatly recently in the Julia ecosystem as with the MATLAB support (and at JuliaLang and elsewhere), here with 45 commits across 30 files:
main ← el-oso:matlab-target
merged 01:06PM - 15 Sep 26 UTC
A MATLAB backend, from the same `@api` declarations as the Python one. Second
o… f three; the last runs real MATLAB in CI.
One `.m` façade per declaration in a `+package` directory, plus a C gateway
that turns `mxArray`s into the carriers and releases what Julia allocated.
Emitting needs no MATLAB. Every fixture's gateway is compiled in the suite with
`-Wall -Wextra -Werror`, and the emitted `.m` and `.c` are pinned by goldens.
```julia
standard_build(@__DIR__; libname = "boundary", matlab_package = "boundary")
```
## An open question
Array arguments are borrowed, so a function that writes to one changes every
variable sharing that buffer. `duplicate_arguments = true` copies instead, but
it is per build: one mutating function taxes every other.
| approach | granularity | cost |
|---|---|---|
| target flag (this PR) | whole library | one mutating function taxes the rest |
| `@api … mutates=(a,)` | per argument | changes the annotation layer |
| `MatlabTarget(…; duplicate=["f"])` | per function | names repeated in the build script |
| always duplicate | none | gives up the no-copy property |
Putting it in `@api` seem the right place as mutability is a fact about the function, not MATLAB — but I left it out for the same reason we dropped the target field: no consumer, no case in hand. What do you think?
@timholy Maybe I need to clarify. MATLAB makes copies of everything and has value semantics almost everywhere. To avoid copying too much by default this wrapper borrows, but could have unintended side-effects. So, there is an option to make copies instead, that makes it more MATLAB-ish. But it is an all or nothing approach. The question is, should we make it more granular? if so, how granular?
**Not in this PR:** running MATLAB. The compile check verifies types, not
semantics, so `mustBeVector([])`, the integer coercion order and finding the
library at run time want a real gate. That is the next PR.
Apologies for the scope creep :sweat_smile:
🤖 Generated with [Claude Code](https://claude.com/claude-code)
I still think Julia is the better language for, and if you’re language agnostic, you might be able to move everything to Julia. AI can probably already do it as has been shown in other cases (in one recent case of large codebase translation by AI for C++ to Julia resulted in 6x speedup):
It’s about 12k LOC (comments, libraries code and doc removed)
Now it’s a question of which is the best language.
Depending on exactly what you’re doing this might apply:
Same AI model, different results: Dyad Agent scored 0.899 versus Claude Code’s 0.533 across four physics problems, at similar cost and runtime.