3 ms·
> Being properly OO kind of messes up the way alot of the HoF stuff works as well, since you don't have a bunch of functions that operate on strings, you have m
by chimeracoder 13y ago
> Being properly OO kind of messes up the way alot of the HoF stuff works as well, since you don't have a bunch of functions that operate on strings, you have methods on string.
It doesn't really - methods are nothing more than closures of general functions around a specific value for the implicit parameter (usually the first parameter). The syntax for doing this in Lisp is pretty straightforward, and that's the way CLOS is structured.
And for what it's worth, Alan Kay (who coined the term "object-oriented") himself said (in 2003!) that the only two object-oriented languages he was aware of were Smalltalk and LISP.
- cgag 13y agoI 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..... :'(