Investigate which language features are blocking mandelbrot example

[dboreham]

This example program from the kroc project implements the Mandelbrot set computation: https://github.com/concurrency/kroc/blob/master/demos/ttygames/mandelbrot.occ

Currently it throws various parse errors when the transpiler processes it.

It would be useful to know which unimplemented language features are blocking clean processing of this example.

[associate-1]

Investigation Results

The mandelbrot demo (kroc/demos/ttygames/mandelbrot.occ) exercises many advanced occam and occam-pi features. Below is a categorized list of every missing feature blocking clean transpilation, with references to existing issues where applicable.

Blocking Features

Critical — Fundamental to program architecture

Feature	Lines	Existing Issue	Notes
CHAN TYPE / MOBILE RECORD definitions	48–57	#40	Defines typed channel bundles CT.WORK.IN, CT.WORK.OUT
SHARED channel qualifier	83, 229–230	#40	SHARED CT.WORK.IN! mwcli.in for worker pool
CLAIM blocks	93–94, 111–112	#40	Mutual exclusion for shared channel access
MOBILE allocation expressions	232–233	#40	mwsvr.in, mwcli.in := MOBILE CT.WORK.IN
DATA TYPE ... RECORD (named record types)	27–30	#40	DATA TYPE COMPLEX64 RECORD ... — foundation for all complex arithmetic
User-defined types in params/decls	59, 62, 65, 70, 73	—	VAL COMPLEX64 x as function parameter type; INITIAL COMPLEX64 iter IS ...

High — Multiple occurrences, significant code sections

Feature	Lines	Existing Issue	Notes
Multi-dimensional array declarations	43, 161	#64	[][5]BYTE, [n][m][k]BYTE
Multi-dimensional array indexing	179, 199, 207	#64	framebuffer[a][b][c] chained indexing
Array types in protocol fields	45–46	—	PROTOCOL P.JOB.IN IS INT; INT; [4]REAL64:
Expression-sized array declarations	46, 90, 161	#62	[IMAGE.WIDTH * 2]BYTE, [MAX.FRAMES][...]BYTE
Operator overloading (string function names)	62–67	—	COMPLEX64 INLINE FUNCTION "+" (...), "**"

Medium — Isolated occurrences

Feature	Lines	Existing Issue	Notes
INITIAL with array types	153	—	INITIAL [4]REAL64 wpacket IS ...
Array comprehensions [i = 0 FOR n | expr]	153	—	[i = 0 FOR 4 | 0.0] replicator-based construction
Typed array literal constructor [x,y](TYPE)	106	—	[x,y](COMPLEX64) explicit type on array literal
*" string escape	84	#65	'*"' inside the table byte literal
CHAN OF PROTOCOL params with user-defined protocol types	94, 112, 115, 140, 154, 160	—	CHAN P.JOB.IN in! — channel of named protocol, used in channel type bodies and proc params

Low — Simple additions

Feature	Lines	Existing Issue	Notes
tim ? AFTER t (timer AFTER input)	187	#60	Wait-until-time in ALT body
Guarded ALT with boolean pre-conditions	218	#67	(hframe <= (lframe + 4)) & tick ? hframe
RESCHEDULE() intrinsic	109	—	Maps to runtime.Gosched()
REAL64 long floating-point literals	116–120, 143, 148–149	—	1.16000014859 triggers ILLEGAL tokens — possible lexer limitation on float length

Related Issues Summary

• Support KRoC mobile/shared channel extensions #40 — CHAN TYPE / MOBILE / SHARED / CLAIM / DATA TYPE — covers the biggest blockers
• Support timer AFTER input (tim ? AFTER expr) #60 — tim ? AFTER expr — timer delay input
• Support expression-sized array declarations #62 — Expression-sized array declarations
• Support multi-dimensional arrays ([][n]TYPE) #64 — Multi-dimensional arrays (declarations and indexing)
• Support *" string escape sequence #65 — *" string escape sequence
• Support guarded ALT with boolean pre-conditions #67 — Guarded ALT with boolean pre-conditions

Features with no existing issue

These would need new issues if someone wants to track them individually:

