well I want SPEL to be compatible with HDL (hardware description langauges), which are typically data-flow oriented. otherwise your description seems fairly consistent with functional and dataflow programming. treating variables as they are in mathematics. dataflow is simply a little more relaxed, and HDL has some synthesis limitations.
I liked your FPGA mention, I also think they are the future for AGI. with 4 order of magnitude less power 4 orders of magnitude faster. On Sun, May 17, 2015 at 01:43:32PM -0700, Steve Richfield wrote: > In the past we have discussed the requirements of a prospective AGI > implementation language. On other forums and in conferences I have also > discussed implementation languages for WSI (Wafer Scale Integrated > circuits). WSI isn't quite as crazy as it sounds, because there is a way of > building fault-tolerant processors that removes all limits on size and > complexity, and postage-stamp-sized processors could be made side-by-side > with conductors interconnecting what would otherwise be their bonding pads. > > Ignoring the syntax issues for the moment and looking VERY closely at the > gaps between what can now be written and desired semantics, the problems > seem to center around the present-day concept of "variables". > > In mathematics, variables are truly variable in they state relationships > and NOT the state at any particular moment or condition. In programming, > variables state a particular value at a particular time and conditions, but > in so doing so aren't truly variable any more, but rather are static and > subject to periodic change. Of course, stating the relationships between > static variables is what programming is all about. > > There is a growing body of evidence that the baby has been thrown out with > the bathwater in adopting present-day computer variables to represent AGI > things, because it GREATLY complicates temporal learning. On the VLSI/WSI > side, when turning concepts into long pipelines of ALUs to do really > complex computations at blazing speeds, there is presently NO language that > supports such things, though some people have experimented with a sort of > gelded C where highly constrained loops are unwound into pipelines of ALUs. > > I could envision a language where variables are truly variable, but where > declarations or some sort of control mechanism would allow their > incremental evaluation (within stated bounds) to implement on digital > computers possible, which of course would be ignored when running the same > code on a programmable analog computer. This would be a language of > formulas on continuously varying variables. > > Bidirectional computing could be implemented by solving the formulas for > each of their constituent variables and running each of the resulting > formulas in parallel. This would be less efficient than a genuine > bidirectional implementation, but would provide an apparently usable path > in that direction. > > Such a language would at least make it possible to write the stuff we have > been talking about here, and move it to future WSI processors for real-time > execution. It should also be a relatively simple matter to write a PC > compiler to run this stuff at home - at a zillionth the speed. > > What (if anything) am I missing here? Do you know of any related language > that already exists? APL seems to come closest by turning all variables > into arrays, but APL doesn't actually get there, though it WAS used to help > design the IBM-360 series of computers > > Thoughts? Suggestions? Ideas? > > Steve > > > > ------------------------------------------- > AGI > Archives: https://www.listbox.com/member/archive/303/=now > RSS Feed: https://www.listbox.com/member/archive/rss/303/5037279-a88c7a6d > Modify Your Subscription: https://www.listbox.com/member/?&; > Powered by Listbox: http://www.listbox.com ------------------------------------------- AGI Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424 Modify Your Subscription: https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657 Powered by Listbox: http://www.listbox.com
