Re: labelled types efficiency
Hello!
On Fri, Mar 08, 2002 at 12:52:58AM -0300, Andre W B Furtado wrote:
> Another question about labelled types, this time concerning about
> efficiency: is there any efficiency differences between functions f and g
> below?
> > data RType = R Int Char
> > data Stype = S {x :: Int, y :: Char}
> > f :: RType -> Int
> > f (R x _) = x
> > g :: SType -> Int
> > g s = x s
> Thanks again,
> -- Andre
In principle, the representation of RType and Stype is the same.
The only difference of Stype over RType is the implicit definition
of the functions (accessors) x and y, as well as the syntactic
sugar for constructing values, pattern matching and functional
update using field names. But as said, that's just functional
sugar and should be just exactly as efficient as using the manual
translation of those constructs on RType.
Now, that said, g *looks* a bit more lazy than f, as in f, you
don't evaluate the right side if the parameter isn't
R _|_ _|_ or more. However, I said *looks*, but if one checkes,
it's thus, desugared:
f (R x _) = x
g s = x s
where
x (S xElem _yElem) = xElem
And if you just evaluate both at _|_, the result is _|_ for both
f and g. So in fact, there equally strict. Finally, the code
for f and g should, save for renaming, be just the same.
Kind regards,
Hannah.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
labelled types efficiency
Another question about labelled types, this time concerning about
efficiency: is there any efficiency differences between functions f and g
below?
> data RType = R Int Char
> data Stype = S {x :: Int, y :: Char}
>
> f :: RType -> Int
> f (R x _) = x
>
> g :: SType -> Int
> g s = x s
Thanks again,
-- Andre
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
pattern-matching with labelled types
Andre W B Furtado writes:
:
| Of course, it is possible to do something like
|
| > update :: MyType -> Int -> MyType
| > update mt newValue = MT {x = newValue, y = oldValue}
| > where oldValue = y mt
|
| but this really annoys me when MyType has too many fields. Suggestions?
update mt newValue = mt {x = newValue}
HTH.
Tom
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
pattern-matching with labelled types
If I have:
> data MyType = MT {
> x :: Int,
> y :: Char
> }
How do I update the Int value of MyType leaving the Char value unaffected? I
tryied something like:
> MT {x = newValue}
but GHC gave me a warning about the Char value and it indeed caused strange
effects. Of course, it is possible to do something like
> update :: MyType -> Int -> MyType
> update mt newValue = MT {x = newValue, y = oldValue}
> where oldValue = y mt
but this really annoys me when MyType has too many fields. Suggestions?
Thanks a lot,
-- Andre
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Question: Database access in Haskell
Dear Sir/Madam, I am considering implement a system using Haskell. I need to use database to manage data there. How can I access the data records in database from Haskell? Thanks for your advice! Best Regards, Dianne __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: rank-n polymorphism
> > GHC 5.0.3 supports rank-n polymorphism. > > Could anyone please point me to a paper that describes type inference > > algorithm used. > Rank-n polymorphism can only happen via explicit type signatures. SPJ and I are working on a formal description of how all of this works, and should have a manuscript ready in few weeks. Yes: the inference is based on Odersky & Laufer, and yes: the trick is to exploit type annotations. The full system, however, has required quite a few innovations beyond this. Our manuscript also describes how to extend Haskell with first-class existentials, in the style described in our FOOL 9 paper "First-class modules for Haskell." Fun for all the family. Regards, Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: rank-n polymorphism
Someone already sent you the Odersky paper, but in brief, there is no type inference (as it is undecidable). Rank-n polymorphism can only happen via explicit type signatures. My understanding is that if these type signatures are not there, GHC will automatically lift all the foralls to the front in type inference. - Hal -- Hal Daume III "Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Thu, 7 Mar 2002, Artem S Alimarine wrote: > Dear all, > > GHC 5.0.3 supports rank-n polymorphism. > Could anyone please point me to a paper that describes type inference > algorithm used. > > Thanks in advance > Artem Alimarine > > ___ > Haskell mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/haskell > ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: rank-n polymorphism
On Thursday 07 March 2002 08:26 am, you wrote:
> Dear all,
>
> GHC 5.0.3 supports rank-n polymorphism.
> Could anyone please point me to a paper that describes type inference
> algorithm used.
The main paper is "Putting Type Annotations to Work" by Odersky and L"aufer:
@InProceedings{Odersky-Laufer96,
author = "Martin Odersky and Konstantin L{\"a}ufer",
title ="Putting Type Annotations to Work",
key = "Odersky \& Laufer",
pages ="54--67",
booktitle ="Conference Record of POPL '96: The 23rd ACM
SIGPLAN-SIGACT Symposium on Principles of Programming
Languages, St. Petersberg Beach, Florida",
year = "1996",
organization = "ACM",
address = "New York, NY",
month =jan,
annote = "31 references.",
}
Cheers,
Andy
--
Andy Moran Ph. (503) 526 3472
Galois Connections Inc. Fax. (503) 350 0833
3875 SW Hall Blvd.http://www.galois.com
Beaverton, OR 97005[EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
rank-n polymorphism
Dear all, GHC 5.0.3 supports rank-n polymorphism. Could anyone please point me to a paper that describes type inference algorithm used. Thanks in advance Artem Alimarine ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
new version of Parser Combinators and Syntax Macros's (beta)
Title: new version of Parser Combinators and Syntax Macros's At: http://www.cs.uu.nl/groups/ST/Software/UU_Parsing you will find the latest/greatest version of our combinators, that are: - faster (faster than Parsec) - correct much faster - compute results lazily, and produce error messages online in the IO monad while parsing (using unsafeInterleavedIO) - are compatible with the syntax macro mechanism we have implemented (beta): http://www.cs.uu.nl/~arthurb/index.html Doaitse -- -- __ S. Doaitse Swierstra, Department of Computer Science, Utrecht University P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ tel: +31 30 253 3962 fax: +31 30 251 3791 mobile: +31 6 2880 1680 __
type aliases in instances
In Haskell type aliases are not allowed in instance definitions. Is there a particular reason for this? For example, is there a problem with type inference? I noticed that when composing monads (in the Moggi/Wadler style) one easily ends up with a cascade of coercions enforced by datatype declarations. Looks a bit tedious. This can be avoided by using type aliases but then the monads in use cannot be instances of the Monad class. Phil uses aliases in his "Essence of functional programming" paper too. But not declaring the monads to be in class Monad can hardly be good style, can it? Many thanks for your help in advance. Bernhard --- Bernhard Reus, COGS University of Sussex ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Rectification Hugs bug
Dear all, After intensive investication of several people at Utrecht University, these are the results: 1. The very latest Hugs version doesn't have the bug 2. All before-december-2001 versions don't have the bug I were using a version downloaded some weeks ago. After installing the current distribution, the problems disappeared. Therefore, I suspect there have been one or more bug-fix updates after December 2001, fixing this problem. However, I couldn't find that documented on the Hugs site. Can anyone confirm such an update? Where can I find last-minute distribution information? Thanks, Rijk-Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Rectification Hugs bug
Dear all, After intensive investication of several people here at Utrecht University, these are the results 1. The very latest Hugs version doesn't have the bug 2. All before-december-2001 versions don't have the bug I were using a version downloaded some weeks ago. After installing the current distribution, the problems disappeared Therefore, I suspect there have been one or more bug-fix updates after December 2001, fixing this problem. However, I couldn't find that documented on the Hugs site. Can anyone confirm such an update? Where can I find last- minute distribution information? Thanks, Rijk-Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
class hierarchies inmature in hugs
I just saw someone "misusing" [EMAIL PROTECTED] for bug reports. I am going to join especially - it is a funny one, - the bug hasn't been fixed since Sep. 2001, - it is not even put in the list of known bugs since then. --- The following code works with ghc but not with hugs (incl. Dec. 2001 release) import Monad class Monad m => C1 m x -- Monad m is implied by C1 but test diverges if constraint not present class (C1 m x) => C2 m x where c2 :: x -> m x instance Monad m => C1 m Bool instance C2 Maybe Bool where c2 = return test :: Maybe Bool test = c2 True --- So you see, C1 is a kind of derived from Monad. C2 is derived from C1 and hence implicitly from Monad. This is a kind of minimal example. Just attempt to evaluate "test". hugs will loop. There is a way to help hugs. Add Monad m as a further class constraint to C2. Then it will work. Please note both programs do type check, and this is in fact fine. More generally, I get these looping programs whenever I have non-trivial class hierarchies with three or more layers. I guess more people should have suffered from that? Ralf -- Dr.-Ing. Ralf Laemmel CWI & VU, Amsterdam, The Netherlands http://www.cwi.nl/~ralf/ http://www.cs.vu.nl/~ralf/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
