skaller wrote: >>>> 1.3: multimethods >>>> >>>> >>> Not sure these make sense. >>> >>> >> I'm a big fan of the lisp multimethods for their object system, >> > > but Lisp is dynamically typed, Felix isn't. This makes a big > difference: OO systems with dynamic typing are quite different > from those with static typing. >
I think we could do it if all our objects have the vtables, as I think a naive implementation is just using the using the typeid of the objects, and checking if that tuple is in a dictionary, and walking up the inheritance tree if it isn't. It should be just a slightly more complicated form of single dispatch. > Statically typed OO is broken, and multi-methods do nothing > to fix the problem: on the contrary they just confuse people > into believing it is possible to fix the problem, when in > fact the problem is fundamental -- OO doesn't and cannot > work, end of story -- except in limited circumstances. > Indeed those limits both enlighten us when OO is useful > and simultaneously condemn the idea it is a general development > paradigm as a fraud. > Oh I completely agree. OO has been used for far too many things. I see it more useful to consider as the dual of pattern matching, where objects are open matching, and traditional pattern matching is closed matching. The best description between the two I've seen is that if you have a lot of types with a small amount of code, it makes sense to group them via functions and pattern matching per compilation unit. This is best shown with something like a compiler. OO shines when there's a small amount of types and a large amount of code. Here, it can be useful to group functions for one type per compilation unit. I'd say a decent example of this would be, say, a scene graph, where you have a small amount of weakly interacting nodes, but the code is quite complicated (I say decent, because I wrote a closed matching scene graph a couple years ago, and it worked out pretty well). > Dynamically typed systems are different because they're *expected* > to fail at run time: there's no concept of type safety in the > first place. So method lookup is just an arbitrary algorithm, > and a multiple dispatch algorithm can be useful. > > >> fun collide(x:Shape, y:Shape) = // generic bounding box collision >> fun collide(x:Box, y:Box) = // optimized box collision >> fun collide(x:Sphere, y:Shape) = // optimized sphere-bounding box collision >> fun collide(x:Sphere, y:Sphere) = // optimized sphere collision >> fun collide(x:Sphere, y:Box) = // optimized sphere-box collision >> > > This is nothing more than an open form of a match: > > match A_shape, B_shape with > | Box of b, Sphere of s => .. > ... > > except the matching construction is closed, and therefore > able to robustly check all the known cases (though in Felix > the exhaustion check isn't being done :) > I believe we can at link time statically determine a dispatch algorithm for each multimethod. Furthermore, I believe at link time we can determine if there are any missing multimethod functions, and emit a warning/error, just like pattern matching. The only time this would become an issue is if we end up dynamically loading modules that would require changes to the dispatch tables, then they'd have to be regenerated, and optionally rechecked for completeness. > This is precisely the kind of problem which CANNOT be solved > with OO, and multiple dispatch does nothing to help. It just > confuses you into believing there is a solution when there > isn't. > > Cecil allows the above kind of thing. Can you see the problem? > Hint: the multi-methods break encapsulation. > Well it does in the same sense that destructuring via pattern matching breaks encapsulation, just like the visitor pattern as well. You have to do something if you have a binary problem, such as collision. Furthermore, we can offer an optimum implementation, as opposed to projects needing to reimplement it when it's needed. > In the pattern matching solution we ADMIT that it cannot > be done with abstraction: we have to work directly with > representations. But OO LIES and pretends you can have > a base abstraction .. and so you can write algorithms > using those abstractions .. only to find there's no way > to implement the required methods. > > In the example, it is clearly a bogus solution. > Using type information is like this is wrong: > it defeats the fundamental concept of modularity: > the Open/Closed principle. > > What happens if I invent a new kind of Box, say Box2? > How do even know which multi-methods to implement? > It depends. Multimethods aren't appropriate for every situation, but there are some cases when the classes are weakly interacting that it becomes useful. Rather than Box2, consider say a heightfield. If we're lazy, we could only implement collision between a heightfield and the root shape object, and specialize it for, say, a wheel object to implement better interaction. For most objects, basic collision is good enough, but occasionally we need a little more for certain types. > Clearly the solution is quadratic in the number of cases. > In the pattern matching system that is manifest in the source, > and is managable because the collection of cases is a CLOSED type. > > In the OO solution it is, and must be open, which means there's > no way to add new types incrementally. The OO way is to add > new methods with the types, which is linear. > > linear doesn't fit into quadratic :) > I know :) I completely agree with you that OO dispatching isn't appropriate in most situations. But there are a couple where it is, and I hope I showed some of them. >> And the dispatcher would automatically determine the most specific match >> between the two objects. >> > > How? Felix doesn't support any kind of subtyping: at best > there are some coercions (throw out some fields of a record > for example), but all that is handled at compile time. > Oh, yeah, that could be added to the list. Wouldn't that be required if we were going to add inheritance to our classes? >>> Care needed: 'metaprogramming' is a bogus idea. It's a >>> way of giving up on what is really required: better >>> polymorphism. >>> >>> >> I should have been a bit more clear. I meant the whole metaocaml-like >> quoting. >> > > Yes. But that's a lame implementation of what is really required: > polyadic programming, aka higher order polymorphism. > > [snip] > > People use 'generic' programming or 'staged evaluation' or > 'partial evaluators' or 'meta-programming' and even > 'dynamic typing' to try to make this work. > > It is all known to be wrong. It is all hacks to get closer > to what is REALLY wanted: polyadic programming. > > Thats awesome. When are you going to implement it? :) That would get rid of a lot of need for metaprogramming, but not all of them. For instance, the inverse of generics with the classic "generate an optimized algorithm/data structure from X options". The metaocaml guys give generating a gaussian elimination algorithm example here: http://www.cas.mcmaster.ca/~carette/publications/ge.pdf. I don't think we have an easy way to do this yet, other than using unsafe macros. I would think it'd be awesome if felix could cover all of these situations, with support for metaprogramming and polymorphic/path/pattern generics. >> True. However, llvm also can generate c code, which could be a nice stopgap. >> > > But I don't think it is worth it -- it need to generate native > code for all commonly available processors or it is useless. > Or .. > Well, it'll come eventually. Since apple will eventually migrate to x86-64, and since it's rumored that llvm will be integrated into the next apple os, it'll have to get that backend eventually. The bytecode can be converted into portable C pretty easily, so it'd be relatively easy to send that to a native C compiler. However, I bet that x86-64 support will be added before we even get a llvm backend working :) >> I was actually thinking of llvm's bytecode and interpretation. >> > > That's a possibility. The problem is .. we'd have to build > llvm which is itself a major toolkit. That's a bit scary at the > moment :) > llvm is a huge toolkit, if you take in consideration to their gcc frontend. We'd have to keep it external to felix. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
