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
G'day all.
On Wed, Jun 05, 2002 at 10:35:52PM -0500, Jon Cast wrote:
> > One general rule of strongly-typed programming is: A program is type
> > correct if it is accepted by my favourite type checker. A corollary
> > is that what you call a type, I reserve the right to call a
> > precondition.
G'day all.
On Sat, Jun 29, 2002 at 05:26:46PM -0500, Mark Carroll wrote:
> Do any of the experimental extensions to Haskell allow a what-he-wanted
> solution? I couldn't arrange one in H98 without something having an
> infinitely-recursive type signature. I'm sure it would have been easy in
> Li
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 Mo
G'day all.
On Fri, Jul 05, 2002 at 11:04:01AM -0700, andy wrote:
> Has anyone seen or have a reference to LR based
> parsing combinators?
Sorry, I just came by this message.
I looked into them some time ago and, basically, they're not a good fit
since they don't decompose bottom-up like LL par
G'day all.
On Fri, Jul 26, 2002 at 01:27:48AM +, Karen Y wrote:
> 1. How would I convert capital letters into small letters?
> 2. How would I remove vowels from a string?
As you've probably found out, these are very hard problems.
Haskell gets it a little wrong here, since the result of so
G'day all.
On Mon, Jul 29, 2002 at 10:23:05AM +0100, Simon Marlow wrote:
> Many of those programs can be written differently to improve
> performance.
To be fair, Doug admits this as well as a lot more:
http://www.bagley.org/~doug/shootout/method.shtml#flaws
Despite these flaws, I did
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
> ther
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 t
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 tas
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) => Constr
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 k
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 t
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 an
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 t
G'day all.
On Tue, Aug 20, 2002 at 05:39:41AM +0200, Scott J. wrote:
> I have a question. Why are sets not implemented in Haskell? . I have read a
> bit how the compiler is made. Ok lists are easier to implement but sets
> could have been implemented too.
> So why didn't the implementors not do
G'day all.
On Tue, Aug 20, 2002 at 10:57:36AM -0700, Hal Daume III wrote:
> Lists with arbitrary
> elements are possible, but not very useful. After all, what could you do
> with them?
It's often useful to have containers of arbitrary _constrained_ types,
because then you can do something with
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
>
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 qu
G'day all.
On Sat, Sep 21, 2002 at 12:56:13PM -0700, Russell O'Connor wrote:
> case (number g) of
> Just n -> Just (show n)
> Nothing ->
> case (fraction g) of
>Just n -> Just (show n)
>Nothing ->
> case (nimber g) of
> Just n -> Just ("*"++(show n))
> Nothing -> Nothin
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 ever
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
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 sl
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 o
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 constru
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 expre
G'day all.
On Tue, Oct 29, 2002 at 11:40:40AM +, Alastair Reid wrote:
> > In particular, Hugs is not currently a Supported Platform(tm).
>
> Please let us know if there's anything in the forthcoming release
> that needs changed to support this library.
There probably won't be any problems a
G'day all.
On Wed, Oct 30, 2002 at 12:56:51PM +1300, Jason Smith wrote:
> Yes Andrew, I'm using the TernaryTrie that u created.I tired the
> suggestion that Alastair gave me regarding the use of -package data but it
> still complained saying that it could not find module
> Control.Monad.Ident
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 [EM
G'day all.
On Wed, Oct 30, 2002 at 10:06:48AM +, Ross Paterson wrote:
> The library needs updating to account for change in Haskell 98: method
> definitions in instance declarations are no longer qualified,
Thanks. I'll set to work on that now.
Cheers,
Andrew Bromage
__
G'day all.
On Wed, Nov 13, 2002 at 04:05:42AM +, Jorge Adriano wrote:
> If I use an STRef to a record, will a new record be created each time I want
> to update a single field?
Basically, yes.
> Right now I'm using a record of STRefs, like:
> data E s = E{
> refi :: STRef s Int,
>
G'day all.
On Thu, Nov 14, 2002 at 09:56:24AM -0500, Mark Carroll wrote:
> Actually, "deriving binary" would be a nice
> thing to have in general - even more, a way to add your own "deriving"
> things from within Haskell, although I have no idea how such a thing would
> work.
Actually, there's o
G'day all.
On Thu, Nov 14, 2002 at 05:17:49PM +, Keith Wansbrough wrote:
> You might be able to get away with running the Haskell program as a
> separate process, communicating via pipes.
IMO, this is almost never the right thing to do. Unless your programs
are really stream processors, or
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''
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 R
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
G'day all.
Simon wrote:
> >There's no reason not to use 8 column tab stops, so please don't do it.
On Fri, Dec 06, 2002 at 02:52:13PM +0100, Ingo Wechsung wrote:
> Ok, if "it just looks better to me" is no reason,
As Simon pointed out, spaces and tabs are visually indistinguishable.
4-column t
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?
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,
A
G'day all.
On Wed, Jan 01, 2003 at 01:15:09PM +0100, Nicolas.Oury wrote:
> From this, I think the safety become intuitive.
Maybe.
Using the OI module from Richard Kieburtz' paper, I can write
this:
-- Bootstrap into the OI comonad
main :: IO ()
main = return $! comain s
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 f
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
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
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 do
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 Mon, Feb 03, 2003 at 03:24:49PM -0600, Jon Cast wrote:
> I, personally, haven't written a program whose bulk will fit in a single
> file in several years, and I doubt I ever will again. So, support for
> separate compilation is a necessity. How do you intend to handle this?
Haske
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 def
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 fr
G'day all.
I noticed a mistake.
On Thu, Feb 06, 2003 at 11:42:21AM +1100, Andrew J Bromage wrote:
> Because of type inference over recursive module imports.
I meant to say _transitive_ module imports, which includes recursive
module imports.
Cheers,
Andrew
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 i
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? http://www.haskell.org/mailman/listinfo/haskell-
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{ wadler89theo
G'day.
On Mon, Mar 03, 2003 at 11:49:29AM +0200, Cagdas Ozgenc wrote:
> Yes, I thought about these too. Do you find these functions practically
> useful? Can you give an example where I can utilize these functions?
Functions like this are useful for plugging into higher-order functions
to tailor
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 di
G'day all.
On Mon, Mar 03, 2003 at 09:53:24PM -0500, Damien R. Sullivan wrote:
> Time to look at arrays, finally.
This might help:
http://haskell.org/wiki/wiki?MemoisingCafs
Cheers,
Andrew Bromage
___
Haskell-Cafe mailing list
[EMAIL PROTECTE
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 i
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 08:37:48AM +0100, Graham Klyne wrote:
> I was thinking some more about this comment of yours, and my own experience
> with the ease of using lists to implement prolog-style generators, and
> think I come to some better understanding.
You might find this amusi
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
G'day all.
On Sat, Jul 05, 2003 at 07:43:18PM +0200, Steffen Mazanek wrote:
> Prelude> 0.1::Rational
> 13421773 % 134217728
That's allowed. The Rational only has to be correct to the limit of
machine precision. (Incidentally, if it's any help in working out how
this Rational was computed, the
G'day all.
On Mon, Jul 07, 2003 at 12:01:09PM +0200, Jerzy Karczmarczuk wrote:
> I don't understand the remark that the internal arithmetic is
> binary. Sure, it is, so what?
The reason is that you can get the Rational representation even
faster than using continued fractions. :-)
toFrac ::
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) ind
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
> comp
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 cont
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 to
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
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 'innerP
G'day all.
On Mon, Jul 28, 2003 at 03:42:11PM +0200, Konrad Hinsen wrote:
> What is the general attitude in the Haskell community towards
> compiler-specific extensions? My past experience with Fortran and C/C++ tells
> me to stay away from them. Portability is an important criterion for me.
T
G'day all.
On Tue, Jul 29, 2003 at 12:11:29PM +0200, Konrad Hinsen wrote:
> I think that C++ was a lot worse, even the accepted features (e.g. templates)
> didn't work the same with all compilers. All non-trivial code came with a
> list of supported compilers.
True. If we had more Haskell imp
G'day all.
On Thu, Aug 14, 2003 at 11:30:11AM -0700, Brandon Michael Moore wrote:
> I'm surprise nobody has mentioned unsafePerformIO (:: IO a -> a).
> As the name suggests, it isn't referentially transparent.
I'm not surprised. First, it's not standard Haskell. Second, people
tend not to ment
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
G'day all.
On Fri, Aug 22, 2003 at 03:41:14PM +1000, [EMAIL PROTECTED] wrote:
> Seeing as its thst time of year again and everyone is posting their
> homework, has anyone got any good puzzles to do?
> I wouldn't mind having a go at something a bit tricky.
OK, here's a tricky problem.
Take a lis
G'day all.
On Tue, Aug 26, 2003 at 02:33:28PM +1000, Thomas L. Bevan wrote:
> I'd like some help building an IO StateTransformer which can be
> escaped midway through without losing the state accummulated up to
> that point.
A simple way to do this is to use a ReaderT monad stacked on top of IO,
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:05:52AM +0200, Ketil Z. Malde wrote:
> We already have prefix operators, don't we? I.e., regular functions
> are prefix?
Not really. This:
- sqrt x
Doesn't mean the same thing as this:
negate sqrt x
I think the difficulty is that it's v
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.
Understoo
G'day all.
In response to the recent poll, and because I promised to, here is a
first attempt at a page to direct people to, should they ask for
homework help in the wrong way:
http://haskell.org/hawiki/HomeworkHelp
Comments, criticisms and contributions are most welcome.
Cheers,
Andrew
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
_
88 matches
Mail list logo
