mshute@r4.uucp (Malcolm Shute) (02/21/90)
In article <1639@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >[...] the difference between encoded (paper tape) and structural >(card deck) representations of data. In encoded representations the >relationships among parts of composite data are encoded within the data, in >structural representations they are part of the data structure; [...] >I know of languages that are mostly structural (Lisp) [...] >[...] most architectures are structural (machine programs are represented as >graphs), but some could be argued to be encoded (e.g. reduction machines). But machines which employ String Reduction are generally executing something which looks like low level Lisp, so by your definition will be 'card-deck' machines; and machines which employ Graph Reduction must surely fit also into your 'structured representation' category. So I am unclear about your definitions here... can you elaborate. (Incidentally, since all functional and single assignment languages can be shown to be mere syntactic variants of each other, a machine which has a low level functional language as its machine code must have the same attributes as high level functional languages. I'm assuming that you are talking about functional-Lisp here (pure-Lisp), of course). Malcolm Shute. (The AM Mollusc: v_@_ ) Disclaimer: all
pcg@aber-cs.UUCP (Piercarlo Grandi) (02/22/90)
In article <983@m1.cs.man.ac.uk> mshute@r4.UUCP (Malcolm Shute) writes: In article <1639@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >[...] the difference between encoded (paper tape) and structural >(card deck) representations of data. In encoded representations the >relationships among parts of composite data are encoded within the data, in >structural representations they are part of the data structure; [...] >I know of languages that are mostly structural (Lisp) [...] >[...] most architectures are structural (machine programs are represented as >graphs), but some could be argued to be encoded (e.g. reduction machines). But machines which employ String Reduction are generally executing something which looks like low level Lisp, so by your definition will be 'card-deck' machines; and machines which employ Graph Reduction must surely fit also into your 'structured representation' category. So I am unclear about your definitions here... can you elaborate. In a fuzzy way -- I covered may back in the other article saying that very few examples are "pure". I think that things like the SK combinator reduction systems (with which I am not very familiar -- had a look at them many years ago) are really processing a string using a parser. They don't really navigate the program. The use of combinators means that the structural relationships among parts of the program are encoded in the program, not out-of-band. Frankly I am hard pressed to think of an architecture that is really encoded. Computers are not good at dealing with encoded information, humans are. That's why parsing and prettyprinting phases exist, after all (the other reason is that computers deal with electric and magnetic "charges", humans with "wawes"). -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
mshute@r4.uucp (Malcolm Shute) (02/23/90)
In article <1656@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > In article <1639@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > >[...] the difference between encoded (paper tape) and structural > >(card deck) representations of data [...] >The use of combinators means that the structural relationships >among parts of the program are encoded in the program, not out-of-band. > >Frankly I am hard pressed to think of an architecture that is really >encoded. [...] Presumably, an architecture which supports only S and K combinators in its instruction set (plus a few luxuries like I,B,C,+,- and integers) would, by your definition, be such an example. Malcolm SHUTE. (The AM Mollusc: v_@_ ) Disclaimer: all