- Haskell-Cafe - Haskell.org

Filtering on data constructors with TH
by Christophe Poucet 01 Jun '06

01 Jun '06

Dear, After having read Bulat's mail regarding TH when I had mentioned my wish for Pretty, I decided to use TH for a much smaller project. That's why today I have created an automated derivation for data constructor filtering. As I started coding someone mentioned that something similar can be done with list comprehensions, so I'm not certain about the scope of usefulness, however personally I have found the need for this at times. Anyways, the code can be obtained from the darcs repo at http://oasis.yi.org:8080/repos/haskell/filter Suggestions, bugs, additions are always welcome :) Here is an example: {-# OPTIONS_GHC -fglasgow-exts -fth #-} module Main where import Filter data T = A Int String | B Integer | C deriving Show data Plop a b = Foo a | Bar b deriving Show $(deriveFilter ''T) $(deriveFilter ''Plop) main :: IO () main = do let l = [A 1 "s", B 2, C] let l2 = [Foo 1, Bar "a", Foo 2, Bar "b"] print l print $ filter isA l print l2 print $ filter isFoo l2 Cheers Christophe (vincenz@irc) -- Christophe Poucet Ph.D. Student Phone:+32 16 28 87 20 E-mail: Christophe (dot) Poucet (at) imec (dot) be Website: http://notvincenz.com/ IMEC vzw – Register of Legal Entities Leuven VAT BE 0425.260.668 – Kapeldreef 75, B-3001 Leuven, Belgium – www.imec.be *****DISCLAIMER***** This e-mail and/or its attachments may contain confidential information. It is intended solely for the intended addressee(s). Any use of the information contained herein by other persons is prohibited. IMEC vzw does not accept any liability for the contents of this e-mail and/or its attachments. **********

3 2

Re[2]: [Haskell] My summer of code project: HsJudy
by Bulat Ziganshin 01 Jun '06

01 Jun '06

(moved to haskell-cafe) Hello Jean-Philippe, Tuesday, May 30, 2006, 2:58:01 PM, you wrote: >> you should also see to the Collections package: >> darcs get --partial http://darcs.haskell.org/packages/collections/ >> although it contains only _immutable_ datastructures at this >> moment. may be, you can codevelop with Bernardy interface for mutable >> maps/sets > I'm not sure there is significant overlap between what we're doing. > I'd be delighted to cooperate if you think this is possible though. well, what i think: while all the actual work will be performed by Caio himself, we can help him (and to ourselves as possible future users of this lib) by describing infrastructure in that he need to insert his work and pointing to "adjancent" projects so, Caio, now i write for you, better organizing my previous post: 1. In terms of Haskell, Judy is a library of _mutable_ collections of _unboxed_ elements. i pointed you to the Array wiki page, where differences between boxed and unboxed, mutable and immutable datastructures are described 2. Collections is a library of _immutable_ datastructures, and Jean-Philippe especially omitted any support for mutable datastructures - because it's the whole story of it's own. So, you don't need to write your work as part of the Collections library 3. Nevertheless, Collections has GREAT organization and it will be very helpful to study it. in particular, see at the Data.Collections module, what describes various classes into which all collections are fitted, and hierarchy between them 4. Next, when you will search for the datatypes/classes whose interface you can imitate, you will find only Data.HashTable - other datatypes in standard libraries are either immutable (say, Map) or need contiguous indexes (say, MArray). So you will need to create your own interface and here you can borrow from the Collections lib. Just see at the differences between IArray and MArray classes. They are very close, only MArray class update arrays on-the-place and has additional 'Monad m' on all it's return types. say, class IArray a e where unsafeAt :: (Index i) => a i e -> i -> e becomes class MArray a e m where unsafeRead :: (Index i) => a i e -> i -> m e You can do the same with Collections classes. instead of reinventing the wheel, you can add letter 'M' to it :) say, class Monoid c => Map c k a | c -> k a where insert :: k -> a -> c -> c delete :: k -> c -> c member :: k -> c -> Bool would become class (Monoid c, Monad m) => MapM c k a | c -> k a where insertM :: k -> a -> c -> m () deleteM :: k -> c -> m () memberM :: k -> c -> m Bool 5. as i already said, then you should use StablePtr and any form of hashing/seriazliation in order to map between boxed (Haskell) and unboxed (C) values. and then you can develop series of Diff transformers what emulates immutable collections via mutable ones (say interface of class Map via the interface of class MapM), DiffArray can serve as template here 6. There is no class framework for container types other than this Data.Collections module, so implementing it's close imitation (with monadic operations) will help future users to easily learn and use both interfaces -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 4

