On Fri, Jul 15, 2005 at 11:51:59PM +0200, Magnus Carlsson wrote:
> A while ago, I attempted to marry value recursion a la Levent Erkök with
> the continuation-monad transformer. It seems possible if the underlying
> monad has value recursion and references. Interestingly, all mfix
> properties ex
A.M.Gimblett:
> Hi all,
>
> I'm something of a Haskell newbie, and this is my first post to this
> list.
>
> I'm trying to do some very basic things with graphs, but can't get
> started with Data.Graph. In particular, linking fails - I'm wondering
> if something's wrong with my install. (For th
> I interpreted the style as removing anything that is redundant in the
> context of the module. In math, when you're talking about vector
> spaces, you say "add" and "multiply", but you don't say "thing" or
> "one"--you still say "vector".
you mean if I have a Vector "thing" and a Matrix "thing"
I have mixed feelings about Module.T, but consider it useful. basically,
I use it only when the module naturally only exports a single type which
is the purpose of the module (modules which incidentally only export a
single type but have a different focus shouldn't use the type synonym)
and the mod
On Fri, Jul 15, 2005 at 03:23:18PM +0100, Simon Marlow wrote:
> Hand-writing .hi files is how GHC used to work (up to version 0.29,
> IIRC). It's not entirely satisfactory because you can get into
> situations where you have to 'make' several times to get to a fixed
> point, and you can construct
On Fri, Jul 15, 2005 at 10:48:04AM +0200, Henning Thielemann wrote:
> On Thu, 14 Jul 2005, Andrew Pimlott wrote:
> > 2) enshrining one-type-per-module in the naming convention is not IMO
> > justified, and may prove limiting;
>
> Other languages like Modula-3 and Oberon do it with great success. T
On Fri, Jul 15, 2005 at 07:13:53PM +0100, Andy Gimblett wrote:
> On Fri, Jul 15, 2005 at 10:42:11AM -0700, Josh Hoyt wrote:
> >
> > I'm pretty new myself, but I ran into a similar problem using a
> > different library. The problem is that some parts of the library are
> > hidden by default, and you
On Fri, Jul 15, 2005 at 10:42:11AM -0700, Josh Hoyt wrote:
>
> I'm pretty new myself, but I ran into a similar problem using a
> different library. The problem is that some parts of the library are
> hidden by default, and you have to tell ghc to include them. To
> solve your immediate problem, add
On 7/15/05, Andy Gimblett <[EMAIL PROTECTED]> wrote:
> Hi all,
> [snipped] Unfortunately, here's
> what happens:
>
> [EMAIL PROTECTED] spa_haskell] ghc -o Main Main.hs
> Main.o(.text+0x145): In function `__stginit_Main_':
> : undefined reference to `__stginit_DataziGraphziInductive_'
> collect2: l
Hi all,
I'm something of a Haskell newbie, and this is my first post to this
list.
I'm trying to do some very basic things with graphs, but can't get
started with Data.Graph. In particular, linking fails - I'm wondering
if something's wrong with my install. (For the record: ghc-6.4
compiled/ins
Interpretation A is correct. The type (constructor) of Lists gives a
monad together with return x = [x] and x >>= f = concatMap f x.
Interpretation B doesn't really work, because the monad interface does
not give one the ability to write "head" or "tail". You basically have
return (which gets you
Here's a question for the Haskell community that I've been wrestling
with lately. When we say "lists are monads" what does that mean? I can
see one of two things. First the slightly superficial...
A.) Lists can be made members of the Monads class, and you can define
a couple of fun
> You guys should really document that nhc98 support mut. rec. modules
> too.
Agreed.
I believe the Haskell'98 libraries are mutually recursive by definition
(Prelude imports Ratio, and Ratio imports the Prelude), so probably all
compilers have had to deal with this from the start. nhc98's libra
On 15 July 2005 11:53, Malcolm Wallace wrote:
> "Simon Marlow" <[EMAIL PROTECTED]> writes:
>
>> I hope you weren't including GHC in "most compilers" :-) GHC's
>> implementation of mutually recursive modules is conformant with
>> Haskell 98 (see Section 5.7).
>
> It depends on how you interpret
Hello
I am having problems with GHC infering functional dependencies related
types in a too conservative fashion.
> class Imp2 a b | a -> b
> instance Imp2 (Foo a) (Wrap a)
>
>
> newtype Wrap a = Wrap { unWrap :: a }
> data Foo a = Foo
> data Proxy (cxt :: * -> *)
>
> foo :: Imp2 (ctx c) d => Pro
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> I hope you weren't including GHC in "most compilers" :-) GHC's
> implementation of mutually recursive modules is conformant with Haskell
> 98 (see Section 5.7).
It depends on how you interpret this phrase:
"may require that imported modules contai
On 15 July 2005 11:24, Henning Thielemann wrote:
> On Fri, 15 Jul 2005, Simon Marlow wrote:
>
>> On 15 July 2005 09:48, Henning Thielemann wrote:
>>
>>> The limit in Haskell is that most compilers don't conform to the
>>> Haskell 98 report which allows mutually recursive modules. But I
>>> think
On Fri, 15 Jul 2005, Simon Marlow wrote:
> On 15 July 2005 09:48, Henning Thielemann wrote:
>
> > The limit in Haskell is that most compilers don't conform to the
> > Haskell 98 report which allows mutually recursive modules. But I think
> > the compilers should allow them instead of forcing user
On 15 July 2005 09:48, Henning Thielemann wrote:
> On Thu, 14 Jul 2005, Andrew Pimlott wrote:
>> 2) enshrining one-type-per-module in the naming convention is not IMO
>> justified, and may prove limiting;
>
> Other languages like Modula-3 and Oberon do it with great success. The
> limit in Haskel
On Thu, 14 Jul 2005, Andrew Pimlott wrote:
> I would like to bristle mildly against the style of using Vector.T to
> represent the vector type. The reasons are 1) it is cryptic to those
> not used to the convention;
What does this tell about the quality of the concept?
> 2) enshrining one-type
20 matches
Mail list logo
