# A function as a process? **URL:** \ **Category:** General\ **Created:** [13 May 2024 08:58 UTC](https://forum.malleable.systems/t/a-function-as-a-process/187 "2024-05-13T08:58:12Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Apostolis](https://forum-cdn.malleable.systems/user_avatar/forum.malleable.systems/apostolis/32/96_2.png) [@Apostolis](https://forum.malleable.systems/u/Apostolis)\ **Post date:** [13 May 2024 08:58 UTC](https://forum.malleable.systems/t/a-function-as-a-process/187/1 "2024-05-13T08:58:12Z")
When trying to split a program into multiple parts, you need to serialize the data. Maybe this project can help in avoiding this. > **[Gibbon](https://iu-parfunc.github.io/gibbon/)** > > A compiler for operating on serialized trees ---
**Author:** ![jryans](https://forum-cdn.malleable.systems/user_avatar/forum.malleable.systems/jryans/32/7_2.png) [@jryans](https://forum.malleable.systems/u/jryans)\ **Post date:** [13 May 2024 10:26 UTC](https://forum.malleable.systems/t/a-function-as-a-process/187/2 "2024-05-13T10:26:27Z")
I do need to sit down and understand this work more deeply, so I’ve added it to my reading queue. 🙂 That reminds me, I recently saw a thread from one of the Gibbon authors discussing their 2019 LoCal paper: > **[mike vollmer 🎃 (@vollmerm@types.pl)](https://types.pl/@vollmerm/112394739624826917)** > > A 🧵 about our PL research on typed functional programming and efficient data representation: > > We have a paper accepted (conditionally) to ECOOP this year that we’ll hopefully be able to post online soon. It is part of our ongoing research project... ---
**Author:** ![Apostolis](https://forum-cdn.malleable.systems/user_avatar/forum.malleable.systems/apostolis/32/96_2.png) [@Apostolis](https://forum.malleable.systems/u/Apostolis)\ **Post date:** [1 February 2026 18:47 UTC](https://forum.malleable.systems/t/a-function-as-a-process/187/3 "2026-02-01T18:47:12Z")
> **[Gibbon](https://gibbon-compiler.github.io/)** > > A compiler for operating on serialized trees The link needs updating. ---
**Author:** ![yihanwu1024](https://forum-cdn.malleable.systems/user_avatar/forum.malleable.systems/yihanwu1024/32/903_2.png) [@yihanwu1024](https://forum.malleable.systems/u/yihanwu1024)\ **Post date:** [2 February 2026 00:04 UTC](https://forum.malleable.systems/t/a-function-as-a-process/187/4 "2026-02-02T00:04:15Z")
My recent attempt at a substrate led to the following discoveries regarding serialization and persistence. In order to understand the following please note that I am writing it in Java/Kotlin and targeting JVM. The language inside the substrate is a simple functional language, currently Clojure. (Long live embeddable languages!) The input events have no more complexity than a tree. Input cannot be a lattice (non-trivially), because I/O or perception is “flat”. Just think about your mode of perception. Your perception is a space, which can be divided into regions. Two _disjoint_ regions of your perception space are _independent_. There is no `let ... in` in perception. There is also no pointer. The input is also immutable and stored on disk. So, I would like to serialize the data in a compact way. But then, according to my plan, the user also needs to maintain some state `fold`ed from the input. I initially used Protobuf `Message.Builder` (which is a mutable, typed message before serialization) for all the state. For a while I thought this style of mutability was necessary. Then, - State requires more complexity than a tree. It can contain a loopy graph. Every off-the-shelf solution, including Protobuf, serializes this kind of data as a tree with references _inlined_, which makes the data structure wrong. - A similar limitation was noted on LoCal page 58. LoCal can only serialize lattices, not loopy graphs. It must have used some equivalent of `let ... in` construct. - If you want to store a loopy graph in a tree, you have to store the adjacency map. The authors of LoCal did not take note of this. We in fact have a capable design! - State does not necessarily use the same data schema as input. This is the whole point of using `fold` over `reduce`, and is also the reason why I decided to leave the state serialization to the user. This approach adheres to the “parse, don’t validate” principle pretty much everywhere, giving freedom to higher-level code. In summary, loopy graph \> lattice \> tree in terms of complexity and serialization cost. LoCal can do a lattice. My substrate allows trees in input, and loopy graphs in state. ---
**Author:** ![Apostolis](https://forum-cdn.malleable.systems/user_avatar/forum.malleable.systems/apostolis/32/96_2.png) [@Apostolis](https://forum.malleable.systems/u/Apostolis)\ **Post date:** [2 February 2026 14:36 UTC](https://forum.malleable.systems/t/a-function-as-a-process/187/5 "2026-02-02T14:36:59Z")
Gibbon’s goal is about the automated compilation of functional programs, to use serialized data. My interest is in the “automated” part, and in the probable ability to use it to split programs into smaller ones. I am not sure if the second case is something that they want to support. And I haven’t looked into the technical details, so I cannot really provide any comment on that.