[Haskell-cafe] haskell or lazy functional as procedure language
Ok, I know, I want something strange. But consider situation, when one is starting a project and finds, that he need s 1) ACID relational storage 2) Power of good RDBMS system (postgresql for example) 3) Power of some very hight level language and compiled (haskell for example) for stored procedures 4) And all data processing MUST be performed inside RDBMS 5) And does not have enough money to by Oracle ore other commercial RDBMS. I already considered using ghc with postgresql. It could be very, very good pair, but ghc runtime cannot be re-initialized, and reqular way for stored procedures in postgresql is calling function from shared object (meaning, I have to shut down ghc runtime each time stored procedure ended). What other options do you see? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Terminal library : which ?
What terminal library you will recomedn? Requirements: crossplatform (win/lin), with direct (i.e. with line/column number pair) cursor positioning and possybly direct symbol output. MUST provide function to get terminal dimensions. (could not find one). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] File position
Is there any way to get current position from System.IO.Handle as Integer? If no, what other b windows/unix portable/b IO function set of file io with this functionality you can suggest? keeping track of current position by hand is not an option, sorry. I'm thinking about c's low-level functions such as open, read, write, but there is no such functions in windows and I do not know if libc from haskell platform provides emulation. If it does, I'll use lowlevel c functions brainfree. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: extcore 1.0
On 01/13/2011 10:45 PM, Tim Chevalier wrote: Hello, I've recently released version 1.0 of extcore, a library for processing code in GHC's text-based External Core format. extcore includes a parser, prettyprinter, typechecker, and interpreter for External Core, as well as modules for computing module dependencies and combining multiple Core modules into a single module. May be a stupid quesion, but does interpreter allow reasonably easy way to expose some haskell functions and data types to interpreted code as 'primitives' ? such an interpreter may be yet another scripting language, yet quite verbose one. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] parsec2 vs. parsec3... again
On 12/23/2010 06:01 AM, Evan Laforge wrote: This is not very encouraging! Especially strange is how Text generates *more* allocation... I'd expect less since it doesn't unpack all the Texts. Errgh. To check against predicate, library HAS to unpack checked character. There is no way around it. There's an obvious problem where I get the digits as a String and then parse that with list functions, but I can't see any way to get parsec to return a chunk of Text. This is roughly how parsec itself parses numbers, in Text.Parsec.Token. Any ideas or experience? If you wish performance so desperatley, you can try hand-coded parsing. What I mean is, that if library has to unpack characters to check them against isDigit predicate, why not to use it in building numeral value immidiatley? This will eliminate intermidiate list. However, every back-tracking parser is slow by definition. If you wish maximum possible speed, consider hand-written lexer (this is not too hard) and possibly Happy to generate parser. BTW, how much utf16 text is around? I never found any in wild web. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] typesetting with lhs2tex
I write docs for my iteratee-like library and I have problem with
lhs2tex. When I execute lhs2tex and then latex, I get a document with
long typesignatures and expressions expanded beyound page margins. I
attached a sourcefile I have problem with. Can someone give me an advise
how to force long signatures and expressions to be broken into multible
lines ?
This module contains basic types and combinators for building and processing streaming data
Note: any data constructor and field names may change. So, do NOT use them in your code, use only
defined functions and instances.
\begin{code}
module Data.Iteration.Types where
\end{code}
We wish full-fledged monad transformers. This imports classes from transformers package.
\begin{code}
import Control.Monad.IO.Class
import Control.Monad.Trans.Class
\end{code}
Enumerator is something that may provide input element or input tail. Enumerator is
newtype for monadic action, that can result in
Nothing - no more input
Just (Left someError) - error occured
Just (Right s, t) - some output provided and computation for source tail provided
\begin{code}
newtype Enumerator e s m
= Enumerator
{ runEnumerator ::
m (Maybe (Either e (s, Enumerator e s m) ) )
}
\end{code}
the following function is a wrapper so resulting interface for different modules be compatible.
It gets three computations: what to do if no input, what to do on error and
how to produce one step of input. Tail of input is reduced in the same computation
\begin{code}
runE :: Monad m = Enumerator e s m - m r - (e - m r) - (s - Enumerator e s m - m r) - m r
runE en pr eh sh = runEnumerator en = \v - case v of
Nothing - pr
Just (Left e) - eh e
Just (Right (s,e) ) - sh s e
\end{code}
Enumeratee is a tool for building enumerator. It is separate from enumerators to not mess the logic.
A way to embed computations in nested monad is needed. A nested monad appears in enumerator only, so
to lift from inner monad we have to enclose computation into resulting enumerator.
\begin{code}
newtype Enumeratee e s m a
= Enumeratee
{ runEnumeratee
:: (a - Enumerator e s m)
- Enumerator e s m
}
\end{code}
Of course, a way to build Enumerator from Enumeratee is needed.
\begin{code}
mkE :: Enumeratee e s m (Enumerator e s m) - Enumerator e s m
mkE e = runEnumeratee e id
\end{code}
A Monad and Functor instances for Continuation monad are adopted brain-free
\begin{code}
instance Monad (Enumeratee e s m) where
return a = Enumeratee ($ a)
m = k = Enumeratee $ \c - runEnumeratee m $ \v - runEnumeratee (k v) c
instance Functor (Enumeratee e s m) where
fmap f m = m = return . f
\end{code}
To embed computation in inner monad, we have to dig into Enumerator as Enumeratee's newtype does not
contain explicit monadic computations. This implementation runs nested computation and then passes
result to continuation and opens newtype.
\begin{code}
instance MonadTrans (Enumeratee e s) where
lift m = Enumeratee $ \c - Enumerator $ m = \v - runEnumerator (c v)
\end{code}
A very traditional MonadIO instance, found as is in most monad transformers libraries.
\begin{code}
instance MonadIO m = MonadIO (Enumeratee e s m) where
liftIO = lift. liftIO
\end{code}
The main part: yield a value. We postfix function with E (Enumeratee) to distinct from
similiar functions found later.
\begin{code}
yieldE :: Monad m = s - Enumeratee e s m ()
yieldE v = Enumeratee $ \c - Enumerator $ return $ Just $ Right (v, c () )
\end{code}
finalE is final computations returns 'dummy' enumerator. It is designed to be
last computation in do-block in Enumerator specification. An alternative exists:
failE, that indicates an error in stream.
\begin{code}
finalE :: Monad m = Enumeratee e s m (Enumerator e s m)
finalE = return $ Enumerator $ return Nothing
failE :: Monad m = e - Enumeratee e s m (Enumerator e s m)
failE e = return $ Enumerator $ return $ Just $ Left e
\end{code}
Iterator is something, that takes enumerator and produces value. Unlike Enumerator, Iterator
is in control: it reduces enumerator whenever needed. However, basic definitions follows the
same pattern.
\begin{code}
newtype Iterator r e s m
= Iterator
{ runIterator
:: Enumerator e s m
- m r
}
newtype Iteratee r e s m a
= Iteratee
{ runIteratee
:: (a - Iterator r e s m)
- Iterator r e s m
}
mkI :: Iteratee r e s m (Iterator r e s m) - Iterator r e s m
mkI i = runIteratee i id
instance Monad (Iteratee r e s m) where
return a = Iteratee ($ a)
m = k = Iteratee $ \c - runIteratee m $ \v - runIteratee (k v) c
instance Functor (Iteratee r e s m) where
fmap f m = m = return . f
instance MonadTrans (Iteratee r e s) where
lift m = Iteratee $ \c - Iterator $ \e - m = \v - runIterator (c v) e
instance MonadIO m = MonadIO (Iteratee r e s m) where
liftIO = lift . liftIO
\end{code}
This function produces final iterator that does nothing and simply returns value provided
\begin{code}
finalI :: Monad m = r - Iteratee r e s m (Iterator r e s m)
Re: [Haskell-cafe] Iteratee-like
On 12/15/2010 05:48 PM, John Lato wrote: From: Permjacov Evgeniy permea...@gmail.com mailto:permea...@gmail.com current links https://github.com/permeakra/Rank2Iteratee https://github.com/permeakra/PassiveIteratee The main difference from 'original' iteratees I read about is that both do not use 'chunks' and pass data one-by-one. So, what I wrote may be slower, but should be easier to maintain and more transparent for ghc optimising facilities. I wanted as clean and simple code as possible, but it is still very, very messy at some places and I want it cleaner. Any suggestions? I also want to check, how good ghc does its work with this messy modules. They may become interesting benchmarks. Have you tried comparing it to either iteratee or enumerator (which had mostly comparable performance last time I checked, with a slight edge to iteratee)? Or to Oleg's library? Try writing test cases, a simple byte-counting application, or similar, so you can compare the performance with the other versions. Both enumerator and iteratee include demo programs that you could use as a starting point. I wrote a simple counter (attached,works for both variants of package), that literally counts bytes of given value in input. I got three-time slower result then with lazy io ( 0_o) with rank2types variant and six-seven time slower result with no CPS-version. Looks like ghc is really good with list fusion... I'm still reading tutorial from iteratee package, so I have not compared with it yet. An equivalend lazy io programm attached. Can someone give an advice how to improve performance? I agree that iteratees which work on a per-element level are very clean and should be amenable to optimization by GHC. It also shows a very clear relationship with stream-fusion techniques. Unfortunately when I last tried it I couldn't get acceptable performance. I was using ghc-6.12.1 IIRC, so it could be different now. John module Main where import Data.List import System.IO import System.Environment main = do (fn:ls:_) - getArgs flip mapM_ ls $ \ec - do fc - readFile fn let v = foldl' (\n cc - if ec == cc then (n+1) else n ) 0 fc putStrLn $ for character ++ show ec ++ count is ++ show v putStrLn $ all done module Main where import Data.Char import Data.Iteration.Types import Data.Iteration.IO.File import Data.Word import System.Environment main = do fn:cl:_ - getArgs flip mapM_ cl $ \c - do let ccc n = do cb - nextI (putStrLn $ count for char ++ show c ++ is ++ show n) (putStrLn . show) n `seq` if (cb == fromIntegral ( ord c ) ) then ccc (n + 1) else ccc n flip runIterator (fileE fn) $ mkI $ ccc 0 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Iteratee-like
On 12/15/2010 05:48 PM, John Lato wrote: From: Permjacov Evgeniy permea...@gmail.com mailto:permea...@gmail.com current links https://github.com/permeakra/Rank2Iteratee https://github.com/permeakra/PassiveIteratee The main difference from 'original' iteratees I read about is that both do not use 'chunks' and pass data one-by-one. So, what I wrote may be slower, but should be easier to maintain and more transparent for ghc optimising facilities. I wanted as clean and simple code as possible, but it is still very, very messy at some places and I want it cleaner. Any suggestions? I also want to check, how good ghc does its work with this messy modules. They may become interesting benchmarks. Have you tried comparing it to either iteratee or enumerator (which had mostly comparable performance last time I checked, with a slight edge to iteratee)? Or to Oleg's library? Try writing test cases, a simple byte-counting application, or similar, so you can compare the performance with the other versions. Both enumerator and iteratee include demo programs that you could use as a starting point. Ok, I tested with ByteString chunks and got roughly the same performance (less then 5 % difference) as with Data.Iteratee (as expected, as it is not a monad a bottlenec when using chunks). However, with Word8' streams I slows down to point six times slower then lazy IO. this is still may be acceptable if IO actions has to be performed while making nontrivial list fusions, but in general it is fail. Well, ghc has another complicated case for compiler optimisation tests. CPS-style with rank2 types provides boost to performance, but when using chunks it is insignificant, so haskell-98 version of iteratees may be used with no worries. I agree that iteratees which work on a per-element level are very clean and should be amenable to optimization by GHC. It also shows a very clear relationship with stream-fusion techniques. Unfortunately when I last tried it I couldn't get acceptable performance. I was using ghc-6.12.1 IIRC, so it could be different now. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Iteratee-like
Ok, I think, I made it right now. I wrote two versions of the very same module with roughly the same interface. It is minimalistic framework for producing, transforming, zipping and folding streaming data (a sample code that does file IO provided, but it is not well tested yet). One version abuses CPS-style, requires rank2types, but should be slightly faster and has cleaner code. Other version is plain haskell-98 and should be reasonable portable, but is tricky at some plases and still uses CPS for specifing stream processors. I want to add many things, but currently I want to document code properly so it be easy to read (BTW, has someone any article, produced from *.lhs with good typesetting and with *.lhs itself avaible? ) current links https://github.com/permeakra/Rank2Iteratee https://github.com/permeakra/PassiveIteratee The main difference from 'original' iteratees I read about is that both do not use 'chunks' and pass data one-by-one. So, what I wrote may be slower, but should be easier to maintain and more transparent for ghc optimising facilities. I wanted as clean and simple code as possible, but it is still very, very messy at some places and I want it cleaner. Any suggestions? I also want to check, how good ghc does its work with this messy modules. They may become interesting benchmarks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] lhs2tex build failure
Hello! I use ghc-7.0.1 and cabal 1.10.0 . When tried to install lhs2tex-1.16 I got error in Setup.lhs: === Setup.hs:294:46: `programArgs' is not a (visible) field of constructor `ConfiguredProgram' Setup.hs:296:46: `programArgs' is not a (visible) field of constructor `ConfiguredProgram' === s/programArgs/programDefaultArgs/ resolves error (cabal changed ConfiguredProgram definition) however, later I had another problem when compiling: === [16 of 19] Compiling MathPoly ( MathPoly.lhs, dist/build/lhs2TeX/lhs2TeX-tmp/MathPoly.o ) MathPoly.lhs:361:39: Ambiguous type variable `tok' in the constraint: (CToken tok) arising from a use of `mkFromTo' Probable fix: add a type signature that fixes these type variable(s) In the expression: mkFromTo fstack rn n rc [fromToken $ TeX False (indent (rn, rc) (n, c))] p ls In the expression: let rstack = dropWhile (\ (rc, _) - rc = c) stack (rn, rc) = findrel (n, c) rstack fstack = (c, l) : rstack in mkFromTo fstack rn n rc [fromToken $ TeX False (indent (rn, rc) (n, c))] p ls In a case alternative: Poly p@(((n, c), ts, ind) : rs) | first - let rstack = dropWhile (\ (rc, _) - ...) stack (rn, rc) = findrel ... rstack in mkFromTo fstack rn n rc [fromToken $ TeX False (indent (rn, rc) (n, c))] p ls | c `elem` z - mkFromTo stack n (n ++ E) c ts rs ls === I cannot fix it on my own. Any suggestions ? Sorry, by I do not want downgrade, if possible. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A home-brew iteration-alike library: some extension quiestions
Well, It looks like with 'transformer' look onto iteratees it is
possible to fold two streams without anything except Iteratee, yet some
complications arise. Even real zipping. for example merging two sorted
streams with output stream sorted, is expressible. More preciesely, I
tried to write a separate module (attached) and with careful use of
'runners' I got stack of Iteratee/Enumeratee transformers, that shall do
the job. However, typing of the running function and input streams is a
mess:
t \i e g - mkEnumeration $ enumerateTo g $ mkIteration $ enumerateTo e
(mkIteration i)
\i e g - mkEnumeration $ enumerateTo g $ mkIteration $ enumerateTo e
(mkIteration i)
:: Iteratee e2 a s2 (Iteratee e1 a s1 (Enumeratee e r s m)) a
- Enumeration e2 a s2 (Iteratee e1 a s1 (Enumeratee e r s m))
- Enumeration e1 a s1 (Enumeratee e r s m)
- Enumeration e r s m
And lifting of innermost iteratee's 'nextIM' is not sufficient for merge
of sorting streams: A separate one must be written.
-- | Pure haskell 98 code : datatypes, instances and so on.
-- No fundeps/typefamilies: they will go to separate packages
module Data.Iteration.Types where
import Control.Monad.Trans.Class
import Control.Monad.IO.Class
newtype Enumeration e r s m
= Enumeration
{ runEnumeration:: m r -- executed if no more input
- (e - m r) -- executed if error encountered
- (s - Enumeration e r s m - m r) -- executed if there is more input
- m r
}
newtype Enumeratee e r s m a
= Enumeratee
{ runEnumeratee :: ( a - Enumeration e r s m ) -- how to generate tail of enumeration ?
- Enumeration e r s m
}
instance Monad (Enumeratee e r s m) where
return a = Enumeratee ( $ a)
m = k = Enumeratee $ \c - runEnumeratee m $ \p - runEnumeratee (k p) c
instance Functor (Enumeratee e r m s) where
fmap f m = m = return . f
instance MonadTrans (Enumeratee e r s) where
lift m = Enumeratee $ \c -
Enumeration $ \pr eh ip - do
v - m
runEnumeration (c v) pr eh ip
instance MonadIO m = MonadIO (Enumeratee e r s m) where
liftIO = lift . liftIO
yield :: s - Enumeratee e r s m ()
yield s = Enumeratee $ \c - Enumeration $ \ _ _ n - n s $ c ()
failE :: e - Enumeratee e r s m a
failE e = Enumeratee $ \_ - Enumeration $ \_ eh _ - eh e
stopE :: Enumeratee e r s m a
stopE = Enumeratee $ \_ - Enumeration $ \r _ _ - r
mkEnumeration :: Enumeratee e r s m a - Enumeration e r s m
mkEnumeration e = runEnumeratee e $ const $ Enumeration $ \pr _ _ - pr
enumerateTo :: Enumeration e r s m - Iteration e r s m - m r
enumerateTo = flip runIteration
--
newtype Iteration e r s m
= Iteration
{ runIteration :: Enumeration e r s m - m r }
newtype Iteratee e r s m a
= Iteratee
{ runIteratee :: ( a - Iteration e r s m )
- Iteration e r s m
}
instance Monad (Iteratee e r s m) where
return a = Iteratee ($ a)
m = k = Iteratee $ \c - runIteratee m $ \ a - runIteratee (k a) c
instance Functor (Iteratee e r s m) where
fmap f m = m = return . f
instance MonadTrans (Iteratee e r s) where
lift m = Iteratee $ \c -
Iteration $ \e - do
v - m
runIteration (c v) e
instance MonadIO m = MonadIO (Iteratee e r s m) where
liftIO = lift . liftIO
stopI :: Monad m = r - Iteratee e r s m a
stopI r = Iteratee $ \_ - Iteration $ \_ - return r
stopIM :: m r - Iteratee e r s m a
stopIM r = Iteratee $ \_ - Iteration $ \_ - r
nextI :: Monad m = r - (e - r) - Iteratee e r s m s
nextI pr eh = Iteratee $ \c - Iteration $ \e -
runEnumeration e (return pr) (return . eh) $ \s e' - runIteration (c s) e'
nextIM :: m r - (e - m r) - Iteratee e r s m s
nextIM pr eh = Iteratee $ \c - Iteration $ \e -
runEnumeration e pr eh $ \s e' - runIteration (c s) e'
mkIteration :: Monad m = Iteratee e a s m a - Iteration e a s m
mkIteration i = runIteratee i $ \v - Iteration $ \_ - return v
--
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A home-brew iteration-alike library: some extension quiestions
Hi. I Wrote a simple iteration library. It was not intensively tested, so it MAY contatin bugs, but it is very unlikely. The library is currently on github: https://github.com/permeakra/iteration I'm not ready to upload it to hackage, as some testing and extension is really needed. However, I'd like to know about possible flaws. Current goal is addition of byte-stream (de)compression and IO functions extenstion. After this package will be cabalized and uploaded to hackage. So, while design is not frozen yet, I'm interested in criticism -)/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A home-brew iteration-alike library: some extension quiestions
Original Message Subject:Re: [Haskell-cafe] A home-brew iteration-alike library: some extension quiestions Date: Thu, 09 Dec 2010 23:07:49 +0300 From: Permjacov Evgeniy permea...@gmail.com To: Antoine Latter aslat...@gmail.com On 12/09/2010 10:54 PM, Antoine Latter wrote: I only have some surface level questions/comments - What existing packages is this similar to? How is it different from any previous work in the area? Main idea was taken from Iteratees invented by Oleg Kiselev (there are two packages on hackage implementing this ideas: data-iteraties and enumerator packages) The difference is, that I wished haskell-2010 compilant package for left-foldable streams, including support for easy builing, transcoding, merging and folding of streams relying on do-notation (see Data.Iteration.Unicode.* for examples of transcoding streams: it is quite clean and easily understandable) and ability to specify easily monadic actions in stream processors. Also, likes looks like you don't need the 'Monad m' constraint on your various Monad and Functor instances in Data.Iteration.Types, which I think is one of the nicest properties of the continuation-based approach to something like this. Errgh. That may be true, but I did not consider non-monadic context at all, so I enforced this constrain mindlessly It's a mater of taste which way to go, but I prefer importing modules qualified rather than have type-suffixes on functions - so I would rather use 'I.next' and 'A.next' instead of 'nextI' and 'nextA'. But reasonable people can disagree on this. Take care, Antoine Thanks! On Thu, Dec 9, 2010 at 1:42 PM, Permjacov Evgeniy permea...@gmail.com wrote: Hi. I Wrote a simple iteration library. It was not intensively tested, so it MAY contatin bugs, but it is very unlikely. The library is currently on github: https://github.com/permeakra/iteration I'm not ready to upload it to hackage, as some testing and extension is really needed. However, I'd like to know about possible flaws. Current goal is addition of byte-stream (de)compression and IO functions extenstion. After this package will be cabalized and uploaded to hackage. So, while design is not frozen yet, I'm interested in criticism -)/ ___ 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] A home-brew iteration-alike library: some extension quiestions
On 12/09/2010 11:17 PM, Antoine Latter wrote: Also, one thing that tripped me up is that your Stream type is fundamentally different from the Stream types in the iteratee/enumerator libraries - yours is more of a monadic list in the inner monad, with explicit errors. How does this change the operation of the Iterator type? The problem was that I wished Zippee. It means that external enumerator must be suspended at some points so Zippee can process elements from both left and right streams in desired order. It makes any other approach I considered impossible to use. Also, in what way are the other libraries not Haskell-2010 compliant? I haven't experimented too much with this sort of thing, since Cabal defaults to the Haskell '98 language, and that's how I install most things. Haskell-2010 does not include functional dependencies (wich are considered evil by many) and, as I recall, type families. This makes mtl haskell-2010 and haskell-98 uncompilant -(. Functional dependencies and type familes are tricky things, so it is better to avoid them. Thanks for your response, Antoine On Thu, Dec 9, 2010 at 2:07 PM, Permjacov Evgeniy permea...@gmail.com wrote: On 12/09/2010 10:54 PM, Antoine Latter wrote: I only have some surface level questions/comments - What existing packages is this similar to? How is it different from any previous work in the area? Main idea was taken from Iteratees invented by Oleg Kiselev (there are two packages on hackage implementing this ideas: data-iteraties and enumerator packages) The difference is, that I wished haskell-2010 compilant package for left-foldable streams, including support for easy builing, transcoding, merging and folding of streams relying on do-notation (see Data.Iteration.Unicode.* for examples of transcoding streams: it is quite clean and easily understandable) and ability to specify easily monadic actions in stream processors. Also, likes looks like you don't need the 'Monad m' constraint on your various Monad and Functor instances in Data.Iteration.Types, which I think is one of the nicest properties of the continuation-based approach to something like this. Errgh. That may be true, but I did not consider non-monadic context at all, so I enforced this constrain mindlessly It's a mater of taste which way to go, but I prefer importing modules qualified rather than have type-suffixes on functions - so I would rather use 'I.next' and 'A.next' instead of 'nextI' and 'nextA'. But reasonable people can disagree on this. Take care, Antoine Thanks! On Thu, Dec 9, 2010 at 1:42 PM, Permjacov Evgeniy permea...@gmail.com wrote: Hi. I Wrote a simple iteration library. It was not intensively tested, so it MAY contatin bugs, but it is very unlikely. The library is currently on github: https://github.com/permeakra/iteration I'm not ready to upload it to hackage, as some testing and extension is really needed. However, I'd like to know about possible flaws. Current goal is addition of byte-stream (de)compression and IO functions extenstion. After this package will be cabalized and uploaded to hackage. So, while design is not frozen yet, I'm interested in criticism -)/ ___ 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] haskell-2010 binary IO
Does haskell 2010 include binary IO? If no, what was the reason? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Digests
On 12/03/2010 10:48 AM, Serguey Zefirov wrote: 2010/12/3 Permjacov Evgeniy permea...@gmail.com: Most of the time you can get away with usual block ciphers (and even with weaker parameters). There is a scheme that transforms block cipher into hash function: http://en.wikipedia.org/wiki/CRHF#Hash_functions_based_on_block_ciphers */me wrote it into to_read list. The problem is, however, that block ciphers are quite unfriendly to plain word8 streams. It is not a deadly problem, but i'd like to avoid block collections. All one-way hashes do block collections. This is unavoidable. Why ? Is there some math behind this proposition ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Digests
On 12/03/2010 11:40 AM, Serguey Zefirov wrote: 2010/12/3 Permjacov Evgeniy permea...@gmail.com: */me wrote it into to_read list. The problem is, however, that block ciphers are quite unfriendly to plain word8 streams. It is not a deadly problem, but i'd like to avoid block collections. All one-way hashes do block collections. This is unavoidable. Why ? Is there some math behind this proposition ? This is hard - to add single byte into the sum with cryptographic (or near cryptographic) security. To quote Wikipedia again: The avalanche effect is evident if, when an input is changed slightly (for example, flipping a single bit) the output changes significantly (e.g., half the output bits flip). This simply means, that active set of bits must be at least of the size of final value and value to be added must be added somehow to every byte in active set. The simplest way to do it is multiplication of vector [active-state-bits++current-byte] and some matrix of size [resulting bytes count|resulting bytes count + 1] (of cource, not in floating-point math, but, for example, using modulo-256 arithmetic or even hand-coded tables for mul and sum). This, of course, means, that byte-streaming hashes needs some initial seed (that must be paired with resulting value to check) and that every byte will cause much operations to perform, resulting in poor performance. So, the conclusion is: byte-streaming hashes are possible, but because of requirements definitly will have poor performance, much worse then block ones. Am I correct? http://en.wikipedia.org/wiki/Avalanche_effect This is true for hashes too. Hash should change about half of the random output bits when single bit of input changes. Especially if you aim to tamper-proof hashes. You have to have that property on every round of hashing, because you don't know when to stop. For bytes, you have to guarantee that you get an avalanche effect for every byte - it means, that you have to transform your entire block plus input byte in an expensive way. MD5 and all other hashes have internal state of various size, they all keep input blocks to make hashing transform less expensive. Fast methods like sum-modulo-poly (CRC variants) or linear congruential generators do not have good avalanche property when used for stream hashing or encryption. Even their combination (one in ZIP encryption) wasn't strong enough. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Digests
The data integrity checks is well-known problem. A common soluting is use of 'checksums'. Most of them , however, are built in quite obfuscated manner (like md5) that results in ugly and error-prone implementations (see reference implementation for same md5). So, the question is: is there a checksum, that is easy to implement over stream of bytes and may work as good checksum and is good in sence that creation of messages with same checksum that given message has is very hard problem (at least 2^128 tries) ? The reason is that I wish a good checksum to be implemented im my stream-oriented library. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Digests
On 12/03/2010 12:33 AM, Serguey Zefirov wrote: 2010/12/3 Permjacov Evgeniy permea...@gmail.com: The data integrity checks is well-known problem. A common soluting is use of 'checksums'. Most of them , however, are built in quite obfuscated manner (like md5) that results in ugly and error-prone implementations (see reference implementation for same md5). So, the question is: is there a checksum, that is easy to implement over stream of bytes and may work as good checksum and is good in sence that creation of messages with same checksum that given message has is very hard problem (at least 2^128 tries) ? 2^128 tries needed for hash size of 256 bits. See http://en.wikipedia.org/wiki/Birthday_attack Ok, I have to use at least 256 bit resulting value. This is four Word64 or 32 Word8 ... Well, maybe it will work Most of the time you can get away with usual block ciphers (and even with weaker parameters). There is a scheme that transforms block cipher into hash function: http://en.wikipedia.org/wiki/CRHF#Hash_functions_based_on_block_ciphers */me wrote it into to_read list. The problem is, however, that block ciphers are quite unfriendly to plain word8 streams. It is not a deadly problem, but i'd like to avoid block collections. RC5, for example, parametrized by number of encryption rounds. RC5 with 12 rounds has sufficiently good avalanche (spread of bit change) so that you can use 12-round RC-5 instead of full death proof 20-round. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal-install is broken
current cabal-install (0.8.2) cannot be compiled with ghc-7.0.1 set of boot libraries. It requires cabal 1.8.* wich fails to compile. Does anyone worked this out ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] xml packages
First question. As I saw in sources, both hxt and haxml uses [Char]'s. this is very inefficient. I want to know, does any effective parser for haskell, written in haskell, exists. Efficient means using ByteString to store strings and possibly building representations that shares one string for all similiary named elements. If there is no, is anyone interested in writing one? Second question. I'd like to have a package for read-write-edit SVG graphics. I think, xslt (both transformations and formatting object) are interesting too. Is anyone considering writing such packages? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is simplest extension language to implement?
ehm. I missed something and ghc api is well documented and stable ? There are other ways of adding Haskell as a scripting language - bundling ghc is not necessary. I still have not found haskell interpreter, that is written in pure haskell and has good quality (i.e. stable, written in stable subset of ghc haskell, is small and so on). I know, that there is haskell-src(-ext), but interpreter (or at least compiler to ext-core) is needed. However, it may be a way... if no other will be found. It is inacceptable for scripting language, faced to no-programmers. Such languages must be as plain and regular, as possible. We give Haskell as a embedded scripting language to non-programmers, and they love it. They especially like the strong typing, which finds their bugs before they ever get the chance to run their script. The terseness and lack of similarity to other programming languages is another benefit. I loved it as well and I was not programmer at that moment. However, I spent about 30-40 evenings to learn it well enough. I wish language, that can be learned in 3 evenings and used well enough for 3 days of work... And many of it's fetures are not standardized yet. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] What is simplest extension language to implement?
Let us think, that we need some scripting language for our pure haskell project and configure-compile-run is not a way. In such a case a reasonably simple, yet standartized and wide known language should be implemented. What such language may be? R(4/5/6)RS ? EcmaScript ? Some other ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is simplest extension language to implement?
Forth is quite easy to implement, but can it be used as extension language? Wiki describes it as quite low level... TCL ... Well, I'll consider it if it have written standart, like RxRS does. On 11/02/2010 09:31 AM, Miguel Mitrofanov wrote: Ehm... Forth? TCL? Отправлено с iPhone Nov 2, 2010, в 9:04, Permjacov Evgeniy permea...@gmail.com написал(а): Let us think, that we need some scripting language for our pure haskell project and configure-compile-run is not a way. In such a case a reasonably simple, yet standartized and wide known language should be implemented. What such language may be? R(4/5/6)RS ? EcmaScript ? Some other ? ___ 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] What is simplest extension language to implement?
ehm. I missed something and ghc api is well documented and stable ? The problem is that haskell is overkill here and it requires esoteric extensions for some tasks (Rank2Types for reflection, for example). It is inacceptable for scripting language, faced to no-programmers. Such languages must be as plain and regular, as possible. So, statically typed languages are out of consideration: they either have poor expressive power, or have expressive, but complex type system (as haskell), or relies on hacks within language for some tasks(typecasts and duck typing in c++). Scheme may be acceptable, and possibly EcmaScript. I do not know any other acceptable standartized language. Yet, Scheme has really ugly synthax and Ecma-262 standard is 250 pages long (Of course, it is not C++ with about 1000 pages in standart, but it still hurts to read 250 pages of techdocs in foreign language). On 11/02/2010 12:21 PM, Lennart Augustsson wrote: I don't understand. Why don't you use Haskell as the scripting language? On Tue, Nov 2, 2010 at 7:04 AM, Permjacov Evgeniy permea...@gmail.com wrote: Let us think, that we need some scripting language for our pure haskell project and configure-compile-run is not a way. In such a case a reasonably simple, yet standartized and wide known language should be implemented. What such language may be? R(4/5/6)RS ? EcmaScript ? Some other ? ___ 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] Finite but not fixed length...
infinite value is value, that have no upper bound (see infinity
definition). So, you have to provide upper bound at compile time. Tree
example provides such bound.
On 10/13/2010 03:27 PM, Eugene Kirpichov wrote:
Again, the question is not how to arrange that all non-bottom values
are finite: this can easily be done using strictness, as in your List
example.
The trick is to reject infinite values in compile time. How can *this* be
done?
13 октября 2010 г. 15:26 пользователь Permjacov Evgeniy
permea...@gmail.com написал:
On 10/13/2010 03:09 PM, Eugene Kirpichov wrote:
1-st scenario: If you have, for example, 2-3 tree, it definitly has a
root. If you construct tree from list and then match over root, the
entire tree (and entire source list) will be forced. And on every
update, 2-3 tree's root is reconstructed in functional setting. So, if
you'll try to build 2-3 tree from infinite list, it will fail in process
due insuffisient memory.
Of course, you can make the same with
data List a = Cons a (!List a) | Nil
second scenario
data Node a = Nil | One a | Two a a
and so Node (Node (Node (Node a))) has at most 2^4 = 16 elements. with
some triks you'll be able to set upper bound in runtime.
I don't see how. Could you elaborate?
13 октября 2010 г. 14:46 пользователь Permjacov Evgeniy
permea...@gmail.com написал:
On 10/13/2010 12:33 PM, Eugene Kirpichov wrote:
I think, tree-like structure, used as sequence (like fingertrees), will
do the work.
but it's not so easy to make infinite lists fail to typecheck...
That's what I'm wondering about.
2010/10/13 Miguel Mitrofanov miguelim...@yandex.ru:
hdList :: List a n - Maybe a
hdList Nil = Nothing
hdList (Cons a _) = Just a
hd :: FiniteList a - Maybe a
hd (FL as) = hdList as
*Finite hd ones
this hangs, so, my guess is that ones = _|_
13.10.2010 12:13, Eugene Kirpichov пишет:
{-# LANGUAGE ExistentialQuantification, GADTs, EmptyDataDecls #-}
module Finite where
data Zero
data Succ a
class Finite a where
instance Finite Zero
instance (Finite a) = Finite (Succ a)
data List a n where
Nil :: List a Zero
Cons :: (Finite n) = a - List a n - List a (Succ n)
data FiniteList a where
FL :: (Finite n) = List a n - FiniteList a
nil :: FiniteList a
nil = FL Nil
cons :: a - FiniteList a - FiniteList a
cons a (FL x) = FL (Cons a x)
list123 = cons 1 (cons 2 (cons 3 nil))
ones = cons 1 ones -- typechecks ok
___
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] Arrow transformers: how to make them wright?
A Control.Arrow in base package introduces an arrow type, and ghc have good support for arrow notation. Many things, avaible in monads, are avaible in arrows as well. There is an arrows package, that introduces some arrow classes : state, reader, writer and so on. However, it does not introduce systematic lifting of arrow classes operations. Arrows are generalisation of monads. There are libraries, that introduces systematic lifting of operations from monad classes. So, the quesions are: what operations should be in arrow transformer class? Captain Obvious says, it should look at least like: class ArrowTrans t where lift :: ( Arrow a, Arrow (t a) ) = a b c - t a b c what laws arrow transformers must obey? C.O. says, at least lift a b c lift a c d == lift ( a b c a c d ) how to perform lifting of actions for classes like this: class Arrow a = ArrowError a e| a- e where raise :: a e () handle :: a e c - a b c - a b c class Arrow a = ArrowReader a e | a - e where look :: a () e local :: a b c - a (b,e) c The answers lies somewhere in category theory, C.O. says. Of course, such answer is not satisfactory. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Parsing of bytestrings with non-String errors?
On 02/21/2010 11:57 PM, haskell-cafe-requ...@haskell.org wrote: Message: 2 Date: Sun, 21 Feb 2010 12:36:21 + From: Magnus Therning mag...@therning.org Subject: [Haskell-cafe] Parsing of bytestrings with non-String errors? To: haskell-cafe haskell-cafe@haskell.org Message-ID: 4b8128c5.6030...@therning.org Content-Type: text/plain; charset=utf-8 I've looked at polyparse and attoparsec and they seem to have in common that the error always is a String. My current ideas for a project would be a lot easier if I could just return some other type, something that I can pattern match on. Is there a parser combinator library out there that works on bytestrings and allows using a custom error type? Or maybe there's some very basic reason why String is so commonly used? You can try to play with ParsecT / ErrorT ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