sum-file shootout test
by Bulat Ziganshin 01 Jun '06

01 Jun '06

Hello Haskell-cafe, i have analyzed performance of various sum-file implementations (see http://shootout.alioth.debian.org/debian/benchmark.php?test=sumcol&lang=all ) first, one-liner implementation (attached as b.hs) works about 500 seconds on my cpu. it can be made 10x faster just by using it's own 'read' procedure (c.hs). this tells us that current 'read' implementation in GHC is VERY SLOW. next step to make things go faster you can see at http://shootout.alioth.debian.org/debian/benchmark.php?test=sumcol&lang=ghc… - now it's the fastest GHC entry on this test. speedup is a result of throwing away all the lines/map/read/sum individual procedures and writing entire algorithm over the plain stream of Chars. this allows us to omit all the construction/deconstruction of lazy boxes, so this program works about 10 seconds on my box. now the main problem is getContents itself, which uses about 70% of total time, because it requires to construct/deconstruct lazy box for each Char read. Using Streams library, we can omit this work and use straightforward imperative code (h.hs). this program works 4 times faster (2.8 seconds) than faster Haskell variant, what should be about 1.5 times faster than today's fastest (D Digital Mars) entry in this test i think that close speed can be also obtained by using line-oriented I/O in Streams+ByteString combination and then applying some "readInt :: ByteString -> Int" conversion while compiling under GHC 6.5 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Re: [Haskell] installing streams library
by Chad Scherrer 01 Jun '06

01 Jun '06

On 5/20/06, Donald Bruce Stewart <dons(a)cse.unsw.edu.au> wrote: > > > Data.ByteString is in the base libraries now. > For a bit of the flavour, see: > http://haskell.org/haskellwiki/Wc > In this message http://article.gmane.org/gmane.comp.lang.haskell.general/13625 Bulat says, i foresee that Streams + Fast Packed Strings together will yield a breakthrough in GHC I/O speed, and this can be implemented even without waiting for GHC 6.6 Before reading this I had thought it might be an XOR situation, but now it seems a happy coexistence may be possible. Are there any preliminary results on how these might work together, and the potential speedups? -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

8 20

Re: [Haskell-cafe] Editors for Haskell
by Doaitse Swierstra 01 Jun '06

01 Jun '06

On 2006 mei 30, at 17:33, Brian Hulley wrote: > But the buffer will nearly always be incomplete as you're editing it. > > I was kind of hoping that the syntax of Haskell could be changed so > that for > any sequence of characters there would be a unique parse that had a > minimum > number of "gaps" inserted by the editor to create a complete parse > tree, and > moreover that this parse could be found by deterministic LL1 recursive > descent. If you use my parsercombinators, and are willing to work on the grammar I think this can in principle be done. The combinators automatically "correct" incorrect (i.e. in this case incomplete) input, but: - you may really need some time to tune the grammar so the corrections are what a user might expect (there are many hooks for doing so, but it will takje some effort, since this s also a human interface issue) - making a Haskell grammar that parsers top-down is not an easy task, and making it LL1 is definitely impossible, but also not needed if you use my combinators - we could in principle provide you with a complete parser for Haskell using our combinators that was tested by replacing the GHC parser with this parser, and that worked (contact athurb(a)cs.uu.nl to get a copy of his code) - did you think about how to handle the offside rule? If not, the good news is that we have combinators for that too. Doaitse Swierstra > > Haskell already seems so very close to having this property - its a > real > pity about => Not only the =>, but e.g. the commonality between patterns and expressions makes left factorisation a not so simple task. > > The problem is: when Haskell was designed, no one seems to have > thought > about the syntax from the point of view of making it easy to parse or > ensuring that it would have this nice property for editing. > >> >>> foo :: {SomeClass a} a->a >>> a Prelude.+ b -- no spaces in the qvarsym >>> a `Prelude.(+)` b -- a little generalization >>> a `Prelude.(+) b -- no need for closing ` >> >> I would not like an editor that forces me to use a special coding >> style (like using brackets where not strictly necessary). Even less >> would I like to use one that introduces non-standard syntax. >> >> My humble opinion is that you'll have to bite the bullet and >> implement >> your syntax recognizer so that it conforms to Haskell'98 (including >> the approved addenda) [and addtionally however many of the existing >> extensions you'll manage to support]. It may be more difficult but in >> the end will also be a lot more useful. And you'll have to find a way >> to (unobtrusively!) let the user know whether some piece of code does >> not yet have enough context to parse it unambigously. > > Thanks for the feedback - I suppose I was being overly optimistic > to think I > could just change the language to suit my editor ;-). > I'll have to find a balance between what I'm able to implement and > what is > specified in Haskell98 (or Haskell' etc) - just as GHCi has done with > qvarsym, and perhaps have different levels of conformance to H98 so > people > could choose their preferred balance between conformity and > instantaneousness of feedback (everything would of course still be > loaded/saved as H98). > > Regards, Brian. > > -- > Logic empowers us and Love gives us purpose. > Yet still phantoms restless for eras long past, > congealed in the present in unthought forms, > strive mightily unseen to destroy us. > > http://www.metamilk.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

