[Haskell-cafe] Re: ANN: Elerea, another FRP library
"Patai Gergely" wrote: > ... > I don't think using dirty tricks to implement FRP deserves flak, at all, from my POV, it sounds like complaining that the IO monad is implemented using C... meaning that if you're that close to bare thunks, you have every right to use any means necessary to make them behave properly. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Best text editor
Jeff Wheeler wrote: > As one of the Yi developers, I'd love to hear some more specific > feedback on this. Do you remember any specific Vim features that were > missing? > Nope, but I'll be writing bug reports next time, at the very least. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Elerea, another FRP library
> I don't think using dirty tricks to implement FRP deserves > flak, at all, from my POV, it sounds like complaining that the > IO monad is implemented using C... meaning that if you're that > close to bare thunks, you have every right to use any means > necessary to make them behave properly. Dirtiness is not the problem, but the fact that it can leak out at the present moment. I want guarantees to exclude the possibility of undesired behaviour on the user side. Am I right thinking that the NOINLINE pragma on unsafeDupablePerformIO prevents the problem of multiple evaluation discussed yesterday? Or should I add NOINLINE to primitives in Elerea.Internal too? If that guaranteed sharing, it would certainly solve most of the problems we talked about. Apart from that, I'm still not sure that latching works the way intended all the time, but the fact that the breakout example works is an indication that at least it's not hopelessly broken. Gergely -- http://www.fastmail.fm - Access all of your messages and folders wherever you are ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] understanding typeable
So I am getting a little further, but i am seeing this bizarre behaviour: I wrote a function that will fold over parameters and push them into a constructor if it can given this type: data Foo = FooC Int | BarC Int deriving (Data, Typeable, Show) i can do this: > let a::Maybe Foo = foldFunc (Just FooC) (params $ BarC 1) Loading package syb ... linking ... done. > a Just (FooC 1) here is the implementation data Child = forall a. (Typeable a, Data a) => Child a params::(Data a) => a -> [Child] params = gmapQ Child --foldFunc :: (Typeable x, Data y) => (Maybe x) -> [Child] -> Maybe y --foldFunc :: forall y1 y. (Typeable y1, Data y) => Maybe y1 -> [Child] -> Maybe y foldFunc (Just ff) (ch:[]) = applyCtor ff ch foldFunc (Just ff) (ch:tt) = foldFunc (applyFunc ff ch) tt foldFunc Nothing _ = Nothing foldFunc (Just ff) [] = castObj ff where castObj::(Typeable y, Data x) => y -> (Maybe x) castObj = cast applyCtor :: (Typeable x, Data y) => x -> Child -> Maybe y applyCtor ff (Child ch) = do func <- castFunc ff return $ func ch where castFunc::(Typeable y, Data x, Data z) => y -> (Maybe (x -> z)) castFunc = cast applyFunc :: (Typeable x, Typeable y) => x -> Child -> Maybe y applyFunc ff (Child ch) = do func <- castFunc ff return $ func ch where castFunc::(Typeable y, Data x, Typeable z) => y -> (Maybe (x -> z)) castFunc = cast now this is the weird part: --foldFunc :: (Typeable x, Data y) => (Maybe x) -> [Child] -> Maybe y --foldFunc :: forall y1 y. (Typeable y1, Data y) => Maybe y1 -> [Child] -> Maybe y if i uncomment either one of those, (shouldn't they be equivalent?), i get an error, the first one gives me ParseG.hs:44:39: Ambiguous type variable `x' in the constraint: `Typeable x' arising from a use of `applyFunc' at ParseG.hs:44:39-53 Probable fix: add a type signature that fixes these type variable(s) Failed, modules loaded: none. the second one gives me: ParseG.hs:46:24: Could not deduce (Data y1) from the context (Typeable y1, Data y) arising from a use of `castObj' at ParseG.hs:46:24-33 Possible fix: add (Data y1) to the context of the type signature for `foldFunc' In the expression: castObj ff In the definition of `foldFunc': foldFunc (Just ff) [] = castObj ff where castObj :: (Typeable y, Data x) => y -> (Maybe x) castObj = cast ParseG.hs:46:32: Couldn't match expected type `y' against inferred type `y1' `y' is a rigid type variable bound by the type signature for `foldFunc' at ParseG.hs:42:22 `y1' is a rigid type variable bound by the type signature for `foldFunc' at ParseG.hs:42:19 In the first argument of `castObj', namely `ff' In the expression: castObj ff In the definition of `foldFunc': foldFunc (Just ff) [] = castObj ff where castObj :: (Typeable y, Data x) => y -> (Maybe x) castObj = cast Failed, modules loaded: none. So they are not equivalent, so why is that so, and why is this the type signature of the function if i dont give one: > :t foldFunc foldFunc :: forall y1 y. (Typeable y1, Data y) => Maybe y1 -> [Child] -> Maybe y ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Elerea, another FRP library
> I will test it on a couple of machines, desktops and laptops. Try using a sensible nonzero value with threadDelay. Apparently it brings CPU usage down under Windows while retaining smoothness. However, increasing it from zero results in jerkiness under Linux... > If you take a look what Yampa does: it hides signals and only > exposes signal functions. But that means that the FRP engine > itself could indeed use mutable variables for its signals, as > long as during the evaluation of the circuit at time T no side > effects should occur; the side effects should take place when > the simulation is advanced to T+dT, which is done after the > circuit is fully evaluated at time T. Assuming that everything works as intended, Elerea is indeed free of side effects. As for the underlying engine, I was also considering the Hume language, but it has an unpleasant property that every box (analogous to the signal functions of Yampa) has an implicit delay. In fact, Elerea can be regarded as some kind of delayless Hume if we squint enough. > I'm only a bit worried about your automatic insertion of > delays; this might break referential transparency at time T, > since it depends on the order in which the nodes in the circuit > are evaluated no? The latter could be problematic when doing > evaluation in parallel on multiple cores I guess. Oh, it's problematic enough even on a single core. ;) If the network changes at one place, it might affect evaluation order in a way that delays can start wandering around in dependency cycles far away. It could be interesting to analyse the effects of this behaviour. Either way, this is just a convenience feature for applications where it makes little difference. I was also thinking about providing two versions of the library: one inserting delays, and another giving an error instead. By the way, it's also in the plans to visualise the network. Gergely -- http://www.fastmail.fm - IMAP accessible web-mail ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: Elerea, another FRP library
"Patai Gergely" wrote: > Am I right thinking that the > NOINLINE pragma on unsafeDupablePerformIO prevents the problem of > multiple evaluation discussed yesterday? > From what I know and experienced, yes. Each individual unsafePerformIO only ever evaluates its action once, and if they are prevented from duplicating, things should work out as intended. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for the fastest Haskell primes algorithm
Edward Kmett wrote: You might want to start with the Sieve of Atkin: http://en.wikipedia.org/wiki/Sieve_of_Atkin Also worth reading _Lazy wheel sieves and spirals of primes_: http://www.cs.york.ac.uk/ftpdir/pub/colin/jfp97lw.ps.gz -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Looking for the fastest Haskell primes algorithm
for the API design, always check others before rolling your own. E.g. the (three) functions with "Prime" in their name from http://java.sun.com/javase/6/docs/api/java/math/BigInteger.html I hope they are there for a reason. While we're at it - do we have modPow? modInverse? And of course check their implementation as well (should be straightforward, but you never know). J.W. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Code Golf
Fancy some Codegolf? I wrote the following function for list diagonalization: > diag l = foldr (.) id ((sel l . flip sel) ((:[]).(:))) [] > where > sel = foldr (\a b c -> id : mrg (a c) (b c)) (const []) . map (flip id) > > mrg [] ys = ys > mrg xs [] = xs > mrg (x:xs) (y:ys) = (x.y) : mrg xs ys Self explanatory, isn't it? Here is a test case: *Main> take 10 $ diag [[ (m,n) | n <- [1..]] | m <- [1..]] [(1,1),(1,2),(2,1),(1,3),(2,2),(3,1),(1,4),(2,3),(3,2),(4,1)] I was trying to golf it down [^1] but my brain explodes. If you succeed in reducing keystrokes, I'd be happy to know! Cheers, Sebastian [^1]: http://codegolf.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code Golf
If I understand the problem correctly... Prelude> let diag = concat . diags where diags ((x:xs):xss) = [x] : zipWith (:) xs (diags xss) Prelude> take 10 $ diag [[ (m,n) | n <- [1..]] | m <- [1..]] [(1,1),(1,2),(2,1),(1,3),(2,2),(3,1),(1,4),(2,3),(3,2),(4,1)] Sebastian Fischer wrote on 15.04.2009 14:32: Fancy some Codegolf? I wrote the following function for list diagonalization: > diag l = foldr (.) id ((sel l . flip sel) ((:[]).(:))) [] > where > sel = foldr (\a b c -> id : mrg (a c) (b c)) (const []) . map (flip id) > > mrg [] ys = ys > mrg xs [] = xs > mrg (x:xs) (y:ys) = (x.y) : mrg xs ys Self explanatory, isn't it? Here is a test case: *Main> take 10 $ diag [[ (m,n) | n <- [1..]] | m <- [1..]] [(1,1),(1,2),(2,1),(1,3),(2,2),(3,1),(1,4),(2,3),(3,2),(4,1)] I was trying to golf it down [^1] but my brain explodes. If you succeed in reducing keystrokes, I'd be happy to know! Cheers, Sebastian [^1]: http://codegolf.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code Golf
Sorry, I misread the task :) / Emil Emil Axelsson skrev: Why not: diag = [(x, sum-x) | sum <- [2..], x <- [1 .. sum-1]] / Emil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data.ByteString woes
Hi, I am battling with Data.ByteString.Lazy.Char8, and currently losing. Any help gratefully received. Here's my code: import qualified Data.ByteString.Lazy.Char8 as B import Text.Regex.Posix ((=~)) test = B.pack "abc" =~ B.pack "b" :: Bool This works fine without the ".Lazy", and is also fine under GHC 6.8.1, but with GHC 6.10.1, it fails with: No instances for (Text.Regex.Base.RegexLike.RegexLike Text.Regex.Posix.Wrap.Regex B.ByteString, Text.Regex.Base.RegexLike.RegexMaker Text.Regex.Posix.Wrap.Regex Text.Regex.Posix.Wrap.CompOption Text.Regex.Posix.Wrap.ExecOption B.ByteString) I then thought I might work around the problem by converting lazy ByteStrings to strict ones in order to do the regex match. I discovered toChunks, which is advertised in the documentation as type ByteString -> [ByteString], but it actually appears to be of type toChunks :: ByteString -> [Data.ByteString.Internal.ByteString] and I can't see any way of converting a Data.ByteString.Internal.ByteString to a (strict) ByteString. Does anyone know whether this is (a) bug(s) in GHC, Data.ByteString, Text.Regex.Posix or (maybe most likely) my own limited understanding? And any ideas for fixes or workarounds (other than the obvious one of downgrading to GHC 6.8)? Thanks in advance David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: Elerea, another FRP library
Am Mittwoch, 15. April 2009 09:03 schrieb Achim Schneider: > I don't think using dirty tricks to implement FRP deserves flak, at > all, from my POV, it sounds like complaining that the IO monad is > implemented using C... meaning that if you're that close to bare > thunks, you have every right to use any means necessary to make them > behave properly. It depends. Using unsafe stuff internally, might be acceptable and sometimes necessary. I also use unsafePerformIO in Grapefruit for implementing CSignals although I’m not very comfortable with this. On the other hand, breaking referential transparency in the external interface is a very bad idea, in my opinion. Actually, this means that the library user would have to turn certain compiler optimizations off to get the intended behavior. Just have a look at the Haddock docs of unsafePerformIO. In my earlier years of Haskell programming, I thought that unsafePerformIO is not too bad but I had to discover that it can quickly lead to a catastrophe. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for the fastest Haskell primes algorithm
For isPrime you might want to implement the AKS test, http://en.wikipedia.org/wiki/AKS_primality_test On Tue, Apr 14, 2009 at 3:05 PM, Edward Kmett wrote: > You might want to start with the Sieve of Atkin: > > http://en.wikipedia.org/wiki/Sieve_of_Atkin > > -Edward > > On Tue, Apr 14, 2009 at 8:40 AM, Niemeijer, R.A. > wrote: >> >> Today I happened to need a large list of prime numbers. Obviously this is >> a well-known problem, so I figured there would be something on Hackage that >> I could use. Surprisingly, there isn’t, or if there is it’s not easy to >> find. Searching for prime or primes on Hackage reveals nothing. Searching >> for primes on Hayoo gives Codec.Encryption.RSA.NumberTheory, but that uses >> the inefficient one-liner implementation. The HaskellWiki article on primes >> (http://www.haskell.org/haskellwiki/Prime_numbers) has a number of >> implementations, but the faster they get, the longer and uglier they become. >> >> >> >> Since it’s such a common problem I’d say it would be a good idea to add a >> package to Hackage that exports >> >> primes :: [Integer] >> >> and hides the ugly implementation details. Data.Numbers.Primes seems a >> logical choice for the namespace, but I’m open to suggestions. >> >> >> >> The trick then is to find the most efficient implementation of primes. The >> Haskell wiki article mentions ONeillPrimes.hs as one of the fastest ones, >> but maybe there’s a faster version. So my question is: does anybody know >> what the fastest Haskell algorithm for generating primes is? >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code Golf
Prelude> let diag = concat . diags where diags ((x:xs):xss) = [x] : zipWith (:) xs (diags xss) this has a different semantics on finite lists, so I should add a test case: *Main> diag [[1,2,3],[4,5,6],[7,8,9]] [1,2,4,3,5,7,6,8,9] Your version yields [1,2,4,3,5,7]. Actually, there are a number of implementations that implement the same behaviour as the original version, e.g., diag = concat . foldr diags [] where diags [] ys = ys diags (x:xs) ys = [x] : merge xs ys merge [] ys = ys merge xs@(_:_) [] = map (:[]) xs merge (x:xs) (y:ys) = (x:y) : merge xs ys I'd be interested if one can *derive* from the original version a simpler version using clever pointfree combinators. Cheers, Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-atomic "atoms" for type-level programming
Am Dienstag, 14. April 2009 20:01 schrieb Tillmann Rendel: > How is the need for a common import for 'data TTrue; data TFalse' > different then the need for a common import for 'data Bool = True | False'? Why not say data True data False, instead of data TTrue data TFalse? I don’t see the reason why we should insert the “T”. Data constructors are in a different namespace than type constructors. By the way, the grapefruit-records package imports type-level, only to not define its own type-level booleans but to reuse “common” types whereas I considered type-level as the standard type level programming library. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Data.ByteString woes
David Carter wrote: > I then thought I might work around the problem by converting lazy > ByteStrings to strict ones in order to do the regex match. > strictBS :: LB.ByteString -> B.ByteString strictBS = B.concat . LB.toChunks lazyBS :: B.ByteString -> LB.ByteString lazyBS = LB.fromChunks . pure -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code Golf
What about diag [[1,2,3],[4],[5,6,7]] ? What it should be? Sebastian Fischer wrote on 15.04.2009 15:28: Prelude> let diag = concat . diags where diags ((x:xs):xss) = [x] : zipWith (:) xs (diags xss) this has a different semantics on finite lists, so I should add a test case: *Main> diag [[1,2,3],[4,5,6],[7,8,9]] [1,2,4,3,5,7,6,8,9] Your version yields [1,2,4,3,5,7]. Actually, there are a number of implementations that implement the same behaviour as the original version, e.g., diag = concat . foldr diags [] where diags [] ys = ys diags (x:xs) ys = [x] : merge xs ys merge [] ys = ys merge xs@(_:_) [] = map (:[]) xs merge (x:xs) (y:ys) = (x:y) : merge xs ys I'd be interested if one can *derive* from the original version a simpler version using clever pointfree combinators. Cheers, Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ambiguous reified dictionaries
Simon Peyton-Jones wrote: > Yes, Haskell says that in any program there should be only one > instance for any particular type (here Monoid Int). GHC > doesn't check that, but it should really do so. It's not > necessary for soundness (ie no runtime crash) but it is > necessary for coherence (ie when you run the program the answer > you get doesn't depend on which dictionary the typechecker > arbitrarily chose). Unless of course, your program implicitly depends on the coherence of dictionary choice for its own soundness, for example, a program using Data.Typeable to implement Dynamic or similar. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code Golf
diag [[1,2,3],[4],[5,6,7]] What it should be? *Main> diag [[1,2,3],[4],[5,6,7]] [1,2,4,3,5,6,7] it's basically just "skipping holes": 1 2 3 4 5 6 7 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-atomic "atoms" for type-level programming
- if type-level tags (such as 'data TTrue'/'data TFalse') are declared repeatedly in separate modules, they represent separate types, preventing shared use (your type-level predicate doesn't return my version of 'TTrue'/'TFalse') How is the need for a common import for 'data TTrue; data TFalse' different then the need for a common import for 'data Bool = True | False'? 'Bool' is hardcoded at the language level (if/then/else), not just standard library, not just implicitly imported Prelude, so that seems very stable - stable enough for a single common standard library import (unlike many type-level programming concepts, which still require experimentation and variation). But even that is considered too unflexible - some users want alternative Preludes (be it temporarily, to develop a better standard, or permanently, for personal preferences), most authors of embedded domain-specific languages have wanted to replace 'Bool' and associated syntax/classes/ operations with a variant matching their needs. Now you have several definitions of 'Bool', some of which may be compatible with each other (say, two variants of FRP libraries that both simply lift 'Bool' into 'Time->Bool'). How do you, as a library user, express that two compatible types from different sources are to be considered equivalent, without forcing the authors of the compatible definitions to collaborate on a common "standard" library for both their projects? It is not a question of possible-in-theory, it is a question of pragmatics. The need to go beyond common imports, temporarily (as systems evolve) or permanently (because tree-like hierarchies do not fit all modularization strategies), exists for 'Bool' as well as for 'TBool'. Standard ML's answer to that kind of issue is type sharing. Haskell has no equivalent. Haskell has further needs in going beyond plain hierarchical import structures, though - think of the proposals for class aliases, or the question of how to split up package dependencies without relying on orphan instances, how to depend on packages in specific configurations, etc. Again, the ML family of advanced module systems has some answers to offer (and, yes, we can encode much of those in Haskell's type system, but who does that when writing cabal packages?). Haskell'98, by design, had the simplest module system it could get away with. These days, additional layers have accumulated around this core, based on libraries and cabal packages. These layers run into all the problems of advanced module systems, only that these problems currently aren't acknowledged as language design problems, but are treated as issues to hack around whenever someone is available to do the hacking. Clearly, the advent of type-level programming necessitates the design of a type-level standard library, which provides standard abstractions to enable interoperation of custom libraries. But I don't see why the module system should not scale to type-level programming. Haskell's module system is an embarrassment ignoring decades of research, its one strong point being its simplicity. There has long been an implicit assumption that advances in modular programming would come either via the type class system, or via extensible records, and that these advanced would happen within modules, without having to evolve the module system beyond simple namespace management. In practice, cabal and hackage have changed all that, introducing a de-facto module configuration system on top of the existing modules, with an evolving design. My typed non-atomic atoms don't fix any of that, but they do seem to offer a workaround for a single issue that has been around for years, and has led to several trac tickets and type-level library awkwardnesses. For instance, it isn't necessary to pre-define hundreds of constant literals for a type-level numeric library if they can be generated in client code, nor is it necessary to hand-define or template-generate an ordering relation on constructors (which some type-level libraries depend on) if it can be defined once and for all. Non of this means that it wouldn't be good to have a standard library for type-level programming - in fact, I'd expect a revised Data.Label to become a small part of such standard!-) Claus ps. If you want to know more about my view on module systems for functional languages, have a look at chapter 4 of http://community.haskell.org/~claus/publications/phd.html , titled "Module Systems for Functional Languages". It is slightly dated by now -lots of things have happened in program (de-)composition research since 1997, when that was written-, but the basis for Haskell's module system is much more ancient that that, so it might be interesting for new Haskellers to see just how old some of Haskell's "advanced" ideas really are;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://w
Re: [Haskell-cafe] Code Golf
Hi, On 15.04.2009, at 13:28, Sebastian Fischer wrote: Actually, there are a number of implementations that implement the same behaviour as the original version, e.g., diag = concat . foldr diags [] where diags [] ys = ys diags (x:xs) ys = [x] : merge xs ys merge [] ys = ys merge xs@(_:_) [] = map (:[]) xs merge (x:xs) (y:ys) = (x:y) : merge xs ys I think your first implementation is a slightly unreadable : ) implementation of this version but uses functional lists instead of standard lists. If we replace some of the lists by functional lists we get the following diag :: [[a]] -> [a] diag = toList . concatFL . foldr diags2 [] where diags [] ys = ys diags (x:xs) ys = (x:) : merge xs ys merge [] ys = ys merge xs@(_:_) [] = map (:) xs merge (x:xs) (y:ys) = ((x:) . y) : merge xs ys with the following definitions concatFL :: [[a] -> [a]] -> [a] -> [a] concatFL = foldr (.) id toList :: ([a] -> [a]) -> [a] toList fl = fl [] Additionally we can move the 'map (:)' in merge to diags diag :: [[a]] -> [a] diag = toList . concatFL . foldr diags [] where diags [] ys = ys diags (x:xs) ys = (x:) : merge (map (:) xs) ys merge [] ys = ys merge xs@(_:_) [] = xs merge (x:xs) (y:ys) = (x . y) : merge xs ys If we now replace toList and concatFL by its definitions it looks very similar to the original implementation. diag :: [[a]] -> [a] diag = foldr (.) id (foldr diags []) [] where diags [] ys = ys diags (x:xs) ys = (x:) : merge (map (:) xs) ys merge [] ys = ys merge xs@(_:_) [] = xs merge (x:xs) (y:ys) = (x . y) : merge xs ys > diag l = foldr (.) id ((sel l . flip sel) ((:[]).(:))) [] > where > sel = foldr (\a b c -> id : mrg (a c) (b c)) (const []) . map (flip id) > > mrg [] ys = ys > mrg xs [] = xs > mrg (x:xs) (y:ys) = (x.y) : mrg xs ys I guess that we can inline diags and get the definition above but I am kind of stuck here. Cheers, Jan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Elerea, another FRP library
Well, a breakout game does *not* work (yet) in most other FRP implementations except Yampa, which do have firm theoretical foundations :-) 2009/4/15 Patai Gergely > > I don't think using dirty tricks to implement FRP deserves > > flak, at all, from my POV, it sounds like complaining that the > > IO monad is implemented using C... meaning that if you're that > > close to bare thunks, you have every right to use any means > > necessary to make them behave properly. > Dirtiness is not the problem, but the fact that it can leak out at the > present moment. I want guarantees to exclude the possibility of > undesired behaviour on the user side. Am I right thinking that the > NOINLINE pragma on unsafeDupablePerformIO prevents the problem of > multiple evaluation discussed yesterday? Or should I add NOINLINE to > primitives in Elerea.Internal too? If that guaranteed sharing, it would > certainly solve most of the problems we talked about. Apart from that, > I'm still not sure that latching works the way intended all the time, > but the fact that the breakout example works is an indication that at > least it's not hopelessly broken. > > Gergely > > -- > http://www.fastmail.fm - Access all of your messages and folders > wherever you are > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code Golf
Why not: diag = [(x, sum-x) | sum <- [2..], x <- [1 .. sum-1]] / Emil MigMit skrev: If I understand the problem correctly... Prelude> let diag = concat . diags where diags ((x:xs):xss) = [x] : zipWith (:) xs (diags xss) Prelude> take 10 $ diag [[ (m,n) | n <- [1..]] | m <- [1..]] [(1,1),(1,2),(2,1),(1,3),(2,2),(3,1),(1,4),(2,3),(3,2),(4,1)] Sebastian Fischer wrote on 15.04.2009 14:32: Fancy some Codegolf? I wrote the following function for list diagonalization: > diag l = foldr (.) id ((sel l . flip sel) ((:[]).(:))) [] > where > sel = foldr (\a b c -> id : mrg (a c) (b c)) (const []) . map (flip id) > > mrg [] ys = ys > mrg xs [] = xs > mrg (x:xs) (y:ys) = (x.y) : mrg xs ys Self explanatory, isn't it? Here is a test case: *Main> take 10 $ diag [[ (m,n) | n <- [1..]] | m <- [1..]] [(1,1),(1,2),(2,1),(1,3),(2,2),(3,1),(1,4),(2,3),(3,2),(4,1)] I was trying to golf it down [^1] but my brain explodes. If you succeed in reducing keystrokes, I'd be happy to know! Cheers, Sebastian [^1]: http://codegolf.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC including System.Time but not Data.Time?
Lennart Augustsson wrote: > Removing a package in a minor release is, to quote, an epic fail. > I don't understand how that could be done. I agree. Is there any chance of 6.10.3 reverting the change? -- John > > -- Lennart > > On Tue, Apr 14, 2009 at 6:56 PM, Bulat Ziganshin > wrote: >> Hello John, >> >> Tuesday, April 14, 2009, 8:44:12 PM, you wrote: >> >>> I understand the goal of removing stuff from GHC, but the practical >>> implications can be rather annoying. >> i think that Haskell Platform will eventually replace what GHC was for >> a years, i.e. out-of-box solution for practical haskell usage. and ghc >> should be just what its name implies - bare compiler >> >> but i agree that stripping one package in minor 6.10.2 version, w/o >> Haskell Platform really available was an error >> >> -- >> Best regards, >> Bulatmailto:bulat.zigans...@gmail.com >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] GHC including System.Time but not Data.Time?
Hello John, Wednesday, April 15, 2009, 5:35:00 PM, you wrote: > I agree. Is there any chance of 6.10.3 reverting the change? both 6.6 and 6.8 had last releases at spring, so i don't expect new 6.10.* at all -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] types and braces
Hi folks In search of displacement activity, I'm trying to tweak Language.Haskell.Exts to support a few more perfidious Exts I have in mind -- they only need a preprocessor, but I do need to work on parsed programs, ideally. I was hoping to add a production to the grammar of types to admit expressions, delimited by braces: { exp } The idea is that instead of writing, (er, hi Claus), data True data False one just re-uses yer actual Bool (which becomes kind {Bool}) and writes {True} or {False}. The trouble is, the production I've added causes a reduce/reduce conflict in the grammar, but I don't get any more precise complaint than that. I guess what I'd like to know is whether I just need to debug my grammar extension, or whether the notation I'm proposing actually introduces a serious ambiguity that I'm too dim to notice. I'm mostly sending this in the hope that I have one of those "d'oh" moments you sometimes get when you articulate a stupid question in public. Put me out of my misery, please... Cheers Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [ANNOUNCE] hgettext 0.1.10 - last major release
Vasyl Pasternak writes: > Hello, > > I've uploaded last (and latest) significant version on hgettext > module. Currently it works fine, and has bindings to all gettext > functions (from libintl.h). Next versions will be only bug fixes of > this version. > I don't see any strong reasons to write any combinators over this > basic bindings. Haskell needs more powerful internationalization > library, and I am plan to design it, but it will be completely > different from gettext principles, so this library will be released > with another name. > Does this means that the string files (if they exist at all) won't be in po format, or some approximation thereof? This could be a problem for translators. Florent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and braces
I'd suggest using some different kind of brackets to relieve the misery, like {| |}. On Wed, Apr 15, 2009 at 4:10 PM, Conor McBride wrote: > Hi folks > > In search of displacement activity, I'm trying to tweak > Language.Haskell.Exts to support a few more perfidious > Exts I have in mind -- they only need a preprocessor, > but I do need to work on parsed programs, ideally. > > I was hoping to add a production to the grammar of types > to admit expressions, delimited by braces: > > { exp } > > The idea is that instead of writing, (er, hi Claus), > > data True > data False > > one just re-uses yer actual Bool (which becomes kind > {Bool}) and writes {True} or {False}. > > The trouble is, the production I've added causes a > reduce/reduce conflict in the grammar, but I don't get > any more precise complaint than that. > > I guess what I'd like to know is whether I just need to > debug my grammar extension, or whether the notation I'm > proposing actually introduces a serious ambiguity that > I'm too dim to notice. I'm mostly sending this in the > hope that I have one of those "d'oh" moments you > sometimes get when you articulate a stupid question in > public. > > Put me out of my misery, please... > > Cheers > > Conor > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and braces
On 15 Apr 2009, at 16:01, Lennart Augustsson wrote: I'd suggest using some different kind of brackets to relieve the misery, like {| |}. That would speed up my tinkering, certainly. I did have a d'oh moment: you can write data Foo = Moo {goo :: Int} -- braces where a type goes and indeed, commenting out field declarations makes happy happy. However, these { exp } guys never stand as types of things, only as parameters of types, so it might be possible to resolve the problem without fat brackets. Whether it's worth it is another matter... Cheers Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cabal install vs. profiling
Hi, Suppose I have installed a number of libraries and have written a program using them. Now, I want to profile my program. What is the best way to get the profiling versions of the libraries installed? Thanks, David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal install vs. profiling
On Wed, Apr 15, 2009 at 11:21 AM, David F. Place wrote: Hi, Suppose I have installed a number of libraries and have written a program using them. Now, I want to profile my program. What is the best way to get the profiling versions of the libraries installed? Thanks, David I'd chuck 'library-profiling: True' into my .cabal/config, and do 'cabal install --reinstall ' (being careful to exclude the core libraries like unix and process). -- gwern signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: level-monad-0.3
I am pleased to announce version 0.3 of the package level-monad. This package implements breadth-first search directly as an instance of MonadPlus (without using an intermediate tree representation). In version 0.3 I have added a MonadPlus instance for iterative deepening inspired by Michael Spivey's paper on "Algebras for combinatorial search"[1]. The package is on Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/level-monad Sources are on Github: http://github.com/sebfisch/level-monad Cheers, Sebastian [1]: http://spivey.oriel.ox.ac.uk/mike/search-jfp.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for the fastest Haskell primes algorithm
I've just uploaded a package with some functions I had lying around. > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Numbers Am 14.04.2009 um 14:40 schrieb Niemeijer, R.A.: Today I happened to need a large list of prime numbers. Obviously this is a well-known problem, so I figured there would be something on Hackage that I could use. Surprisingly, there isn’t, or if there is it’s not easy to find. Searching for prime or primes on Hackage reveals nothing. Searching for primes on Hayoo gives Codec.Encryption.RSA.NumberTheory, but that uses the inefficient one-liner implementation. The HaskellWiki article on primes (http:// www.haskell.org/haskellwiki/Prime_numbers) has a number of implementations, but the faster they get, the longer and uglier they become. Since it’s such a common problem I’d say it would be a good idea to add a package to Hackage that exports primes :: [Integer] and hides the ugly implementation details. Data.Numbers.Primes seems a logical choice for the namespace, but I’m open to suggestions. The trick then is to find the most efficient implementation of primes. The Haskell wiki article mentions ONeillPrimes.hs as one of the fastest ones, but maybe there’s a faster version. So my question is: does anybody know what the fastest Haskell algorithm for generating primes is? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe PGP.sig Description: Signierter Teil der Nachricht ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fast mutable arrays of ByteString?
Hello all, I have been rewriting a small utility program of mine from C to Haskell for fun. This tool reads lines from stdin or from files, shuffles them one or more times using the Fisher-Yates algorithm, and outputs the result to stdout. Since this algorithm is based on in-place updates, I've been storing my strings in a mutable array in the ST monad. Since it's holding strings I could not use an unboxed array. The resulting program works fine and seems to run at a decent speed, even though it is much slower than the original C version, slightly more so than I expected. While trying to optimize it using profiling, and playing with the number of shuffling passes, I noticed that this operation was responsible for a significant amount of the runtime, much more so than with the C version. I also noticed that the %GC time was around 56%. In order to do more tests, I wrote another version of this program which keeps the strings in a pure and immutable array, and stores the indices of this array in an unboxed mutable ST array. The shuffling is then done on this indices array instead of the strings array. This version runs much faster and only spends ~21% of its time in the garbage collector, at the cost of consuming more memory for the indices array. I'm attaching both versions of the code to this e-mail, and I'd be curious to hear about any possible improvements to it, and whether the performance of STArray of ByteString I'm observing corresponds to people's expectations. Thanks in advance, Maxime Henrion {-# LANGUAGE BangPatterns #-} module Main where import Control.Monad import Control.Monad.ST import Data.Array.ST import Data.ByteString.Char8 (ByteString) import qualified Data.ByteString.Char8 as S import Data.Maybe import System.Console.GetOpt import System.Environment import System.IO import System.Random data Config = Config { separator :: Char , numPasses :: Int } deriving (Eq, Show) defaultConfig = Config { separator = '\n' , numPasses = 1 } options :: [OptDescr (Config -> Config)] options = [ Option ['0'] [] (NoArg (\cfg -> cfg { separator = '\0' })) "expect ASCII NUL characters as separators" , Option ['d'] [] (OptArg ((\d cfg -> cfg { separator = d }) . maybe '\n' head) "delim") "use provided character as separator" , Option ['n'] [] (OptArg ((\n cfg -> cfg { numPasses = n }) . readNumPasses) "npass") "run # passes instead of just 1" ] where readNumPasses = maybe 1 (headMaybe 1 fst . reads) headMaybe _ f [x] = f x headMaybe d _ _ = d main :: IO () main = do argv <- getArgs case getOpt RequireOrder options argv of (opts, args, []) -> do g <- newStdGen input <- getInput args let Config { separator = sep , numPasses = n } = foldl (flip id) defaultConfig opts forM_ (shuffle g n (slice sep input)) $ \ln -> S.putStr ln >> putChar sep (_, _, (err:_)) -> do prog <- getProgName hPutStr stderr (prog ++ ": " ++ err) getInput :: [FilePath] -> IO ByteString getInput [] = S.getContents getInput ps = S.concat `fmap` mapM S.readFile ps slice :: Char -> ByteString -> (Int, [ByteString]) slice d s = slice' d s 1 [] where slice' d s !count lns = case S.elemIndex d s of Nothing-> (count, s:lns) Just n | n == S.length s - 1 -> (count, S.take n s:lns) -- ignore empty trailing lines | otherwise -> slice' d (S.drop (n + 1) s) (count + 1) (S.take n s:lns) {-# INLINE slice #-} shuffle :: RandomGen g => g -> Int -> (Int, [ByteString]) -> [ByteString] shuffle g n (count,lns) = runST $ do arr <- newListArray (0,count - 1) lns :: ST s (STArray s Int ByteString) forM_ swaps $ \(i,j) -> when (i /= j) $ do tmp <- readArray arr i readArray arr j >>= writeArray arr i writeArray arr j tmp getElems arr where swaps = zipWith (\n k -> (n - 1, k `mod` n)) (concat $ replicate n [count,count-1..2]) (randoms g) {-# LANGUAGE BangPatterns #-} module Main where import Control.Monad import Control.Monad.ST import Data.Array import Data.Array.ST import Data.ByteString.Char8 (ByteString) import qualified Data.ByteString.Char8 as S import Data.Maybe import System.Console.GetOpt import System.Environment import System.IO import System.Random data Config = Config { separator :: Char , numPasses :: Int } deriving (Eq, Show) defaultConfig = Config { separator = '\n' , numPasses = 1 } options :: [OptDescr (Config -> Config)] options = [ Option ['0'] [] (NoArg (\cfg -> cfg { separator = '\0' })) "expect ASCII NUL characters as separators" , Option ['d'] [] (OptArg ((\d cfg
RE: [Haskell-cafe] Strange type error with associated type synonyms
| But the core part of my suggestion (which this example was meant | to help explain) remains attractive, at least to me: somewhere during | type inference, GHC *does* unify the *apparently free* 'd' with an | internal type variable (lets call it 'd1, as in the type error message) You are speculating about the *algorithm*. I rather doubt that exposing more of the algorithm to users is going to be helpful; the whole point of a declarative description of the type system is that it specifies which programs are typeable without giving the nitty gritty of an algorithm. Even I, who implemented GHC's current algorithm, cannot follow your algorithmic explanation. | that has no explicit counterpart in source code or type signature, | so the inferred type should not be | | f' :: forall d. (Fun d) => Memo d a -> Memo d a -- (1) | | but rather | | f' :: forall d. (Fun d,d~d1) => Memo d a -> Memo d a -- (2) What is this d1? Where is it bound? | All I'm suggesting is that the type *printed* by GHCi does not | really represent the type *inferred* by GHCi (or else there should | not be any attempt to match the *free* 'd' against some unknown | 'd1', as the error message says), and that there might be ways to | make the discrepancy explicit, by printing the inferred type differently. I believe that it *does* really represent the type inferred by GHC, in fact. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Maybe off-topic -- Writing contracts or software specifications
There's one sentence I remember from some Extreme Programming books I read: "the customer only knows what he wants when he gets it" :-) On Tue, Apr 14, 2009 at 11:27 AM, Achim Schneider wrote: > "Richard O'Keefe" wrote: > > > If you have a low level of trust, you'll need a great level of > > detail, and it still won't help. > > > Heh. Keep your friends close, your enemies closer. > > Freelancing, I was always paid per hour, not per feature. From my > experience, writing something like "The contractor will work closely > with an employee designated by Foo to ensure formal and informal, known > or yet to be discovered, specifications are implemented" is the best > thing you can do. If you have it, mention your QA and its guidelines. > If you don't have it, get both. [1] > > It's more than enough to boot a bad teamplayer out of his contract, > doesn't induce frowns in top coders (SNAFU, as those are the ones you > want to hire), does not risk mis-specifying requirements (which, with > legal backing, is also SNAFU) and doesn't take longer and/or cost more > to work out than the program itself (SNAFU, again). Be sure that not > only bugs are fixed, but the reasons they appeared in the first place, > too: That's the secret people writing space shuttle control software and > similar use. > > > [1] Even if it's just one guy working out things like "Every function >must be documented" and me getting a bug report saying "Help text >does not mention how to display help text". > -- > (c) this sig last receiving data processing entity. Inspect headers > for copyright history. All rights reserved. Copying, hiring, renting, > performance and/or quoting of this signature prohibited. > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Elerea, another FRP library
but the fact that the breakout example works is an indication that at least it's not hopelessly broken. Well, a breakout game does *not* work (yet) in most other FRP implementations except Yampa, which do have firm theoretical foundations :-) While certainly more entertaining, the problem looks similar enough to the NLift example (a lift serving requests on n floors[0]) in FunWorlds (the 2002 OpenGL version[1], not the 2001 VRML version[2]), chosen to test some expressiveness aspects of the language: - a dynamically updated collection (requests in NLift, bricks in breakout) - an object moving in response to user input (lift/paddle+ball) - collection and object reacting to each other's relative positions (lift at floor levels/paddle ball brick collisions) In NLift, user input (keyboard) adds to the requests collection, and the lift reacts to the request collection and its own status, while in breakout, user input (mouse) directly controls the paddle, to which the ball reacts. The lift stopping at a floor directly removes a request there, while breakout bricks disappear when hit by the additional ball. In NLift, collisions and movement are one-dimensional, while breakout is two-dimensional. On the other hand, I hadn't got round to cleaning up the interface, let alone firming the theoretical foundations, so perhaps this isn't an exception to your rule?-) But I thought I'd mention it on the topic of "other FRP libraries", with variations of approach/concepts. Claus [0] http://community.haskell.org/~claus/FunWorlds/NLift.hs [1] http://community.haskell.org/~claus/FunWorlds/ [2] http://community.haskell.org/~claus/FunWorlds/VRML/ FunWorlds/OpenGL in brief: - a behaviour is a description of an experiment - a behaviour can be sampled (performing the experiment), yielding a current value and a residual behaviour (the latter replaces the original behaviour) - the results of measurements can be broadcast and observed via behavioural channels (a channel observer simply behaves as the channel source behaviour, with a slight delay) That's it! The is no special role for time at all. One can establish local clocks, one can even broadcast their ticking behaviours. But one cannot take an arbitrary absolute time and ask for the value of a behaviour at that time (other than actually running that behaviour forward or backward from "now"). Also, there is a natural distinction between describing and running a behaviour, with the ability to refer to either the description or to sample outcomes. And having the same behaviour description on both sides of an event in a stepper/until does not mean that nothing changes at the step: the second copy doesn't continue where the first left off, but starts from its own beginning (with no special tricks to achieve this). There are no separate events, and delays enter via behavioural channels. Well, there were lots of negatives as well (eg FunWorlds was an "engine-exposed" workbench rather than a user-directed library), but I thought I'd try to get you interested first!-) I'd love to have funding to work out the details and clean up/modernize the interface, but without funding, it'll just have to wait until I get round to it (or one of the newer FRP libraries renders it superfluous..). If you try the examples, you'll notice that some of them run too fast on modern machines (because they weren't tied to an external clock), so you'd have to slow them down (eg, Surface and Torus, in addition to the standard rotate/scale controls, also react to 't'/'T' for scaling time) but they are are still fun to watch in their naivete (try Boids for simplicity, Flock2 for chaos - you'll need to scale it 's'/'S'). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and braces
Hi Conor, Conor McBride: > The trouble is, the production I've added causes a > reduce/reduce conflict in the grammar, but I don't get > any more precise complaint than that. To get more precise complaints, you should give the -i flag to happy, that will cause happy to print the whole parser table into a file named Parser.info. It also tells you in which states the conflicts occur, allowing you to track 'em down. > I guess what I'd like to know is whether I just need to > debug my grammar extension, or whether the notation I'm > proposing actually introduces a serious ambiguity that > I'm too dim to notice. I'm mostly sending this in the > hope that I have one of those "d'oh" moments you > sometimes get when you articulate a stupid question in > public. I don't immediately see what the clash in that context would be - I *think* what you propose should be doable. I'd be interested to know what you come up with, or I might have a look at it myself when I find a few minutes to spare. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and braces
Hi Niklas Good to hear from you, and thanks for providing such a useful starting point for my experiments. On 15 Apr 2009, at 19:27, Niklas Broberg wrote: Hi Conor, Conor McBride: The trouble is, the production I've added causes a reduce/reduce conflict in the grammar, but I don't get any more precise complaint than that. To get more precise complaints, you should give the -i flag to happy, that will cause happy to print the whole parser table into a file named Parser.info. It also tells you in which states the conflicts occur, allowing you to track 'em down. So that's how you do it! I was expecting that some such thing would exist. I guess what I'd like to know is whether I just need to debug my grammar extension, or whether the notation I'm proposing actually introduces a serious ambiguity that I'm too dim to notice. I'm mostly sending this in the hope that I have one of those "d'oh" moments you sometimes get when you articulate a stupid question in public. I don't immediately see what the clash in that context would be - I *think* what you propose should be doable. I'd be interested to know what you come up with, or I might have a look at it myself when I find a few minutes to spare. I've found that I can add a production atype :: { Type } ... | '{' trueexp '}' if I remove the productions for record declarations constr1 :: { ConDecl } | con '{' '}' { RecDecl $1 [] } | con '{' fielddecls '}'{ RecDecl $1 (reverse $3) } which suggests that it is indeed the syntax data Moo = Foo {goo :: Boo Hoo} which is in apparent conflict with my proposed extension. The current parser uses the type parser btype to parse the initial segment of constructor declarations, so my change causes trouble. Further trouble is in store from infix constructors data Noo = Foo {True} :*: Foo {False} should make sense, but you have to look quite far to distinguish that from a record. So I don't see that my proposed extension introduces a genuine ambiguity, but it does make the parser a bit knottier. I can use (|...|) as the brackets I need in the meantime, without even disturbing the lexer, but I'd much rather use {...} if I can learn a bit more happy hacking. My efforts so far have been clumsy and frustrating, but -i might help me see what I'm doing wrong. Subtle stuff Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Enum to String, and back?
Hi, Using Show it is possible to establish a relationship between an enum type data Color = Red | Blue | Green | Yellow | Orange | Brown | White | Black deriving (Show, Eq, Enum, Bounded) and a String type to display it. *Main> Red Red *Main> [Red,Green,Blue] [Red,Green,Blue] *Main> which is Red :: Color -> "Red" :: [Char] Can one as easily establish a reverse relationship, i.e., convert a String type like "Red" back to its corresponding Color type? So that "Red" :: [Char] -> Red :: Color Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Enum to String, and back?
Hi Michael, michael rice wrote: Can one as easily establish a reverse relationship, i.e., convert a String type like "Red" back to its corresponding Color type? So that "Red" :: [Char] -> Red :: Color Yes, simply add Read to your list of to be derived type classes. Then you can say: > read "Red" :: Color HTH, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Enum to String, and back?
On Wed, Apr 15, 2009 at 3:13 PM, michael rice wrote: > Using Show it is possible to establish a relationship between an enum type > and a String type to display it. > Can one as easily establish a reverse relationship, i.e., convert a String > type like "Red" back to its corresponding Color type? > Make it an instance of the Read type class. http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t%3ARead That will allow you to write - read "Red" :: Color => Red HTH Rahul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Elerea, another FRP library
I think it would be nice if we could make a "reactive benchmark" or something: some tiny examples that capture the essence of reactive systems, and a way to compare each solution's pros and cons. For example the "plugging a space leak with an arrow" papers reduces the recursive signal problem to e = integral 1 e Maybe the Nlift problem is a good example for dynamic collections, but I guess we'll need more examples. The reason why I'm talking about examples and not semantics is because the latter seems to be pretty hard to get right for FRP? On Wed, Apr 15, 2009 at 6:39 PM, Claus Reinke wrote: > but the fact that the breakout example works is an indication that at >>> least it's not hopelessly broken. >>> >> Well, a breakout game does *not* work (yet) in most other FRP >> implementations except Yampa, which do have firm theoretical foundations >> :-) >> > > While certainly more entertaining, the problem looks similar enough > to the NLift example (a lift serving requests on n floors[0]) in FunWorlds > (the 2002 OpenGL version[1], not the 2001 VRML version[2]), chosen > to test some expressiveness aspects of the language: > > - a dynamically updated collection (requests in NLift, bricks in breakout) > - an object moving in response to user input (lift/paddle+ball) > - collection and object reacting to each other's relative positions (lift > at floor levels/paddle ball brick collisions) > > In NLift, user input (keyboard) adds to the requests collection, and the > lift reacts to the request collection and its own status, while in > breakout, user input (mouse) directly controls the paddle, to which the ball > reacts. The lift stopping at a floor directly removes a request there, while > breakout bricks disappear when hit by the additional ball. In NLift, > collisions and movement are one-dimensional, while breakout is > two-dimensional. > > On the other hand, I hadn't got round to cleaning up the interface, let > alone firming the theoretical foundations, so perhaps this isn't an > exception to your rule?-) But I thought I'd mention it on the topic of > "other FRP libraries", with variations of approach/concepts. > > Claus > > [0] http://community.haskell.org/~claus/FunWorlds/NLift.hs > [1] http://community.haskell.org/~claus/FunWorlds/ > [2] http://community.haskell.org/~claus/FunWorlds/VRML/ > > FunWorlds/OpenGL in brief: > > - a behaviour is a description of an experiment > > - a behaviour can be sampled (performing the experiment), yielding a > current > value and a residual behaviour (the latter replaces the original behaviour) > > - the results of measurements can be broadcast and observed via behavioural > channels (a channel observer simply behaves as the channel source > behaviour, > with a slight delay) > > That's it! The is no special role for time at all. One can establish local > clocks, one can even broadcast their ticking behaviours. But one cannot > take an > arbitrary absolute time and ask for the value of a behaviour at that time > (other than actually running that behaviour forward or backward from > "now"). > > Also, there is a natural distinction between describing and running a > behaviour, with the ability to refer to either the description or to sample > outcomes. And having the same behaviour description on both sides of an > event > in a stepper/until does not mean that nothing changes at the step: the > second > copy doesn't continue where the first left off, but starts from its own > beginning (with no special tricks to achieve this). There are no separate > events, and delays enter via behavioural channels. > > Well, there were lots of negatives as well (eg FunWorlds was an > "engine-exposed" workbench rather than a user-directed library), but I > thought I'd try to get you interested first!-) I'd love to have funding to > work out the details and clean up/modernize the interface, but without > funding, it'll just have to wait until I get round to it (or one of the > newer > FRP libraries renders it superfluous..). > > If you try the examples, you'll notice that some of them run too fast on > modern machines (because they weren't tied to an external clock), so > you'd have to slow them down (eg, Surface and Torus, in addition to the > standard rotate/scale controls, also react to 't'/'T' for scaling time) but > they are are still fun to watch in their naivete (try Boids for simplicity, > Flock2 for chaos - you'll need to scale it 's'/'S'). > > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Mondrian and Haskell
Hello, Several days ago I posted a question about retargeting GHC to generate CIL so that Haskell could be a .NET language. One objection was Haskell "lazy" nature didn't fit well with .NET's CLR. I found a couple publications http://www.ddj.com/windows/184404967;jsessionid=0AVCEATVAEGKMQSNDLOSKH0CJUNN2JVN?_requestid=33708 ... more popular presentation http://docs.msdnaa.net/ark_new/Webfiles/WhitePapers/ECOOP.pdf... this paper seems to be saying that Mondrian's "lazy" nature fits in quite well Any opinions from Mondrian people "listening" in? What lessons were learned from the Mondrian experience that could speak to Haskell in particular GHC? Regards, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Brackets and Asynchronous Exceptions
Hi, In a program I am writing, I have many locations where I acquire a resource, perform an operation with it, then release it. I have been using the 'bracket' function so that the "release" operation would be performed even if the operation threw an exception. This seems to work nicely. In the event of an asynchronous exception, however, is there a possible scenario where a release is not performed after an acquire? Looking at the example given in bracket documentation: bracket (openFile "filename" ReadMode) (hClose) (\fileHandle -> do { ... }) Is it possbile that an asynchronous exception could be raised in this thread after openFile executes but *before* the appropriate handlers are installed and the operation is run, preventing hClose from executing? If 'bracket' does not handle this case, should I be using the block/unblock functions to disable asynchronous exceptions: block (bracket (openFile "filename" ReadMode) (hClose) (\fileHandle -> do unblock ({ ... }))) Thanks, Andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Brackets and Asynchronous Exceptions
On Wed, Apr 15, 2009 at 4:06 PM, Andrew Gallagher wrote: > Hi, > > In a program I am writing, I have many locations where I acquire a resource, > perform an operation with it, then release it. I have been using the > 'bracket' function so that the "release" operation would be performed even > if the operation threw an exception. This seems to work nicely. > > In the event of an asynchronous exception, however, is there a possible > scenario where a release is not performed after an acquire? > > Looking at the example given in bracket documentation: > > bracket > (openFile "filename" ReadMode) > (hClose) > (\fileHandle -> do { ... }) > > Is it possbile that an asynchronous exception could be raised in this thread > after openFile executes but *before* the appropriate handlers are installed > and the operation is run, preventing hClose from executing? > > If 'bracket' does not handle this case, should I be using the block/unblock > functions to disable asynchronous exceptions: > > block > (bracket > (openFile "filename" ReadMode) > (hClose) > (\fileHandle -> do > unblock > ({ ... }))) Does this answer your question? http://haskell.org/ghc/docs/latest/html/libraries/base/src/Control-Exception-Base.html#bracket If so, I found it by going to haskell.org/hoogle searching for bracket and then following the haddock "Source" to the definition. I hope that helps! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: Elerea, another FRP library
Peter Verswyvelen wrote: > The reason why I'm talking about examples and not semantics is > because the latter seems to be pretty hard to get right for FRP? > There's a difference between those two? I've heard much, but never anyone complaining about specifications overlapping in a compatible way. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Brackets and Asynchronous Exceptions
Great. Thanks! This is exactly what I was looking for. Apparently this issue is also described in the paper Asynchronous Exception in Haskell. Thanks, Andrew On Wed, 15 Apr 2009, Jason Dagit wrote: On Wed, Apr 15, 2009 at 4:06 PM, Andrew Gallagher wrote: Hi, In a program I am writing, I have many locations where I acquire a resource, perform an operation with it, then release it. I have been using the 'bracket' function so that the "release" operation would be performed even if the operation threw an exception. This seems to work nicely. In the event of an asynchronous exception, however, is there a possible scenario where a release is not performed after an acquire? Looking at the example given in bracket documentation: bracket (openFile "filename" ReadMode) (hClose) (\fileHandle -> do { ... }) Is it possbile that an asynchronous exception could be raised in this thread after openFile executes but *before* the appropriate handlers are installed and the operation is run, preventing hClose from executing? If 'bracket' does not handle this case, should I be using the block/unblock functions to disable asynchronous exceptions: block (bracket (openFile "filename" ReadMode) (hClose) (\fileHandle -> do unblock ({ ... }))) Does this answer your question? http://haskell.org/ghc/docs/latest/html/libraries/base/src/Control-Exception-Base.html#bracket If so, I found it by going to haskell.org/hoogle searching for bracket and then following the haddock "Source" to the definition. I hope that helps! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.ByteString woes
Could you pastebin something that demoes the error? -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Enum to String, and back?
Thanks guys. It works like a charm. Michael --- On Wed, 4/15/09, Rahul Kapoor wrote: From: Rahul Kapoor Subject: Re: [Haskell-cafe] Enum to String, and back? To: Cc: haskell-cafe@haskell.org Date: Wednesday, April 15, 2009, 3:20 PM On Wed, Apr 15, 2009 at 3:13 PM, michael rice wrote: > Using Show it is possible to establish a relationship between an enum type > and a String type to display it. > Can one as easily establish a reverse relationship, i.e., convert a String > type like "Red" back to its corresponding Color type? > Make it an instance of the Read type class. http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t%3ARead That will allow you to write - read "Red" :: Color => Red HTH Rahul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code Golf
I think this has the semantics you're looking for. (it would probably be somewhat prettier if "mappend" wasn't such an ugly identifier (compared to, say, (++)), but this is just me trying to sneak a shot in against the Monoid method's names ;) ghci> let diag = foldr (curry (prod mappend fst snd . uncurry (coprod mappend (splitAt 2) (splitAt 1 [] ghci> diag [[1,2,3],[4,5,6],[7,8,9]] [1,2,4,3,5,7,6,8,9] ghci> diag [[1,2,3],[4],[5,6,7]] [1,2,4,3,5,6,7] On Wed, Apr 15, 2009 at 5:32 AM, Sebastian Fischer < s...@informatik.uni-kiel.de> wrote: > Fancy some Codegolf? > > I wrote the following function for list diagonalization: > > > diag l = foldr (.) id ((sel l . flip sel) ((:[]).(:))) [] > > where > > sel = foldr (\a b c -> id : mrg (a c) (b c)) (const []) . map (flip id) > > > > mrg [] ys = ys > > mrg xs [] = xs > > mrg (x:xs) (y:ys) = (x.y) : mrg xs ys > > Self explanatory, isn't it? Here is a test case: > >*Main> take 10 $ diag [[ (m,n) | n <- [1..]] | m <- [1..]] >[(1,1),(1,2),(2,1),(1,3),(2,2),(3,1),(1,4),(2,3),(3,2),(4,1)] > > I was trying to golf it down [^1] but my brain explodes. If you succeed in > reducing keystrokes, I'd be happy to know! > > Cheers, > Sebastian > > [^1]: http://codegolf.com/ > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code Golf
*..against Monoid's method names. On Wed, Apr 15, 2009 at 9:59 PM, Matt Morrow wrote: > ... against the Monoid method's names. > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code Golf
And i forgot to include the defs of (co)prod: coprod (<>) i1 i2 = (\a b -> i1 a <> i2 b) prod (><) p1 p2 = (\a -> p1 a >< p2 a) diag = foldr (curry (prod mappend fst snd . uncurry (coprod mappend (splitAt 2) (splitAt 1 [] Matt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Issues with running Ghci from emacs
I am having problem running GHCI with Haskell files that include imports. I am running emacs22 on Ubuntu, with haskell-mode-2.4 extensions. I load my file (Fal.lhs in this case) in emacs. Then try to run the Ghci by doing C-c C-l. The result is shown below. Ghci fails to find the Draw.lhs which is also on the same directory as the Fal.lhs. Note: If I go to the directory where Fal.lhs is and run Ghci directly it all works fine. Any idea how I can get the interepreter to work form emacs? GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. *Prelude> :cd ~/.cabal/ Prelude> :load "../Documents/haskell/SOE/src/Fal.lhs" * ../Documents/haskell/SOE/src/Fal.lhs:76:9: Could not find module `Draw': Use -v to see a list of the files searched for. Failed, modules loaded: none. Prelude> Thanks, Daryoush ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] google-like "do you mean?" feature
I'm thinking of writing a parser to load files that my customers have created. I'm a software requirements engineer; the data consists of the customers' thoughts in response to the latest release of the requirements doc. In fact, the files will probably be copies of the requirements doc itself, into which customers have entered their notes and made changes. The original requirements doc will have a format that can be parsed; probably something simple like lines marked with codes like //customer={customer name goes here} //requirement= {requirement text goes here} When I parse the documents that come back from the customers, they are likely to contain some errors. Field names may be mangled or misspelled. Customer names may be entered in unrecognizable variants (e.g. someone named "Michael" is indicated as "Mike") and so forth. I was thinking that it might be useful to have a Google-like "do you mean this?" feature. If the field name is //customer=, then the parser might recognize a huge list of variants like //ustomer=, //customor=, etc... that is, recognize them well enough to continue parsing and give a decent error message in context. Any ideas how to go about this? I don't think I would create a parser language that includes every variant, but instead the field names would be tokens that could be passed to another routine. The variants could be generated ahead of time. I would limit the number of variants to something manageable, like 10,000 for each field name. Thanks, Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] google-like "do you mean?" feature
2009/4/16 Michael Mossey : > I was thinking that it might be useful to have a Google-like "do you mean > this?" feature. If the field name is //customer=, then the parser might > recognize a huge list of variants like //ustomer=, //customor=, etc... that > is, recognize them well enough to continue parsing and give a decent error > message in context. > > Any ideas how to go about this? To measure how similar two strings are, you can use a metric like Levenshtein distance, Damerau-Levenshtein distance, or Jaro-Winkler distance: http://en.wikipedia.org/wiki/Levenshtein_distance http://en.wikipedia.org/wiki/Damerau%E2%80%93Levenshtein_distance http://en.wikipedia.org/wiki/Jaro-Winkler_distance The first two basically count the number of mistakes that a user would have to make to get from the correct string to the one you read from the file. There's an 'edit-distance' package in Hackage that implements the first two: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/edit-distance When you find an unrecognised field name in the file, you could calculate the edit distance to each correct field name, and if there's one within a certain threshold, assume that's what the user meant (if there's more than one close match, maybe it's better to report an error than risk choosing the wrong one). I imagine this brute-force approach would be fast enough, but if not you could look at the techniques used by spell checkers to suggest corrections. Maybe even use a spell checking library, if such a thing exists (either pure Haskell or a binding to a library like aspell, although I couldn't see either from a quick search in Hackage). Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] google-like "do you mean?" feature
On Wed, 15 Apr 2009 23:31:50 -0700 Michael Mossey wrote: > I was thinking that it might be useful to have a Google-like "do you > mean this?" feature. If the field name is //customer=, then the > parser might recognize a huge list of variants > like //ustomer=, //customor=, etc... You could reduce the probability of such errors by providing a standard template that could be copy-pasted in wherever necessary. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe