- Haskell-Cafe - Haskell.org

Re: type equivalency
by Jon Cast 06 Jun '02

06 Jun '02

Andrew J Bromage <andrew(a)bromage.org> wrote: > G'day all. > On Wed, Jun 05, 2002 at 08:20:03PM -0500, Jon Cast wrote: > > I think you're confused about what the type declarations mean. > > When you say > > > sqrt :: Float -> Float > > you're promising to operate over /all/ Floats. > That would be true of Haskell functions were constrained to be total > functions. They are not. Sqrt takes values of type Float, but it > just happens to be a partial function over that type. That depends on what you mean by ``partial function''. Technically, of course, a function of type (a -> b) is a subset of (a x b) satisfying certain constraints. All Haskell functions f satisfy the property (forall x::a. exists y::b. (x, y) <- f), so you can always get a value of f at any x. In other words, sqrt can take any x and compute with it; it just delivers _|_ at some of them. My point was, (sqrt x) is legal Haskell (and has a value) for all (x :: Float). > > Unfortunately, Haskell doesn't allow {x :: Float | x >= 0} as a > > type, nor does it provide a positive-only floating point type. > One general rule of strongly-typed programming is: A program is type > correct if it is accepted by my favourite type checker. A corollary > is that what you call a type, I reserve the right to call a > precondition. If I accepted that, I would be un-defining crucial terms. That would destroy the potential for discussion here, no? > Cheers, > Andrew Bromage Jon Cast

4 3

Re: type equivalency
by Jon Cast 05 Jun '02

05 Jun '02

Cagdas Ozgenc <co19(a)cornell.edu> wrote: > For example all functions with Int -> Int are type equivalent, > because structural equivalency is used. Most of the time the > functions are not compatible because they have different pre/post > conditions, even though they seem to have the same input output > types. I rather make my functions an instance of a type-class to > tell the compiler that they can be used interchangably. For example > sqrt :: Float -> Float > sqrt a = /* pre : a >= 0 */ > negate :: Float -> Float > /* no precondition */ > are different functions. You cannot just plug one in place of > another (you can in Haskell because of structural type equivalency). I think you're confused about what the type declarations mean. When you say > sqrt :: Float -> Float you're promising to operate over /all/ Floats. If you want to restrict that to only certain Floats, you would need a different ``type'': > sqrt :: {x :: Float | x >= 0} -> Float or introduce your own type isomorphic to this. Unfortunately, Haskell doesn't allow {x :: Float | x >= 0} as a type, nor does it provide a positive-only floating point type. I think your problem is related to the concepts of ``different'' and ``plug in''. All the Haskell compiler performs is type checking; unfortunately, type checking is purely structural; it doesn't enquire whether the resulting program is correct (or even meaningful). You can tell Haskell isn't concerned with whether your programs are meaningful, because Haskell allows the following program: > main = main This is obviously completely meaningless. Now, then, obviously sqrt and negate are different in the sense of ``unequal''. If you don't know, equality between Haskell functions is defined (ommitting some complications) like such: > f = g <=> forall x.f x = g x Clearly negate /= sqrt! However, taking your notion of ``not different'', which is apparantly > f = g <=> domain f = domain g note that both > sqrt x = x ** (1/2) and > qrrt x = x ** (1/4) have the same domain. Are they equivalent? It (obviously) depends on the context. Consider the function dist: > dist :: (Double, Double) -> (Double, Double) -> Double > dist (x1, x2) (y1, y2) = sqrt ((x1 - y1) ** 2 + (x2 - y2) ** 2) You can't use qrrt in dist and expect it to be correct any more than you an use negate. On the other hand there may be terms which don't care which among qrrt and sqrt you give them but don't want negate. So, equivalence is a tricky problem---and one you can't solve without reading the programmer's mind. That's why Haskell doesn't address it, being content with type checking. > Also a function working over (Int,Int) will do so even if the > numbers are totally irrelevant to that function. They maybe the > number of (apples,oranges) or number of (books,authors). You're right that the type constructor (,) doesn't carry a lot of information; but I think you misunderstand why: given a type declaration > data FiddleDeDee a b = MkFiddleDeDee a b FiddleDeDee is ``structurally equivalent'' to (,), and also carries about as much information. Consider: ``What's the French for fiddle-de-dee?'' ``Fiddle-de-dee's not English,'' Alice replied gravely. ``Who ever said it was?'' said the Red Queen. Lewis Carroll, ``Through the Looking Glass'' > However, > data D a b = MkD a b > data E a b = MkE a b > (D Int Int) and (E Int Int) are trated as different because of name > equivalency testing. > Basically there are 2 type constructors -> ( , ) with structural > equivalency, which is odd. Someone just dumped some idiosyncracies > of lamda calculus into the language. I assume from your example that by ``structural equivalence'' you mean the relationship between D and E. But they also share that relationship with (,)---what exactly is the difference? Functions over (D Int Int) work even if the caller thinks its (D #apples #oranges) and the function thinks its (D #books #authors). Again, the problem is with Int, not D (or (,)). > Thanks again.

