Jonathan Cast wrote:
Lennart Augustsson <[EMAIL PROTECTED]> wrote:
A somewhat similar problem exists even without fields:
foo :: Either a b -> Either () b
foo (Left _) = Left ()
foo x@(Right _) = x
Since Haskell type checking doesn't use the information gained
by pattern matching to refine ty
It's true that GADTs does just that. But only if you use them.
And they are not part of Haskell. :)
-- Lennart
Jacques Carette wrote:
I was under the impression that, in ghc 6.4 at least, GADTs did just
that: use information gained by matching on the type constructor to
refine types.
Jan-Willem Maessen wrote:
On Jun 22, 2005, at 9:38 PM, Andrew Ward wrote:
Pal-Kristian Engstad wrote:
On Wednesday 22 June 2005 05:38 pm, Andrew Ward wrote:
What would be the normal way for a Haskell programmer to handle the
typical shape example in beginner OO tutorials?
By not doing
On Thu, Jun 23, 2005 at 09:08:12PM +0200, Christian Maeder wrote:
> Malcolm Wallace wrote:
> >>voidcast :: Fields a -> Fields Void
> >>voidcast v@(VariantWithTwo{}) = v { field1 = Void , field2 = Void }
> >>voidcast v@(VariantWithOne{}) = v { field1 = Void }
>
> I would not expect that updating on
Lennart Augustsson <[EMAIL PROTECTED]> wrote:
> A somewhat similar problem exists even without fields:
>
> foo :: Either a b -> Either () b
> foo (Left _) = Left ()
> foo x@(Right _) = x
>
> Since Haskell type checking doesn't use the information gained
> by pattern matching to refine types we ju
Bulat,
a) building (i) a list of data is fundamentally different
from building (ii) a list of anticipated results of each datum.
I would be surprised to hear that this counts as a valid technique.
BTW, you can do the *same* in a lazy OO language. (No lazy OO language
at hand -- well lazyness can b
On Thu, 23 Jun 2005, Christian Maeder wrote:
> Malcolm Wallace wrote:
> >>voidcast :: Fields a -> Fields Void
> >>voidcast v@(VariantWithTwo{}) = v { field1 = Void , field2 = Void }
> >>voidcast v@(VariantWithOne{}) = v { field1 = Void }
>
> I would not expect that updating only field1 can change
Malcolm Wallace wrote:
>>voidcast :: Fields a -> Fields Void
>>voidcast v@(VariantWithTwo{}) = v { field1 = Void , field2 = Void }
>>voidcast v@(VariantWithOne{}) = v { field1 = Void }
I would not expect that updating only field1 can change the type of v.
The right thing is to construct a new valu
Andreas Rossberg said:
> [Followups to Haskell Cafe]
> as far as I read it, "dynamic" or "late binding" is orthogonal to
> subtyping, or typing in general. It is just that most typed OO
languages
> lump these concepts together.
Absolutely agreed.
> Often a simple first-class function, or a reco
On Thu, 23 Jun 2005, Malcolm Wallace wrote:
> > module Fieldbug where
> > data Fields a =
> > VariantWithTwo { field1 :: a
> >, field2 :: a }
> > | VariantWithOne { field1 :: a }
>
> The key point here is that the data structure with named fields has more
> than one cons
On Thu, 23 Jun 2005, Lennart Augustsson wrote:
> A somewhat similar problem exists even without fields:
>
> foo :: Either a b -> Either () b
> foo (Left _) = Left ()
> foo x@(Right _) = x
>
> Since Haskell type checking doesn't use the information gained
> by pattern matching to refine types we j
I was under the impression that, in ghc 6.4 at least, GADTs did just that: use information gained by matching on the
type constructor to refine types. I sort-of expected that the extension to pattern matching would follow.
Or is that a nice paper waiting to be written?
Jacques
Lennart Augusts
A somewhat similar problem exists even without fields:
foo :: Either a b -> Either () b
foo (Left _) = Left ()
foo x@(Right _) = x
Since Haskell type checking doesn't use the information gained
by pattern matching to refine types we just have to accept that
some perfectly safe programs don't typ
I have discovered something I believe to be a problem in Haskell'98,
although it is not a simple bug as such - it has more of the flavour of
an unintended mismatch in the interaction of two separate features.
Since Haskell is deeply principled language, a feature conflict is
extremely rare, and so
Interestingly this is exactly the approach taken in the OOHaskell paper!
The difference is we used extensible records with subtyping (from the
HList paper)
to implement inheritance and overloading, which you cannot do with ordinary
Haskell records.
So you statment that it is better to do it in Has
Hello Ralf,
Thursday, June 23, 2005, 11:36:20 AM, you wrote:
>> just create list of draw functions itself:
>>
>> [drawCircle (10,10) 5, drawSquare (20,20) 10]
RL> No! the exercise is about lists of shapes
RL> not lists of results of drawing shapes.
RL> This is clearly a major difference.
in ca
Thomas Sutton wrote:
> Main> :t (Impl (Prop "p") (Poss (Prop "p")))-- "p -> <>p"
> Impl (Prop "p") (Poss (Prop "p")) :: PC
So the type says that this is a formula in the predicate calculus?
(Even though you combine two formulae of modal logics.)
Are you happy with that? Just wondering?
Al
On 11/06/2005, at 11:18 PM, Thomas Sutton wrote:
In Java (C#, Python, etc) I'd do this by writing an interface
Formula and have a bunch of abstract classes (PropositionalFormula,
ModalFormula, PredicateFormula, etc) implement this interface, then
extend them into the connective classes Conju
On 6/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> getList = do
> putStrLn "Give me a number (or 0 to stop):"
> numString <- getLine
> let num = read numString
> if num == 0
> then return []
> else return (num:getList)
This will give you an error as well. 'num' is of
19 matches
Mail list logo
