Mark P Jones writes an interesting suggestion:
...
> Hmm, ok, but perhaps you're worrying now about having to enumerate
> a verbose list of language features at the top of each module you
> write. Isn't that going to detract from readability? This is where
> the module system wins big! Just
Koen Claessen writes:
> * Stream processors (from Fudgets) are nice arrows:
>
> data SP a b = Get (a -> SP a b) | Put a (SP a b) | Nil
>
> But the first operator assumes that the product type
> associated with this arrow must be Haskell's product
> (,), but in fact a s
Ashley Yakeley writes:
> At 2001-01-16 10:23, Magnus Carlsson wrote:
>
> >You can use overloading for the definition of theValue instead:
> >
> > class TheValue a where theValue :: a -> Maybe Int
> >
> > instance TheValue Basewhere theVa
You can use overloading for the definition of theValue instead:
class TheValue a where theValue :: a -> Maybe Int
instance TheValue Basewhere theValue _ = Nothing
instance TheValue Derived where theValue x = Just (x.value)
/M
Ashley Yakeley writes:
> How do you do OOP-style polymorp
S. Alexander Jacobson writes:
> In principle I can do this, but:
> 1. how do I hide the import of show String to replace it w/ my own?
> 2. If I do replce show String what else will break?
I'd rather let the preprocessor insert calls to eshow, and leave show
as it is.
> 3. If instead I defin
I've been using a preprocessor to Haskell that I call HacWrite, which
adds a new kind of string appropriate for entering text. Such strings
can span multiple lines and can be escaped using curly brackets:
var1 = 2*2
var2 = 4*var1
var3 = «Foobar»
sqlstring = «insert into mytable values
Mark P Jones writes:
> | 2. Is there a way to modify the signatures to make it legal?
>
> Not that I can see!
>
> Personally, I think you've found a bug in the Haskell report! But, as
> it stands, others can reasonably say this is a bug in Hugs 98 ... I guess
> we should modify the typec
Here are some questions for the Haskell-98 enthusiasts.
1. Why is the following declaration group illegal?
f :: String
f = g 1 ++ g True
g :: Show a => a -> String
g x = fst (show x, show f)
2. Is there a way to modify the signatures to make it legal?
/M
The result of the filtering to the right of >>= must be of monadic
type, you can use `return' for this. In hbi:
> getDirectoryContents "." >>= (return . filter (\(x:_) -> x /= '.'));
["GoodNews","BadNews","OldNews","mbox"]
>
Or, by using `fmap', `head', and a section:
> filter
Marcin Benke writes:
>
> So far I have been unable to find a Haskell compiler that would use/support
> shared libraries (yes, I know hbi uses them, but it's not really a
> compiler). Why is it so? Is there some fundamental problem preventing
> from using them with a lazy functional language
> What are first class modules ? Can you give a reference (preferably
> online) ?
Modules can be viewed as records. See Luca Cardelli and Peter Wegner:
"On Understanding Types, Data Abstraction, and Polymorphism".
Claus Reinke has a virtual bookshelf devoted to modules at
http://www.inform
[...]
> However, passing around option values to the different parts of your
> program is a major bore, so what about instead treating argv for what
> it really is, a constant, and make it available as such
> (System.argv :: [String]), say. Having it as constant has the nice
> property that
If you want to play with a monadic fixpoint combinator in HBC, you can
use
module FixMonad where
import UnsafeDirty(assign,deref,ref)
fix :: Monad m => (a -> m a) -> m a
fix f = do
a <- f (deref r)
assign r a `seq` return a
where r = ref (undefined f)
Here is a stupid ex
Maybe you have seen some mail lately on this list about something
called "Haskell 1.3", and wondered
What is this "Haskell 1.3" anyway?,
Can I buy it?,
or
Do I have it?
By compiling and running the following two-module Haskell program, you
will at least get an answer to the last que
Philip Wadler writes:
>
> > It looks ugly, but we could say that a data declaration does not
> > have to have any constructors:
> >
> >data Empty =
> >
> >-- Lennart
>
> I agree that the best way to fix this is to have a form of data
> declaration with no constructors, but
I wrote:
> For the same reasons, length [1..n] does not run in constant space.
Forget that. In this case, any reasonable implementation of course
evaluates the elements (to see if the end of the list is
reached). Thanks to Niklas R=F6jemo who pointed it out.
/M
My complete post:
> The prob
The problem is that the elements in the list [1..] are not used by
the function lens, so they will not be evaluated. This is fatal, since
the unevaluated elements are becoming larger and larger function applications:
[1..] = [1, 1+1, 1+1+1, ...]
For the same reasons, length [1..n] does not
17 matches
Mail list logo