James, If you look at what Greg has done w/ rho calculus
https://arxiv.org/search/cs?searchtype=author&query=Meredith%2C+L+G and then these more recent elaborations of Native Type Theory that provide a more elegant way of doing what Curry-Howard tries to do (and does in limited cases), https://github.com/leithaus/rho4u/blob/main/oslf/oslf.pdf you'll see something that extends to quantum type systems pretty naturally too... MeTTa language that we're developing for Hyperon will be perfectly capable of dealing w/ quantum type systems... which should ultimately make it portable to general purpose quantum computers, and in the shorter term, should make it useful to implement classical-computer-based drivers of specialized quantum computing hardware... But we have a few fish to fry before that becomes our biggest problem ;) ... for now we are looking at the best ways to leverage Greg's work to make MeTTa extremely efficient in a classical multiprocessor setting.. (e.g. server farms of multi-GPU boxes...) ben On Sun, Mar 5, 2023 at 8:18 AM James Bowery <jabow...@gmail.com> wrote: > > When I was tasked by AT&T & Knight-Ridder to architect their nationwide > rollout of a mass market information utility starting with electronic > newspapers, it was before TCP/IP had been carved in stone so I went to David > P. Reed (Mr UDP) and talked with him about his PhD thesis regarding a > distributed programming synchronization paradigm that, coincidentally (or > perhaps not so), was isomorphic to the dataflow architecture by the guys the > next floor or two down at the MIT LCS (Arvind and Gostellow's U-Interpreter). > A version finally ended up being implemented as TeaTime under the now-defunct > Croquet system. I had some additional semantics sufficing to deal with the > memoization (cache) maintenance problem elegantly that didn't get > incorporated into TeaTime. The main limitation as I saw it was the focus on > functional (N:1) programming as opposed to relational (N:M) programming since > one can get functional programming as a degenerate case of relational. The > XSB Prolog guys finally got something done with incremental tabling that > handled part of the memoization (cache) maintenance problem, but the > parallelization and distributed atomic action problems remain. My focus on > relational semantics was reinforced by my interactions with Backus regarding > his seminal Turing Lecture about FFP when he admitted that would be an > afterthought. > > While it is true that we live in a world where there is an apparent unitary > state transition going on, hence N:1 is a kind of underlying assumption, this > is only true in the case of an atomic action "commit". Up until that point > in time, the atomic action can be undone in a quasi-reversible programming > sense. So, despite getting to know not only Backus, but also Curry and > Church toward their end of their lives, I saw relations as the cornerstone of > any programming paradigm for which I would be responsible since I could have > affected the lives of billions by failing to so-discipline my architecture. > > This obviously leads directly into quantum information systems, which > Federico Faggin attempted to explore with my colleagues at Boundary Institute > -- refugees from Paul Allen's Interval Research -- by resurrecting Russell's > Relation Arithmetic as the proper formal language of the quantum core. > > But here's the thing that everyone seems to miss about quantum information > systems: > > If we accept that they are at the basis of the empirical world (as Russell > said of Relation Arithmetic) then physical dimensions should naturally fall > out of the structure. By "physical dimensions" I mean stuff of the physical > world that any programming language dealing with artificial intelligence must > necessarily deal with in order to be considered MODELs of reality. > > Other than Relation Arithmetic (as revived at Boundary), I've seen absolutely > NOTHING in the SIGPLAN-proximate world that remotely accomplishes this except > as a bricolage kludge. This is quite frustrating and, to be quite honest, I > don't think ANY new programming language deserves to exist that doesn't > perform this feat as an inevitability of its structure. > > This isn't just an autistic demand for a pet project. It gets to the > foundation of the way computers model reality. > > > > On Sun, Mar 5, 2023 at 12:06 AM Ben Goertzel <bengoert...@gmail.com> wrote: >> >> On Sat, Mar 4, 2023 at 6:06 AM stefan.reich.maker.of.eye via AGI >> <agi@agi.topicbox.com> wrote: >> > >> > I'd be very curious to hear what you see as the role of Rust in AGI if >> > you'd be willing to expand on it a little bit. (Trade secret?! :) >> > >> > Stefan >> >> It's not very secret, see e.g. >> >> https://github.com/trueagi-io/hyperon-experimental >> >> We have created our own AGI language (MeTTa) to play a key role in our >> new OpenCog Hyperon system, >> >> https://wiki.opencog.org/w/Hyperon >> >> but the interpreter for core MeTTa has to be written in something else >> and that is Rust (which we chose over C++ or Haskell for this purpose >> for fairly familiar reasons...) >> >> ben > > Artificial General Intelligence List / AGI / see discussions + participants + > delivery options Permalink -- Ben Goertzel, PhD b...@goertzel.org "My humanity is a constant self-overcoming" -- Friedrich Nietzsche ------------------------------------------ Artificial General Intelligence List: AGI Permalink: https://agi.topicbox.com/groups/agi/Ta26ae6adc3928674-M1b7df0eb1e42d968ef5366c4 Delivery options: https://agi.topicbox.com/groups/agi/subscription
