For some time now, I’ve been trying to answer similar and related questions regarding an I/O model I devised several years ago:
-
Has it been done before?
(presumably by someone much smarter than an amateur implementor:-)- That prior work would provide an existing base from which to explore the model further.
-
Has it been dismissed? (due to the discovery of some fundamental theoretical weakness)
- Being refuted in that way means I can save myself and others the enormous job of retrofitting the new I/O model into GHC, even as a prototype.
-
Has it been superseded? (perhaps by a denotative technique)
- The prior work on that successor may already provide sufficient detail for an implementation in GHC to be built more quickly.
Some basic information about the model:
-
Being a model, it’s in the language (not the implementation) so it is definitely not denotative.
-
It’s an abstraction of pseudo-data - there’s no intervening infinite (lazy) structured value such as a tree or list.
-
Some consider the direct use of pseudo-data (without an intervening abstraction) “low-level” - see:
-
On the Expressiveness of Purely Functional I/O Systems (page 15 of 28),
-
and Programming Reactive Systems in Haskell (page 7 of 16).
Due to it’s connection to pseudo-data, this I/O model also has that characteristic.
-
-
It does rely on a syntactic construct or primitive definition for sequencing evaluation (which
Prelude.seqisn’t).
Note: the prototype doesn’t have to be based on GHC - the implementation for Clean could also be used, after I’ve acquainted myself with its codebase. The Miranda(R) or old Hugs implementation could be another option…after the second Rust compiler is firmly established (in 2024?) so that the very old warhorse both currently rely on can finally be retired.
Then again, a long-forgotten and denotative solution to interactivity will be rediscovered in the meantime and it can be implemented instead, making this I/O model an academic curiosity…