On Wednesday 01 December 2004 21:18, John Goerzen wrote:
> I also have a very small start on a "haskell for hackers" ("hackers" in
> the non-evil sense) sort of document. One this doesn't ignore I/O as
> "hard" or "unimportant". I/O in Haskell doesn't suck.
I come from a similar area (large cont
Using ghci, I am getting this error message:
*Main> timeOp $ print $ sizeFM bigFM'
GHC's heap exhausted: current limit is 268435456 bytes;
>From this code:
makeList x = map ((\x->x `mod` range).abs) $
Random.randoms (Random.mkStdGen x)::[Int]
range=10
fmRec
On 1 Dec 2004, at 18:29, Ben Rudiak-Gould wrote:
Here's the page:
http://haskell.org/hawiki/GlobalMutableState
Nice summary.
What I think is missing is an explanation of when you would want this
feature (and when you wouldn't, more importantly). Here is the kind of
platonic dialogue that summ
On 2004-11-30, GoldPython <[EMAIL PROTECTED]> wrote:
> Has anyone tried presenting the language to the average rank and file
> programming community? If so, was it successful? If not, is there
> interest in doing so?
I am very interested in doing that.
I'm a relatively recent Haskeller. I come
On Wednesday 01 Dec 2004 6:29 pm, Ben Rudiak-Gould wrote:
> I put up a wiki page summarizing the main proposals for top-level
> mutable state. The type-dictionary approach isn't there yet, but there's
> a space for it; I'll probably fill it in within the next 24 hours unless
> someone else feels li
I put up a wiki page summarizing the main proposals for top-level
mutable state. The type-dictionary approach isn't there yet, but there's
a space for it; I'll probably fill it in within the next 24 hours unless
someone else feels like doing it first.
Please add more detail, objections, example
On Wed, 1 Dec 2004, Dusan Kolar wrote:
> Hello,
>
> I'm trying to make work the following code (I'm using GHCi
> with flags -fglasgow-exts -fallow-undecidable-instances):
>
> infixl 6 :+, :-
> infixl 6 .+, .-
>
> data TMyExpr = TMyExpr :+ TMyExpr
> | TMyExpr :- TMyExpr
>
Hello,
I'm trying to make work the following code (I'm using GHCi
with flags -fglasgow-exts -fallow-undecidable-instances):
infixl 6 :+, :-
infixl 6 .+, .-
data TMyExpr = TMyExpr :+ TMyExpr
| TMyExpr :- TMyExpr
| Val Int
| Id String
class MkExpr a b where
(.+)
Adrian Hey wrote:
Oh yes, so you did. Sorry. What alternative would you propose?
Something like Keeans thread talking to the rest of the
world by channels?
When Keean suggested this I objected that there was still
no way to prevent accidental forking of multiple copies
of this supposedly unique res
On Wednesday 01 Dec 2004 4:22 pm, Lennart Augustsson wrote:
> Adrian Hey wrote:
> >>I agree with you that at some level there has to be a unique
> >>resource (for that computer), but it's not something I'd keep
> >>in a global variable.
> >
> > How would you implement this "global variable". In C?
Adrian Hey wrote:
I agree with you that at some level there has to be a unique
resource (for that computer), but it's not something I'd keep
in a global variable.
How would you implement this "global variable". In C?
I said I would NOT keep it in a global variable. :)
Because I don't like them.
Hi,
foo _ = undefined
works fine.
Otherwise the poor little "a" has no chance to get disambiguated.
... Ambiguous type variable `a' in the top-level constraint ...
Ralf
Stefan Holdermans wrote:
Hi,
Just out of curiosity (I cannot come up with a practical example):
Why doesn't the following piece
Hi,
Just out of curiosity (I cannot come up with a practical example): Why
doesn't the following piece of code type check in GHC (with
extensions)?
> foo :: (forall a . (Eq a) => a) -> Integer
> foo = undefined
It seems like the type-class constraint is playing a decisive rôle
here, since the
Actually I now think that not only are top level TWIs okay, I can
get extra contexts by rewriting the MVar module. Here I can
create a TWI in the new MVar module called context, and all
mvar writes and reads would be parameterised by context. In
this way I can change the context then call oneShot
Adrian wrote (snipped):
> But if top level MVars are all that's on offer I'd settle for that :-)
> I can still implement my "oneShot" examples just by passing the top
> level MVar as an argument to oneShot rather than having it create its
> own.
I am not sure which the oneShot examples are, but I s
On Wednesday 01 Dec 2004 12:07 pm, Lennart Augustsson wrote:
> Adrian Hey wrote:
> It's not a language issue. It's a design issue. And in the case
> of device drivers you do want to pass the buck up to the layer
> that handles device drivers. Having each driver keep it's own
> global state is ju
Adrian Hey wrote:
If userInit is exported, it could reasonably be described as "global",
but this doesn't matter because as far as users are concerned it's just
a perfectly ordinary side-effectful, state manipulating IO function that
works it's magic by unknown means. There's no reason for them to
On Tuesday 30 Nov 2004 9:19 pm, Benjamin Franksen wrote:
> I don't get it: How can they be top-level without scoping over an entire
> module? I mean, the proposal was to have
>
> x <- action
>
> at the top-level, right? Then how can it not be visible in the whole
> module? What scope *does* it have
On Tuesday 30 Nov 2004 4:01 pm, Simon Peyton-Jones wrote:
> (d) I'm not averse to changing GHC in some way, but big changes (e.g top
> level <-) would need a jolly persuasive argument and solid consensus.
> Smaller changes (e.g. a robust promise about top-level newMVars) are
> easier of course.
>
>
Adrian Hey wrote:
On Tuesday 30 Nov 2004 3:02 pm, Lennart Augustsson wrote:
I reiterate: not even device drivers written in C use TWIs.
(Well, at least not quality drivers. :))
A finite pool of N devices is still a unique resource.
Ultimately you have to contain the problem locally with a modular
On Tuesday 30 Nov 2004 3:02 pm, Lennart Augustsson wrote:
> I reiterate: not even device drivers written in C use TWIs.
> (Well, at least not quality drivers. :))
A finite pool of N devices is still a unique resource.
Ultimately you have to contain the problem locally with a modular
solution, or
Jules Bean <[EMAIL PROTECTED]> writes:
>> When writing a compiler, it makes sense to collect errors as by the
>> writer monad, and not abort anything - producing dummy values instead
>> (except perhaps some fatal errors when it's inconvenient).
>
> Or you could use the monad:
>
> data Perhaps a =
On Tue, 30 Nov 2004 18:36:46 + (UTC), Pavel Zolnikov
<[EMAIL PROTECTED]> wrote:
> [..]
> type M2 a = OuptutMonadT Maybe String a
> whenError:: M2 a -> M2 a -> M2 a â
>
> 1 foo a b = do
> 2 output "before"
> 3 let r = liftM2 (+) a b
> 4 `whenError` $ reportError "error"
> 5
[EMAIL PROTECTED] wrote:
That is too pessimistic, I'm afraid. There is also an intensional
equality. Granted, it can be sound but never, in general, complete
(although it can be total). That is, if the comparison function
returns True, then the arguments truly denote the same, identically the
same
On 1 Dec 2004, at 00:37, Marcin 'Qrczak' Kowalczyk wrote:
Ben Rudiak-Gould <[EMAIL PROTECTED]> writes:
I may be confused, but I don't think it does. It seems like the OP
wants a type like
data Perhaps a = Success a | Failure [Error]
When writing a compiler, it makes sense to collect errors as b
On 30 Nov 2004, at 23:29, Ben Rudiak-Gould wrote:
Jules Bean wrote:
However, your problem *does* have a natural underlying monad, if you
care to use it.
I may be confused, but I don't think it does. It seems like the OP
wants a type like
data Perhaps a = Success a | Failure [Error]
[snip]
I d
26 matches
Mail list logo