2 1

RE: Counting occurrences question
by Andy Fugard 05 Jun '02

05 Jun '02

>===== Original Message From "xoo" <ixoo21(a)hotmail.com> ===== >hi.. i was just wondering if some body could give a simple equation for the following situation.other than recursion plz.. > >occurrences :: Eq a => a -> [a] -> [a] >--occurrences xs ys returns the number of times that xs occurs in ys You may find it easier if you make occurrences :: Eq a => a -> [a] -> Integer since it would seem it is to return a number, and not another list! Also I would guess the function will have a form something like occurrences x xs = foldr (countOp x) 0 xs where countOp :: Eq a => a -> a -> Integer -> Integer ... I'm not sure if I should go any further, in case this is a homework question... Andy -- [ Andy Fugard ] [ +44 (0)7901 603075 ]

3 3

Bilgisayar Egitiminde Bir Numara
by Sertifikam.Com 05 Jun '02

05 Jun '02

1 0

Bilgisayar Egitiminde Bir Numara
by Sertifikam.Com 05 Jun '02

05 Jun '02

1 0

Direct Email Blaster, Email extractor, email downloader, email verify ...........
by targetemailextractor＠btamail.net.cn 02 Jun '02

02 Jun '02

1 0

HTTP Implementation
by Warrick Gray 02 Jun '02

02 Jun '02

I've been tinkering with a client-side HTTP/1.1 implementation for Haskell. My ambition is to write a small Haskell program for checking my Hotmail account. In the interests of finding all bugs and giving something for nothing I've made the code available: http://homepages.paradise.net.nz/warrickg/haskell/http Significantly missing is any hint of SSL and request pipelining. Suggestions on improvements are welcome. Warrick. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

2 1

RE: Naming conventions for compiler options [Was: layout rule infelicity]
by Jay Allen 30 May '02

30 May '02

-Wmissing-prototypes, actually (http://www.esat.kuleuven.ac.be/~gcc/) But good guess. ;) -J- -----Original Message----- From: Ashley Yakeley [mailto:ashley@semantic.org] Sent: Thu 5/30/2002 5:26 PM To: Haskell Cafe List Cc: Subject: Re: Naming conventions for compiler options [Was: layout rule infelicity] At 2002-05-30 16:51, oleg(a)pobox.com wrote: >-Wmissing-protons Compiles BASIC? -- Ashley Yakeley, Seattle WA _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Re: Naming conventions for compiler options [Was: layout rule infelicity]
by Ashley Yakeley 30 May '02

30 May '02

At 2002-05-30 16:51, oleg(a)pobox.com wrote: >-Wmissing-protons Compiles BASIC? -- Ashley Yakeley, Seattle WA

1 0

Naming conventions for compiler options [Was: layout rule infelicity]
by oleg＠pobox.com 30 May '02

30 May '02

[redirected to haskell-cafe] Jón Fairbairn wrote: > 1. Why "-f" anyway? It took me ages to work out what > "-fallow-overlapping-instances" meant -- I wondered how > "fallow" could apply to overlapping instances. I believe the authors of GHC followed the naming conventions of GCC, which can be gleaned from GCC's info page. -warning-related options typically start with -W -machine-independent flags that control optimization, code-generation or language dialects start with -f. Most flags have positive and negative forms. -many pre-processor-related options start with -i -hardware-dependent options start with -m, e.g., -mcpu=i686 -mno-fancy-math-387 -malign-int -mno-power [RS/6000-related option] -myellowknife [On embedded PowerPC systems, assume that the startup module is called `crt0.o' and the standard C libraries are `libyk.a' and `libc.a'] Of possible interest is a file gcc-2.95.2/gcc/future.options from GCC's source code. The file lists a few suggested options. The file is an e-mail message from Noah Friedman to Richard Stallman, Jim Blandy and a few other people. Some of the suggested options are: -Waggravate-return -Wcast-spell -Wcaste-align [cf. the existing GCC option -Wcast-align] -Win [I guess warn about the Windows system] -Wmissing-protons -Wredundant-repetitions -antsy -fbungee-jump -fexpensive-operations [cf. -fexpensive-optimizations] -fextra-strength [must be a negative form of -fstrength-reduce] -fkeep-programmers-inline [cf. the existing option -fkeep-inline-functions] -fjesus-saves [cf. the existing option -fcaller-saves] -fno-peeping-toms [cf. the existing option -fno-peephole] -fruit-roll-ups [cf. the existing option -funroll-loops] -fshort-enough -mno-dialogue -vomit-frame-pointer

1 0