- Haskell-Cafe - Haskell.org

too much like Java
by enrico.santoemma＠tin.it 30 Aug '04

30 Aug '04

Hello again. I began coding the haskell prototype of the java app I told here some weeks ago. I'm finding myself writing a new module where in Java I'd have written a class, and exporting from the module only the type, the constructor and the functions. By now I'm only writing the functions' signature. The topic is CRM, and modules are stuff like orders, products, invoices... I'm asking a little help just to be sure I'm not going in the wrong direction. My doubts come from the fact that this design looks too much like if I am writing Java code. I know that when it is the time to implement the functions I'll take advantage of the functional way, but by now I'm not using it at all. The exact question is: where one has tenths of entities, is it correct to write a module (in the form of ADT) for each entity? thanks, Enrico

1 0

Functor instance for weak pointers?
by David Roundy 29 Aug '04

29 Aug '04

Might it be possible to create a Functor instance for weak pointers? I don't really need to, but it would certainly be handy. Unfortunately, I don't see how it could be implemented, since there's no way to create a new already-tombstoned weak pointer, and without that ability, I can't see how one could do this. I'd like to write weakFmap :: (a -> b) -> Weak a -> Weak b but don't see how I can, since if deRefWeak returns Nothing, I have no way of creating a Weak b that will also return Nothing. :( A simple emptyWeak :: Weak a would be sufficient, as I could then write weakFmap f wa = unsafePerformIO $ do ma <- deRefWeak wa case ma of Nothing -> return emptyWeak Just b -> mkWeakPtr (f b) Nothing -- David Roundy http://www.abridgegame.org

1 0

anti-memoization?
by David Roundy 28 Aug '04

28 Aug '04

I've been thinking and wondering about the possiblility of anti-memoization. Memoization reduces computational time at the expense of additional memory use. I would like to be able to do the opposite. Obviously, antimemoization is something you'd only want to do with "cheap" functions having larger outputs than inputs. In particular, I have (in darcs) a number of "parsing" functions, which use up a lot of memory, and *also* hold onto their argument. The simplest example is linesPS, which breaks a PackedString (from my FastPackedString library) into lines. The contents of the argument are not copied, so the original string is held in memory as long as its parsed version is also held. linesPS :: PackedString -> [PackedString] I'd like to be able to tell the GC that it can "throw away" the parsed lines, and replace the thunk of the [PackedString] with the original function if necesary. I think this can be approximated using weak pointers, but to do it "right" would require support in the compiler. Using weak pointers I imagine something like: antimemoize :: (a -> b) -> a -> AntiMemo a b readAntiMemo :: AntiMemo a b -> b with data AntiMemo a b = AntiMemo (a -> b) a (IORef (Weak b)) where readAntiMemo (AntiMemo f a iowb) = case unsafePerformIO (readIORef iowb >>= deRefWeak) of Nothing -> case f a of newb -> unsafePerformIO $ do wb <- mkWeakPtr newb Nothing writeIORef iowb wb return newb Just b -> b antimemoize f a = unsafePerformIO $ do wb <- mkWeakPtr (f a) Nothing iowb <- newIORef wb return (AntiMemo f a iowb) I haven't actually tested it, but to the extent that I understand weak pointers, it ought to work. Comments or suggestions are welcome. It would be really nice if this could be done at the "thunk" level, so it could be transparent to the caller. I'd really like to be able to create the function antimemoize :: (a -> b) -> (a -> b) which like "memo" would be completely transparent in the sense that it would be a pure function and wouldn't modify the output of the function it modifies, but would just make the output of that function a thunk that when evaluated stores not only the output b, but also the function itself and the input a, so that the b output could be garbage-collected. On the other hand, perhaps there's a reason why all this wouldn't work. I certainly don't understand space usage in haskell as well as I wish. But I also *really* would like to reduce the space usage of darcs. Some of this I can acheive by strategically introducing laziness, but that's a rather fragile way to reduce the memory footprint, since relatively small modifications change what gets held in memory. So it'd be nice to be able to throw away the results of a parse that I can always re-perform. -- David Roundy http://www.abridgegame.org/darcs

1 0

file upload with Network.CGI
by Peter Simons 27 Aug '04

27 Aug '04

Has anyone managed to process the results of a "file upload" formular, such as <form action="input_file.htm" enctype="multipart/form-data"> <p>Choose a file: <input name="foobar" type="file" size="50" maxlength="100000" accept="text/*"> </p> </form> ..., with Network.CGI successfully? I have tried it, but it appears that the library can't handle the "multipart/form-data" encoding -- is that possible? I'll appreciate any suggestions how to work around (or fix) this problem. Peter P. S.: I have made a lot of changes to the CGI library already; does anyone actively maintain it? Or should I just post my diffs on the libraries list?

2 2

Re: Extensible Serialization class with type classes
by Ralf Laemmel 27 Aug '04

27 Aug '04

[redirected to Haskell-cafe from ghc...] I think the point is not to define your class Seriliazer, but to define it as a generic function instead. After all, it is kind of show (because it is serialisation). Reading your earlier emails, it seems a remaining problem is to keep this function somewhat open as to allow to special cases afterwards. This is a nice topic. Here we go. The normal serialisation function with a serialisation result Q is of such a type serialise :: Data a => a -> Q Internally such a function would be probably defined by recursion such as serialise = ... gmapQ serialise ... In fact, some types would already be subject to special cases. So we have serialise = generic_case `extQ` specific_case1 `extQ` specific_case2 ... where generic_case = ... gmapQ serialise ... specific_case1 = ... % do something for my favourite type This is exactly the code skeleton of show. Now the question is how to make the whole business extensible. I normally do this with a type as follows: extensible_serialise :: Data a => (forall b. Data b => b -> Maybe Q) -> a -> Q That is, there is an extra parameter for the type specific cases to be ruled from the outside. Note the Maybe. Here, Nothing means that a specific type is not handled by the parameter, so the normal serialise has to be applied. Regarding your other problem, optional types, this seems to be solvable as well. Again, *don't* define this class class XSDType a with where xsdType :: a -> String xsdNS :: a -> String ...but rather define a generic function, this time is nothing but a type case of type forall x. Typeable x => x -> Maybe (String, String) Hope it helps. Conclusion: don't use classes, rather use generic functions. Ralf Simon David Foster wrote: >On Thu, 2004-08-26 at 20:52, Ralf Laemmel wrote: > > >>Hi Simon, >> >>I think you should be able to succeed with Scrap your boilerplate. >>(I am not sure that you need existentials.) >> >>For the overall XmlIsh style of type erasue and type validation see the >>XmlIsh example at: >>http://www.cs.vu.nl/boilerplate/ >> >> > >The main requirements for the XML serializer are; > >1) It should be scalable; so users should be able to import a compile >module with the basic XML infrastructure and add serializers for new >Complex and Simple (i.e. leaf node) types. > >2) It should be optionally typeable; there exists several systems for >typing an XML document, the most prominent of which is XSD. The main >requirement is that if the XML tree is to be typed, clearly each node in >the tree must be associated with mapping to an XSD name and name-space >(2 Strings) or some other data items if typing by another system. The >way I was planning on doing this was using a class; XSDType a with >functions xsdType :: a -> String and xsdNS :: a -> String. Then at >serialisation if a particular type and all it's constituent types were >XSD Typeable, extra data (i.e. an extra attribute type="nsp:name") can >(again optionally) be inserted into the tree. > >The XmlIsh example uses a number of functions for serialising different >data-types down the tree. I'm not sure how scalable doing it this way >would be; can you integrate a type-class system with it? The other >problem is dealing with Schematic extensions, such as SOAP Arrays which >have the requirement that the elements are always typeable but should >not be part of the core serialiser. > >My other question is, section 7 only mentions polymorphic types which >hold constraints Data, Typeable and Typeable1; can the new Generics deal >with other polymorphic constraints? This is the main problem; the >type-class system can deal fine with just serialisation of data-type >content, it just doesn't seem to be able to handle an optional >type-system. > >Ideally I need to produce a system where one XML namespace maps to one >module and that module provides data-types, serialisers and typers for >the given XML types, such that other modules which use those data-types >themselves should be able to import that module and its serialisers to >(heuristically) build serialisers for itself. > >-Si. > > > >_______________________________________________ >Glasgow-haskell-users mailing list >Glasgow-haskell-users(a)haskell.org >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >

1 0

ghc binaries for sunos, hpux, aix, irix, and osf1?
by Goetz Isenmann 23 Aug '04

23 Aug '04

Hi! Are there other binary ghc versions available besides those on http://www.haskell.org/ghc/download.html, that I can use for ghc bootstrap on sunos (5.5.1-5.9), hpux (10.20 and 11.x), aix (4.3-5.2), irix (6.5), and osf1 (4.0-5.1)? -- Goetz Isenmann

1 0

Fun with multi-parameter type classes
by Sam Mason 22 Aug '04

22 Aug '04

Hi, I've been getting into Haskell over the past few months and have just come up against a bit of a brick wall when trying to encapsulate some of the data structures in my code nicely. Basically what I want to have, is a type class where one of the intermediate values is opaque with respect to code using its implementations. This is a simplified version of what I'm trying to accomplish: class Foo t where encode :: String -> t decode :: t -> String instance Foo Int where encode = read decode = show test = decode . encode This currently fails, because the type checker insists on trying to figure out what its type should be - even though it shouldn't be needed. Any suggestions on how to encode this sort of thing? And if it is possible, can it be extended to multiple type parameters? as this is really what I want to use it for. About the only way I can think of "fixing" it, is by turning the code inside out - sort of like the way an AST drives the compiler, but without knowing how it represents things internally. Thanks, Sam

4 4

hugs, ghc portability
by Vadim Zaliva 20 Aug '04

20 Aug '04

Hi! I have following code: import Data.Bits xcomp :: Int -> Int -> Int xcomp a m = (xor a (complement m)) which compiles fine under GHC. However hugs does not like it, since they intentionally did not do: --instance Bits Int How can I resolve this to have this code work under GHC and hugs? Sincerely, Vadim -- "La perfection est atteinte non quand il ne reste rien a ajouter, mais quand il ne reste rien a enlever." (Antoine de Saint-Exupery)

2 1

Logic programming in Haskell
by Stefan Monnier 20 Aug '04

20 Aug '04

Has anyone already tried to embed prolog-style logic programming as a Haskell library? Kind of like Schelog but for Haskell? I know about Curry, but I'd like a Haskell library rather than another language. Stefan

4 3

Re: [Haskell-cafe] Fun with multi-parameter type classes
by Jon Cast 19 Aug '04

19 Aug '04

> Hi, > > I've been getting into Haskell over the past few months and have just > come up against a bit of a brick wall when trying to encapsulate > some of the data structures in my code nicely. Basically what I > want to have, is a type class where one of the intermediate values > is opaque with respect to code using its implementations. This is > a simplified version of what I'm trying to accomplish: > > class Foo t where > encode :: String -> t > decode :: t -> String > > instance Foo Int where > encode = read > decode = show > > test = decode . encode > > This currently fails, because the type checker insists on trying to > figure out what its type should be - even though it shouldn't be > needed. The intermediate type /is/ needed---it's a (hidden) parameter to your `encode' and `decode' functions. Why do you think it shouldn't be? <snip> Jon Cast

3 3