[Haskell-cafe] RE: Re[4]: [Haskell] Dynamic binding
Ralf Lammel
ralfla at microsoft.com
Thu Jun 23 15:40:13 EDT 2005
Bulat,
a) building (i) a list of data is fundamentally different
from building (ii) a list of anticipated results of each datum.
I would be surprised to hear that this counts as a valid technique.
BTW, you can do the *same* in a lazy OO language. (No lazy OO language
at hand -- well lazyness can be simulated.)
Anyway, even if people end up coding as you propose,
it won't work in general. Think of mutation methods that
change the state but preserve the type. Then your list will
still be heterogonous. NO?
b)
You wrote:
> this state is just don't need to appear in interface definition :)
> circle x y r
You are not talking about state but constructor arguments.
Please have a look here:
http://www.angelfire.com/tx4/cus/shapes/cpp.html
Circle Interface (Circle.h)
class Circle: public Shape {
public:
Circle(int newx, int newy, int newradius);
int getRadius();
void setRadius(int newradius);
void draw();
private:
int radius;
};
[See getRadius and setRadius)
In OO, mutable state tends to leak to the interface,
perhaps not as public fields, perhaps not even as public
proxy properties (but in the shapes example, it *does*), but
then still as sublcass-specific interface member.
Anyway, I am happy to add your and Lennart's proposals
as appendices to the OOHaskell saga.
And finally, Bulat, I agree with your point that
> original exercise was about OO way to solve some problem. i want
> to say that in Haskell it's better in most cases to use another,
> functional way
Thanks,
Ralf (returning to his VB problem)
> -----Original Message-----
> From: Bulat Ziganshin [mailto:bulatz at HotPOP.com]
> Sent: Thursday, June 23, 2005 4:55 AM
> To: Ralf Lammel
> Cc: Andrew Ward; Pal-Kristian Engstad; haskell-cafe at haskell.org
> Subject: Re[4]: [Haskell] Dynamic binding
>
> Hello Ralf,
>
> Thursday, June 23, 2005, 11:36:20 AM, you wrote:
>
> >> just create list of draw functions itself:
> >>
> >> [drawCircle (10,10) 5, drawSquare (20,20) 10]
>
> RL> No! the exercise is about lists of shapes
> RL> not lists of results of drawing shapes.
> RL> This is clearly a major difference.
>
> in cases where you need to call only one function on created objects,
> you can just insert in list calls to this functions (not their
results! i
> suppose
> that drawXXX functions has "... -> IO ()" type)
>
> in cases where you need to call several functions for this object, you
> can insert in list tuple or structure for each object, as i do in next
> example. original exercise was about OO way to solve some problem. i
want
> to say that in Haskell it's better in most cases to use another,
> functional way
>
> RL> Bulat wrote:
>
> >> for more complex tasks - declare interface as a structure:
> >>
> >> data ShapeInterface = Shape { draw :: IO (),
> >> moveTo :: Point -> IO (),
> >> calcArea :: Float
> >> }
>
> RL> No! You miss the point that the different shapes
> RL> differ regarding state types.
> RL> You don't have a chance when you use one datatype.
>
> this state is just don't need to appear in interface definition :)
>
> see for example:
>
> data ShapeInterface = Shape { draw :: IO (),
> calcArea :: Float
> }
>
> circle x y r = Shape { draw = drawCircle x y r,
> calcArea = pi*r*r
> }
>
> square x y size = Shape { draw = drawSquare x y size,
> calcArea = size*szie
> }
>
> figures = [circle 1 2 3, square 4 5 6, circle 7 8 9]
>
>
>
>
>
> if you need to maintain mutable state, this is also not a problem:
>
> data ShapeInterface = Shape { draw :: IO (),
> moveTo :: (Int,Int) -> IO (),
> calcArea :: Float
> }
> circle x y r = do
> center <- ref (x,y)
> return Shape { draw = val center >>= drawCircle r
> , moveTo = (center=:)
> , calcArea = pi*r*r
> }
> main = do
> figures <- sequence [circle 1 2 3, square 4 5 6, circle 7 8 9]
> mapM_ draw figures
> mapM_ (moveTo (0,0)) figures
> mapM_ draw figures
>
> ref=newIORef
> val=readIORef
> (=:)=writeIORef
>
>
> RL> haskell-cafe?
>
> as you wish :)
>
> --
> Best regards,
> Bulat mailto:bulatz at HotPOP.com
>
>
More information about the Haskell-Cafe
mailing list