Re: Re[2]: [Haskell-cafe] Confused about Cyclic struture
On Sat, 2005-07-09 at 13:12 +0400, Bulat Ziganshin wrote: > Hello Dinh, > > Friday, July 08, 2005, 9:12:22 PM, you wrote: > > DTTA> Another question, it's said in the book that using cyclic structure > (like > DTTA> ones = 1:ones) , the list would be represented by a fixed amount of > memory. > > DTTA> Does it mean [1,1,1..] only occupy one cell of memory ? > DTTA> How about in " take 100 [1,1,...] " ? > > in order to understand how Haskell datastructures uses memory, you > must remember that Haskell does LAZY evaluation. Hi, I'll be a little bit pedantic here. Haskell, the language definition, does not prescribe lazy evaluation. It says that the language is non-strict. Lazy evaluation is an implementation technique which satisfies non-strict semantics, but it is not the only technique which does this. As it happens, GHC, Hugs and nhc98 all employ lazy evaluation. Note that they may still vary in subtle ways as to the precise details of evaluation order, due to program transformations that may be applied to the program during compilation. As I said in my previous mail, the degree of sharing you get within Haskell data structures is not defined in the language, it is defined (perhaps loosely) by the implementation technique. Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Overlapping Instances with Functional Dependencies
This is still an ad-hoc solution, cause you lose
the `most-specific' instance property. You really have to
impose a `fixed' ordering in which instance-improvement rules
fire.
Recap:
The combination of overlapping instances
and type improvement leads to a `non-confluent' system, i.e.
there're too many (inconsistent) choices how to improve and reduce
constraints.
The standard approach to deal with overlapping instances is to
impose a fixed order among the resulting reduction rules
(the `most-specific' order can be seen as a special instance
of a fixed order).
FDs imply improvement rules. In case of overlapping instances these
improvement rules are immediately non-confluent.
As Simon pointed out:
"...what ever mechanism is used for instance matching, the same
would be used for type dependencies..."
Hence, combining instances and improvement rules is the obvious
`solution'. Hints can be found in my first two replies where I said:
1) "... You find some hints how to achieve this in ... ESOP'04".
2) "...instances and type dependencies are closer linked to each other
then one might think..."
Concretely, the TypeCast trick already appears in the ESOP'04 paper
on p8 (mid-page).
Conclusion:
I think it's wrong to explain a new feature in terms of an
implementation-specific encoding. We need something more principled
here. Otherwise, we'll face some unexpected behavior (eventually)
again.
Martin
[EMAIL PROTECTED] writes:
>
> Daniel Brown wrote:
>
> >class Baz a b | a -> b
> >instance Baz (a -> b) (a -> [b])
> >instance Baz a a
> > ...but Baz fails with this error...
> >
> > When confronted with overlapping instances, the compiler chooses the
> > most specific one (if it is unique), e.g. `Baz (a -> b) (a -> [b])` is
> > more specific than `Baz a a`.
> >
> > But it seems that the combination of the two features is broken: if the
> > most specific instance is chosen before checking the functional
> > dependency, then the fundep is satisfied; if the fundep is checked
> > before choosing the most specific instance, then it isn't.
>
> There is a way to write your example in Haskell as it is. The key idea
> is that functional dependencies can be given *per instance* rather than
> per class. To assert such dependencies, you need the `TypeCast'
> constraint, which is throughly discussed in the HList technical
> report.
> http://homepages.cwi.nl/~ralf/HList/
>
> The following is the complete code for the example, which runs on GHC
> 6.4. We see that the functional dependencies work indeed: the compiler
> figures out the types of test1 and test2 and test3 (and thus resolved
> overloading) without any type signatures or other intervention on our
> part.
>
>
> {-# OPTIONS -fglasgow-exts #-}
> {-# OPTIONS -fallow-undecidable-instances #-}
> {-# OPTIONS -fallow-overlapping-instances #-}
>
> module Foo where
>
>
> {-
> class Baz a b | a -> b
> instance Baz (a -> b) (a -> [b])
> instance Baz a a
> -}
>
> -- No functional dependencies here!
> class Baz a b where baz :: a -> b
>
> -- Rather, dependencies are here
> instance TypeCast a r => Baz a r where
> baz a = typeCast a
>
> instance TypeCast (a -> [b]) r => Baz (a -> b) r where
> baz f = let r = \a -> [f a] in typeCast r
>
> -- Chooses the instance Baz a a
> test1 = baz True
> -- True
>
> -- Chooses the instance Baz (a -> b) (a -> [b])
> test2 = (baz show) (1::Int)
> -- ["1"]
>
> test3 x = (baz show) x
> test3' = test3 (Just True)
> -- ["Just True"]
>
> -- copied verbatim from the HList library
> class TypeCast a b | a -> b, b->a where typeCast :: a -> b
> class TypeCast' t a b | t a -> b, t b -> a where typeCast' :: t->a->b
> class TypeCast'' t a b | t a -> b, t b -> a where typeCast'' :: t->a->b
> instance TypeCast' () a b => TypeCast a b where typeCast x = typeCast' () x
> instance TypeCast'' t a b => TypeCast' t a b where typeCast' = typeCast''
> instance TypeCast'' () a a where typeCast'' _ x = x
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Overlapping Instances with Functional Dependencies
Daniel Brown wrote:
>class Baz a b | a -> b
>instance Baz (a -> b) (a -> [b])
>instance Baz a a
> ...but Baz fails with this error...
>
> When confronted with overlapping instances, the compiler chooses the
> most specific one (if it is unique), e.g. `Baz (a -> b) (a -> [b])` is
> more specific than `Baz a a`.
>
> But it seems that the combination of the two features is broken: if the
> most specific instance is chosen before checking the functional
> dependency, then the fundep is satisfied; if the fundep is checked
> before choosing the most specific instance, then it isn't.
There is a way to write your example in Haskell as it is. The key idea
is that functional dependencies can be given *per instance* rather than
per class. To assert such dependencies, you need the `TypeCast'
constraint, which is throughly discussed in the HList technical
report.
http://homepages.cwi.nl/~ralf/HList/
The following is the complete code for the example, which runs on GHC
6.4. We see that the functional dependencies work indeed: the compiler
figures out the types of test1 and test2 and test3 (and thus resolved
overloading) without any type signatures or other intervention on our
part.
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-undecidable-instances #-}
{-# OPTIONS -fallow-overlapping-instances #-}
module Foo where
{-
class Baz a b | a -> b
instance Baz (a -> b) (a -> [b])
instance Baz a a
-}
-- No functional dependencies here!
class Baz a b where baz :: a -> b
-- Rather, dependencies are here
instance TypeCast a r => Baz a r where
baz a = typeCast a
instance TypeCast (a -> [b]) r => Baz (a -> b) r where
baz f = let r = \a -> [f a] in typeCast r
-- Chooses the instance Baz a a
test1 = baz True
-- True
-- Chooses the instance Baz (a -> b) (a -> [b])
test2 = (baz show) (1::Int)
-- ["1"]
test3 x = (baz show) x
test3' = test3 (Just True)
-- ["Just True"]
-- copied verbatim from the HList library
class TypeCast a b | a -> b, b->a where typeCast :: a -> b
class TypeCast' t a b | t a -> b, t b -> a where typeCast' :: t->a->b
class TypeCast'' t a b | t a -> b, t b -> a where typeCast'' :: t->a->b
instance TypeCast' () a b => TypeCast a b where typeCast x = typeCast' () x
instance TypeCast'' t a b => TypeCast' t a b where typeCast' = typeCast''
instance TypeCast'' () a a where typeCast'' _ x = x
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interaction in Haskell
Dinh Tien Tuan Anh wrote:
> > Yes, it is certainly not Hugs which prevents from realtime interaction but
> > it is the terminal you are using. If the terminal lets you delete the
> > characters on the current line it has to keep them until you complete it
> > with ENTER. Piping from and to other programs or files may not have this
> > problem.
>
> You're right, i've been using shell in Emacs to run Hugs, but when back to
> normal terminal, it works.
>
> Just for curiousity, why does it happen ?
Emacs' shell-mode doesn't send anything to the terminal driver until
you hit Return, at which point it sends the whole line.
Note that the terminal driver itself normally does line-buffering,
although this is disabled if you set the buffering for stdin to
NoBuffering.
You can't disable the line-buffering inherent in Emacs' shell-mode;
you would have to use terminal-emulator instead ("M-x term" instead of
"M-x shell").
--
Glynn Clements <[EMAIL PROTECTED]>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't explain this error
Thanks for your reply, i just simply removed the first line and it works, but i dont understand why 1/x is not Float. It depends on the type of 'x'. If 'x' is a Float, (1/x) will be a Float. If 'x' is a Double, (1/x) will be a Double. If 'x' is an Integer (1/x) will not typecheck because (/) is only defined for Fractional arguments, and Integer is not an element of Fractional. In your case, you had constrained 'x' to be an Integer, so it requires a cast to perform the division and get a Float. Removing the type signature allows the compiler to assign a more general type to 'x', and so it typechecks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't explain this error
You are trying to divide by an Integer and get a Float. Haskell doesn't do automatic numeric conversion, so you have to do the casts manually. Prelude> let sumHam n = sum [ 1 / (fromIntegral x) | x <- [1..n] ] Prelude> sumHam 5 2.283 Dinh Tien Tuan Anh wrote: could anyone tell me what i did wrong with this please sumHam :: Integer -> Float sumHam n = sum [1/x | x<-[1..n]] Error: type error in explicitly typed binding Term: sumHam Type: Integer -> Integer Does not match : Integer -> Float it only works if i remove the first line. Tried changing Float by Double and still not working Pls help Cheers _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't explain this error
Thanks for your reply, i just simply removed the first line and it works, but i dont understand why 1/x is not Float. Try this: sumHam :: Integer -> Float sumHam n = sum [1.0/(fromIntegral x) | x<-[-1..n]] -- Andy _ Use MSN Messenger to send music and pics to your friends http://messenger.msn.co.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't explain this error
On 11 Jul 2005, at 17:37, Dinh Tien Tuan Anh wrote: sumHam :: Integer -> Float sumHam n = sum [1/x | x<-[1..n]] Try this: sumHam :: Integer -> Float sumHam n = sum [1.0/(fromIntegral x) | x<-[-1..n]] -- Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Can't explain this error
could anyone tell me what i did wrong with this please sumHam :: Integer -> Float sumHam n = sum [1/x | x<-[1..n]] Error: type error in explicitly typed binding Term: sumHam Type: Integer -> Integer Does not match : Integer -> Float it only works if i remove the first line. Tried changing Float by Double and still not working Pls help Cheers _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interaction in Haskell
You're right, i've been using shell in Emacs to run Hugs, but when back to normal terminal, it works. Just for curiousity, why does it happen ? Thank you very much Cheers Yes, it is certainly not Hugs which prevents from realtime interaction but it is the terminal you are using. If the terminal lets you delete the characters on the current line it has to keep them until you complete it with ENTER. Piping from and to other programs or files may not have this problem. _ Use MSN Messenger to send music and pics to your friends http://messenger.msn.co.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interaction in Haskell
On Mon, 11 Jul 2005, Dinh Tien Tuan Anh wrote: > Hi, > im using Hugs 98 and learing how to use interactive Haskell. > As read in the book: > > capitalise :: [Char] -> [Char] > capitalise = takeWhile(/='.') . map toUpper > > > interact capitalise > > its said the program is FULLY INTERACTIVE, i.e: as soon as 'h' typed on the > keyboard, an 'H' appears on the screen. But the program above always waits > untill ENTER was hit to display the result > > Is this normal ? Is the book right ? Yes, it is certainly not Hugs which prevents from realtime interaction but it is the terminal you are using. If the terminal lets you delete the characters on the current line it has to keep them until you complete it with ENTER. Piping from and to other programs or files may not have this problem. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Interaction in Haskell
Hi, im using Hugs 98 and learing how to use interactive Haskell. As read in the book: capitalise :: [Char] -> [Char] capitalise = takeWhile(/='.') . map toUpper interact capitalise its said the program is FULLY INTERACTIVE, i.e: as soon as 'h' typed on the keyboard, an 'H' appears on the screen. But the program above always waits untill ENTER was hit to display the result Is this normal ? Is the book right ? I thought if the list was evaluated lazily, then it should be fully interactive. Cheers. _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: cabal --user question
Isaac Jones writes: > ./setup configure --user #if it depends on user-local packages > ./setup build > ./setup install --user > Perhaps install --user should be the default if you > configure --user. Yes, I think that would be more intuitive. It would also be nice to be able to configure Cabal to do the user-style install per default. An environment variable, maybe? Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal --user question
Hi Isaac, Is there a way to specify a particular package.conf for use when installing and registering packages with Cabal? I'm trying to Cabal-ize WASH which has a number of packages which depend on each other. The problem is that in order to build the next package, the previous one has to be installed, yet users typically want to do a full build *before* installing anything. I was thinking that for the 'make' step it could just install each package locally and register it in a local package.conf (i.e. somewhere in the project tree), and then 'make install' would rerun the install commands with the final install location and final package database as arguments. But I can't figure out how to specify the local package.conf to 'configure' or 'install', there are just the '--user' and '--global' commands which aren't quite enough. Frederik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
