On Sat, Dec 01, 2007 at 10:01:13PM -0800, Stefan O'Rear wrote:
> On Sun, Dec 02, 2007 at 05:45:48AM +0100, Tomasz Zielonka wrote:
> > That's a questionable decision, IMO:
> > - it changes behavior
> > - I expect :browse to be used more often, so it deserves the sort
> > :b version (:bro is not th
On Sun, Dec 02, 2007 at 05:45:48AM +0100, Tomasz Zielonka wrote:
> On Fri, Nov 30, 2007 at 08:55:51AM +, Neil Mitchell wrote:
> > Hi
> >
> > > Prelude> :b Control.Concurrent.MVar
> > > module 'Control.Concurrent.MVar' is not interpreted
> >
> > :b now defaults to :breakpoint, you want :br
On Fri, Nov 30, 2007 at 08:55:51AM +, Neil Mitchell wrote:
> Hi
>
> > Prelude> :b Control.Concurrent.MVar
> > module 'Control.Concurrent.MVar' is not interpreted
>
> :b now defaults to :breakpoint, you want :browse
That's a questionable decision, IMO:
- it changes behavior
- I expect :br
On Sun, Dec 02, 2007 at 03:54:05AM +, Kannan Goundan wrote:
> On Sat, 01 Dec 2007 21:22:53 -0600, Derek Elkins wrote:
>
> > Use ST. First-class state isn't too great unless you specifically want
> > that.
>
> I did try using ST but ran into a problem because its type variable (s)
> ended up
On Sat, 01 Dec 2007 21:22:53 -0600, Derek Elkins wrote:
> Use ST. First-class state isn't too great unless you specifically want
> that.
I did try using ST but ran into a problem because its type variable (s)
ended up invading all of my types.
-- Target needs 's' because of the STRef
data
On Sun, 2007-12-02 at 03:29 +, Robin Green wrote:
> On Sat, 01 Dec 2007 21:22:53 -0600
> Derek Elkins <[EMAIL PROTECTED]> wrote:
>
> > > There's also the issue of finding a more elegant way of threading
> > > the Store through my evaluator, but I'm not concerned too much
> > > about that at th
On Sat, 01 Dec 2007 21:22:53 -0600
Derek Elkins <[EMAIL PROTECTED]> wrote:
> > There's also the issue of finding a more elegant way of threading
> > the Store through my evaluator, but I'm not concerned too much
> > about that at this point. I can probably define a state-carrying
> > monad like P
On Sun, 2007-12-02 at 03:11 +, Kannan Goundan wrote:
> I'm implementing an interpreter for the lambda calculus augmented with
> mutable variables. I'm having problems doing the mutable state stuff in
> Haskell. Here's what I have so far:
>
> type Expr= ... terms in the language ...
>
I'm implementing an interpreter for the lambda calculus augmented with
mutable variables. I'm having problems doing the mutable state stuff in
Haskell. Here's what I have so far:
type Expr= ... terms in the language ...
type Value = ... values in the language ...
type Ident = St
On Dec 1, 2007, at 21:43 , PR Stanley wrote:
Hi
> type assoc k v = [(k, v)]
works beautifully and everything makes sense.
> type Assoc v = (Ord k) => [(k, v)]
This doesn't work. Is there any wayof defining k as an element of
type Ordinal. I could redefine k by putting Char or Int in its
Should work with glasgow extensions (-fglasgow-exts).
- Phil
On Dec 1, 2007 6:43 PM, PR Stanley <[EMAIL PROTECTED]> wrote:
> Hi
> > type assoc k v = [(k, v)]
>
> works beautifully and everything makes sense.
>
> > type Assoc v = (Ord k) => [(k, v)]
>
> This doesn't work. Is there any wayof def
Hi
> type assoc k v = [(k, v)]
works beautifully and everything makes sense.
> type Assoc v = (Ord k) => [(k, v)]
This doesn't work. Is there any wayof defining k as an element of
type Ordinal. I could redefine k by putting Char or Int in its place.
Why can't I be more general?
Thanks,
Paul
Hello All,
The Gtk2Hs basics tutorial, based on the Tony Gale and Ian Main GTK+2.0
tutorial, is now available for review and comment. The TOC:
1. Introduction
2. Getting Started
3. Packing
3.1 Packing Widgets
3.2 Packing Demonstration Program
3.3 Packing Using
> PRS: (>>=) :: Parser a -> Parser b -> Parser b
> p >>= f = \inp ->
>case p inp of
> [] -> []
> [(v, out)] -> parse (f v) out
You probably want:
(>>=) :: Parser a -> (a -> Parser b) -> Parser b
p >>= f = \inp -> case parse p inp of
[] -> []
> Hi
> (>>=) :: Parser a -> Parser b -> Parser b
> p >>= f = \inp ->
>case p inp of
> [] -> []
> [(v, out)] -> parse (f v) out
> based on a lot of guesswork, after the mess created by the OCR, I
> managed to get the above example to work syntactically but is it
> semantically correct?
Hi guys.
I just wrote this prime number generator. It's... unusual. It seems to
go increadibly fast though. Indeed, I asked it to write the first
1,000,000 prime numbers to a text file, and scanning the bit array
seemed to take longer than constructing the bit array! Odd...
Anyway, for your
Hi
(>>=) :: Parser a -> Parser b -> Parser b
p >>= f = \inp ->
case p inp of
[] -> []
[(v, out)] -> parse (f v) out
based on a lot of guesswork, after the mess created by the OCR, I
managed to get the above example to work syntactically but is it
semantically correct?
Thanks, Paul
__
hi,
with the large number of "just chatting" messages on
haskell-cafe, it is all too easy to miss problem reports
here. you might have a better chance asking on more
specific lists, eg. for ghc use, or library issues
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.hask
On Nov 30, 2007 9:13 PM, Maurício <[EMAIL PROTECTED]> wrote:
> Nice tip. Do you know of a free news server
> that allows read and post for that group?
http://groups.google.com/group/fr.sci.maths/topics?lnk=gschg
___
Haskell-Cafe mailing list
Haskell-Ca
Am Samstag, 1. Dezember 2007 07:18 schrieb PR Stanley:
> Hi
> taken from ch.8.3 in the Hutton book:
> "Whereas return v always succeeds, the dual parser failure always
> fails regardless of the contents of the input string:"
> The dual parser failure?
> Cheers,
> Paul
>
The dual parser, "failure",
PR Stanley <[EMAIL PROTECTED]> writes:
> Hi
> taken from ch.8.3 in the Hutton book:
> "Whereas return v always succeeds, the dual parser failure
> always fails regardless of the contents of the input
> string:"
> The dual parser failure?
It's a question of how you parse the phrase "dual parser
fa
21 matches
Mail list logo
