Syntran interpreter 1.6.0 release

Announcements
1

After releasing syntran 1.0 a year and a half ago, I’m happy to announce version 1.6 of syntran, an interpreted language I’ve written in Fortran

Syntran is aimed at people who like Fortran’s array semantics but want an interactive scripting language. A few highlights:

Fortran-style arrays

Arrays are column-major like Fortran (but zero-indexed, with half-open ranges). Slicing supports ranges, steps, and vector subscripts, on either side of an assignment:

let m = [
	0,  1,  2,
	3,  4,  5,
	6,  7,  8,
	9, 10, 11 ;
	3, 4         // size
];
println(m[1, :]);           // [1, 4, 7, 10]
println(m[0: 2, [0, 3]]);   // [0, 1,   9, 10] as a 2x2 array
m[:, 0] += 100;             // compound assignment on a slice

Static type checking

Scripts are type-checked before they run, with compiler-style diagnostics:

let x = [1.0, 2.0, 3.0];
let s = "abc";
let y = x * s;

Error[E48]: binary operator `*` is not defined for types array_type and str_type
  --> <stdin>:3:11
   |
 3 | let y = x * s;
   |           ^ wrong types for this binary operator

Written in Fortran

The lexer, parser, bytecode compiler, and VM are all written in modern Fortran (the only C is a small shim and the vendored isocline library for REPL line editing), and it builds with gfortran or Intel Fortran using fpm or CMake

You can try syntran in your browser without installing anything: https://syntran.jeffirwin.xyz/

This only scratches the surface. More details are in the project README: GitHub - JeffIrwin/syntran: An interpreter written in Fortran, I guess · GitHub

4 Likes
2

Nice work!

How about a transpiler to Fortran, for those who want to prototype in Syntran, but then want the fastest possible native binary?

1 Like
3

You’re right, performance is a concern.

A transpiler is a good idea. I had considered making a compiler with LLVM, but a transpiler is more easily attainable and should have fewer compatibility problems. Syntran’s % operator works like Fortran’s mod, / truncates like Fortran, etc. Matching all of that behavior with LLVM would require a lot of care.

I’m already on my second backend. For a while I had a hand-written AST-walking interpreter. In syntran 1.3 in June I added a vibe-coded bytecode interpreter. That brought syntran’s performance roughly on par with python, which is obviously still not great.

It depends on the task of course. For large matmul’s, syntran’s performance is close to Fortran without BLAS, because the matmul is already hapenning in Fortran anyway. For small vectors in hot loops, syntran is closer to python.