- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Implementing tryReadMVar
by MR K P SCHUPKE 02 Sep '04

02 Sep '04

>might be a reason to want to prefer one event over another. You can still use a single channel... If you read all pending events on the channel into a FIFO (lazy list) then you can check for high priority events on read, and then deal with the next item on the top of the FIFO... something like the following (in pseudo code) while channel not empty read next event if event high priority process now else queue event in FIFO process first event in FIFO So inbetween processing low priority events we check ahead for any high priority ones... This could be extended with multiple FIFO's to deal with multiple priority levels... but this ensures all events are dealt with sequentially (if out of order)# Keean.

2 1

Re: [Haskell-cafe] Implementing tryReadMVar
by MR K P SCHUPKE 01 Sep '04

01 Sep '04

>tryReadMVar mv = do mc <- tryTakeMVar mv The normal reason people want tryRead is to do something like unix's 'select' function, where you want to wait on one of several signals... In my opinion it is better to do this with a _single_ channel and have one thread taking from the channel, whilst all sources of the 'events' write to the same channel... so the refactoring would be like: data Event = Even1 | Event2 | Event3 ... c <- newChan forkIO (...) a <- readChan c case a of Event1 -> ... Event2 -> ... Keean.

2 1

Haskell Naming Conventions ?
by Koray Can 01 Sep '04

01 Sep '04

Hi, I am new to haskell. One of the things that struck me odd from the very beginning was the names of things. At my workplace (where we use imperative languages), we abide by standards such as this: http://www-106.ibm.com/developerworks/library/ws-tip-namingconv.html Such conventions are debatable, but I believe some of them are worthy of applying. "ShowS" and "shows" do not have the same type, I know, but I read them as the same word. Similarly, fractional is "Fractional", but numeric is just "Num". There are "seq", "sequence" and "sequence_", etc. In The Gentle Introduction to Haskell, the author states: "...We use the term /error/ for /_|_/: a condition which cannot be recovered from such as non-termination or pattern match failure. Exceptions, on the other hand, can be caught and handled within the I/O monad...." Then he goes on to say that the data type's name is IOError (not IOException, as I was expecting.) I can imagine once one gets used to them, they don't pose any problems. Nevertheless, while I still learn, these names are quite awkward for me to read and talk about haskell. I searched the mailing list archives for a similar discussion, but I couldn't fine one. Is there a reason why things are named in such a way that conflicts with what's being followed for other languages ? Thanks for your replies.

2 1

RE: [Haskell-cafe] Higher-order unification
by Simon Peyton-Jones 01 Sep '04

01 Sep '04

| Yeah, here's a program which causes GHC to hang on compilation, but | causes no problem for hugs. Does this qualify as higher-order unification? | | newtype X a = X (X a -> a) | | selfapp :: X a -> a | selfapp self@(X f) = f self It's a documented bug in GHC. http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html Nothing to do with h-o unification Simon

1 0

BBEdit syntax highlighting for Haskell
by David Menendez 31 Aug '04

31 Aug '04

If anyone else is using BBEdit 8.0 on the Mac, I've put together a simple language module for highlighting Haskell syntax. <http://www.eyrie.org/~zednenem/sw/bbedit/haskell-syntax.plist> To install, download the file above to ~/Application Support/BBEdit/Language Modules and restart BBEdit. -- David Menendez <zednenem(a)psualum.com> | "In this house, we obey the laws <http://www.eyrie.org/~zednenem> | of thermodynamics!"

1 0

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