3 ms·
I guess it's not actually about OO, more a syntactic thing of having that special implicit parameter, and needing to transform methods methods into procs that c
by cgag 13y ago
I guess it's not actually about OO, more a syntactic thing of having that special implicit parameter, and needing to transform methods methods into procs that call call the method on their parameter, rather than just passing around functions.
edit: I suppose that the code "f", invokes f with no arguments rather than returns the method with name f also complicates things
- chimeracoder 13y ago> I suppose that the code "f", invokes f with no arguments rather than returns the method with name f also complicates things Why should it? "a.f(b, c, d)" is just "(apply #'f a b c d)". "a.f" is just (apply #'f a). "f" is just (apply #'f). This assumes that you know the type of f, of course (f could be a string, which should't be applied). But that's not really much of an issue - you just do something like (define (naive-evaluate f) (if (applyable-p f) (apply #'f) f)) where "applyable-p" checks if "f" is a lambda term that has any free (unbound) variables. This isn't the most efficient underlying implementation, but you get the idea. From the perspective of the lambda calculus, OO is dead simple. On a side, note, writing this example out reminded me of how much I really miss writing Lisp every day..... :'(