krulwich@ils.nwu.edu (Bruce Krulwich) (08/24/90)
matthias@titan (Matthias Felleisen) writes: >Guillermo J. Rozas writes that "since [Scheme] is such that even >numbers and strings (and pairs, etc.) can be built out of the very >powerful glue of procedures." I disagree. Please show us how to build >numbers such that number? and procedure? work and our programs still >work, too. My guess is that you could do this pretty easily, although you probably wouldn't want to. The typical example of this type of thing is replacing booleans and conditionals with LAMBDA's and calls, with: #T => (lambda (t-val f-val) t-val) #F => (lambda (t-val f-val) f-val) (IF <bool> <t-val> <nil-val>) => (<bool> <t-val> <f-val>) You could probably do the same with integers, by replacing them with closures that take one argument, say a symbol from set of {NUMBER?, DEC, INC, ZERO?}, and return the appropriate value (boolean's in the first and last case, new numbers in the middle two cases). The numerical values could be stored within the closures as lists whose length is the value of the integer in question. More complex numerical types could be built on top of this. You'd have to then change PROCEDURE? to do a test to make sure that its argument wasn't a number (or a boolean, etc), but this shouldn't be too hard. If all types were made of procedures, then there could be a standard argument to pass to an object to determine its type. Clearly this isn't something that you'd WANT to do (unlike the boolean case that has some appeal), because constructs that are closer to machine implementations can be manipulated so much better, but it does seem to be possible. (If you're a logician type, constructing numbers and functions on them from pure predicate calculus has been done, e.g., in Peter Andrews's book "An Introduction to Mathematical Logic and Type Theory: To Truth Through Proof.") Bruce Krulwich Institute for the Learning Sciences
krulwich@ils.nwu.edu (Bruce Krulwich) (08/24/90)
In article <1475@anaxagoras.ils.nwu.edu>, I wrote: >The typical example of this type of thing is replacing booleans and >conditionals with LAMBDA's and calls, with: > > #T => (lambda (t-val f-val) t-val) > #F => (lambda (t-val f-val) f-val) > (IF <bool> <t-val> <nil-val>) => (<bool> <t-val> <f-val>) When writing this I forgot to wrap the (LAMBDA () ...)'s around <t-val> and <f-val> in the IF transformation, and add evaluation of the appropriate thunk in the #T and #F procedures. This is necessary in order to have only the appropriate value evaluated. Bruce Krulwich Institute for the Learning Sciences