Arc Forumnew | comments | leaders | submitlogin
Meaning-preserving modularity (
2 points by rocketnia 2343 days ago | 1 comment

2 points by rocketnia 2343 days ago | link


I began to write this post as a companion to my posts about dataflow[1], since neither a graph syntax nor a hierarchical syntax for dataflow does much to address module boundaries. It took me a while to get my thoughts into a single focused topic, and this is the result.




By limiting module exports to only query-answer pairs for which no other answer could ever be provided, we can cause the effect of modules on a system's overall knowledge to be declarative and monotonic. No program in this system ever changes meaning, but some programs' meaning is unknown without access to a sufficient knowledge base.

If we relax that export constraint to allow exports for which only one author can change the query answer and they have little incentive to cause harm that way, we can preserve most of these properties but gain extra bonuses: The language implementer can use a much less mathematically sophisticated query resolver, and the language user can capture informal, change-tolerant program dependencies with informal queries.