1. User-defined types in params/declarations — accepting COMPLEX64 etc. as types in function params, INITIAL, variable decls
2. Array types in protocol fields — [n]TYPE inside PROTOCOL ... IS definitions
3. Operator overloading — FUNCTION "+", FUNCTION "**" with string-literal names
4. INITIAL with array types — INITIAL [n]TYPE name IS expr:
5. Array comprehensions — [i = 0 FOR n | expr]
6. Typed array literal constructor — [exprs](TYPE) suffix
7. RESCHEDULE() — trivial; maps to runtime.Gosched()
8. CHAN OF PROTOCOL params — channels carrying named protocol types
9. REAL64 long float literal lexing — possible lexer bug with longer decimal sequences

[associate-1]

Feasibility: Rewriting with Currently-Supported Features

It should be possible to rewrite the mandelbrot example using only features the transpiler already supports. Here's an analysis of each blocker and the proposed workaround.

Easy workarounds

Blocker	Workaround
DATA TYPE COMPLEX64 / user-defined types	Decompose into pairs of REAL64 variables (real, imag). Inline the arithmetic.
Operator overloading ("+", "**")	Goes away once COMPLEX64 is eliminated — just use explicit real/imag math.
Expression-sized arrays ([IMAGE.WIDTH * 2]BYTE)	Precompute as VAL INT constants (e.g., VAL INT OUTPUT.WIDTH IS 200:).
Array comprehensions ([i = 0 FOR 4 | 0.0])	Replace with plain array declaration + SEQ initialization loop.
Typed array constructor ([x,y](COMPLEX64))	Not needed once COMPLEX64 is eliminated.
INITIAL with array types	Use plain array declaration + SEQ init.
RESCHEDULE()	Remove — it's just a scheduling yield hint.
*" string escape (#65)	Avoid the quote character in the lookup table, or use a byte literal.
Long REAL64 literals	May be a cascading parse error rather than a real lexer bug. If real, approximate with fewer decimal digits.

Moderate restructuring

Blocker	Workaround
Multi-dimensional arrays (#64)	Flatten [MAX.FRAMES][IMAGE.HEIGHT][WIDTH]BYTE into a 1D array with manual index calculation: buf[(frame * HEIGHT * WIDTH) + (row * WIDTH) + col].
tim ? AFTER t (#60)	Replace with tim ? now + a polling WHILE loop, or a fixed delay via a counting loop.
Guarded ALT (#67)	Restructure (expr) & chan ? x into nested IF/ALT where the boolean check happens before entering the ALT, or use a separate control channel.

Major restructuring — Worker pool architecture

The CHAN TYPE / MOBILE / SHARED / CLAIM family (#40) is the biggest blocker. The entire worker-pool pattern needs to be redesigned:

Current architecture (requires SHARED/CLAIM):

• Single shared channel bundle — multiple workers CLAIM and read from it
• Farmer pushes jobs onto the shared input channel
• Harvester reads from the shared output channel

Proposed replacement (uses only supported features):

• Per-worker channel pairs: [N.WORKERS]CHAN OF P.JOB.IN and [N.WORKERS]CHAN OF P.JOB.OUT
• Farmer dispatches round-robin to individual worker input channels
• Harvester uses ALT i = 0 FOR N.WORKERS (supported) to receive from any worker's output channel
• Eliminates the need for SHARED, CLAIM, CHAN TYPE, and MOBILE entirely

Array types in protocol fields — also needs workaround:

• Job params ([4]REAL64): send as 6 individual values in a sequential protocol — PROTOCOL P.JOB.IN IS INT; INT; REAL64; REAL64; REAL64; REAL64:
• Output row ([200]BYTE): hardest part. Options: (a) workers send individual bytes in a loop over a plain CHAN OF BYTE, or (b) restructure so workers write to a higher-scoped array and signal completion via a simple CHAN OF INT

Proposed rewrite plan

1. Eliminate COMPLEX64 — use pairs of REAL64 variables for all complex arithmetic
2. Replace shared channel bundles with per-worker [N.WORKERS]CHAN OF ... arrays
3. Farmer dispatches jobs round-robin; harvester uses ALT replicator to collect results
4. Flatten the 3D framebuffer to 1D with manual index math
5. Replace sequential protocol array fields with individual values
6. Replace tim ? AFTER with timer polling or a delay loop
7. Remove RESCHEDULE(), work around *" escape and guarded ALT

The result would be less idiomatic occam but functionally equivalent and transpilable today.