G'day all.
On Wed, Jun 05, 2002 at 08:20:03PM -0500, Jon Cast wrote:
I think you're confused about what the type declarations mean. When
you say
sqrt :: Float - Float
you're promising to operate over /all/ Floats.
That would be true of Haskell functions were constrained to be
total
G'day all.
On Sun, Jun 30, 2002 at 01:51:56PM +0100, Peter G. Hancock wrote:
Why not have a monad m a = Int - (a,Int) which is a state monad plus
the operation bump : Int - m Int
bump k n = (n,n+k)
Oh, ye of insufficient genericity. We can do better than that...
import
G'day all.
On Tue, Jul 30, 2002 at 08:14:27AM +0100, D. Tweed wrote:
Mmm, such statements really assume that there's a sensible meaning to
`almost always' when applied to the set of all programmers, whereas I
think a much more realistic assumption is that `there's lots of people out
there,
G'day all.
On Tue, Jul 30, 2002 at 01:57:58PM +0200, Josef Svenningsson wrote:
I think the reason why Haskell compilers aren't generating any faster code
is that there is a lack of competition among different compilers. And I
think that the lack of competition depends on that noone wants to
G'day all.
On Wed, Jul 31, 2002 at 09:59:31AM +0100, D. Tweed wrote:
It's in saying this is warranted by `almost all'
processes being bound by things other than throughput which may be true in
the average sense, but I don't think that all programmers have almost all
their programming tasks
G'day all.
I have a large number of functions all of which use the same set
of type constraints, such as:
foo :: (Monad m, Ord t, Show t) = ...
Ideally, I'd like to combine them into one typeclass. At the moment,
I'm using the equivalent of:
class (Monad m, Ord t, Show t) =
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
G'day all.
On Sun, Aug 11, 2002 at 05:36:21PM -0700, Alex Peake wrote:
I am new to Haskell. I want to do something very simple (I thought)
but got lost in the world of Monads.
I want to implement something like the C idea of:
n += i
So how does one doe this in Haskell?
I think this
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 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 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 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 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 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 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 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 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 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 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 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.
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 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 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 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 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.
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.
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 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 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 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 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 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, 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.
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 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 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 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 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 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 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 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 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
58 matches
Mail list logo
