On Mon, 2007-09-17 at 14:37 -0500, John Goerzen wrote:
> * It would be really nice if QuickCheck supported I/O and some version
> of HUnit's TestLabel to generate hierarchical names when failures
> occur.
I've done this for testing IO (reading and writing files):
> prop_serialize (E s) =
>
On 9/17/07, Hugh Perkins <[EMAIL PROTECTED]> wrote:
> Just out of curiosity, how could one do something like a factory, so
> that by default a library uses, say, Data.Map, but by making a simple
> assignment we can switch the library to use a different
> implementation?
>
> (This is alluded to abov
On 9/18/07, Hugh Perkins <[EMAIL PROTECTED]> wrote:
> Just out of curiosity, how could one do something like a factory, so
> that by default a library uses, say, Data.Map, but by making a simple
> assignment we can switch the library to use a different
> implementation?
(And of course, the 10 mill
Just out of curiosity, how could one do something like a factory, so
that by default a library uses, say, Data.Map, but by making a simple
assignment we can switch the library to use a different
implementation?
(This is alluded to above, but not explicitly stated. I guess it's
too easy, but someo
Couple of thoughts/observations:
- Erlang has a vm, so that would avoid building a vm.
On the downside, erlang is not pure: the message-passing and the io:
commands imply the possibility of side-effects.
Still, it could be good enough for a proof-of-concept?
- implementation as a library functi
Paul Johnson-2 wrote:
>
> SevenThunders wrote:
>> Unfortunately if I wrap my matrix references in the IO monad, then at
>> best
>> computations like
>> S = A + B are themselves IO computations and thus whenever they are
>> 'invoked' the computation ends up getting performed repeatedly contrar
who knows how to compile yi-gtk?
i tried,but it told me mine miss gtk.
2007-09-18
clisper
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Hi
> Competing packages for XML or DBM is really awful, unless they happen
> to be interface compatible.
Imagine two XML libraries which share the same interface. That implies
that they have exactly the same design criteria, take the same view of
XML files and are pretty much the same in every us
Competing packages for XML or DBM is really awful, unless they happen
to be interface compatible.
And there is a good way of switching imps at assembly time, such that
lib code that consumes xml doesn't depend on which xml imp I have.
Of course, I realize that a good interface for those is still an
>{-# LANGUAGE TypeFamilies #-}
Hi Justin, thanks for your interest. Hope this helps!
>module Examples where
>import Records
To get started, you need to define your labels. They are just
singleton datatypes:
>data FirstName = FirstName deriving (Show, Eq, Ord)
>data Surna
On 9/17/07, Roberto Zunino <[EMAIL PROTECTED]> wrote:
> I thought this was possible with GADTs (is it?):
>
> data Z
> data S n
> data List a len where
>Nil :: List a Z
>Cons:: a -> List a len -> List a (S len)
>
Slightly related:
The other day I was playing with exactly this GADT. See: ht
Andrew Coppin wrote:
Adrian Hey wrote:
Personally I don't really like the idea of Data.Map, Data.Map.AVL or
any other lib becoming entrenched as official or de-facto standards.
It seems like a recipe for stagnation to me. IMHO such libs just
shouldn't be bundled with ghc (or any other compiler)
Andrew Coppin wrote:
If something is broken, it should be fixed. If something isn't broken, I
see no reason to change it. You might call that "stagnation", but I view
it as something else...
Nobody is talking about changing anything, at least not Data.Map.
We're talking about why alternatives
[EMAIL PROTECTED] wrote:
Andrew Coppin writes:
Out of curiosity... what's so bad about "stagnation"? (Otherwise
known as "having a fixed structure that everybody can rely on"...)
Oh come on, you know the answer, do you like provocations?
Shall I remind how many people are unhappy e.g., with t
Hi
> > They are less stable and have less quality control.
>
> Surely you jest? I see no evidence of this, rather the contrary in fact.
No, dead serious. The libraries have a library submission process.
Compare me changing my tagsoup library, to me changing my filepath
library which comes bundle
On Mon, Sep 17, 2007 at 07:38:00PM +0100, Malcolm Wallace wrote:
> David Roundy <[EMAIL PROTECTED]> writes:
>
> > Data.Map is a standardized interface, *not* a standardized implementation.
> > I'm not saying it's a *good* standardized interface, but it's the only one
> > we've got.
>
> Not so! T
Roberto Zunino wrote:
apfelmus wrote:
cons:: a -> List e f a -> List Nonempty f a
But unfortunately, finiteness is a special property that the type
system cannot guarantee. The above type signature for cons doesn't
work since the following would type check
bad :: a -> List Nonempty
Philippa Cowderoy wrote:
> On Mon, 17 Sep 2007, Adrian Hey wrote:
>> Ideally the way to deal with this is via standardised interfaces (using
>> type classes with Haskell), not standardised implementations. Even this
>> level of standardisation is not a trivial clear cut design exercise.
>> e.g we c
Hi
> What's bad about stagnation is that nobody will bother to produce
> anything better (at least not as a fully polished publicly available
> open source project), precisely because they have little chance of
> achieving a user base exceeding 1 (at least not if the attitude of
> David and Neil i
Adrian Hey wrote:
Personally I don't really like the idea of Data.Map, Data.Map.AVL or
any other lib becoming entrenched as official or de-facto standards.
It seems like a recipe for stagnation to me. IMHO such libs just
shouldn't be bundled with ghc (or any other compiler) for this reason.
Out
Philippa Cowderoy wrote:
> On Mon, 17 Sep 2007, Adrian Hey wrote:
>
>> Ideally the way to deal with this is via standardised interfaces (using
>> type classes with Haskell), not standardised implementations. Even this
>> level of standardisation is not a trivial clear cut design exercise.
>> e.g w
Hi folks,
I just announced ListLike[1] on [EMAIL PROTECTED] Rather than repeat
that announcement here, I'd like to make a few observations that came
out of the development of this program:
* I wrote extensive QuickCheck cases for this and wrapped them in HUnit
for better display and future ext
On Sat, 15 Sep 2007, Joachim Breitner wrote:
today while mowing the lawn, I thought how to statically prevent some
problems with infinte lists. I was wondering if it is possible to
somehow mark a list as one of finite/infinite/unknown and to mark
list-processing functions as whether they can ha
On 9/17/07, Henning Thielemann <[EMAIL PROTECTED]> wrote:
> On Sat, 15 Sep 2007, Sam Hughes wrote:
> > Prelude> (x,y) <- return $ (repeat 1, repeat 2)
> You didn't tell, which Monad this shall be.
GHCi always runs in the IO monad.
-- ryan
___
Haskell
On 9/16/07, Mads Lindstrøm <[EMAIL PROTECTED]> wrote:
> Hi all
>
> If I have this type:
>
> data Foo a b = ...
>
> and this class
>
> class Bar (x :: * -> *) where ...
>
> I can imagine two ways to make Foo an instance of Bar. Either I must
> "apply" the 'a' or the 'b' in (Foo a b). Otherwise i
On Mon, Sep 17, 2007 at 06:43:40PM +0100, Adrian Hey wrote:
> >so that other packages can use them in their interfaces without putting
> >undue burden on their users (and without the users being forced to
> >figure out how to convert back and forth between various different
> >Data.Map.*).
>
> I w
David Roundy <[EMAIL PROTECTED]> writes:
> Data.Map is a standardized interface, *not* a standardized implementation.
> I'm not saying it's a *good* standardized interface, but it's the only one
> we've got.
Not so! There is another more venerable interface, namely Data.FiniteMap.
That interface
Andrew Coppin writes:
Adrian Hey wrote:
Personally I don't really like the idea of Data.Map, Data.Map.AVL or
any other lib becoming entrenched as official or de-facto standards.
It seems like a recipe for stagnation to me. IMHO such libs just
shouldn't be bundled with ghc (or any other compiler
On Sat, 15 Sep 2007, Sam Hughes wrote:
That's weird.
Prelude> (x,y) <- return $ (repeat 1, repeat 2)
You didn't tell, which Monad this shall be.
Prelude> Just x <- return $ Just (repeat 1)
[1,1,1,...
Prelude> (x,_) <- return $ (repeat 1, repeat 2)
[1,1,1,...
Prelude> Just (x,y) <- return $
Neil Mitchell wrote:
Hi
They are less stable and have less quality control.
Surely you jest? I see no evidence of this, rather the contrary in fact.
No, dead serious. The libraries have a library submission process.
It does not follow that libraries that have not been submitted
to this pro
On Mon, 17 Sep 2007, Adrian Hey wrote:
> Ideally the way to deal with this is via standardised interfaces (using
> type classes with Haskell), not standardised implementations. Even this
> level of standardisation is not a trivial clear cut design exercise.
> e.g we currently have at least two com
David Roundy wrote:
On Mon, Sep 17, 2007 at 11:07:10AM +0100, Adrian Hey wrote:
Ketil Malde wrote:
What would the disadvantages be to replacing Data.Map with this
implementation?
Personally I don't really like the idea of Data.Map, Data.Map.AVL or
any other lib becoming entrenched as official
On Mon, Sep 17, 2007 at 04:50:13PM +0100, Ian Lynagh wrote:
> On Mon, Sep 17, 2007 at 07:54:02AM -0700, David Roundy wrote:
> >
> > cabal-install may help, but what I'd really want is packaging in debian.
> > That's my (biased, because I used debian) standard of a "maintained, useful
> > library."
apfelmus wrote:
cons:: a -> List e f a -> List Nonempty f a
But unfortunately, finiteness is a special property that the type system
cannot guarantee. The above type signature for cons doesn't work since
the following would type check
bad :: a -> List Nonempty Finite a
bad x = let
Neil Mitchell wrote:
Would you care to explain why you have this aversion to libs that aren't
bundled with ghc?
They are less stable and have less quality control.
Surely you jest? I see no evidence of this, rather the contrary in fact.
Though I must admit the documentation situation for mos
On 9/16/07, Barney Hilken <[EMAIL PROTECTED]> wrote:
> Now that I have a version of ghc with type classes, I have had a go
> at implementing records based on the ideas I mentioned on this list a
> few months ago. The code of my first attempt is available at http://
> homepage.ntlworld.com/b.hilken/
On Mon, Sep 17, 2007 at 07:32:53PM +0800, L.Guo wrote:
>
> I have toolchain for the targer system. Using which, I can
> compile on PC and run the program on the embed system.
This isn't something that anyone's ever done with GHC, to the best of my
knowledge. You'd probably have to get your hands
On Mon, Sep 17, 2007 at 07:54:02AM -0700, David Roundy wrote:
>
> cabal-install may help, but what I'd really want is packaging in debian.
> That's my (biased, because I used debian) standard of a "maintained, useful
> library." It's obviously a biased standard, but it isn't too hard for a
> pack
On Mon, Sep 17, 2007 at 11:07:10AM +0100, Adrian Hey wrote:
> Ketil Malde wrote:
> >What would the disadvantages be to replacing Data.Map with this
> >implementation?
>
> Personally I don't really like the idea of Data.Map, Data.Map.AVL or
> any other lib becoming entrenched as official or de-fact
On Mon, Sep 17, 2007 at 10:05:36AM +0100, Neil Mitchell wrote:
> > Would you care to explain why you have this aversion to libs that aren't
> > bundled with ghc?
>
> They are less stable and have less quality control. It is also an
> additional burden for a user to install the library to get the p
Odd place it is, indeed!
QUOTE: "Data.Fixed... DESCRIPTION... This module defines a Fixed
type for
fixed-precision arithmetic...*This module also contains generalisations
of div, mod, and divmod to work with any Real instance.*"
Thanks a lot. I wouldn't have found that myself ;-)
Jules Bea
Peter Verswyvelen wrote:
Maybe this is a stupid question, but I don't find something similar in
Haskell.
I find mod and rem, which work on integers. But I'm looking for a
function similar to C's fmod.
Of course I can write it myself, but I guess it must already exist under
a different name?
On 9/17/07, Martin Lütke <[EMAIL PROTECTED]> wrote:
> What is the url for the wiki entry?
There was already a page at
http://haskell.org/haskellwiki/GHC/GHCi
so I put it there, but I also took the liberty of creating some #REDIRECTs, so
http://haskell.org/haskellwiki/ghci
should work just
Hi all:
How to build a GHC which can run in a embed linux system ?
I have toolchain for the targer system. Using which, I can
compile on PC and run the program on the embed system.
Is this means, if I change CC env-var to the toolchain compiler
and compile GHC manually, I can get a program for t
Maybe this is a stupid question, but I don't find something similar in
Haskell.
I find mod and rem, which work on integers. But I'm looking for a
function similar to C's fmod.
Of course I can write it myself, but I guess it must already exist under
a different name?
Thanks,
Peter
On 9/16/07, Ryan Ingram <[EMAIL PROTECTED]> wrote:
Is there a way to make GHCi not print the result
of an action but still make my variables get bound?
This seems to be a common question (I myself asked it recently), so
I've added an entry to the GHCi page on the
Ketil Malde wrote:
It seems Adrian's library is a replacement for Data.Map, only with
higher performance and more features.
Well not quite for anyone using indexing or who needs O(1) size, but
apart from that it should be a fully compatible replacement. At least
that was my intention, though I
Hi
> Would you care to explain why you have this aversion to libs that aren't
> bundled with ghc?
They are less stable and have less quality control. It is also an
additional burden for a user to install the library to get the program
working.
cabal-install should fix the second. Some useful com
David Roundy wrote:
On Sat, Sep 15, 2007 at 08:27:02AM +0100, Adrian Hey wrote:
Perhaps what you really mean is, you long for a Data.Map.Strict that
carries the offically blessed status of being shipped with ghc (reminds
me of someone asking for a "ghc approved" SDL binding a while back :-).
Y
49 matches
Mail list logo
