Re: [Haskell-cafe] Iteratee, ghc 6.12/7.0 strange behaviour -epollControl: permission denied (Operation not permitted)
I tried with both 7.0.2 and 7.0.3 -Original Message- On Mon, Mar 28, 2011 at 7:31 PM, Michael A Baikov pa...@bk.ru wrote: I am still playing with lastest iteratee and i think i found something strange. let's suppose we have a file test.hs like this: import Data.Iteratee import Data.Iteratee.IO import Data.Iteratee.Char main = fileDriver printLines /etc/passwd It works fine when executed via runhaskell / ghci in ghc 6.12. Compiled version in ghc 7 also works, but when i am trying to execute it via runhaskell / ghci i am getting this error: iter.hs: epollControl: permission denied (Operation not permitted) Any ideas? Make sure you have at least GHC 7.0.2. There were some I/O manager bugs in 7.0.1. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] working off a Yesod example file, need help lifting values from one monad into another. (and probably other things too).
On 29 March 2011 05:00, Michael Litchard mich...@schmong.org wrote: I just noticed those. I think that came from hpaste. The first mail was a cut and paste from a post I made there. When I went to look at your reply, I had the very same question as you. IIRC IE users have this problem, it copies the line numbers too. To avoid it you can just click 'view raw file': http://hpaste.org/raw/45119/working_off_a_yesod_example_fi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Iteratee, ghc 6.12/7.0 strange behaviour -epollControl: permission denied (Operation not permitted)
Could you please file a bug at http://hackage.haskell.org/trac/ghc/ Give an as small reproducible test case as possible and as much information about your system as possible. Thanks! Johan 2011/3/29 Michael A Baikov pa...@bk.ru: I tried with both 7.0.2 and 7.0.3 -Original Message- On Mon, Mar 28, 2011 at 7:31 PM, Michael A Baikov pa...@bk.ru wrote: I am still playing with lastest iteratee and i think i found something strange. let's suppose we have a file test.hs like this: import Data.Iteratee import Data.Iteratee.IO import Data.Iteratee.Char main = fileDriver printLines /etc/passwd It works fine when executed via runhaskell / ghci in ghc 6.12. Compiled version in ghc 7 also works, but when i am trying to execute it via runhaskell / ghci i am getting this error: iter.hs: epollControl: permission denied (Operation not permitted) Any ideas? Make sure you have at least GHC 7.0.2. There were some I/O manager bugs in 7.0.1. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
Wren Thornton wrote: This is often conflated with the iteratee throwing an error/exception, which is wrong because we should distinguish between bad program states and argument passing. I guess this is a matter of different points of view on exceptions. I am a fan of the model of (effectful) computation proposed by Cartwright and Felleisen a while ago: http://okmij.org/ftp/Computation/monads.html#ExtensibleDS In their model, all the computation is done by throwing resumable exceptions -- including the pure computation such as arithmetic and CBV/CBN applications. The similarity of ExtensibleDS.hs with Iteratee should be quite noticeable, especially regarding the part about throwing `errors.' The relation with co-routines is hard to miss: in fact, Iteratees are built upon co-routines, which are being resumed by the enumerator. The error message is the additional piece of data that is being associated with `yield', telling the enumerator to do something extra rather than mere getting the next piece of data and resuming the co-routine. The co-routine is the simplest part of the iteratee; it is the plumbing that takes a long time to engineer. John A. De Goes: 2. Error recovery is ill-defined because errors do not describe what portion of the input they have already consumed; I'm confused about this complaint: if an iteratee encounters an unusual condition or just has a special request, it sends a message that eventually propagates to the responsible enumerator. That enumerator knows how much data it has sent down to iteratees. The RandomIO module http://okmij.org/ftp/Haskell/Iteratee/RandomIO.hs is a good illustration: when the enumerator receives the seek request, it checks if the desired stream offset corresponds to the data already in the current IO buffer. If so, no IO is performed and the iteratee is resumed with the existing buffer data. The tests in the file check for that. Iteratee knows nothing about the buffer or if there is a buffer. Wren Thornton wrote: In an ideal framework the producers, transformers, and consumers of stream data would have a type parameter indicating the up-stream communication they support or require (in addition to the type parameters for stream type, result type, and side-effect type). Very true. Currently the design of Iteratees quite resembles that of Control.Exception: everything can throw SomeException. Ideally one would like to be more precise, and specify what exceptions or sorts of exceptions could be thrown -- by Iteratees, and by ordinary Haskell functions. The design of a good effect system is still the topic of active research, although there are some encouraging results. John A. De Goes: 3. Iteratees sometimes need to manage resources, but they're not designed to do so which leads to hideous workarounds; Gregory Collins: The thing which I find is missing the most from enumerator as it stands is not this -- it's the fact that Iteratees sometimes need to allocate resources which need explicit manual deallocation (i.e. sockets, file descriptors, mmaps, etc), but because Enumerators are running the show, there is no local way to ensure that the cleanup/bracket routines get run on error. I used to think that processing several inputs at different paces was indeed a stumbling block. It seemed that an iteratee needed to open a separate file, which it is indeed ill-equipped to do. Fortunately, that difficulty has been overcome, surprisingly in a natural way with no changes to the library: http://okmij.org/ftp/Streams.html#2enum1iter The pleasant surprise is that we can iterate (no pun intended) Iteratee monad transformers, just as we did with (IORT s) monad transformer in the Lightweight Monadic Regions. Thus we maintain the region-like discipline of managing resources. I'm keen to hear of the example that seem to require Iteratee's allocating additional resources. I'd really like to see if any of such cases can be cast it terms of regions, implemented via iterated Iteratee transformers. John A. De Goes: 1. It does not make sense in general to bind with an iteratee that has already consumed input, but there's no type-level difference between a virgin iteratee and one that has already consumed input; I'm not sure I follow. Why should it make a difference between a virgin iteratee and the one that consumed some input. One should think of the Iteratee as two arguments of fold (f and z) bundled together. Why the function being folded over should care how many times it has been applied to input data? It is a pure function, transforming state plus input to a new state. The useful laws of fold hold precisely because the function f is pure and doesn't care. A detailed example showing why you think you need this distinction would be appreciated. 4. Iteratees cannot incrementally produce output, it's all or nothing, which makes them terrible for many real world problems that require both
Re: [Haskell-cafe] object oriented technique
Hi,
just so you know that I have almost no idea what I'm doing, I'm a complete
Haskell noob, but trying a bit I came up with this before getting stuck:
class Drawable a where
draw :: a - String
data Rectangle = Rectangle { rx, ry, rw, rh :: Double }
deriving (Eq, Show)
instance Drawable Rectangle where
draw (Rectangle rx ry rw rh) = Rect
data Circle = Circle { cx, cy, cr :: Double }
deriving (Eq, Show)
instance Drawable Circle where
draw (Circle cx cy cr) = Circle
data Shape = ???
Untill I read about existential types here:
http://www.haskell.org/haskellwiki/Existential_type
And was able to complete the definition:
data Shape = forall a. Drawable a = Shape a
Testing it with a silly example:
main :: IO ()
main = do putStr (test shapes)
test :: [Shape] - String
test [] =
test ((Shape x):xs) = draw x ++ test xs
shapes :: [Shape]
shapes = [ Shape (Rectangle 1 1 4 4) , Shape (Circle 2 2 5) ]
Don't know if this helps...
Cheers,
-Tako
On Tue, Mar 29, 2011 at 07:49, Tad Doxsee tad.dox...@gmail.com wrote:
I've been trying to learn Haskell for a while now, and recently
wanted to do something that's very common in the object oriented
world, subtype polymorphism with a heterogeneous collection.
It took me a while, but I found a solution that meets
my needs. It's a combination of solutions that I saw on the
web, but I've never seen it presented in a way that combines both
in a short note. (I'm sure it's out there somewhere, but it's off the
beaten
path that I've been struggling along.) The related solutions
are
1. section 3.6 of http://homepages.cwi.nl/~ralf/OOHaskell/paper.pdf
2. The GADT comment at the end of section 4 of
http://www.haskell.org/haskellwiki/Heterogenous_collections
I'm looking for comments on the practicality of the solution,
and references to better explanations of, extensions to, or simpler
alternatives for what I'm trying to achieve.
Using the standard example, here's the code:
data Rectangle = Rectangle { rx, ry, rw, rh :: Double }
deriving (Eq, Show)
drawRect :: Rectangle - String
drawRect r = Rect ( ++ show (rx r) ++ , ++ show (ry r) ++ ) --
++ show (rw r) ++ x ++ show (rh r)
data Circle = Circle {cx, cy, cr :: Double}
deriving (Eq, Show)
drawCirc :: Circle - String
drawCirc c = Circ ( ++ show (cx c) ++ , ++ show (cy c)++ ) --
++ show (cr c)
r1 = Rectangle 0 0 3 2
r2 = Rectangle 1 1 4 5
c1 = Circle 0 0 5
c2 = Circle 2 0 7
rs = [r1, r2]
cs = [c1, c2]
rDrawing = map drawRect rs
cDrawing = map drawCirc cs
-- shapes = rs ++ cs
Of course, the last line won't compile because the standard Haskell list
may contain only homogeneous types. What I wanted to do is create a list
of
circles and rectangles, put them in a list, and draw them. It was easy
for me to find on the web and in books how to do that if I controlled
all of the code. What wasn't immediately obvious to me was how to do that
in a library that could be extended by others. The references noted
previously suggest this solution:
class ShapeC s where
draw :: s - String
copyTo :: s - Double - Double - s
-- needs {-# LANGUAGE GADTs #-}
data ShapeD where
ShapeD :: ShapeC s = s - ShapeD
instance ShapeC ShapeD where
draw (ShapeD s) = draw s
copyTo (ShapeD s) x y = ShapeD (copyTo s x y)
mkShape :: ShapeC s = s - ShapeD
mkShape s = ShapeD s
instance ShapeC Rectangle where
draw = drawRect
copyTo (Rectangle _ _ rw rh) x y = Rectangle x y rw rh
instance ShapeC Circle where
draw = drawCirc
copyTo (Circle _ _ r) x y = Circle x y r
r1s = ShapeD r1
r2s = ShapeD r2
c1s = ShapeD c1
c2s = ShapeD c2
shapes1 = [r1s, r2s, c1s, c2s]
drawing1 = map draw shapes1
shapes2 = map mkShape rs ++ map mkShape cs
drawing2 = map draw shapes2
-- copy the shapes to the origin then draw them
shapes3 = map (\s - copyTo s 0 0) shapes2
drawing3 = map draw shapes3
Another user could create a list of shapes that included triangles by
creating
a ShapeC instance for his triangle and using mkShape to add it to a list of
ShapeDs.
Is the above the standard method in Haskell for creating an extensible
heterogeneous list of objects that share a common interface? Are there
better
approaches? (I ran into a possible limitation to this approach that I plan
to ask about later if I can't figure it out myself.)
- Tad
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] object oriented technique
Sorry , the following line got lost in the copy paste:
{-# LANGUAGE ExistentialQuantification #-}
-Tako
On Tue, Mar 29, 2011 at 11:09, Tako Schotanus t...@codejive.org wrote:
Hi,
just so you know that I have almost no idea what I'm doing, I'm a complete
Haskell noob, but trying a bit I came up with this before getting stuck:
class Drawable a where
draw :: a - String
data Rectangle = Rectangle { rx, ry, rw, rh :: Double }
deriving (Eq, Show)
instance Drawable Rectangle where
draw (Rectangle rx ry rw rh) = Rect
data Circle = Circle { cx, cy, cr :: Double }
deriving (Eq, Show)
instance Drawable Circle where
draw (Circle cx cy cr) = Circle
data Shape = ???
Untill I read about existential types here:
http://www.haskell.org/haskellwiki/Existential_type
And was able to complete the definition:
data Shape = forall a. Drawable a = Shape a
Testing it with a silly example:
main :: IO ()
main = do putStr (test shapes)
test :: [Shape] - String
test [] =
test ((Shape x):xs) = draw x ++ test xs
shapes :: [Shape]
shapes = [ Shape (Rectangle 1 1 4 4) , Shape (Circle 2 2 5) ]
Don't know if this helps...
Cheers,
-Tako
On Tue, Mar 29, 2011 at 07:49, Tad Doxsee tad.dox...@gmail.com wrote:
I've been trying to learn Haskell for a while now, and recently
wanted to do something that's very common in the object oriented
world, subtype polymorphism with a heterogeneous collection.
It took me a while, but I found a solution that meets
my needs. It's a combination of solutions that I saw on the
web, but I've never seen it presented in a way that combines both
in a short note. (I'm sure it's out there somewhere, but it's off the
beaten
path that I've been struggling along.) The related solutions
are
1. section 3.6 of http://homepages.cwi.nl/~ralf/OOHaskell/paper.pdf
2. The GADT comment at the end of section 4 of
http://www.haskell.org/haskellwiki/Heterogenous_collections
I'm looking for comments on the practicality of the solution,
and references to better explanations of, extensions to, or simpler
alternatives for what I'm trying to achieve.
Using the standard example, here's the code:
data Rectangle = Rectangle { rx, ry, rw, rh :: Double }
deriving (Eq, Show)
drawRect :: Rectangle - String
drawRect r = Rect ( ++ show (rx r) ++ , ++ show (ry r) ++ ) --
++ show (rw r) ++ x ++ show (rh r)
data Circle = Circle {cx, cy, cr :: Double}
deriving (Eq, Show)
drawCirc :: Circle - String
drawCirc c = Circ ( ++ show (cx c) ++ , ++ show (cy c)++ ) --
++ show (cr c)
r1 = Rectangle 0 0 3 2
r2 = Rectangle 1 1 4 5
c1 = Circle 0 0 5
c2 = Circle 2 0 7
rs = [r1, r2]
cs = [c1, c2]
rDrawing = map drawRect rs
cDrawing = map drawCirc cs
-- shapes = rs ++ cs
Of course, the last line won't compile because the standard Haskell list
may contain only homogeneous types. What I wanted to do is create a list
of
circles and rectangles, put them in a list, and draw them. It was easy
for me to find on the web and in books how to do that if I controlled
all of the code. What wasn't immediately obvious to me was how to do that
in a library that could be extended by others. The references noted
previously suggest this solution:
class ShapeC s where
draw :: s - String
copyTo :: s - Double - Double - s
-- needs {-# LANGUAGE GADTs #-}
data ShapeD where
ShapeD :: ShapeC s = s - ShapeD
instance ShapeC ShapeD where
draw (ShapeD s) = draw s
copyTo (ShapeD s) x y = ShapeD (copyTo s x y)
mkShape :: ShapeC s = s - ShapeD
mkShape s = ShapeD s
instance ShapeC Rectangle where
draw = drawRect
copyTo (Rectangle _ _ rw rh) x y = Rectangle x y rw rh
instance ShapeC Circle where
draw = drawCirc
copyTo (Circle _ _ r) x y = Circle x y r
r1s = ShapeD r1
r2s = ShapeD r2
c1s = ShapeD c1
c2s = ShapeD c2
shapes1 = [r1s, r2s, c1s, c2s]
drawing1 = map draw shapes1
shapes2 = map mkShape rs ++ map mkShape cs
drawing2 = map draw shapes2
-- copy the shapes to the origin then draw them
shapes3 = map (\s - copyTo s 0 0) shapes2
drawing3 = map draw shapes3
Another user could create a list of shapes that included triangles by
creating
a ShapeC instance for his triangle and using mkShape to add it to a list
of
ShapeDs.
Is the above the standard method in Haskell for creating an extensible
heterogeneous list of objects that share a common interface? Are there
better
approaches? (I ran into a possible limitation to this approach that I
plan
to ask about later if I can't figure it out myself.)
- Tad
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Re: [Haskell-cafe] How to best deal with nullPtr from alloca and friends?
Excerpts from Jason Dagit's message of Tue Mar 29 00:43:10 -0400 2011: I was reading up on the documentation for alloca and friends[1], which says, If any of the allocation functions fails, a value of nullPtrhttp://www.haskell.org/ghc/docs/7.0.2/html/libraries/base-4.3.1.0/Foreign-Ptr.html#v:nullPtr is produced. It seems like every example of FFI code that I find which uses alloca ignores the possibility of a nullPtr[2, 3, 4]. So then I started trying out examples with the help of dmwit and others from #haskell. It seems that actually, alloca and friends throw exceptions: dmwit main = allocaArray (2^30) (\ptr - print ((nullPtr :: Ptr Double) == ptr)) dmwit lispy: alloca also throws an exception. dmwit lispy: Or rather, allocaBytes throws an exception, and alloca is implemented in terms of allocaBytes, so I'm *guessing* that alloca throws an exception. I'm on a 64bit version of windows here with more than 4GB of memory to spare for the GHC process. Unfortunately, allocaBytes takes an Int so I can't test it with a request larger than the amount of physical ram I have. You could try testing by setting different limits on the memory usage of your process with ulimit. I'll give a test, but the prevailing wisdom is that if you OOM, you're really out of luck. Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] object oriented technique
Tad,
It doesn't look bad, but depending on what you want to do with the
[ShapeD] aftewards you might not need this level of generality.
Remember that the content of a ShapeD has type (forall a. ShapeC a =
a), so all you can do with it is call class methods from ShapeC. So if
all you do is construct some ShapeD and pass that around, the following
solution is equivalent:
data Shape = Shape {
draw :: String
copyTo :: Double - Double - Shape
-- ^ We loose some information here. The original method of ShapeC
-- stated that copyTo of a Rectangle will be a rectangle again
-- etc. Feel free to add a proxy type parameter to Shape if this
-- information is necessary.
}
circle :: Double - Double - Double - Shape
circle x y r = Shape dc $ \x y - circle x y r
where dc = Circ ( ++ show x ++ , ++ show y ++ ) -- ++ show r
rectangle :: Double - Double - Double - Double - Shape
rectangle x y w h = ... (analogous)
shapes = [rectangle 1 2 3 4, circle 4 3 2, circle 1 1 1]
-- Steffen
On 03/29/2011 07:49 AM, Tad Doxsee wrote:
I've been trying to learn Haskell for a while now, and recently
wanted to do something that's very common in the object oriented
world, subtype polymorphism with a heterogeneous collection. It took
me a while, but I found a solution that meets my needs. It's a
combination of solutions that I saw on the web, but I've never seen
it presented in a way that combines both in a short note. (I'm sure
it's out there somewhere, but it's off the beaten path that I've been
struggling along.) The related solutions are
1. section 3.6 of http://homepages.cwi.nl/~ralf/OOHaskell/paper.pdf
2. The GADT comment at the end of section 4 of
http://www.haskell.org/haskellwiki/Heterogenous_collections
I'm looking for comments on the practicality of the solution, and
references to better explanations of, extensions to, or simpler
alternatives for what I'm trying to achieve.
Using the standard example, here's the code:
data Rectangle = Rectangle { rx, ry, rw, rh :: Double } deriving (Eq,
Show)
drawRect :: Rectangle - String drawRect r = Rect ( ++ show (rx r)
++ , ++ show (ry r) ++ ) -- ++ show (rw r) ++ x ++ show
(rh r)
data Circle = Circle {cx, cy, cr :: Double} deriving (Eq, Show)
drawCirc :: Circle - String drawCirc c = Circ ( ++ show (cx c) ++
, ++ show (cy c)++ ) -- ++ show (cr c)
r1 = Rectangle 0 0 3 2 r2 = Rectangle 1 1 4 5 c1 = Circle 0 0 5 c2 =
Circle 2 0 7
rs = [r1, r2] cs = [c1, c2]
rDrawing = map drawRect rs cDrawing = map drawCirc cs
-- shapes = rs ++ cs
Of course, the last line won't compile because the standard Haskell
list may contain only homogeneous types. What I wanted to do is
create a list of circles and rectangles, put them in a list, and draw
them. It was easy for me to find on the web and in books how to do
that if I controlled all of the code. What wasn't immediately obvious
to me was how to do that in a library that could be extended by
others. The references noted previously suggest this solution:
class ShapeC s where draw :: s - String copyTo :: s - Double -
Double - s
-- needs {-# LANGUAGE GADTs #-} data ShapeD where ShapeD :: ShapeC s
= s - ShapeD
instance ShapeC ShapeD where draw (ShapeD s) = draw s copyTo (ShapeD
s) x y = ShapeD (copyTo s x y)
mkShape :: ShapeC s = s - ShapeD mkShape s = ShapeD s
instance ShapeC Rectangle where draw = drawRect copyTo (Rectangle _ _
rw rh) x y = Rectangle x y rw rh
instance ShapeC Circle where draw = drawCirc copyTo (Circle _ _ r) x
y = Circle x y r
r1s = ShapeD r1 r2s = ShapeD r2 c1s = ShapeD c1 c2s = ShapeD c2
shapes1 = [r1s, r2s, c1s, c2s] drawing1 = map draw shapes1
shapes2 = map mkShape rs ++ map mkShape cs drawing2 = map draw
shapes2
-- copy the shapes to the origin then draw them shapes3 = map (\s -
copyTo s 0 0) shapes2 drawing3 = map draw shapes3
Another user could create a list of shapes that included triangles by
creating a ShapeC instance for his triangle and using mkShape to add
it to a list of ShapeDs.
Is the above the standard method in Haskell for creating an
extensible heterogeneous list of objects that share a common
interface? Are there better approaches? (I ran into a possible
limitation to this approach that I plan to ask about later if I can't
figure it out myself.)
- Tad
___ Haskell-Cafe mailing
list Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
On Mar 29, 2011 10:42 AM, o...@okmij.org wrote: I'm keen to hear of the example that seem to require Iteratee's allocating additional resources. I'd really like to see if any of such cases can be cast it terms of regions, implemented via iterated Iteratee transformers. Hello Oleg, The first example which comes to mind - because I recently implemented this - is HTTP uploads: the input stream can hold N files (the value of N not known ahead of time), and each upload can go to a separate temporary file. If the request stream fails early (e.g. client browser closes connection), any already-created temp files and any open file handles must be cleaned up. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Please allow variation in the Yackage page title
Could you please add a way of varying the title of the Yackage web page? That would make it much easier to work with multiple Yackages at once. For my particular setup, including its port number in the web page title would do the trick. But perhaps the easiest and most general thing would be to add a command-line option for setting the title. Using multiple Yackages is a very simple yet powerful technique to keep cabal versions straight. You can use it to group package versions in various ways - versions that you are currently hacking on, versions that have stabilized but you are not releasing yet while you work on other related packages, versions shared by various teams and subteams of developers, etc. Multiple Yackages are especially useful in combination with cabal-dev, but currently you have to fiddle a little bit to get cabal-dev to use a modified cabal config file. See: http://www.haskell.org/pipermail/haskell-cafe/2011-March/090492.html Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] object oriented technique
Actually, Tako:
data Shape = forall a. Drawable a = Shape a
Can also be done with GADTs:
data Shape where
Shape :: Drawable a = a - Shape
If wouldn't know if one approach is preferable to the other or if is just a
matter of taste.
Your problem, Tad, is kind of common. I ran against it several times. I know
of two ways to solve it :
- The open way (this is your method, with a class ShapeC and datatype
ShapeD which wraps instances of ShapeC)
- The closed way, which can be broken in two alternatives:
* Using a plain Haskell98 ADT:
data Shape = Circle | Rectangle
draw :: Shape - String
draw (Circle ...) = ...
draw (Rectangle ...) = ...
Flexible and simple, but not safe, since you have no way to
type-diferenciate Circles from Rectangles.
* Using a GADT and empty data declarations:
data Circle
data Rectangle
data Shape a where
Circle :: Double - Double - Double - Shape Circle
Rectangle :: Double - Double - Double - Double - Shape Rectangle
And then you can both use Shape a or Shape Circle/Shape Rectangle, which
enables you either to make lists of Shapes or to specifically use Circles or
Rectangles.
The drawback of it is that since you have a closed type (the GADT Shape),
you cannot add a new shape without altering it.
2011/3/29 Steffen Schuldenzucker sschuldenzuc...@uni-bonn.de
Tad,
It doesn't look bad, but depending on what you want to do with the
[ShapeD] aftewards you might not need this level of generality.
Remember that the content of a ShapeD has type (forall a. ShapeC a =
a), so all you can do with it is call class methods from ShapeC. So if
all you do is construct some ShapeD and pass that around, the following
solution is equivalent:
data Shape = Shape {
draw :: String
copyTo :: Double - Double - Shape
-- ^ We loose some information here. The original method of ShapeC
-- stated that copyTo of a Rectangle will be a rectangle again
-- etc. Feel free to add a proxy type parameter to Shape if this
-- information is necessary.
}
circle :: Double - Double - Double - Shape
circle x y r = Shape dc $ \x y - circle x y r
where dc = Circ ( ++ show x ++ , ++ show y ++ ) -- ++ show r
rectangle :: Double - Double - Double - Double - Shape
rectangle x y w h = ... (analogous)
shapes = [rectangle 1 2 3 4, circle 4 3 2, circle 1 1 1]
-- Steffen
On 03/29/2011 07:49 AM, Tad Doxsee wrote:
I've been trying to learn Haskell for a while now, and recently
wanted to do something that's very common in the object oriented
world, subtype polymorphism with a heterogeneous collection. It took
me a while, but I found a solution that meets my needs. It's a
combination of solutions that I saw on the web, but I've never seen
it presented in a way that combines both in a short note. (I'm sure
it's out there somewhere, but it's off the beaten path that I've been
struggling along.) The related solutions are
1. section 3.6 of http://homepages.cwi.nl/~ralf/OOHaskell/paper.pdf
2. The GADT comment at the end of section 4 of
http://www.haskell.org/haskellwiki/Heterogenous_collections
I'm looking for comments on the practicality of the solution, and
references to better explanations of, extensions to, or simpler
alternatives for what I'm trying to achieve.
Using the standard example, here's the code:
data Rectangle = Rectangle { rx, ry, rw, rh :: Double } deriving (Eq,
Show)
drawRect :: Rectangle - String drawRect r = Rect ( ++ show (rx r)
++ , ++ show (ry r) ++ ) -- ++ show (rw r) ++ x ++ show
(rh r)
data Circle = Circle {cx, cy, cr :: Double} deriving (Eq, Show)
drawCirc :: Circle - String drawCirc c = Circ ( ++ show (cx c) ++
, ++ show (cy c)++ ) -- ++ show (cr c)
r1 = Rectangle 0 0 3 2 r2 = Rectangle 1 1 4 5 c1 = Circle 0 0 5 c2 =
Circle 2 0 7
rs = [r1, r2] cs = [c1, c2]
rDrawing = map drawRect rs cDrawing = map drawCirc cs
-- shapes = rs ++ cs
Of course, the last line won't compile because the standard Haskell
list may contain only homogeneous types. What I wanted to do is
create a list of circles and rectangles, put them in a list, and draw
them. It was easy for me to find on the web and in books how to do
that if I controlled all of the code. What wasn't immediately obvious
to me was how to do that in a library that could be extended by
others. The references noted previously suggest this solution:
class ShapeC s where draw :: s - String copyTo :: s - Double -
Double - s
-- needs {-# LANGUAGE GADTs #-} data ShapeD where ShapeD :: ShapeC s
= s - ShapeD
instance ShapeC ShapeD where draw (ShapeD s) = draw s copyTo (ShapeD
s) x y = ShapeD (copyTo s x y)
mkShape :: ShapeC s = s - ShapeD mkShape s = ShapeD s
instance ShapeC Rectangle where draw = drawRect copyTo (Rectangle _ _
rw rh) x y = Rectangle x y rw rh
instance ShapeC Circle where draw = drawCirc copyTo (Circle _ _ r) x
y = Circle x y r
r1s = ShapeD r1
[Haskell-cafe] ANN: improve-0.3.1
ImProve [1] is an imperative DSL for hard realtime embedded applications. ImProve programs are verified with infinite state,unbounded model checking (k-induction, invariant strengthening, SMT). In addition to C, ImProve now supports Simulink [2] as a backend target. Simulink is a popular language for automotive and aerospace control systems. -Tom [1] http://hackage.haskell.org/package/improve [2] http://www.mathworks.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to best deal with nullPtr from alloca and friends?
On Tue, Mar 29, 2011 at 2:37 AM, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from Jason Dagit's message of Tue Mar 29 00:43:10 -0400 2011: I was reading up on the documentation for alloca and friends[1], which says, If any of the allocation functions fails, a value of nullPtr http://www.haskell.org/ghc/docs/7.0.2/html/libraries/base-4.3.1.0/Foreign-Ptr.html#v:nullPtr is produced. It seems like every example of FFI code that I find which uses alloca ignores the possibility of a nullPtr[2, 3, 4]. So then I started trying out examples with the help of dmwit and others from #haskell. It seems that actually, alloca and friends throw exceptions: dmwit main = allocaArray (2^30) (\ptr - print ((nullPtr :: Ptr Double) == ptr)) dmwit lispy: alloca also throws an exception. dmwit lispy: Or rather, allocaBytes throws an exception, and alloca is implemented in terms of allocaBytes, so I'm *guessing* that alloca throws an exception. I'm on a 64bit version of windows here with more than 4GB of memory to spare for the GHC process. Unfortunately, allocaBytes takes an Int so I can't test it with a request larger than the amount of physical ram I have. You could try testing by setting different limits on the memory usage of your process with ulimit. I'll give a test, but the prevailing wisdom is that if you OOM, you're really out of luck. I just want to be clear: You can get alloca and friends to fail well BEFORE you are OOM. Just allocate something larger than the remaining contiguous space. If you're allocating a few KB and you run out of memory that can be bad situation, but I don't think we should treat all allocation failures as if the sky is falling :) Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] SoC / Cabal project proposal: specify Setup.hs dependencies
I've been wanting to share code between cabal projects for some time, and I finally had a chance to write up the rough idea as a simple proposal. Here's the description, with links to the SoC trac and reddit haskell_proposals pages. SoC ticket: http://hackage.haskell.org/trac/summer-of-code/ticket/1602 Reddit: http://www.reddit.com/r/haskell_proposals/comments/ge1zp/cabal_dependency_specifications_for_setuphs/ Non-standard builds often need to implement specific build steps in Setup.hs, specifying a build-type: Custom in the project cabal file. The user hook system works reasonably well for modifying or replacing the specific sub steps of a build, but *implementing* anything more than the simplest logic in Setup.hs is very difficult. A great deal of this difficulty stems from the lack of library support for code in Setup.hs. Adding a cabal section that specifies a build-depends: for Custom (and possibly other) build types would allow developers to reuse build code between projects, to share build system modifications on hackage more easily, and to prototype new additions to cabal. Setup.hs *can* allow arbitrarily complex build system manipulations; however, it is not practical to do so because the infrastructure surrounding Setup.hs doesn't promote code reuse. The addition of dependencies that cabal-install would install prior to building setup.hs and issuing the build would enable developers to produce custom builds that perform complex operations that utilize the high-quality libraries available on hackage. Furthermore, this would provide the means to prototype (and distribute) new cabal / cabal-install features before integrating experimental code into the stable tools. I'm interested in thoughts / feedback about the idea, as well as hearing from anyone interested in pursuing this as a summer of code project :) Thanks! --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Summer of Code Mentors for Language.C
Would anybody be interested in mentoring me for a summer of code project working on language.c? I want to write an internal pre-processor that saves information such as comments and potentially some specially defined annotations, so that code can be analyzed better. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] object oriented technique
Actually, after thinking it back, I found out one other method. The key idea
is to split what is common to every shape with what is not:
data Circle = Circle { cr :: Double }
data Rectangle = Rectangle { rw, rh :: Double }
class Shapeful s where
name :: s - String
fields :: s - String
instance Shapeful Circle where
name _ = Circle
fields (Circle cr) = show cr
instance Shapeful Rectangle where
name _ = Rectangle
fields (Rectangle rw rh) = show rw ++ , ++ show rh
data Shape = forall s. (Shapeful s)
= Shape { sx, sy :: Double,
inner :: a }
drawShape :: Shape - String
drawShape (Shape sx sy inner) = name inner ++ ( ++ show sx ++ , ++
show sy ++ , ++ fields inner ++ )
list :: [Shape]
list = [Shape 10 10 $ Circle 5, Shape 40 40 $ Rectangle 12 10]
Since you loose the exact type of what contains Shape, your class Shapeful
must provide all the necessary information (but that is kind of usual in
Haskell).
The advantage here is that you generalize the position (sx and sy fields)
which are no longer duplicated within Rectange and Circle.
2011/3/29 Yves Parès limestr...@gmail.com
Actually, Tako:
data Shape = forall a. Drawable a = Shape a
Can also be done with GADTs:
data Shape where
Shape :: Drawable a = a - Shape
If wouldn't know if one approach is preferable to the other or if is just a
matter of taste.
Your problem, Tad, is kind of common. I ran against it several times. I
know of two ways to solve it :
- The open way (this is your method, with a class ShapeC and datatype
ShapeD which wraps instances of ShapeC)
- The closed way, which can be broken in two alternatives:
* Using a plain Haskell98 ADT:
data Shape = Circle | Rectangle
draw :: Shape - String
draw (Circle ...) = ...
draw (Rectangle ...) = ...
Flexible and simple, but not safe, since you have no way to
type-diferenciate Circles from Rectangles.
* Using a GADT and empty data declarations:
data Circle
data Rectangle
data Shape a where
Circle :: Double - Double - Double - Shape Circle
Rectangle :: Double - Double - Double - Double - Shape
Rectangle
And then you can both use Shape a or Shape Circle/Shape Rectangle,
which enables you either to make lists of Shapes or to specifically use
Circles or Rectangles.
The drawback of it is that since you have a closed type (the GADT Shape),
you cannot add a new shape without altering it.
2011/3/29 Steffen Schuldenzucker sschuldenzuc...@uni-bonn.de
Tad,
It doesn't look bad, but depending on what you want to do with the
[ShapeD] aftewards you might not need this level of generality.
Remember that the content of a ShapeD has type (forall a. ShapeC a =
a), so all you can do with it is call class methods from ShapeC. So if
all you do is construct some ShapeD and pass that around, the following
solution is equivalent:
data Shape = Shape {
draw :: String
copyTo :: Double - Double - Shape
-- ^ We loose some information here. The original method of ShapeC
-- stated that copyTo of a Rectangle will be a rectangle again
-- etc. Feel free to add a proxy type parameter to Shape if this
-- information is necessary.
}
circle :: Double - Double - Double - Shape
circle x y r = Shape dc $ \x y - circle x y r
where dc = Circ ( ++ show x ++ , ++ show y ++ ) -- ++ show r
rectangle :: Double - Double - Double - Double - Shape
rectangle x y w h = ... (analogous)
shapes = [rectangle 1 2 3 4, circle 4 3 2, circle 1 1 1]
-- Steffen
On 03/29/2011 07:49 AM, Tad Doxsee wrote:
I've been trying to learn Haskell for a while now, and recently
wanted to do something that's very common in the object oriented
world, subtype polymorphism with a heterogeneous collection. It took
me a while, but I found a solution that meets my needs. It's a
combination of solutions that I saw on the web, but I've never seen
it presented in a way that combines both in a short note. (I'm sure
it's out there somewhere, but it's off the beaten path that I've been
struggling along.) The related solutions are
1. section 3.6 of http://homepages.cwi.nl/~ralf/OOHaskell/paper.pdf
2. The GADT comment at the end of section 4 of
http://www.haskell.org/haskellwiki/Heterogenous_collections
I'm looking for comments on the practicality of the solution, and
references to better explanations of, extensions to, or simpler
alternatives for what I'm trying to achieve.
Using the standard example, here's the code:
data Rectangle = Rectangle { rx, ry, rw, rh :: Double } deriving (Eq,
Show)
drawRect :: Rectangle - String drawRect r = Rect ( ++ show (rx r)
++ , ++ show (ry r) ++ ) -- ++ show (rw r) ++ x ++ show
(rh r)
data Circle = Circle {cx, cy, cr :: Double} deriving (Eq, Show)
drawCirc :: Circle - String drawCirc c = Circ ( ++ show (cx c) ++
, ++ show (cy c)++ ) -- ++ show (cr
Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
0.4.9 has been uploaded to cabal, with the new operators. Changes are in the replied-to post (and also quoted below), plus the new operators proposed by Kazu Yamamoto. Here's the corresponding docs (they have examples!) -- -- | @enum =$ iter = 'joinI' (enum $$ iter)@ -- -- #x201c;Wraps#x201d; an iteratee /inner/ in an enumeratee /wrapper/. -- The resulting iteratee will consume /wrapper/#x2019;s input type and -- yield /inner/#x2019;s output type. -- -- Note: if the inner iteratee yields leftover input when it finishes, -- that extra will be discarded. -- -- As an example, consider an iteratee that converts a stream of UTF8-encoded -- bytes into a single 'TL.Text': -- -- consumeUTF8 :: Monad m = Iteratee ByteString m Text -- -- It could be written with either 'joinI' or '(=$)': -- -- import Data.Enumerator.Text as ET -- -- consumeUTF8 = joinI (decode utf8 $$ ET.consume) -- consumeUTF8 = decode utf8 =$ ET.consume -- -- Since: 0.4.9 -- | @enum $= enee = 'joinE' enum enee@ -- -- #x201c;Wraps#x201d; an enumerator /inner/ in an enumeratee /wrapper/. -- The resulting enumerator will generate /wrapper/#x2019;s output type. -- -- As an example, consider an enumerator that yields line character counts -- for a text file (e.g. for source code readability checking): -- -- enumFileCounts :: FilePath - Enumerator Int IO b -- -- It could be written with either 'joinE' or '($=)': -- -- import Data.Text as T -- import Data.Enumerator.List as EL -- import Data.Enumerator.Text as ET -- -- enumFileCounts path = joinE (enumFile path) (EL.map T.length) -- enumFileCounts path = enumFile path $= EL.map T.length -- -- Since: 0.4.9 -- Minor release note -- 0.4.9 and 0.4.9.1 are the exact same code; I just forgot a @ in one of the new docs and had to re-upload so Hackage would haddock properly. There is no difference in behavior. On Monday, March 28, 2011 10:50:45 PM UTC-7, John Millikin wrote: Since the release, a couple people have sent in feature requests, so I'm going to put out 0.4.9 in a day or so. New features will be: - tryIO: runs an IO computation, and converts any exceptions into ``throwError`` calls (requested by Kazu Yamamoto) - checkContinue: encapsulates a common pattern (loop (Continue k) = ...) when defining enumerators - mapAccum and mapAccum: sort of like map and mapM, except the step function is stateful (requested by Long Huynh Huu) Anyone else out there sitting on a request? Please send them in -- I am always happy to receive them, even if they must be declined. --- Also, I would like to do a quick poll regarding operators. 1. It has been requested that I add operator aliases for joinI and joinE. 2. There have been complaints that the library defines too many operators (currently, 5). Do any existing enumerator users, or anyone for that matter, have an opinion either way? The proposed operators are: -- infixr 0 =$ infixr 0 $= (=$) :: Monad m = Enumeratee ao ai m b - Iteratee ai m b - Iteratee ao m b enum =$ iter = joinI (enum $$ iter) ($=) :: Monad m = Enumerator ao m (Step ai m b) - Enumeratee ao ai m b - Enumerator ai m b ($=) = joinE -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] object oriented technique
Should that be inner :: s?
data Shape = forall s. (Shapeful s)
= Shape { sx, sy :: Double,
inner :: a }
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] WANTED: Compensated Haskell Hacker for Language Project
Hi Jake! My only question is this: what does your language offer that others do not with respect to soft real time systems? The language you describe in the linked forum thread looks neat, but I think I'm missing the reasoning behind its design. Why is this design beneficial for soft real time compared to other high level languages? The main thrust of the design is to provide nearly the power of Lisp and ML's semantics in a form that is syntactically palatable to the mass of intelligent industry programmers. While industry programmers typically prefer C-style languages, it's just not possible to build a C-style language with a reasonable macro development (language orientation) experience due to C's inherent syntactic complexities. Further, it seems to have been historically demonstrated that C-family programmers are not willing to make the a syntactic leap as far as say, Lisp or Ocaml. Barring the provision of yet another C-style language, there's another set of languages many C-family programmers do rather like: Ruby and Python. So by finding a direct mapping from s-expressions to a language with an feel and visual appeal similar to Python that ALSO approaches the machine efficiency of C++, I hope to create a lisp- and ML-derived language that is accessible to an audience wider than existing functional languages seem to have reached. As you can see, the design does admit some semantic compromises in the name of syntax and efficiency, but the compromise is surprisingly (at least to me) minimal. One compromise made in the name of C++ efficiency is the use of a machine word-sized default number type rather than the default number type used in lisp or Haskell. Of course, arbitrary number types can be made available naturally via a library using simple binary operation overrides, but they are not the default when you type the literal 5. I've discovered, at least to my own current satisfaction, that bringing lisp- and ML-style semantics to the masses is possible with less semantic compromises than previously seemed possible. By providing a language that industry programmers feel comfortable with, I hope to move as many of them as possible into the functional / language-oriented world. But more than that, I'm just designing the language I wish I could use everyday instead of C++ and C# :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] WANTED: Compensated Haskell Hacker for Language Project
2011/3/29 Bryan Edds bryane...@yahoo.com: Hi Jake! My only question is this: what does your language offer that others do not with respect to soft real time systems? The language you describe in the linked forum thread looks neat, but I think I'm missing the reasoning behind its design. Why is this design beneficial for soft real time compared to other high level languages? The main thrust of the design is to provide nearly the power of Lisp and ML's semantics in a form that is syntactically palatable to the mass of intelligent industry programmers. While industry programmers typically prefer C-style languages, it's just not possible to build a C-style language with a reasonable macro development (language orientation) experience due to C's inherent syntactic complexities. Further, it seems to have been historically demonstrated that C-family programmers are not willing to make the a syntactic leap as far as say, Lisp or Ocaml. Barring the provision of yet another C-style language, there's another set of languages many C-family programmers do rather like: Ruby and Python. So by finding a direct mapping from s-expressions to a language with an feel and visual appeal similar to Python that ALSO approaches the machine efficiency of C++, I hope to create a lisp- and ML-derived language that is accessible to an audience wider than existing functional languages seem to have reached. As you can see, the design does admit some semantic compromises in the name of syntax and efficiency, but the compromise is surprisingly (at least to me) minimal. One compromise made in the name of C++ efficiency is the use of a machine word-sized default number type rather than the default number type used in lisp or Haskell. Of course, arbitrary number types can be made available naturally via a library using simple binary operation overrides, but they are not the default when you type the literal 5. I've discovered, at least to my own current satisfaction, that bringing lisp- and ML-style semantics to the masses is possible with less semantic compromises than previously seemed possible. By providing a language that industry programmers feel comfortable with, I hope to move as many of them as possible into the functional / language-oriented world. But more than that, I'm just designing the language I wish I could use everyday instead of C++ and C# :) Hi, First of all, I wish you good luck in your project. Your mail made me think of my little syntactical[0] library. It needs some love but is in principle very flexible. It makes a clear mapping between distfix expressions and s-expressions. Distfix expressions are flexible enough to accomodate for a lot of the usual constructs one can find in programming languages. Maybe you'll find it useful. Cheers, Thu [0] http://hackage.haskell.org/package/syntactical ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code Mentors for Language.C
Hello Andrew, This is something I've been wanting for a while, and I'd definitely be interested in mentoring the work. We'd want to work together (along with Benedikt Huber, the current maintainer) to define a specific scope that's appropriate for the summer of code. A fully-compliant internal pre-processor could be quite a lot of work, but it may be possible to come up with something that would be close enough to be useful, and have a plan for how to continue working on it after the summer. However, I should mention that the Haskell community has put together a fairly long list of potential projects, many of which are more widely useful than Language.C work. This may mean that it would have a relatively low chance of being accepted. A high-quality proposal would help the odds, however. :) Aaron -- Aaron Tomb Galois, Inc. (http://www.galois.com) at...@galois.com Phone: (503) 808-7206 Fax: (503) 350-0833 On Mar 29, 2011, at 10:48 AM, Andrew Hirsch wrote: Would anybody be interested in mentoring me for a summer of code project working on language.c? I want to write an internal pre-processor that saves information such as comments and potentially some specially defined annotations, so that code can be analyzed better. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Please allow variation in the Yackage page title
Done, and uploaded as yackage 0.1.0. This version of Yackage uses the newer Yesod 0.7.0. Just pass it the command line flag --title. Michael On Tue, Mar 29, 2011 at 1:13 PM, Yitzchak Gale g...@sefer.org wrote: Could you please add a way of varying the title of the Yackage web page? That would make it much easier to work with multiple Yackages at once. For my particular setup, including its port number in the web page title would do the trick. But perhaps the easiest and most general thing would be to add a command-line option for setting the title. Using multiple Yackages is a very simple yet powerful technique to keep cabal versions straight. You can use it to group package versions in various ways - versions that you are currently hacking on, versions that have stabilized but you are not releasing yet while you work on other related packages, versions shared by various teams and subteams of developers, etc. Multiple Yackages are especially useful in combination with cabal-dev, but currently you have to fiddle a little bit to get cabal-dev to use a modified cabal config file. See: http://www.haskell.org/pipermail/haskell-cafe/2011-March/090492.html Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hdbc-odbc adds a space to the value
OK, if you send me a tested patch I will be happy to apply it.
-- John
On 03/23/2011 04:09 PM, vagif.ve...@gmail.com wrote:
Latest from hackage: 2.2.3.2
On Wednesday, March 23, 2011 01:58:52 PM you wrote:
On 03/23/2011 06:43 AM, Gershom Bazerman wrote:
I've run into that bug too. I'm pretty sure its an issue with
hdbc-odbc, but haven't wanted to patch it without testing it across a
few other configurations, which I haven't had time/found
straightforward to do.
I should add, for those interested, where I think the bug is. In the
bindCol method of Statement.hsc, there's the following:
rc2 - sqlBindParameter sthptr (fromIntegral icol)
#{const SQL_PARAM_INPUT}
#{const SQL_C_CHAR} coltype
(if isOK rc1 then colsize else fromIntegral cslen + 1) decdigits
csptr (fromIntegral cslen + 1) pcslen
Either one or both of the fromIntegral csLen + 1 expressions
shouldn't
have the + 1.
What version of HDBC-ODBC are those of you with the problem running? I
believe a fix for this was recently checked into my git tree.
-- John
Cheers,
Gershom
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code Mentors for Language.C
On Tue, Mar 29, 2011 at 3:05 PM, Aaron Tomb at...@galois.com wrote: However, I should mention that the Haskell community has put together a fairly long list of potential projects, many of which are more widely useful than Language.C work. This may mean that it would have a relatively low chance of being accepted. A high-quality proposal would help the odds, however. :) A high-quality proposal from a student that demonstrates some prior experience, capacity, and knowledge is huge in the decision making process. Motivated students can also turn in more than one proposal, which I would encourage. It can be the case that two talented candidates both applied for the same proposal, or that of a candidate's proposals, one fits much better than the other with what folks are looking to sponsor. Cheers, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
Hello John, Sorry that I'm late. And honestly one day for request submissions is a bit narrow. I have a request, too: Right now it is difficult to compose enumeratees. An equivalent of (.) for enumeratees would be great. So instead of: joinI $ e1 $$ joinI $ e2 $$ iter one could write let e = e1 .= e2 in e =$ iter I would appreciate a 0.4.10 with such a composition operator. Greets, Ertugrul John Millikin jmilli...@gmail.com wrote: Since the release, a couple people have sent in feature requests, so I'm going to put out 0.4.9 in a day or so. New features will be: - tryIO: runs an IO computation, and converts any exceptions into ``throwError`` calls (requested by Kazu Yamamoto) - checkContinue: encapsulates a common pattern (loop (Continue k) = ...) when defining enumerators - mapAccum and mapAccum: sort of like map and mapM, except the step function is stateful (requested by Long Huynh Huu) Anyone else out there sitting on a request? Please send them in -- I am always happy to receive them, even if they must be declined. --- Also, I would like to do a quick poll regarding operators. 1. It has been requested that I add operator aliases for joinI and joinE. 2. There have been complaints that the library defines too many operators (currently, 5). Do any existing enumerator users, or anyone for that matter, have an opinion either way? The proposed operators are: -- infixr 0 =$ infixr 0 $= (=$) :: Monad m = Enumeratee ao ai m b - Iteratee ai m b - Iteratee ao m b enum =$ iter = joinI (enum $$ iter) ($=) :: Monad m = Enumerator ao m (Step ai m b) - Enumeratee ao ai m b - Enumerator ai m b ($=) = joinE -- -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SoC / Cabal project proposal: specify Setup.hs dependencies
On Tue, Mar 29, 2011 at 1:26 PM, Rogan Creswick cresw...@gmail.com wrote: I've been wanting to share code between cabal projects for some time, and I finally had a chance to write up the rough idea as a simple proposal. Here's the description, with links to the SoC trac and reddit haskell_proposals pages. SoC ticket: http://hackage.haskell.org/trac/summer-of-code/ticket/1602 Reddit: http://www.reddit.com/r/haskell_proposals/comments/ge1zp/cabal_dependency_specifications_for_setuphs/ Non-standard builds often need to implement specific build steps in Setup.hs, specifying a build-type: Custom in the project cabal file. The user hook system works reasonably well for modifying or replacing the specific sub steps of a build, but *implementing* anything more than the simplest logic in Setup.hs is very difficult. A great deal of this difficulty stems from the lack of library support for code in Setup.hs. Adding a cabal section that specifies a build-depends: for Custom (and possibly other) build types would allow developers to reuse build code between projects, to share build system modifications on hackage more easily, and to prototype new additions to cabal. Setup.hs *can* allow arbitrarily complex build system manipulations; however, it is not practical to do so because the infrastructure surrounding Setup.hs doesn't promote code reuse. The addition of dependencies that cabal-install would install prior to building setup.hs and issuing the build would enable developers to produce custom builds that perform complex operations that utilize the high-quality libraries available on hackage. Furthermore, this would provide the means to prototype (and distribute) new cabal / cabal-install features before integrating experimental code into the stable tools. I'm interested in thoughts / feedback about the idea, as well as hearing from anyone interested in pursuing this as a summer of code project :) I really like the idea behind this proposal. I've had some rather hairy Setup.hs files that would have benefited from being able to use external packages. This could also be really nice when it comes to writing custom test/benchmarking/etc. hooks, by letting you factor out a lot of that common code into reusable libraries. -Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SoC / Cabal project proposal: specify Setup.hs dependencies
On Tue, Mar 29, 2011 at 4:39 PM, Edward Kmett ekm...@gmail.com wrote: On Tue, Mar 29, 2011 at 1:26 PM, Rogan Creswick cresw...@gmail.comwrote: I've been wanting to share code between cabal projects for some time, and I finally had a chance to write up the rough idea as a simple proposal. Here's the description, with links to the SoC trac and reddit haskell_proposals pages. SoC ticket: http://hackage.haskell.org/trac/summer-of-code/ticket/1602 Reddit: http://www.reddit.com/r/haskell_proposals/comments/ge1zp/cabal_dependency_specifications_for_setuphs/ Non-standard builds often need to implement specific build steps in Setup.hs, specifying a build-type: Custom in the project cabal file. The user hook system works reasonably well for modifying or replacing the specific sub steps of a build, but *implementing* anything more than the simplest logic in Setup.hs is very difficult. A great deal of this difficulty stems from the lack of library support for code in Setup.hs. Adding a cabal section that specifies a build-depends: for Custom (and possibly other) build types would allow developers to reuse build code between projects, to share build system modifications on hackage more easily, and to prototype new additions to cabal. Setup.hs *can* allow arbitrarily complex build system manipulations; however, it is not practical to do so because the infrastructure surrounding Setup.hs doesn't promote code reuse. The addition of dependencies that cabal-install would install prior to building setup.hs and issuing the build would enable developers to produce custom builds that perform complex operations that utilize the high-quality libraries available on hackage. Furthermore, this would provide the means to prototype (and distribute) new cabal / cabal-install features before integrating experimental code into the stable tools. I'm interested in thoughts / feedback about the idea, as well as hearing from anyone interested in pursuing this as a summer of code project :) I really like the idea behind this proposal. I've had some rather hairy Setup.hs files that would have benefited from being able to use external packages. This could also be really nice when it comes to writing custom test/benchmarking/etc. hooks, by letting you factor out a lot of that common code into reusable libraries. Yes. And I think it would also make it possible solve this bug as a sort of extension to cabal: http://hackage.haskell.org/trac/hackage/ticket/815 http://hackage.haskell.org/trac/hackage/ticket/815 The summary of that ticket is: translate buildplans (after dependency resolution) into concrete makefile (or inputs for other build systems, SCons, etc). If the meat of the proposal is too little for a GSoC project, then building a solution for that bug would be a nice way to roundout the student's time :) Although, I think probably to do it right and properly test it, just this feature could take a full summer. Just my $0.02! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
On Tue, Mar 29, 2011 at 6:15 PM, Ertugrul Soeylemez e...@ertes.de wrote: Hello John, Sorry that I'm late. And honestly one day for request submissions is a bit narrow. I have a request, too: Right now it is difficult to compose enumeratees. An equivalent of (.) for enumeratees would be great. So instead of: joinI $ e1 $$ joinI $ e2 $$ iter one could write let e = e1 .= e2 in e =$ iter I would appreciate a 0.4.10 with such a composition operator. Greets, Ertugrul It looks like we can't quite fit Enumeratee into the Category typeclass (without newtypes, at least). That's a shame. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
Hello, (=$) :: Monad m = Enumeratee ao ai m b - Iteratee ai m b - Iteratee ao m b enum =$ iter = joinI (enum $$ iter) ($=) :: Monad m = Enumerator ao m (Step ai m b) - Enumeratee ao ai m b - Enumerator ai m b ($=) = joinE -- The operators sound good to me. My only request would be to put in a usage example in the documentation. I'd be happy to write one if you'd like. Personally, I think that =$ will *greatly* clean up my code. I have a tutorial to describe how to use the enumerator library in Japanese. Since it is popular among the Haskell community in Japan, I guess it's worth translating into English. So, I did. http://www.mew.org/~kazu/proj/enumerator/ This tutorial explains how to use (=$) and ($=) as well as other operators(($$), (==), (=)). Of course, my English is broken. If English native speakers will kindly correct broken grammar, it would be appreciated. I'm reachable by e-mail or twitter (@kazu_yamamoto). --Kazu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
Antoine Latter aslat...@gmail.com wrote: It looks like we can't quite fit Enumeratee into the Category typeclass (without newtypes, at least). That's a shame. Yeah. Intuitively it looks like iteratees and enumeratees are excellent candidates for Category and even Arrow. Unfortunately they can either be monad transformers or arrows. You can't mix without, as you said, a newtype. That's very unfortunate. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
On 3/29/11 4:40 AM, o...@okmij.org wrote: Wren Thornton wrote: This is often conflated with the iteratee throwing an error/exception, which is wrong because we should distinguish between bad program states and argument passing. I guess this is a matter of different points of view on exceptions. The problem is not so much the exceptions per se (one goto is about as good as any other), it has more to do with the fact that important things are being left out of the types. One of the great things about Haskell is that you can lean so heavily on the type system to protect yourself when refactoring, designing by contract, etc. However, if there's an unspoken code of communication between specific enumerators and iteratees, it's very easy to break things. This is why the communication should be captured in the types, regardless of the control-flow mechanism used to implement that communication. I'd like the static guarantee that whatever special requests my iteratee could make, its enumerator is in a position to fulfill those requests (or die trying). Allowing for the iteratee to be paired with an enumerator which is incapable of handling its requests is a type error and should be treated as such. Wren Thornton wrote: In an ideal framework the producers, transformers, and consumers of stream data would have a type parameter indicating the up-stream communication they support or require (in addition to the type parameters for stream type, result type, and side-effect type). Very true. Currently the design of Iteratees quite resembles that of Control.Exception: everything can throw SomeException. Ideally one would like to be more precise, and specify what exceptions or sorts of exceptions could be thrown -- by Iteratees, and by ordinary Haskell functions. The design of a good effect system is still the topic of active research, although there are some encouraging results. Yeah, I'm not a big fan of extensible exceptions either. Don't get me wrong, it's an awesome hack and it's far cleaner than the Java approach; but it still goes against my sensibilities. I think a big part of the problem is that we don't have a good type theory for coroutines. The idea of functions that never return just doesn't cut it. And conflating legitimate control-flow manipulation with bottom doesn't either. But, as of yet, that's all we've got. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] object oriented technique
Greg,
Thanks for your help. Is there any significant difference between
using existential quantification
data ShapeD = forall s. ShapeC = ShapeD s
versus a GADT
data ShapeD where
ShapeD :: ShapeC s = s - ShapeD
I'm not sure I understood what you meant by You don't need to write
more typeclass instances this way.
Thanks for pointing out the Control.Exception library. It was very
helpful. Earlier, I was trying to figure out
how to use Data.Dynamic for down-casting and couldn't get what I
wanted. The Data.Typeable usage in Control.Exception is what I was
looking for.
Tad
On Tue, Mar 29, 2011 at 12:57 AM, Gregory Collins
g...@gregorycollins.net wrote:
On Tue, Mar 29, 2011 at 7:49 AM, Tad Doxsee tad.dox...@gmail.com wrote:
class ShapeC s where
draw :: s - String
copyTo :: s - Double - Double - s
-- needs {-# LANGUAGE GADTs #-}
data ShapeD where
ShapeD :: ShapeC s = s - ShapeD
Is the above the standard method in Haskell for creating an extensible
heterogeneous list of objects that share a common interface? Are there
better
approaches? (I ran into a possible limitation to this approach that I plan
to ask about later if I can't figure it out myself.)
The usual way to do this is:
{-# LANGUAGE ExistentialQuantification #-}
data SomeShape = forall s . ShapeClass s = SomeShape s
You don't need to write more typeclass instances this way. If you give
SomeShape a ShapeClass instance also, you can treat them
uniformly. The downside to these approaches is that any additional
information about the original concrete type is obliterated -- to get
OO-style downcasting you need Typeable support, and it isn't free.
For an example of code which uses this idiom, see the exceptions
support from the base library:
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html
G
--
Gregory Collins g...@gregorycollins.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] object oriented technique
Hi Steffen,
Thanks for your answer. It was very helpful. Suppose that the shape
class has 100 methods and
that 1000 fully evaluated shapes are placed in a list. In this
unlikely scenario, would your suggested
technique require more memory than the GADT technique, because each
instance of the Shape data
type would have to carry 100 pointers to functions, whereas in the
GADT technique, each instance
of the ShapeD data type would only have to remember what type
(Circle, Rect, etc.) it is? (I'm asking
about this unlikely scenario to better understand how Haskell works
under the covers.)
Tad
On Tue, Mar 29, 2011 at 2:53 AM, Steffen Schuldenzucker
sschuldenzuc...@uni-bonn.de wrote:
Tad,
It doesn't look bad, but depending on what you want to do with the
[ShapeD] aftewards you might not need this level of generality.
Remember that the content of a ShapeD has type (forall a. ShapeC a =
a), so all you can do with it is call class methods from ShapeC. So if
all you do is construct some ShapeD and pass that around, the following
solution is equivalent:
data Shape = Shape {
draw :: String
copyTo :: Double - Double - Shape
-- ^ We loose some information here. The original method of ShapeC
-- stated that copyTo of a Rectangle will be a rectangle again
-- etc. Feel free to add a proxy type parameter to Shape if this
-- information is necessary.
}
circle :: Double - Double - Double - Shape
circle x y r = Shape dc $ \x y - circle x y r
where dc = Circ ( ++ show x ++ , ++ show y ++ ) -- ++ show r
rectangle :: Double - Double - Double - Double - Shape
rectangle x y w h = ... (analogous)
shapes = [rectangle 1 2 3 4, circle 4 3 2, circle 1 1 1]
-- Steffen
On 03/29/2011 07:49 AM, Tad Doxsee wrote:
I've been trying to learn Haskell for a while now, and recently
wanted to do something that's very common in the object oriented
world, subtype polymorphism with a heterogeneous collection. It took
me a while, but I found a solution that meets my needs. It's a
combination of solutions that I saw on the web, but I've never seen
it presented in a way that combines both in a short note. (I'm sure
it's out there somewhere, but it's off the beaten path that I've been
struggling along.) The related solutions are
1. section 3.6 of http://homepages.cwi.nl/~ralf/OOHaskell/paper.pdf
2. The GADT comment at the end of section 4 of
http://www.haskell.org/haskellwiki/Heterogenous_collections
I'm looking for comments on the practicality of the solution, and
references to better explanations of, extensions to, or simpler
alternatives for what I'm trying to achieve.
Using the standard example, here's the code:
data Rectangle = Rectangle { rx, ry, rw, rh :: Double } deriving (Eq,
Show)
drawRect :: Rectangle - String drawRect r = Rect ( ++ show (rx r)
++ , ++ show (ry r) ++ ) -- ++ show (rw r) ++ x ++ show
(rh r)
data Circle = Circle {cx, cy, cr :: Double} deriving (Eq, Show)
drawCirc :: Circle - String drawCirc c = Circ ( ++ show (cx c) ++
, ++ show (cy c)++ ) -- ++ show (cr c)
r1 = Rectangle 0 0 3 2 r2 = Rectangle 1 1 4 5 c1 = Circle 0 0 5 c2 =
Circle 2 0 7
rs = [r1, r2] cs = [c1, c2]
rDrawing = map drawRect rs cDrawing = map drawCirc cs
-- shapes = rs ++ cs
Of course, the last line won't compile because the standard Haskell
list may contain only homogeneous types. What I wanted to do is
create a list of circles and rectangles, put them in a list, and draw
them. It was easy for me to find on the web and in books how to do
that if I controlled all of the code. What wasn't immediately obvious
to me was how to do that in a library that could be extended by
others. The references noted previously suggest this solution:
class ShapeC s where draw :: s - String copyTo :: s - Double -
Double - s
-- needs {-# LANGUAGE GADTs #-} data ShapeD where ShapeD :: ShapeC s
= s - ShapeD
instance ShapeC ShapeD where draw (ShapeD s) = draw s copyTo (ShapeD
s) x y = ShapeD (copyTo s x y)
mkShape :: ShapeC s = s - ShapeD mkShape s = ShapeD s
instance ShapeC Rectangle where draw = drawRect copyTo (Rectangle _ _
rw rh) x y = Rectangle x y rw rh
instance ShapeC Circle where draw = drawCirc copyTo (Circle _ _ r) x
y = Circle x y r
r1s = ShapeD r1 r2s = ShapeD r2 c1s = ShapeD c1 c2s = ShapeD c2
shapes1 = [r1s, r2s, c1s, c2s] drawing1 = map draw shapes1
shapes2 = map mkShape rs ++ map mkShape cs drawing2 = map draw
shapes2
-- copy the shapes to the origin then draw them shapes3 = map (\s -
copyTo s 0 0) shapes2 drawing3 = map draw shapes3
Another user could create a list of shapes that included triangles by
creating a ShapeC instance for his triangle and using mkShape to add
it to a list of ShapeDs.
Is the above the standard method in Haskell for creating an
extensible heterogeneous list of objects that share a common
interface? Are there better approaches? (I ran into a possible
limitation to this
Re: [Haskell-cafe] object oriented technique
Hi Tako,
The link to http://www.haskell.org/haskellwiki/Existential_type was
very helpful and gave examples
very similar to the answers I received from the haskell-cafe contributors.
Thanks,
Tad
On Tue, Mar 29, 2011 at 2:12 AM, Tako Schotanus t...@codejive.org wrote:
Sorry , the following line got lost in the copy paste:
{-# LANGUAGE ExistentialQuantification #-}
-Tako
On Tue, Mar 29, 2011 at 11:09, Tako Schotanus t...@codejive.org wrote:
Hi,
just so you know that I have almost no idea what I'm doing, I'm a complete
Haskell noob, but trying a bit I came up with this before getting stuck:
class Drawable a where
draw :: a - String
data Rectangle = Rectangle { rx, ry, rw, rh :: Double }
deriving (Eq, Show)
instance Drawable Rectangle where
draw (Rectangle rx ry rw rh) = Rect
data Circle = Circle { cx, cy, cr :: Double }
deriving (Eq, Show)
instance Drawable Circle where
draw (Circle cx cy cr) = Circle
data Shape = ???
Untill I read about existential types
here: http://www.haskell.org/haskellwiki/Existential_type
And was able to complete the definition:
data Shape = forall a. Drawable a = Shape a
Testing it with a silly example:
main :: IO ()
main = do putStr (test shapes)
test :: [Shape] - String
test [] =
test ((Shape x):xs) = draw x ++ test xs
shapes :: [Shape]
shapes = [ Shape (Rectangle 1 1 4 4) , Shape (Circle 2 2 5) ]
Don't know if this helps...
Cheers,
-Tako
On Tue, Mar 29, 2011 at 07:49, Tad Doxsee tad.dox...@gmail.com wrote:
I've been trying to learn Haskell for a while now, and recently
wanted to do something that's very common in the object oriented
world, subtype polymorphism with a heterogeneous collection.
It took me a while, but I found a solution that meets
my needs. It's a combination of solutions that I saw on the
web, but I've never seen it presented in a way that combines both
in a short note. (I'm sure it's out there somewhere, but it's off the
beaten
path that I've been struggling along.) The related solutions
are
1. section 3.6 of http://homepages.cwi.nl/~ralf/OOHaskell/paper.pdf
2. The GADT comment at the end of section 4 of
http://www.haskell.org/haskellwiki/Heterogenous_collections
I'm looking for comments on the practicality of the solution,
and references to better explanations of, extensions to, or simpler
alternatives for what I'm trying to achieve.
Using the standard example, here's the code:
data Rectangle = Rectangle { rx, ry, rw, rh :: Double }
deriving (Eq, Show)
drawRect :: Rectangle - String
drawRect r = Rect ( ++ show (rx r) ++ , ++ show (ry r) ++ ) --
++ show (rw r) ++ x ++ show (rh r)
data Circle = Circle {cx, cy, cr :: Double}
deriving (Eq, Show)
drawCirc :: Circle - String
drawCirc c = Circ ( ++ show (cx c) ++ , ++ show (cy c)++ ) --
++ show (cr c)
r1 = Rectangle 0 0 3 2
r2 = Rectangle 1 1 4 5
c1 = Circle 0 0 5
c2 = Circle 2 0 7
rs = [r1, r2]
cs = [c1, c2]
rDrawing = map drawRect rs
cDrawing = map drawCirc cs
-- shapes = rs ++ cs
Of course, the last line won't compile because the standard Haskell list
may contain only homogeneous types. What I wanted to do is create a list
of
circles and rectangles, put them in a list, and draw them. It was easy
for me to find on the web and in books how to do that if I controlled
all of the code. What wasn't immediately obvious to me was how to do that
in a library that could be extended by others. The references noted
previously suggest this solution:
class ShapeC s where
draw :: s - String
copyTo :: s - Double - Double - s
-- needs {-# LANGUAGE GADTs #-}
data ShapeD where
ShapeD :: ShapeC s = s - ShapeD
instance ShapeC ShapeD where
draw (ShapeD s) = draw s
copyTo (ShapeD s) x y = ShapeD (copyTo s x y)
mkShape :: ShapeC s = s - ShapeD
mkShape s = ShapeD s
instance ShapeC Rectangle where
draw = drawRect
copyTo (Rectangle _ _ rw rh) x y = Rectangle x y rw rh
instance ShapeC Circle where
draw = drawCirc
copyTo (Circle _ _ r) x y = Circle x y r
r1s = ShapeD r1
r2s = ShapeD r2
c1s = ShapeD c1
c2s = ShapeD c2
shapes1 = [r1s, r2s, c1s, c2s]
drawing1 = map draw shapes1
shapes2 = map mkShape rs ++ map mkShape cs
drawing2 = map draw shapes2
-- copy the shapes to the origin then draw them
shapes3 = map (\s - copyTo s 0 0) shapes2
drawing3 = map draw shapes3
Another user could create a list of shapes that included triangles by
creating
a ShapeC instance for his triangle and using mkShape to add it to a list
of
ShapeDs.
Is the above the standard method in Haskell for creating an extensible
heterogeneous list of objects that share a common interface? Are there
better
approaches? (I ran into a possible limitation to this approach that I
plan
to ask about later if I can't figure it out myself.)
- Tad
