6 ms·

With the current proliferation of structured file formats (xml, json, yaml, toml, protobuf, messagepack) I got wondering if there is room for a format based on

With the current proliferation of structured file formats (xml, json, yaml, toml, protobuf, messagepack) I got wondering if there is room for a format based on one of these stack/list based languages that could be easily implemented even on microcontrollers or on some locked-down corporate machine with only a decade-old IDE and no third-party libraries. My original thought was something that was a subset of Forth, though I get the impression that vanilla Forth is a headache dealing with data types other than ints and the result would be sufficiently custom that it wouldn't be worth it. Something based on TCL or S-expressions sounds like it would give the needed flexibility, though maybe at the expense of being able to implement on microcontrollers. Has anyone played with parsing either of those? I know that the PCB designer tool in KiCAD uses S-expressions so it's been done before.

DennisP 6y ago
Postscript is a stack language, with strong typing and Lisp-inspired data structures. Maybe that could be a model for what you're talking about. https://en.wikipedia.org/wiki/PostScript#The_language https://en.wikipedia.org/wiki/PostScript#The_language
blacksqr 6y ago
Forth implemented in Tcl: https://github.com/wejgaard/TclForth https://github.com/wejgaard/TclForth
megameter 6y ago
The limitation in crossing the boundary from a data language to an executable language is mostly down to contrasts between "divisions" within and "bindings" across data. Some Forths include an additional floating point stack, and many implement types on top, but the basic nature of the thing is not to address division of data into sizes, fields and regions of memory directly, and instead to let the user define those things. Where Forth is powerful is in allowing layers of binding to build up, since the language can flip-flop between execution and compilation easily - that's why basic control flow words like IF - THEN - ENDIF can be bootstrapped, as can any desired type checker. But in the process, the binding format - the Forth dictionary - becomes one of the core dependencies. The "just data" formats like JSON only approach the topic of binding in limited ways like key-value structures or a defined schema. The types are static during parsing, so the data is less tangled and context-driven and more approachable through a simple divide-and-conquer.

DennisP 6y ago

Postscript is a stack language, with strong typing and Lisp-inspired data structures. Maybe that could be a model for what you're talking about. https://en.wikipedia.org/wiki/PostScript#The_language https://en.wikipedia.org/wiki/PostScript#The_language

blacksqr 6y ago

Forth implemented in Tcl: https://github.com/wejgaard/TclForth https://github.com/wejgaard/TclForth

megameter 6y ago

The limitation in crossing the boundary from a data language to an executable language is mostly down to contrasts between "divisions" within and "bindings" across data. Some Forths include an additional floating point stack, and many implement types on top, but the basic nature of the thing is not to address division of data into sizes, fields and regions of memory directly, and instead to let the user define those things. Where Forth is powerful is in allowing layers of binding to build up, since the language can flip-flop between execution and compilation easily - that's why basic control flow words like IF - THEN - ENDIF can be bootstrapped, as can any desired type checker. But in the process, the binding format - the Forth dictionary - becomes one of the core dependencies. The "just data" formats like JSON only approach the topic of binding in limited ways like key-value structures or a defined schema. The types are static during parsing, so the data is less tangled and context-driven and more approachable through a simple divide-and-conquer.