@Jon, You posted a True-False example and said that this was an example that open-world languages couldn't find errors in; but I posted the equivalent PEC code and showed that it produced a similar error message to ML (including giving an example of what was wrong). Therefore I would contest that there is at least one multiple-dispatch- open-world language with just as robust error checking, PEC.
There are plenty of examples of when you want to increase the expressions available: 1. A syntax tree for a programming language that is evolving - adding new expressions 2. Adding new numeric types, e.g. if you have int and real and want to add complex or matrix 3. Adding new list types that might have different performance/memory/ concurrency trade offs 4. It is also useful to provide partial implementations and leave the user of the API to complete the class - abstract classes 5. etc. By the way: I am not contesting that Java is perfect, indeed I have written an expanded version - PEC, or that functional programming doesn't have its good points, PEC includes immutable types for example. I would also like to be able to add/remove methods to an already compiled class, this is one of the nice features of dynamic languages like Ruby. But I think functional languages like ML and Haskell have at least as many problems as current OO languages and I would also probably go with Haskell and Clean as an improvement over ML, particularly the way they handle mutable data. To me Scala is a step in the right direction, so is Fortress, and I hope PEC. I also hope other languages will follow. Howard. On Nov 13, 10:32 pm, Jon Harrop <[EMAIL PROTECTED]> wrote: > On Tuesday 13 November 2007 07:30, hlovatt wrote: > > > @Jon, > > > You keep saying that you loose type checking with multiple dispatch - > > that isn't true. > > If you make your code very generic, e.g. using multiple dispatch, then you > undermine static checking. That is not specific to multiple dispatch: using > polymorphic variants in the same way also undermines static checking in > exactly the same way. > > My advice is to avoid this kind of genericity. > > This whole discussion just boils down to the recent fad of trying to solve the > expression problem in OO languages to test their expressiveness. While that > may be an interesting academic exercise, I believe it has no practical > importance. > > -- > Dr Jon D Harrop, Flying Frog Consultancy > Ltd.http://www.ffconsultancy.com/products/?e --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
