G'day all.
On Tue, Sep 09, 2003 at 02:52:48PM +0200, Johannes Waldmann wrote:
but this might be an issue for others, who have to maintain legacy code.
You know a language has made it when we're talking about legacy code.
On the other hand, you have to worry about a pure declarative language
G'day all.
On Wed, Sep 03, 2003 at 08:34:58AM +0100, Simon Peyton-Jones wrote:
One suggestion: it'd be good to suggest *strongly* that people only
send their homework-style questions to Haskell-café, not to the main
Haskell list.
Done, thanks.
Cheers,
Andrew Bromage
G'day all.
On Fri, Aug 29, 2003 at 05:39:09PM -0700, Hal Daume III wrote:
I'm attempting to get a sense of the topology of the Haskell
community.
I used Haskell to write a compiler for the RenderMan shading language
for a former employer. Unfortunately, the compiler never shipped.
I still
G'day all.
On Wed, Aug 27, 2003 at 04:57:27PM +0100, Simon Marlow wrote:
GHC tries to do so, but sometimes gets it wrong. See the
-fwarn-incomplete-patterns flag. We'd appreciate it if someone could
overhaul this code - it's been on the wish list for a long time.
As a matter of curiosity,
G'day all.
On Wed, Aug 27, 2003 at 04:03:52PM +, Jonas Ritter wrote:
+ :: Intervall - Intervall - Intervall
(a,b) + (c,d) = (a+c,b+d)
In general this is insufficient because of floating point rounding.
The standard IEEE 754 rounding rule is the floating point equivalent
of rounding to
G'day all.
On Wed, Aug 27, 2003 at 05:50:14PM -0400, Matthew Donadio wrote:
For the first case, I would vote for D and/or E as appropriate. For the
second case, I vote for (F) Ignore.
IMO, based on the result of this poll, we should develop some kind of
short FAQ (e.g. on the wiki) which we
G'day all.
On Thu, Aug 28, 2003 at 11:25:43AM +0200, Ketil Z. Malde wrote:
I suppose C is one way to do F, in particular by providing a working
program so complex and opaque that no first-year could possibly have
written it.
Uhm... yes.
I'm not sure I care much for politesse.
Understood
G'day all.
On Fri, Aug 22, 2003 at 09:40:12AM +1000, Job L. Napitupulu wrote:
Can anyone help me how to make a function which takes an integer n 0 and
returns the list of integers in Line of Pascal's Triangle. For examples,
pascalLine 4 - [1,4,6,4,1]
pascalLine 7 - [1,7,21,35,35,21,7,1]
G'day all.
On Wed, Aug 20, 2003 at 07:42:59AM +0200, Jan Scheffczyk wrote:
I always thought that there is a tiny difference between let and where:
They're semantically equivalent. See, for example:
http://haskell.org/onlinereport/decls.html#sect4.4.3.2
Cheers,
Andrew Bromage
G'day all.
On Tue, Aug 19, 2003 at 11:11:23AM +0100, Ganesh Sittampalam wrote:
I was thinking of a situation like
let x = unsafePerformIO readFooFromDB in x+x
I see from your Secrets of the GHC inliner paper that x wouldn't be
inlined by GHC, but it seems to me like a serious abuse of
G'day all.
On Tue, Aug 19, 2003 at 12:31:08PM +0200, Konrad Hinsen wrote:
Under what conditions would Haskell programmers make some type an instance of
Functor? Whenever it could possibly be done (i.e. whenever fmap makes sense)?
Or just when fmap would be used frequently for some type?
G'day all.
On Sat, Aug 09, 2003 at 01:32:49AM +0200, Wolfgang Jeltsch wrote:
ghci -fglasgow-exts -fallow-overlapping-instances compiles it without
complaint
If it helps, ghci will complain the first time you actually try to use
it.
Cheers,
Andrew Bromage
G'day all.
On Fri, Jul 25, 2003 at 03:48:15PM -0400, Dylan Thurston wrote:
Another approach is to make Universe a multi-parameter type class:
class (RealFrac a, Floating a) = Universe u a | u - a where
distanceVector :: u - Vector a - Vector a - Vector a
...
Actually, this is a nice way
G'day all.
On Sun, Jul 27, 2003 at 10:36:46PM -0400, Dylan Thurston wrote:
However, I would be sure to distinguish between an inner product space
and a vector space.
That's true. If you're after a completely generic solution, this might
be an issue.
An inner product space has the
G'day all.
On Mon, Jul 21, 2003 at 01:07:39PM +0200, Christian Maeder wrote:
Mere overload resolution (over monomorphic types) is not NP-hard. (This
is only a common misconception.)
I can only repeat my above sentence.
I'm a firm believer in the maxim that the best way to find information
G'day all.
On Sat, Jul 19, 2003 at 01:52:32AM -0400, Dylan Thurston wrote:
It's maybe easiest to think in terms of group theory with an
action on a set: you're just distinguishing between the multiplication
of group elements and the actual action. This distinction is not
usually reflected
G'day all.
On Fri, Jul 18, 2003 at 04:08:25AM -0400, Dylan Thurston wrote:
What's wrong with that solution?
Working with these operators, I would spend a significant amount of
time getting the '' and '' notations right rather than writing
code. I don't like that.
For example, using the
G'day all.
On Fri, Jul 18, 2003 at 11:08:16AM +0200, Christian Maeder wrote:
Mere overload resolution (over monomorphic types) is not NP-hard. (This
is only a common misconception.)
No, but as you note below, the interesting cases are. Most
of the more interesting number-like types are
G'day all.
On Thu, Jul 17, 2003 at 05:21:47PM +0200, Christian Maeder wrote:
Why do you outrule other useful libraries (see above). In fact ($) is
quite cryptic (for a non-Haskeller).
Actually this gives me a perfect opportunity to rant a bit. :-)
($) is a wart, even for a Haskeller. It
G'day all.
On Thu, Jul 17, 2003 at 04:46:13PM +0100, Jon Fairbairn wrote:
Someone mentioned multiplying by a scalar. I think this is a
good application, but what we need is to agree (somehow) on
the symbol used. I've used (*.) and (.*), with the dot being
on the side the scalar is on (on the
G'day all.
On Mon, Jul 14, 2003 at 11:08:55PM -0400, Ken Shan wrote:
I just wanted to see that asterisk again.
...and semicolons returned to their rightful place as separators
for list comprehension/diagonalisation qualifiers.
Cheers,
Andrew Bromage
G'day all.
On Fri, Jul 11, 2003 at 04:28:19PM -0400, Dylan Thurston wrote:
Don't be silly [...]
Never!
Cheers,
Andrew Bromage
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
G'day all.
On Sun, Jul 13, 2003 at 10:09:21AM +1000, Andrew Rock wrote:
I think that each being a customisation *is* sufficient for coherence
of one data structure to hold them all.
I agree, though using different data structures for each set of
configuration parameters which will be used
G'day all.
On Thu, Jul 10, 2003 at 11:16:56PM -0700, Ashley Yakeley wrote:
As written, this is _not_ a good idea. Trust me, you end up having to
put type annotations everywhere. Even (3 + 4 :: Integer) is ambiguous,
you have to write (3 :: Integer) + (4 :: Integer).
But that's what
G'day all.
On Wed, Jul 09, 2003 at 05:25:20PM +0200, Jerzy Karczmarczuk wrote:
While this is a possible solution, I would shout loudly: Arrest this man,
he is disrespectful wrt math!. Actually, this shows once more that the Num
class and its relatives is a horror...
Yup.
I recently
G'day all.
On Tue, Jul 08, 2003 at 08:56:10AM +0100, Simon Peyton-Jones wrote:
No it does not. As the paper explains.
Serves me right for playing with the toy before I read the manual.
Cheers,
Andrew Bromage
___
Haskell mailing list
[EMAIL
G'day all.
On Tue, Jul 08, 2003 at 01:06:23PM +0100, Jon Fairbairn wrote:
Unfortunately we don't have Real (in
libraries as far as I remember -- if you have a continued
fraction implementation of it, it ought to go to the
libraries list).
Not one, but TWO implementations! One using
G'day all.
On Mon, Jul 07, 2003 at 11:23:59AM +0100, Simon Peyton-Jones wrote:
The paper has a strongly tutorial flavour, and comes complete with a
prototype implementation that you can play with.
Does the prototype implementation not support recursive lets?
*Main tcs let fix = (\\f
G'day all.
As you note, some kind of indirection is what you want here.
On Mon, Jul 07, 2003 at 04:04:17PM +0100, Sarah Thompson wrote:
I would also need to implement efficient indexes into the data structure
-- flat searching will be too slow for non-trivial amounts of data. In
C++, I'd
G'day all.
On Mon, Jul 07, 2003 at 04:04:17PM +0100, Sarah Thompson wrote:
I would also need to implement efficient indexes into the data structure
-- flat searching will be too slow for non-trivial amounts of data. In
C++, I'd implement one or more external (probably STL-based) indexes
G'day all.
On Mon, Jul 07, 2003 at 04:37:46PM +0100, Sarah Thompson wrote:
I'd considered something like embedding the type in the IO monad, with
links between components implemented as IORefs, but I'd really prefer
something cleaner (pure functional). If the code ends up horribly
G'day all.
On Sat, Jul 05, 2003 at 11:44:54PM -0400, Dimitry Golubovsky wrote:
What would be really nice to have is some sort of object input/output
over network. Then, by sending a String, I would expect it to be
recreated at the other end. And if the other end expects, say [Int] then
an
G'day.
On Tue, Jul 01, 2003 at 10:02:36AM +0200, [EMAIL PROTECTED] wrote:
Does anybody know of a suffix tree implementation
for Haskell? Are there algorithms for a (lazy) functional
setting?
Yes. Take a look here:
http://www.techfak.uni-bielefeld.de/~kurtz/publications.html
The
G'day all.
On Wed, Jun 25, 2003 at 08:48:12AM -0700, Hal Daume wrote:
I'm not sure this is really necessary (at least syntax-wise).
Well, of course, no extension is absolutely necessary in a Turing-hard
language. :-)
For the record, here are a couple of other solutions which avoid the
G'day all.
I've been toying with an idea for a small language extension, and I
was curious what you all think of this.
As a motivating example, consider the following standard typeclass:
class Bounded a where
min :: a
max :: a
This is an example of what I refer
G'day all.
On Wed, Jun 11, 2003 at 12:36:30PM +0200, Jerzy Karczmarczuk wrote:
It is possible, instead of implementing the *data backtracking* through lazy
lists, to make lazy backtrackable continuations, permitting to redirect
the flow of control to produce something else. The two ways are
G'day all.
On Wed, Jun 04, 2003 at 07:31:03PM -0500, Tim Sweeney wrote:
Conjecture: It's impossible to implement RefMonad directly in Haskell
without making use of built-in ST or IO functionality and without unsafe or
potentially diverging code (such as unsafeCoerce).
Any takers?
WARNING:
G'day all.
On Wed, Jun 04, 2003 at 02:00:08PM +0100, Keith Wansbrough wrote:
This formulation is particularly nice because in memory, you *share*
all of the lists from the previous iteration, rather than making
copies.
[...]
Notice all the sharing - this is a very efficient representation!
G'day all.
On Wed, Apr 02, 2003 at 11:26:46AM +1000, [EMAIL PROTECTED] wrote:
in this case, I have a string containing multiples fields seperated by *two*
blank lines (\n\n). I can't just break on the newline character, as single
newline characters can be found inside each field.
any idea
G'day all.
On Tue, Mar 11, 2003 at 08:34:06AM +1300, Tom Pledger wrote:
If, on the other hand, you want to vary the state type *during* a
single monadic computation, it gets messy. You could try one of the
following.
Very often, you just want to vary the state type for some portion
of the
G'day all.
On Mon, Mar 03, 2003 at 12:10:28PM -0500, Matthew Donadio wrote:
This is my biggest gripe with Haskell, at least for what I do. The
numeric class system is good, but it assumes that the sub-classes are
distict, where in fact integers are a proper subset of reals, which
are a
G'day all.
On Mon, Mar 03, 2003 at 04:59:21PM -0800, Hal Daume III wrote:
I think you would get a big speed-up if you got rid of all the rational
stuff and just used:
comb m n = fact m `div` (fact n * fact (m-n))
Or, even better, if you didn't multiply stuff that you're just going
to
G'day all.
On Sun, Mar 02, 2003 at 10:18:13AM +0200, Cagdas Ozgenc wrote:
Is identity function the only meaningful function one can write
without constraining the type variable using a typeclass? If not,
could you please give a counter-example?
This might help:
@incollection{
G'day all.
On Fri, Feb 21, 2003 at 04:28:27PM -0800, Richard Nathan Linger wrote:
What do people think about this?
Has anyone else ever wished they had such support for unnamed sums?
I sometimes wish that Haskell did _not_ have support for unnamed
product types. To be honest, how hard is it
G'day.
On Wed, Feb 19, 2003 at 09:46:02AM -0600, Rex Page wrote:
Here are two things I found interesting:
1. The author comments that programs are not theorems.
No, he argues that programming _languages_ are not theorems.
All that is required of a theorem is that it is correct.
A tool, on
G'day.
On Mon, Feb 17, 2003 at 01:44:07AM -0500, Mike T. Machenry wrote:
I was wondering if it's better to define them as type classes with the
operations defined in the class. What do haskellian's do?
I can't speak for other Haskellians, but on the whole, it depends.
Here's the common
G'day all.
On Thu, Feb 13, 2003 at 02:54:42PM -0500, David Roundy wrote:
That's pretty nice (although not quite as nice as it would be to be able to
use real ifs with no extra parentheses). Any idea how to do something like
this with a case?
G'day.
On 05-Feb-2003, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
H98 has nothing to say about the separate compilation; it's an issue for
the implementation.
H98 indeed says nothing about separate compilation, and it is indeed
an issue for the implementation.
What H98 does is it defines
G'day all.
On Wed, Feb 05, 2003 at 04:16:33PM -0800, Iavor S. Diatchki wrote:
why do you think separate compilation is difficult to achieve in Haskell
98?
Because of type inference over recursive module imports. Determining
the type of a function may, in general, require inferring types
G'day all.
On Wed, Feb 05, 2003 at 08:05:56PM -0600, Jon Cast wrote:
I'm not sure I follow this. If you change the type of a value exported
from a given module, that's a public change, no? And if you don't, why
should re-compilation be needed?
Consider this:
module A where
import B
{-
G'day all.
On Wed, Feb 05, 2003 at 09:28:05PM -0600, Jon Cast wrote:
I think I see what you're saying. I still maintain, however, that,
since you've changed the type of B.b (admittedly implicitly), and B.b is
exported from B, that you've changed B's interface.
There is a reason make is
G'day.
On Tue, Feb 04, 2003 at 05:24:29PM -, Guest, Simon wrote:
I can still access my backtracked state using Control.Monad.State.{get,put}, but
I can't access my non-backtracked state.
Iavor mentioned using lift, plus some other ideas. That's what
I'd do:
liftNondet = lift
G'day all.
On Fri, Jan 31, 2003 at 09:08:22AM +0100, Ralf Hinze wrote:
John Hughes wrote a nice pearl on the subject, see
http://www.math.chalmers.se/~rjmh/Globals.ps
Nice! Why isn't RefMonad in hslibs?
Possibly because of the class signature:
class Monad m = RefMonad m r |
G'day all.
On Fri, Jan 31, 2003 at 01:54:26PM -0600, Jon Cast wrote:
Otherwise, though, see my other post on this subject: unsafePerformIO
will perform its action when the variable is accessed, so you can't
write a Haskell program which differentiates between what any compiler
actually does
G'day all.
On Fri, Jan 31, 2003 at 09:05:11AM -, Guest, Simon wrote:
This bit I don't understand. I only have one monad transformer, which I use to
transform my SM monad.
What I mean is (and recall that I have not looked very hard at your
program, just the BACKTR implementation, so I'm
G'day all.
On Thu, Jan 30, 2003 at 01:55:50PM -, Guest, Simon wrote:
I'm trying to make a backtracking state monad using Ralf Hinze's
backtracking monad transformer. My problem is that it won't backtrack
very far.
Suppose I try ( a b ) `mplus` c.
If b fails, it should try c, but
G'day all.
On Fri, Jan 24, 2003 at 06:13:29PM -0500, Norman Ramsey wrote:
In a fit of madness, I have agreed to deliver a 50-minute lecture
on type classes to an audience of undergraduate students. These
students will have seen some simple typing rules for F2 and will
have some exposure to
G'day all.
On Tue, Jan 14, 2003 at 07:13:57PM +1100, Fergus Henderson wrote:
That's not the only problem. The other problem is that because
`Typeable' instances aren't built-in, `fromDynamic' is not type-safe.
The implementation of `fromDynamic' calls `typeOf' and then if the types
match,
G'day all.
On Tue, Jan 07, 2003 at 10:01:38PM -0600, Kim-Ee Yeoh wrote:
Why can't field labels have the same name in different types?
Because it would generate two functions with the same name.
I'm not an expert on programming languages, but doesn't it seem
that Haskell, as a strongly-typed
G'day all.
On Thu, Jan 02, 2003 at 08:39:18AM +, Alastair Reid wrote:
Please note that this is NOT TRUE!
Whoops, you're right. Sorry, my mistake.
Cheers,
Andrew Bromage
___
Haskell mailing list
[EMAIL PROTECTED]
G'day all.
On Thu, Jan 02, 2003 at 05:49:41PM +0100, Ferenc Wagner wrote:
What's the way to express the following: a compound object
is generally made up of two components with identical type.
This should work:
\begin{code}
module Test where
class Component b where
property :: b - Int
G'day all.
On Thu, Jan 02, 2003 at 08:08:20PM -0800, Ashley Yakeley wrote:
So is Kieburtz smoking crack, or are we writing OI-style programs
incorrectly?
I mailed him the example and asked. (I phrased the question a bit
differently, though.)
One possibility is that comonads are useful for
G'day all.
On Wed, 1 Jan 2003, Andrew J Bromage wrote:
It has quite different performance characteristics, though. In
particular, this uses O(n) stack space whereas the accumulator one
uses O(1) stack space.
On Wed, Jan 01, 2003 at 12:17:10PM +0200, Shlomi Fish wrote:
This is assuming
G'day all.
On Mon, Dec 30, 2002 at 01:47:37PM -0600, Artie Gold wrote:
One suggestion, though is that you're working too hard; there's really
no reason to define a locally defined function. The much simpler:
long [] = 0
long (x:xs) = 1 + long xs
will do quite nicely.
It has quite
G'day all.
On Mon, Dec 09, 2002 at 11:35:54AM +1100, Thomas L. Bevan wrote:
main = do (a:b:cs) - getArgs
i - return (read a :: Int)
j - return (read b :: Int)
putStr $ i + j
How can I catch any possible cast exception?
How about this?
readM
G'day all.
Slight correction...
On Mon, Dec 09, 2002 at 12:03:03PM +1100, Andrew J Bromage wrote:
main = runErrorT main'
Of course you need to define an error type and do something with the
result of runErrorT, but you get the general idea.
Cheers,
Andrew Bromage
G'day all.
On Fri, Dec 06, 2002 at 05:40:28PM +0100, Ingo Wechsung wrote:
No. It didn't hamper portability with C, Java, Perl or any other *nix stuff
since more than 30 years except with COBOL, Python (?) and Haskell, [...]
Add to that: Fortran, Occam and Makefiles. There's probably also a
G'day all.
On Thu, Dec 05, 2002 at 09:49:27PM +0100, Ingo Wechsung wrote:
I am not going to change my editing habits just to make hugs or ghc happy.
What editor do you use? If you use a relatively smart one (e.g. vim,
emacs etc), you should be able to configure it to do it to do what you
want
G'day all.
On Thu, Dec 05, 2002 at 06:36:22PM -0800, Ashley Yakeley wrote:
Haven't we all been through this argument several months ago? I believe
the conclusion was people have different preferences, and Haskell allows
for that.
Sure, but that's a separate issue.
My remark was merely in
G'day all.
Just to clarify...
On Tue, Dec 03, 2002 at 12:42:21PM -0500, David Bergman wrote:
But, design patterns are clearly overestimated as a tool for (indirect)
code production, you are right in that.
Absolutely agreed. Design patterns are little more than:
- A common language
G'day all.
On Mon, Dec 02, 2002 at 08:26:06AM +0100, Johannes Waldmann wrote:
well I love design patterns, it's just that in Haskell-land
they are called higher-order functions, or polymorphic functions, etc.
Can I safely translate that as We use design patterns but we don't
like the name?
G'day all.
On Mon, Dec 02, 2002 at 10:27:21AM +0100, John Hughes wrote:
There are patterns of that sort in our programs, which we would probably
rather call design techniques, which aren't so easily captured by a
higher-order function definition.
As a matter of interest, _why_ would we
G'day all.
On Mon, Dec 02, 2002 at 01:05:27PM -0500, David Bergman wrote:
It seems like all the patterns, at least the ones in the GoF's
enumeration, can be expressed as higher-order functions and classes if
we only would have a way to traverse a record structure dynamically. If
someone can
G'day all.
On Thu, Nov 28, 2002 at 12:32:19PM -0500, Paul Hudak wrote:
reminds of what I think is one of the biggest problems with conventional
software development: the lack of appreciable mathematics in the
specification, design, coding, or implementation of programs.
In the interest of
G'day all.
On Mon, Nov 25, 2002 at 12:19:10PM +0100, George Russell wrote:
I have a confession to make. Andrew Bromage's list-based code is
much faster than my array-based code. So I think I shall end up
adapting Andrew Bromage's code, even though I do not understand it.
You mean you did
G'day all.
On Thu, Nov 21, 2002 at 09:12:58AM -, Simon Peyton-Jones wrote:
So GHC is 30 lines shorter thanks to you.
...and I didn't even have to delete a single line of code myself!
Thanks, Simon.
Cheers,
Andrew Bromage
___
G'day all.
On Fri, Nov 22, 2002 at 05:13:07AM +1100, Fergus Henderson wrote:
Would a Mercury version help? The Mercury distribution includes a
Mercury version of Myer's algorithm: it's in the directory `samples/diff'.
Disclaimer: I wrote the Mercury version.
That particular algorithm
G'day all.
In a recent GHC checkout, the following program:
module Main(main) where
import Maybe
import Control.Monad
test :: (MonadPlus m) = [a] - m Bool
test xs
= do
(_:_) - return xs
return True
`mplus`
do
G'day all.
On Wed, Nov 20, 2002 at 08:25:46PM +, Jorge Adriano wrote:
I think both versions can be very useful:
findM :: (Monad m) = (a - m Bool) - [a] - m (Maybe a)
findM' :: (Monad m) = (a - Bool) - [m a] - m (Maybe a)
I can also make a case for:
findM'' :: (Monad
G'day all.
On Wed, Nov 20, 2002 at 08:44:36PM -0500, Mike T. Machenry wrote:
I am trying to construct an infinate list of pairs of random colors.
I am hung up on getting a random color. I have:
data Color = Blue | Red | Green deriving (Eq, Ord, Show)
am I supposed to instantiate a Random
G'day all.
On Tue, Nov 12, 2002 at 05:25:42PM +, Alastair Reid wrote:
So as people try to come up with a distribution and build mechanism
that will work for GHC, it would be good to think about how that
same mechanism would work for Hugs too.
If you will allow me to AOL...
Me too!
G'day all.
On a very recently checked out copy of GHC (late last week, from
memory) I get the following panic:
% ghc -fglasgow-exts -c Bug.hs
ghc-5.05: panic! (the `impossible' happened, GHC version 5.05):
applyTys
Please report it as a compiler bug to [EMAIL PROTECTED],
or
G'day all.
On Tue, Oct 29, 2002 at 11:20:47AM +0200, George Kosmidis wrote:
I am sure there are a billion errors in this.
This is the first one:
Line:17 - Last generator in do {...} must be an expression
What this means is that the compiler has interpreted the last line
of a do
G'day.
On Wed, Oct 30, 2002 at 01:49:37PM +1300, Jason Smith wrote:
i.e. TernaryTrie.hs:165: Data constructor not in scope: `M'
There is no M in that module anywhere, and I'm pretty sure there
never was.
Please update your copy from CVS and, if it still isn't working, send
a bug report to
G'day all.
On Mon, Oct 28, 2002 at 08:47:08AM +, Alastair Reid wrote:
(btw There were some remarks that Chris's library might be dropped
from distributions because no-one is supporting it. I don't recall
whether a decision was made on this.)
If Jason is using a version of Edison that
G'day all.
On Sat, Oct 26, 2002 at 11:40:04AM -0700, Nuno Silva wrote:
can anyone help me how to get the dozen number? using Int
example
dozen 1020
the expected result is: 2
dozen :: Int - Int
dozen 1020 = 2
Hope this helps.
Cheers,
Andrew Bromage
G'day all.
On Thu, Oct 24, 2002 at 04:05:05PM +0100, Simon Peyton-Jones wrote:
I definitely can't do that at this stage. I have never liked
Float/Double/Ratio being in Enum, but there is no possibility of
removing them now. A year or two ago, maybe.
Just to clarify: Did you mean for
G'day all.
On Thu, Oct 17, 2002 at 11:08:57AM -0400, [EMAIL PROTECTED] wrote:
For an
interpreter I'm writing, I found myself writing a function
constructVarExpr :: String - Expr just to make it easier.
As an alternative opinion, I don't think there's anything wrong
with this. A constructor
G'day all.
On Wed, Oct 16, 2002 at 07:54:17AM -0700, Hal Daume III wrote:
I was reading the HFL libs, namely Control.Monad.Logic, and there's a
definition in there:
newtype Logic a = Logic { mkLogic :: (forall b. (a - b - b) - b - b) }
I'm curious why this is legal, but
newtype
G'day all.
On Wed, Oct 16, 2002 at 08:40:18AM +0100, Simon Peyton-Jones wrote:
There aren't many type constructors T for which T a is an equality
type...
I can think of a few, like IORef. Admittedly I can't think of any that
are also monads.
Cheers,
Andrew Bromage
G'day all.
On Tue, Oct 15, 2002 at 04:47:22PM -0700, Hal Daume III wrote:
I was wondering if anyone has a brand-spaking-new version of edison or
anything like it. The edison docs still refer to ghc 4.06, which can't be
good. If not, is there an edison-like project out there?
Chris Okasaki
G'day all.
On Thu, Oct 10, 2002 at 11:50:39AM +0200, Jerzy Karczmarczuk wrote:
There are of course more serious approaches: intervals, etc. The infinite-
precision arithmetic is a mature domain, developed by many people. Actually
the Gosper arithmetic of continued fractions is also based on
G'day all.
On Wed, Oct 09, 2002 at 02:29:26PM -0400, David Roundy wrote:
I get a speedup of about a factor of 6 for the test files I was using (of
course, this would depend on file size), and find that now only 2% of my
time is spent in that function. I'm still something like 100 times
G'day all.
On Fri, Sep 27, 2002 at 12:56:38PM -0400, Dean Herington wrote:
I'm not sure why you consider the code you refer to above so ugly.
Anything which relies on unsafePerformIO (or seq, for that matter)
is ugly. Personal opinion, of course. :-)
Question:
Why do you use `seq` on
G'day all.
On Thu, Sep 26, 2002 at 12:06:36AM +0100, Liyang Hu wrote:
The problem I'm having is with the preferences: How do I make it
available throughout the entire program? (FWIW, most of the work is
effectively done inside the IO monad.) I could explicitly pass the
record around
G'day all.
On Wed, Aug 21, 2002 at 02:46:16PM -0400, Mark Carroll wrote:
One issue we have here is that any Haskell we write is stuff we'll
probably want to keep using for a while so, although we've only just got
most of the bugs out of the H98 report, I'll certainly watch with interest
as
G'day all.
On Wed, Aug 21, 2002 at 02:31:05PM +0100, Guest, Simon wrote:
Please could someone explain the meaning of | in this class
declaration (from Andrew's example):
class (Ord k) = Map m k v | m - k v where
lookupM :: m - k - Maybe v
Others have answered the question
G'day all.
On Mon, Aug 12, 2002 at 10:06:51PM +0100, Alistair Bayley wrote:
OTOH, if you want to do anything useful with any language you have to learn
to do IO (and simple IO is tackled early in most languages), and therefore
you must deal with Monads. I often wish that Haskell books and
G'day all.
On Mon, Aug 12, 2002 at 04:19:38AM -0700, John Meacham wrote:
grr. this used to be in a FAQ at the Wiki. whatever happened to that?
Unfortunately, the ReportingProblems page is one of the ones which
died. It's also not in the google cache.
Does anyone know who's responsible for
G'day all.
On Sun, Aug 11, 2002 at 07:03:04PM -0700, Alex Peake wrote:
I am trying to implement a long-lived accumulator
How long is long? Over what kind of code must it be preserved?
In what kind of code do you want to modify it and in what kind of
code do you want to read it?
By what
1 - 100 of 126 matches
Mail list logo
