On Thu, May 1, 2008 at 4:10 PM, Daniil Elovkov
<[EMAIL PROTECTED]> wrote:
> Felipe Lessa wrote:
>
> > On Thu, May 1, 2008 at 9:44 AM, Felipe Lessa <[EMAIL PROTECTED]>
> wrote:
> >
> > > On Thu, May 1, 2008 at 9:32 AM, Edsko de Vries <[EMAIL PROTECTED]>
> wrote:
> > > > So then the question become
Hello Ben,
Saturday, May 3, 2008, 5:13:48 AM, you wrote:
> have the issues with castIOUArray (and thus hGetArray, hPutArray) in
> Data.Array.IO discussed below been resolved?
there is alternative arrays library [1], where bounds are recalculated
when casting
[1] http://haskell.org/haskellwiki/L
On 03/05/2008, Keith Fahlgren <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
> Our next BayFP meeting will be this Thursday, May 8th, 2008 at 7:30pm.
> We'll feature Bryan O'Sullivan on Concurrent and multicore programming
> in Haskell. Bryan is a co-author of the upcoming O'Reilly book Real
Cant wait fo
hi there,
i assume you're asking about benefits with respect to serialization?
other than some performance hacks, probably none. there was no good
reason for me to use hPutArray and the like, i just saw them in the
API docs and decided to try them out -- and got burned! Data.Binary
has worked gr
midfield:
> hi haskellers,
>
> have the issues with castIOUArray (and thus hGetArray, hPutArray) in
> Data.Array.IO discussed below been resolved?
>
> http://www.haskell.org/pipermail/libraries/2003-January/thread.html
>
> here is a (trivial) program which has rather unexpected behavior.
> (i'm
hi haskellers,
have the issues with castIOUArray (and thus hGetArray, hPutArray) in
Data.Array.IO discussed below been resolved?
http://www.haskell.org/pipermail/libraries/2003-January/thread.html
here is a (trivial) program which has rather unexpected behavior.
(i'm switching to Data.Binary in
Hi,
I was wondering if anybody had experimented with using Template Haskell
(TH) and ordinary SQL to make type-safe database access?
To clarify what I am thinking about I will sketch how it could be done.
The TH function should take two inputs. SQL (as a string) and a database
source name (DSN).
Hi,
Our next BayFP meeting will be this Thursday, May 8th, 2008 at 7:30pm.
We'll feature Bryan O'Sullivan on Concurrent and multicore programming
in Haskell. Bryan is a co-author of the upcoming O'Reilly book Real
World Haskell [http://book.realworldhaskell.org/]. (among all sorts of
other snazz
Well, if you could change your data structure, probably something like
this could work (in spirit of Daniil's response):
module Main where
data Tree = Tree {
parent :: Maybe (Either Tree Tree)
, left :: Maybe Tree
, right :: Maybe Tree
}
buildTree :: (a -> (Maybe a, Maybe a)) -> a -> Tree
>unification
>f :: a = h = (e -> d -> c)
>x b = d
>
> No. x :: b = d (a typo?)
>Paul: What's wrong with x being of type b and of type d?
> Could you perhaps explain the error please?
>
Nothing's wrong, you just forgot a ::, that is, you wrote x b = d
2008/5/1 Galchin, Vasili <[EMAIL PROTECTED]>:
> Sorry .. my example was bad. I want to use "x" .. in then branch where
> it occur ...
>
> e.g.
> bonzo :: Maybe Bozo -> IO ()
> bonzo maybe_bozo = do
> case maybe_bozo of
> Just (Bozo x) -> x
>
2008/5/2 Claus Reinke <[EMAIL PROTECTED]>:
>
> > 2008/5/2 Simon Marlow <[EMAIL PROTECTED]>:
> >
> > > David Waern wrote:
> > >
> > > > No it doesn't, but it's on the TODO list. It needs a fix in GHC.
> > > >
> > > > By the way, I'm going to experiment with doing the parsing of comments
> > > > on t
> I remember an article ranting about how lazy evaluation would be great to
> do signal processing, but it was lacking real world example.
The nyquist language does this. It's not haskell, but it does use
lazy evaluation for signals.
___
Haskell-Cafe m
2008/5/2 Simon Marlow <[EMAIL PROTECTED]>:
David Waern wrote:
> No it doesn't, but it's on the TODO list. It needs a fix in GHC.
>
> By the way, I'm going to experiment with doing the parsing of comments
> on the Haddock side instead of in GHC.
> If that works out, we won't have to fix these thi
I'm not sure there's a proof as such, more like a definitional absence
of distinction between initiality and finality. In other words,
the CPO framework is orthogonal to such extremality considerations.
Perhaps someone here knows about work enriching CPOs in that
direction.
-- Kim-Ee
Michael
On Fri, May 2, 2008 at 12:16 AM, Donn Cave <[EMAIL PROTECTED]> wrote:
> Graham Fawcett wrote:
>
>
> > I would like to communicate with an external, line-oriented process,
> > which takes a sequence of one-line commands, each returning an
> > arbitrary number of lines, and waits for another command
2008/5/2 Simon Marlow <[EMAIL PROTECTED]>:
> David Waern wrote:
>
> > No it doesn't, but it's on the TODO list. It needs a fix in GHC.
> >
> > By the way, I'm going to experiment with doing the parsing of comments
> > on the Haddock side instead of in GHC.
> > If that works out, we won't have to fi
Thomas Girod:
Recently, I read a few articles about Haskell (and FP in general) and
music/sound.
I remember an article ranting about how lazy evaluation would be great to
do signal processing, but it was lacking real world example.
Check (e.g. through Google) what Henning Thielemann wrote
Thomas Girod wrote:
Hi there. Following this advice
(http://reddit.com/info/6hknz/comments/c03vdc7), I'm posting here.
Recently, I read a few articles about Haskell (and FP in general) and
music/sound.
I remember an article ranting about how lazy evaluation would be great
to do signal proc
On Fri, 2 May 2008, Thomas Girod wrote:
Hi there. Following this advice
(http://reddit.com/info/6hknz/comments/c03vdc7), I'm posting here.
Recently, I read a few articles about Haskell (and FP in general) and
music/sound.
I remember an article ranting about how lazy evaluation would be gr
Hi there. Following this advice
(http://reddit.com/info/6hknz/comments/c03vdc7), I'm posting here.
Recently, I read a few articles about Haskell (and FP in general) and
music/sound.
I remember an article ranting about how lazy evaluation would be great
to do signal processing, but it was la
Just in case anyone missed this:
[1]
funk f x = f (funk f) x
f :: a
x :: b
funk f x :: c
therefore funk :: a -> b -> c
RHS
f (funk f) x :: c
f (funk f) :: d -> c
x :: d
f :: e -> d -> c
fun
Hi Don,
> Just a quick announcement, I've uploaded to hackage 'ghc-core' , a
> wrapper over ghc for displaying the optimised core and assembly language
> ghc produces from your programs.
This is cool, but it still lags behind the facilities found in yhc-core.
http://yhc06.blogspot.com/2006/12/
23 matches
Mail list logo
