Comment by qazxcvbnm
1 year ago
Ahh that is certainly a very interesting idea to explore! Indeed, programming on the nets directly would not need messing with the fairly complex details of beta-optimality, leaving it as something to be dealt with, if required, by the programmer directly. As a language in its own right rather than as a computational device, interaction nets becomes a kind of Prolog-like language, where one similarly directly defines atoms and uses them as if they were data types.
By the way, I'm fairly certain that the Interaction Nets is the more general term, encompassing Interaction Combinators as merely some set of nets that happens to be a universal model of computation. They definitely both share the distinctions of principal ports v.s. auxiliary ports.
It feels really like Prolog, specially the `DiffList` example.
------
> They definitely both share the distinctions of principal ports v.s. auxiliary ports.
Version (1) and (2) both have principal ports v.s. auxiliary ports.
But only (1) has input ports v.s. output ports.
(I was actually quite shocked by this, when I read the 1997 paper.)
Indeed, I see that Lafont's 1990 paper introduces 'input' and 'output' denominations under Section 2 "Type Discipline".
> The choice of an input/output denomination is purely conventional: it does not matter if you call input what I call output, and conversely, but we must agree on matching. [...] typing ensures local correctness of computations
It seems to me that the input/output convention is really just one particular type system, orthogonal to the essential idea of Interaction nets or Interaction combinators. Indeed if iNet requires such a typing discipline, then nets like Interaction combinators cannot be implemented.