Hi Ralf, On 6/6/05, Ralf Lammel <[EMAIL PROTECTED]> wrote: > Re: your enumeration. Let me add one more bullet. > In cases where inheritance is about abstract base classes > and concrete subclasses ((add interface polymorphism likewise)) > you can use a (for unknown reasons) unappreciated pattern for > extensible datatypes in Haskell: > http://homepages.cwi.nl/~ralf/OOHaskell/src/interpreter/extensible.hs > (Note: conceptually unrelated to OOHaskell) >
Okay. I wasn't looking for that kind of inheritance but thanks for bringing it in. > Re: OOHaskell > Thanks for calling this a very good and thorough attempt :-) > I would really like to understand why you think that > a) this could possibly be a "huge hack" Well, please don't pay attention to my wording ;) It's only my beginner's narrow view of a paper targeted at more advanced users. That's why I added the last sentence in my initial post. I regard your work as the most comprehensive I've seen on the topic. > b) "awkward syntax" would be involved. > > Regarding a), could it be that you are overwhelmed > by the details of the implementation of OOHaskell' > *typeful* object system? Wouldn't you be similarly concerned > when looking at details of *any* other object system of *any* > other *typed* language? I certainly am. > (( We are currently massaging the OOHaskell paper. > From what you say, it might seem appropriate to emphasize > the OO programming API more clearly, while moving > implementation details of OOHaskell out of the face > of a programmer who migrates from C#/Java to Haskell. )) > > Regarding b), could it be that you would want to see > special keywords in your face, rather than thinking > in terms of records, monadic functions, open fixpoints, > closing fixpoints, ...? If yes, I guess that's an valid > desire. If there was a mainstream technique for Haskell > syntax extension, we want to use it for OOHaskell. Yes I do, as most of us would I believe. I remember you talking in the paper about adding syntactic sugar to OOHaskell to make it more convenient. That would certainly ease the path for Haskell starters. But, from what you're saying, I understand you must be hitting a wall somewhere. I don't say sugar is essential but it helps. You know I just don't feel comfortable using concepts I don't fully understand and OOHaskell relies on many advanced ones. The standard "do" notation is such a nice example of syntactic sugar, it allows you to use monads without even knowing it. The point here is that when you use the "do" notation, you don't have the feeling you're using something you don't fully master. But I'm not gonna lecture you on this ;) Regarding your paper, all I can say is that I'm not against a version targeted at more entry-level users ! This sounds like a very good idea. Otherwise, I'll certainly go back to your work, but once I got the necessary knowledge to tackle it. In the meantime I'll be keeping an eye on the project for incoming events. Slightly off-topic, but I'm sure there are many people out there, coming from the same background as mine, who have a hard time getting into Haskell just because there's no "Haskell for Java/C++/OO programmer". The ice on the cake being the Haskell way of naming its structures, that is so misleading for a Java programmer. If you knew how long it took me only to figure that Haskell names its interfaces "classes" and its classes "instances", you wouldn't believe me. Cédric _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
