Marlow [mailto:[EMAIL PROTECTED]
: , 15.06.2004 15:06
: Mike Aizatsky; [EMAIL PROTECTED]
: RE: Strange problems with binary file output: result of incorrect size
On 11 June 2004 14:46, Mike Aizatsky wrote:
Hello,
I'm having strange problems with binary file output. In my
application I'm preparing
Hello,
I'm having strange problems with binary file output. In my application I'm
preparing the [Word8], then doing just 4 operations:
1. openBinaryFile
2. newListArray from my list
3. hPutArray
4. file close
Everything works ok till I change one function deep in computational code.
The change
Andre,
Thanks for paper pointers.
Hmm, what's the higher goal of what you're trying to achieve? I, like
you, came from a background of object-oriented programming, and I've
always managed to avoid making a list containing more than one type
after re-thinking about the problem. You can do
Ralf,
thanks for your time to look into the HList paper.
It's quite good. It reminds me the quirks Alexandrescu does in his Modern
C++ Design or here
http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html .
Since type system allows implementation of natural arithmetic, do you
Windows XP
D:\Tools\ghcghc-6.2.1\bin\ghc.exe -fglasgow-exts foo.hs
ghc.exe: panic! (the `impossible' happened, GHC version 6.2.1):
deSugar/DsMeta.hs:286: Non-exhaustive patterns in function repC
module Foo where
import Language.Haskell.THSyntax
class MyInterface a where
foo
Windows XP
D:\Tools\ghcghc-6.2.1\bin\ghc.exe -fglasgow-exts --make foo.hs
Chasing modules from: foo.hs
Compiling Any ( ./Any.hs, ./Any.o )
Compiling Foo ( foo.hs, foo.o )
Loading package base ... linking ... done.
Loading package haskell98 ... linking ... done.
Loading
Ralf,
I've read the paper (surprisingly it's quite new - Jun 2004) and your
sample. Here are several comments:
1. It looks like your HList is basically a sugarized version of
data AnyMyInterface = Impl1 MyImplementation1 | Impl2 MyImplementation2
with the same drawback: you require me to
Hello,
I'm in process of rewriting the old Java application. While this is for sure
lots of fun, there're some problems in modeling the java interfaces.
Here's the common Java scenario (it's actually the pattern, common for all
OO-languages, so there should be no problems in understanding it):