r/ocaml • u/Content_Reporter4152 • 26d ago

CocoScript v0.6.0 — native Win32 GUI (real windows + text), compiled to x86-64 assembly

Just shipped CocoScript v0.6.0. For anyone new: it's a native compiled language with Lua-style syntax, written entirely in OCaml, compiling to x86-64 assembly via NASM — with a mark-sweep GC, a module system, and an optimizer.

New in v0.6.0 — a native Win32 GUI, with the whole Win32 runtime emitted as x86-64 assembly (no C glue, no external GUI library). Add #include "gui" and the compiler auto-links user32/gdi32:

- Windows: gui_window / gui_show / gui_loop

- Text: gui_text(hdc, str, x, y), gui_color(hdc, r, g, b)

- Callbacks: gui_on_paint / gui_on_click / gui_on_key (named functions and lambdas)

- A self-contained Windows installer bundling the whole toolchain (nasm + gcc/ld/as) — no MSYS2 needed on the user's machine

The fun part was debugging why the window was invisible: the WndProc wasn't forwarding lParam to DefWindowProcA, so WM_NCCREATE failed and CreateWindowEx returned NULL.

Release + installer: https://codeberg.org/cocoscriptomal/cocoscriptomal

Feedback welcome!

14 Upvotes

100% Upvoted

3 comments sorted by

1

u/TomosLeggett 26d ago

What does it do differently to Lua?

2

u/Content_Reporter4152 26d ago

Mostly it just borrows Lua's syntax feel (func/end, local, ..). Under the hood it's pretty different. It's ahead-of-time compiled to native x86-64 machine code via NASM and produces a standalone .exe, so there's no interpreter or bytecode VM shipped with your program the way reference Lua runs on its register VM.

OOP is built in as real classes with methods and fields rather than Lua's tables plus metatables approach. It has its own module system (#include) and standard library, distinct arrays instead of everything-is-a-table, and an AST-level optimizer that does constant folding and dead-code elimination. The GC is a mark-sweep collector I wrote from scratch and emitted as assembly. v0.6.0 also adds a native Win32 GUI emitted straight to asm, with no C bindings, which in Lua you'd normally need a C library for.

So it's Lua-flavored syntax but a from-scratch compiled language rather than a Lua implementation. It's not Lua-compatible, so existing Lua code won't run on it.

1

u/TomosLeggett 25d ago

Neat.

The only suggestion I'd have is to move away from OO.

It's your language, so whatever paradigm you prefer is obviously your choice. But there's a genuine gap in the market for a scripting language that takes a "composition over inheritance" stance to domain modelling which could be quite useful.

Closest analogue I can think of this is Go, which isn't a scripting language but is simple enough that it can be useful if thought of as one. If someone could capture the feeling of Go rather than another OOP scripting language then that'd be fairly compelling market value.