On Thu, Aug 16, 2001 at 01:11:25AM -0400, Avi Pfeffer wrote:
> Works fine. Things get tricky when I try to add pairs. In order to type
> a pair expression, I find I need to create a Pair class and introduce a
> class constraint:
>
> class Pair a b c | a -> b c, b c -> a
>
> instance Pair (b,c
How about:
===
data Expr a = Haskell a
| If (Expr Bool) (Expr a) (Expr a)
| forall b . Appl (Expr (b->a)) (Expr b)
| forall b c . MkPair (Expr b) (Expr c) (b -> c -> a)
eval :: Expr a -> a
eval (
Hi all,
I'm trying to write an interpreter for a language embedded in Haskell,
that "inherits" Haskell types and values. So I create a type Expr a, to
represent expressions of type a, and an evaluator that takes an Expr a
and produces an a. (To keep things simple, let's assume there are no
vari
Hi Simon,
>>>>> "Simon" == Simon Peyton-Jones <[EMAIL PROTECTED]> writes:
> | Subject: Type signatures in instance declarations?
> ..
> | I think it would be even useful to the compiler when one has a
> | polymorphic recursion.
| Subject: Type signatures in instance declarations?
|
| > Why are these illegal? I appreciate that they can't
| give useful information
| > to the compiler, which knows the type already from the
| class, but in my
| > opinion they are still useful to the maintain
: comments).
I would love to see type signatures in export lists.
It may also allow you to export a function implemented
with a universal type signature for a certain specific type.
> module Foo( same :: Int -> Int -> Bool ) where
> same :: a -> a -> Bool
> same = (==)
Regards,
Marc
Some people write:
| "Type signatures in instance declarations?"
| Why are these illegal?
I agree completely. Related questions are:
* Why can one not have a type declaration of a function
twice ore more in a file? It seems a bit silly, because
you are allowed to pu
George Russell <[EMAIL PROTECTED]> writes:
> Why are these illegal? I appreciate that they can't give useful information
> to the compiler, which knows the type already from the class, but in my
> opinion they are still useful to the maintainer, because they serve as
> a reminder
George Russell ([EMAIL PROTECTED]) wrote:
: Why are these illegal? I appreciate that they can't give useful information
: to the compiler, which knows the type already from the class, but in my
: opinion they are still useful to the maintainer, because they serve as
: a reminder of the type.
:
Why are these illegal? I appreciate that they can't give useful information
to the compiler, which knows the type already from the class, but in my
opinion they are still useful to the maintainer, because they serve as
a reminder of the type.
> > Here's a good Haskell 98 question: is this a valid H98 module?
> >
> > module F where
> > sin :: Float -> Float
> > sin x = (x::Float)
> >
> > f :: Float -> Float
> > f x = Prelude.sin (F.sin x)
> >
> That sounds like a fine thing to do if
it in the H98 report. And the same applies to
> fixity declarations.
>
> I propose to treat it as a typo, and add a clarifying remark
> to Section 5.5.2 (name clashes) that makes it clear that type signatures
> and fixity declarations are always unqualified, and refer (of course)
>
ere, so presumably
there is only one 'sin' that can possibly be meant by this signature,
namely F.sin.
But this isn't explicit in the H98 report. And the same applies to
fixity declarations.
I propose to treat it as a typo, and add a clarifying remark
to Section 5.5.2 (name clashes) th
Folks,
Warren Burton makes what appears to me to be a Jolly Sensible suggestion about
the syntax of type signatures. Haskell already has many dual ways of doing
things (let/where, case/pattern-matching). Warren proposes an alternative
syntax for type signatures.
Simon
--- Forwarded
14 matches
Mail list logo