Newbie: Applying Unknown Number Arguments to A Partial Function
by Aditya Siram 31 May '06

31 May '06

I am trying to write a function 'applyArguments' which takes a function and a list and recursively uses element each in the list as an argument to the function. I want to do this for any function taking any number of arguments. applyArgument f (arg) = f arg applyArgument f (arg:args) = applyArgument (f arg) args This has failed in Hugs, so my question is: Can I conceptually do this? If so, what is the type signature of this function? Deech

8 9

changing out
by Jenny678 31 May '06

31 May '06

hello, i want to change my input integers In> 23 98 Out> 98 23 I think its simple... sorry .... my first steps in Haskell.... thanks for solutions. -- View this message in context: http://www.nabble.com/changing+out-t1707014.html#a4634189 Sent from the Haskell - Haskell-Cafe forum at Nabble.com.

2 1

String to binary tree
by Nuno Santos 31 May '06

31 May '06

Hi, I have this type which represents polish expressions (floorplan representation): data PeAux a = Folha Char | Nodo Char (PeAux a) (PeAux a) deriving Show The reverse polish expression are the result of doing a post order visit to the tree One example of this reverse polish expression is "12H3V" and a example of tree is pe5 = Node 'V' (Node 'H' (Folha '1') (Folha '2')) (Folha '3') the tree above is the same as the expression "12H3V" What i need and i cant do is turn the expression a tree again... I have done the following: converteAux [] (x,y) = (x,y) converteAux (a:t) (x,y) | ((length (a:t))<3) = converteAux [] (x,y ++ (a:t)) converteAux (a:b:t) (x,y) | ((length (a:b:t))<3) = converteAux [] (x,y ++ (a:b:t)) converteAux (a:b:c:t) (x,y) | (isNumber a) && (isNumber b) && (isLetter c) = converteAux t (x ++ [(Nodo c (Folha a) (Folha b))],y) | otherwise = converteAux (b:c:t) (x,y++[a]) The strategy followed is to recognize operand, operand, operator and then put it as a basic element in a list, for instance, 12H -> Node 'H' (Folha '1') (Folha '2') And at the end put it togheter in one tree. ( not done yet) But i'm getting to the conclusion that it doesnt cover every case... Can anybody give me a light here? Many thx, Best regards, Nuno Santos

4 5

On GADT, phantom types, etc. terminology
by oleg＠pobox.com 30 May '06

30 May '06

