Re: Why is there a space leak here?
On Tue, 5 Jun 2001, Tom Moertel wrote: > "Wojciech Moczydlowski, Jr" wrote: > > > Even so, your results suggest that nhc98 is doing something > interesting. Does the memory usage remain constant even if you take 10 > or 100 times the number of elements? If so, perhaps nhc98 is smart I was just writing that it stayed constant, when the executing program ran out of heap :). Seems that my claim about nhc98 was false - I didn't wait long enough to see the program stop. Sorry for mistaking you. > Tom Wojciech Moczydlowski, Jr ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Why is there a space leak here?
On Tue, 5 Jun 2001, Tom Moertel wrote: > The reason that foo1 "leaks" space is because the middle of v grows > faster than its head. So taking elements from v causes its in-memory > footprint to grow. To see why this is the case, evaluate foo1 by hand: > > So the problem isn't Hugs but rather the definition of v, which grows > faster than it can be consumed. > Tom How come then that the very program compiled under nhc98 evaluates without any problem, with memory usage below 1M during its execution? Wojciech Moczydlowski, Jr ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: BAL paper available
On Wed, 16 May 2001, Simon Marlow wrote: > > Besides, MArray.lhs uses ST and ST requires not only > > multiparameter type > > classes, but also explicit universal quantification. > > ST doesn't require multiparameter type classes (although MArray does). You're of course right. > It also doesn't require full support for explicit universal > quantification, if runST is known to the compiler. So it's another thing to put inside a compiler? > Also, the ST array types are really an optional part of the MArray > interface - it works perfectly well with just the IO array types. Perhaps. It just shows that the module was created specifically for ghc. > > I don't like ST and the idea that someone who wants to use arrays > > outside of IO has to use ST gives me creeps. > > What would you suggest as an alternative? I suppose you could have a > monad which just supported a single array, but special-purpose monads > tend to be a pain in practice (eg. what happens when you want two > arrays?). I'd rather have a monad which just supports a single array as a standard and IO/STArray as a language extension, than the other way. You could tell the same about MonadState. And I've never needed to use ST - somehow MonadState was always enough. And I vaguely remember some problems with typing when I tried to use ST once. IOArray is better - though it is unnatural to be forced to use IO whenever one wants to do something on arrays. So, in the end, if I were to choose between STArray, IOArray and a monad with a single array, I'd choose the monad. Though the best solution probably would be to support all of them. I don't know how the TODO list of nhc developers looks like, but if they aren't implementing multiparameter type classes now, it probably (disclaimer: I am not a Haskell compiler developer) would be easier to implement a simple monad, than type classes + ST. > Simon Wojciech Moczydlowski, Jr ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: BAL paper available
On Wed, 16 May 2001, Fergus Henderson wrote: > On 15-May-2001, Wojciech Moczydlowski, Jr <[EMAIL PROTECTED]> wrote: > > On 15 May 2001, Marcin 'Qrczak' Kowalczyk wrote: > > > What should be improved compared to existing STUArray Int Double > > > and similar? > > > > A simple standard proposal, not using ST and multiparameter type classes, > > so that it would be possible to implement it in other compilers (namely nhc), > > would be a great improvement for me. > > I think multiparameter type classes or other extensions to Haskell 98 are > really needed to solve these kinds of problems in a simple and elegant way. > > The right solution, IMHO, is to extend nhc and other Haskell compilers > to support multiparameter type classes, not to try to shoehorn things > that don't fit into Haskell 98. > > Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit I don't like the idea of a program working which compiles only under compilers which have certain language extensions built in. If I understand things correctly, there is a list of language extensions (FFI for example), which has been accepted by all Haskell compilers developers. If multiparameter type classes were in that list, I would agree. Besides, MArray.lhs uses ST and ST requires not only multiparameter type classes, but also explicit universal quantification. I don't like ST and the idea that someone who wants to use arrays outside of IO has to use ST gives me creeps. By the way, I'm really surprised by the lack of time complexity information in MArray. I mean, that's the most important thing in arrays - that one can update/read a data in O(1). Wojciech Moczydlowski, Jr ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: BAL paper available
On 15 May 2001, Marcin 'Qrczak' Kowalczyk wrote: > Tue, 15 May 2001 21:14:02 +0300, Dylan Thurston <[EMAIL PROTECTED]> pisze: > > >> Nor hard numeric work (efficient, easy to manipulate arrays). > > > > If I understand correctly, Marcin Kowalczyk is working on exactly > > this last point... > > Well, I improved efficiency of ghc's arrays by removing various > unnecessary overheads and I'm working on a generic interface > of collections, but I don't have any deeper plans about arrays. > > What should be improved compared to existing STUArray Int Double > and similar? > > QRCZAK A simple standard proposal, not using ST and multiparameter type classes, so that it would be possible to implement it in other compilers (namely nhc), would be a great improvement for me. Wojciech Moczydlowski, Jr ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: io monad question
On Sun, 13 May 2001, luc wrote:
> i designed some basic functions, , mainly String -> [String], or similar with types,
>plus some more complex datatypes.
>
> Up to now; i was testing them on a basic database I was creating in the core main,
>"by hand".
> Then i added a basic parser with happy; and bingo; my test database is now loaded
>from a file... as IO String..; huh!
>
> after a second though; this makes sense, except that i have to change all the type
>of my functions; now IO String..
>
> plus a few that just dont compile; and i cant understand why...
>
> my question:
> I had to change most of my type of the functions.as is propagated through the code.
>(i.e. f need g; that need h; etc...) to add IO.
> is that kind of propagation normal, or can i Stop it somewhere ? how?
You can stop it at the very beginning:
f :: String -> String
g :: [A] -> [B] -- etc, any functions without IO
parse :: [String] -> [ A ]
main = do
h <- openFile "sampleFile" ReadMode
contents <- hGetContents h
-- and now you have file contents binded to contents and you can apply your
--functions any way you want, i. e.
let result = g (parse contents)
putStrLn (show result)
Wojciech Moczydlowski, Jr
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: FFI - some comments
On Thu, 5 Apr 2001, Ronald Legere wrote: > KDirect: Looked at it abit. Pretty sparsely > documented. I could not figure > out how it fits in with the latest tools. How does KDirect is still in a development phase. That, and lack of time, is a cause for sparse documentation. > QForeign relate to > Foreign? What is an hsc file? Also it is pretty Thanks for the criticism. I'll add these informations to the documentation. > limitted in the marshalling. It is, indeed. What more would you want? > No callbacks etc. Could you elaborate on that? Wojciech Moczydlowski, Jr ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Announce: Haskell libpq binding
The Haskell libpq (client-side PostgreSQL programming library) binding is now available to download, along with a simple DBI for Haskell, similar to this in Perl, allowing a programmer to write a database-independent code. It can be found at http://www.astercity.net/~khaliff/haskell/dbi/dbi.tgz. To compile, KDirect (http://www.astercity.net/~khaliff/kdirect) and the latest version of QForeign (http://sourceforge.net/projects/qforeign) is needed. It should compile both under ghc and nhc, yet only ghc was tested. It is no end-user product, though - there is no "install" rule in Makefile and Makefile editing is necessary, I'm afraid. If someone finds it useful or has any suggestions, I would love to hear them. Wojciech Moczydlowski, Jr ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: FFI tutorial??
On Sat, 10 Mar 2001, Ronald Legere wrote: > Does anyone know of a tutorial introduction to the > FFI? How does one go about getting started with this > thing? Any simple examples? I just want to be able > to do simple things (mostly access a c library from > haskell... ok maybe not trivial :) ) I would be > happy if I could just call c programs with simple > types and pointers (no way am I going to figure out > struct alignment! ). >I have had some success with Java Native methods, > so I believe such things can be done :0 > > Cheers! Try KDirect - it is relatively simple and the tutorial is present. On the other hand, it isn't very powerful - yet it may satisfy you. http://www.astercity.net/~khaliff/haskell/kdirect Wojciech Moczydlowski, Jr ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Question about types
I have a question regarding standard. The follow piece of code is accepted by hugs and ghc, rejected by nhc and (I haven't seen it) by hbc. Is this code correct or not? type A = Either Int f :: (a -> b) -> A a -> A b f _ _ = Left 0 Wojciech Moczydlowski, Jr
Class instantiation and polymorphic types - a proposal for a syntax extension
Suppose I have a type: data A a b = A a String b Int and classes class C1 t where c1 :: t a -> (a, Int) class C2 t where c2 :: t a -> (a, String) (the example is not practical, but shows the case). Now, whilst I can say: instance C1 (A a) where c1 (A a s b i) = (b, i) I cannot say: instance C2 (A ...) where c2 (A a s b i) = (a, s) where ... is the missing syntax - for saying that I want to generalize over the first type variable in A, not the second one as in instance C1. Wouldn't it be nice to be able to say, in the place of ..., something like A _ a? Or more generally, to develop some syntax for types like A, to create from A not only: type B = A (Int, Int) -- A (Int, Int) String b Int but also: type B1 = ... -- A a String (Int, Int) Int where again ... is the missing syntax (A _ (Int, Int)? ). If that would be possible, I could ask for even more happiness - to be able to name the order of holes left in a definition, so that (pseudo-syntax): data A a b c = A a b c type C = A _2 _1 Int -- C String Char = A Char String Int -- C String = A _1 String Int -- C = A _2 _1 Int The "normal" definitions can be translated to a new syntax: type D = A Int -- D = A Int _1 _2 It all comes to lambda-expressions on types - type C = \b a -> A a b Int instance C2 (\a -> A a b) where instance C1 (\b -> A a b) where The rule of translation from normal syntax is obvious - if we have data A a1 ... an = A a1 ... an, then A a1 translates to (\a2 ... an -> A a1 ... an) A a1 a2 translates to (\a3 ... an -> A a1 ... an) and so on. It's just a couple of thoughts, perhaps impossible to implement or having some hidden flaws - I do not know. But it really would be helpful sometimes - when dealing with very general types and operations on them. Khaliff TM [EMAIL PROTECTED]
