John's Emails	Strip links 4
Strip links 2
To: Frank Schuurmans <frank@bio.vu.nl> Hi Frank, >> Now if we actually PROGRAM using the same linking principles then I think >> you may agree that it will still be very easy to find your way around and >> hence to EDIT, TRACE, RUN and DEBUG programs - the four big ones. If we >> can produce a "zoomable" graphical plan of the whole labyrinth then >> things could be even easier. I don't know how to do this yet. >for this zoomability we need self similarity. Could you say in a bit more detail how zoomability could achieved using self similarity, in practice. >I hope my idea's are clearer to you know. Stripping links from hups >doesn't mean you lose the ability to map, it means the map information is >completely seperated from the operators. Secondly it is possible to draw >a lot of maps using the same hups. I'm afraid I may have misunderstood what you were saying. For me to really understand, you may have to give some explicit examples. At the moment I can't follow what you mean. In the present webneuron idea, all operators (+ * / etc) are in the script which is inside the webneuron (see http://brain.eu.org/693.htm). These operators can be used in combination with statements such as IF, to change link data, e.g. IF (inlink1 + inlink2) > 5 outlink3 = 10 ELSE outlink3 = 0 ENDIF It will be necessary also to automatically make/delete links. For a new link from say existing webneuron A to existing webneuron B, this may best be done using a temp websub with two inputs, i.e. input1 URLA (caller A) input2 URLB (target B) and the temp websub script just something like:- START CREATE_NEURON webaxAB Create a new webneuron which will be the webaxon of the new link from A to B. Call this new webneuron, webaxAB. MAKE_LINK(URLA, webaxAB) caller to webaxon link MAKE_LINK(webaxAB, URLA) webaxon to target link END Thus the caller and target are now linked via webaxAB . The interpreter would do the work of actually locating and adding to the input and output lists in webneurons A and B. The initial data in the webaxon would usually be null or undefined. and to delete a link:- START DELETE_LINK(URLA, URLB) END The scripts are simplified, and need improving to allow for multiple links from A to B. This is my current understanding of how operators and links work together. It would help me if you could say what parts of these examples you would change when we include your idea. >> A further point to add is that we could BOTH have our ways and a winner >> may emerge. > >I hope you see that my idea means we have both our ways. I don't really understand how you can remove the webneuron links and still make a map. >> i.e. in the webneuron script we can build in as much logic >> flow as we like. We can include WHILE, FOR, GOSUB, - whatever you like. >> For a particular application you may then just have one massive webneuron >> with no links, just loads of tangled script if that's what you like.. > >I don't like the idea of applications. Nor do I, I just use it because it is expected. I will try to stop this. there is really only one application - i.e. the whole network. Linking applications can be problem for a conventional OS. Best to remove the term altogether in relation to weblets. >> It may help my case to send you a pictorial of webneuron type structures >> implemented in assembler. I designed most of this several years ago, but >> it is remarkably simple. Only a few structures, functions, small kernel, >> and a look-up table are required to get the ball rolling. Even if we >> don't use assembler, the assmebler implementation may be good for >> theorising about how the system should be built. I will try and send it >> soon but I am making some adjustments to fit in URL's to the look-up >> table. > >It might help me understanding your view better. > >> By the way Frank, thank you very much for continuing with me. I believe >> our chances of success are increased by mutual support. > >The discussion with you helpt to clear up my own idea's on programming. And >at the moment I see possiblilities to join concepts. As I metioned before >my idea's about programming is a more biological way. If you are interested >in the logic of seperating flow controle from operators, the way program >starts to look like (actually a more powerful way than) DNA coding. Please >say so, I'll try to explain it. Yes, I do not understand your idea to separate flow control from operators, please try to explain. This sounds most interesting about DNA. Obviously protein formation involves a sort of programming language of the DNA. This is something I have not followed up. I have concentrated on a larger scale view (neurons and axons) and neglected the inner workings of the neuron, except to say that these inner workings could possibly be modeled by the webneuron script, or attached/nested webfuns.