David Roundy wrote: > data CommuteResult a b c where > CR :: C a b c d => (P a d, P d c) -> CommuteResult a b c > ... > or that somehow GADTs aren't interacting with FDs as I'd like It must be emphasized that there are *NO* GADTs is the above code. Except Stefan Monnier's message, no code posted in the thread `help with MPTC for type proofs?' had any GADTs, the notation |data ... where| notwithstanding. In particular, the data type |CommuteResult a b c| is the ordinary algebraic datatype, and can be written in the traditional notation as > data CommuteResult a b c = forall d. C a b c d => CR (P a d, P d c) To recall, the datatype > data MEither a b where > MLeft :: a -> MEither a b > MRight :: b -> MEither a b is the ordinary algebraic datatype > data MEither a b = MLeft a | MRight b The two notations are totally equivalent. The constructors MLeft and MRight create the values of the type |MEither a b| -- which is just as general as the type being defined |MEither a b|. OTH, > data MEither2 a b where > MLeft2 :: Int -> MEither2 Int b > MRight2 :: b -> MEither2 Char b is truly _generalized_ ADT, because the values created by the constructors MLeft2 and MRight2 have the types that span only the subset of the type family |MEither2 a b|. Thus, to tell if something written in the |data ... where| notation is GADT or not, we just look at the result type. If it is the same as what follows the |data| keyword, we have the ordinary ADT. Incidentally, I strongly prefer writing ordinary algebraic data types in the traditional notation (precisely to avoid the confusion with GADTs and to keep the code portable). Because David Roundy's example had no GADTs, it is not fair to blame GADT's interacting with FD. There are indeed issues, at present, with GADT and FD. But those issues do not bear on the problem at hand. Therefore, waiting for GHC 6.8 is, alas, hopeless in this respect. David Roundy wrote: > I want the return type "d" to be a phantom type of some sort (although > I'm not clear on the distinction between phantom and existential > types). Well, they are, in a sense, dual to each other. In the declaration, > data Patch a b = P a the type variable 'b' appears only on the left-hand side of the definition. The corresponding type is phantom. In the declaration > data PatchW a = forall b. PW (Patch a b) the type variable 'b' appears only on the right-hand side of the defining equation. So, informally, the type |PatchW a| is existential, abstracting over |b|. Perhaps the |where| notation makes things clearer: > data Patch a b where P :: a -> Patch a b > data PatchW a where PW :: Patch a b -> PatchW a Here, the type variable |b| shows up only in the result of |P|. It is phantom. The type variable |b| shows up only in the argument of |PW|. It is existential. David Roundy wrote: > when I realized that the problem could be solved much more elegantly > using GADTs as a type witness (with unsafeCoerce#, admittedly) That is quite puzzling: the whole advantage of GADTs is that we don't need to coerce values because type coercion, after checking the run-time evidence (that is, successful pattern-match) is the very essence of GADTs. Incidentally, to coerce phantom types, there is no need to resort to unsafeCoerce#. The access to the data constructor suffices. David Roundy wrote: > Can someone explain to me why this doesn't work? > > {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-} > > module MPTC where > > > > class C a b c d | a b c -> d, a d c -> b > > > > instance (C a b c d) => C a d c b > > > > data P a b = P deriving (Show) > > > > data CommuteResult a b c where > > CR :: C a b c d => (P a d, P d c) -> CommuteResult a b c When we abstract over |d|, there is generally no way to get the original type back (short of various casts, which generally require run-time evidence). One can think of it as upcast/downcast problem in OO: we can always pretend that an object of the type A is an object of a more general type ASuper (and any object is an object of the Top type). However, downcasting from a value of a more general type to the value of a more specific type requires some run-time evidence (even if the more general value was obtained by the upcast from the desired specific type). The nature of abstraction is to irreversibly forget -- hence the encapsulation guarantee. If that is not desired, we can use some other translucent, type-preserving, ways. For example, > {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-} > module MPTC where > > data P a b = P deriving (Show) > > data CommuteResult a b c = forall d. CR (P a (d b), P (d b) c) > > commute :: (P a (d b), P (d1 b) c) -> CommuteResult a b c > commute (P, P) = CR (P, P) > > test (x,y) = do CR (y',x') <- return $ commute (x,y) > CR (y'', x'') <- return $ commute (x,y) > CR (x''',y''') <- return $ commute (y',x'') > return () which type-checks... David Roundy wrote: > I guess what hasn't been addressed is the question I didn't know to ask... It would help me personally to see the `ideal' code -- the code that you wish to write and to typecheck. The code should be sufficiently realistic (the IO can be stubbed though). I'll be out of town for a week so unable to reply promptly.

2 1

LDIF output library
by Ferenc Wagner 30 May '06

30 May '06

Hi, does anybody know of a library for writing LDIF files? If not, I may create one, and would be grateful for suggestions. Is it worth integrating with John Goerzen's LDAP binding, for example? -- Thanks, Feri.

1 0