FYI - some of my opions on compiler building

[Paul Tarvydas]

[David Barbour]

I read your opinions on compiler building. I've been following the Koru language, which compiles to Zig and JavaScript based on similar ideas.

My current effort involves developing a general-purpose assembly language. I take a different approach from you, but towards a similar end. A program ultimately 'writes' a binary, or a folder thereof, whether it's ELF, WASM, or a higher-level language. However, I introduce some structured indirection: composable, extensible intermediate representations based on mixins and freer monads. The motive is to ensure useful properties remain consistent across stages, especially regarding extensibility, adaptability, diagnostics/debugging, and backtracking program search.

I do disagree on one point: I believe there is still a lot of room for compilers. The main issue is that targeting high-level languages like Go introduces an "abstraction floor." Targeting machine code or assembly can eliminate or isolate the notion of function calls. There are also many opportunities with data structures that don't mesh well with conventional language APIs or module systems. This isn't just a performance concern: beating the performance of modern compilers is very difficult, though an LLM could handle low-hanging optimizations. Rather, it is about maximizing freedom and eliminating unnecessary friction and impedance mismatch.

[Paul Tarvydas]

Interesting, thanks! 

For whatever reason, your comments evoke this line of thinking for me:

• a CPU is just a building material like any other IC in a hardware circuit
• unlike most ICs, CPUs have malleable functionality - a CPU is a "narrow waist" that exposes a small subset of what electronics can do and assigns numeric codes to each operation in the narrow waist
• a CPU is, by design and definition, synchronous and sequential
• programming languages for human use don't have to be synchronous and sequential, but tend to be synchronous and sequential anyway
• "assembler" is a simple mapping of numeric codes to concise, more-human-readable mnemonics
• "assembler" is usually related to CPU ICs, but not so much to FPGA ICs, GPU ICs, and - most importantly - to distributed, asynchronous nodes in a circuit or a network (like the internet)
• we (my colleagues and I) once built a declarative assembler as the back end to an Orthogonal Code Generator project
• LLMs are trained on existing synchronous, sequential coding techniques and shouldn't be trusted to use or evolve other coding styles
• a lot of interesting non-sequential uses of CPUs came into existence, like Prolog, Statecharts, Tiny Basic (the first VM (virtual machine) that I witnessed), etc., through the act of inventing little "engines" using whatever was provided by CPUs. Such engines act as scaffolding for other ways of approaching, expressing software design.

I haven't heard of Koru and intend to take a peek at it.

thanks

pt

--
You received this message because you are subscribed to the Google Groups "PiLuD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pilud+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pilud/CAAOQMSvd6wkphZS%3DpU0QzpWATUO97eO6XrLZrZj34zCZt-cx3g%40mail.gmail.com.

[David Barbour]

The LLMs with big context windows can adapt to non-sequential languages very well, in my experience.

I don't view 'assembly language' as strongly connoting CPU code. Rather, assembly is about absolute control at the lowest level accessible, avoiding abstractions. Ideally, a modern general purpose assembly language would give users all the amenities of advanced PLs: debugging, testing, static analysis, a very high abstraction ceiling, etc..

Under my view, we would benefit from effective assembly of heterogeneous systems including CPUs, WASM, FPGAs, GPGPUs, PCBs, etc..

To view this discussion visit https://groups.google.com/d/msgid/pilud/A1218F68-FB6C-4737-AB81-E8926208F802%40gmail.com.