Hi
hoping someone can shed some light on this:
The following code causes a "C stack overflow" in hugs (version 20051031)
but not in ghc (version 6.6)
The point of the exercise is to process a very large file lazily, returning
the consumed and unconsumed
parts (i.e. basic parser combinators).
It requires a patch to cabal. I have such a patch. the patch provides an
aditional config parameter which will allow you to configure the
documentation directory but in absence of any setting will default to old
behaviour.
the patch is very rough
JV.
- Original Message -
From: "Matt
NB
the essence what I am trying to do is to define a proxy class Foo for class
Ba1 I would have thought that something as simple as the following would
have worked ??
class Ba1 a where
dosomething :: a -> IO ()
ba1 :: Ba1 a => a -> IO ()
ba1 x = dosomething x
instance Ba1 Int where
doso
** this is literate haskell
hoping someone can help me. What I am trying to do is
class Ba1 a
ba1 :: Ba1 a => a -> IO ()
ba1 x = print "helllo"
what I wish to do is declare another function
class Foo a
proxy :: Foo a => a -> IO ()
so that I can do something like
proxy x = ba1 x
correct me if I am wrong but ...
1. Field namespaces: solved by using type classes
This would imply that the type of the field is the same between all
instances of this common field.
Under this proposal two fields with same label and different type would
not be possible
eg { name :
I would like to sound out the Haskell community on what the feeling are most
desirable to improve the "commerciality" (i.e. its general use) of ghc and
Haskell in general (as distinct from feature set)
my pick would be to
1) GHC runtime to be dynamically loaded.
Enable the ghc runtime sys
