July 2002 - Haskell-Cafe

Fw: 2 Positions
by Manuel M. T. Chakravarty 06 Jul '02

06 Jul '02

Not 100% Haskell-related, but I thought some people on this list might be interested in these two open positions at UNSW. Manuel

1 0

Is there any algorithms for solving equation systems
by Daniel Andersson 04 Jul '02

04 Jul '02

Hi I looking for algorithms for solving equation systems and wonder if there is anyone that has seen an algorithm, either a numerical or an analytical, for solving equation systems in haskell. thanks Daniel _____________________________________________________ Följ VM på nära håll på Yahoo!s officielle VM-sajt www.yahoo.se/vm2002 Håll dig ajour med nyheter och resultat, med vinnare och förlorare...

1 0

Re: Writing a counter function
by Jon Cast 02 Jul '02

02 Jul '02

Mark Carroll <mark(a)chaos.x-philes.com> wrote: > On Sat, 29 Jun 2002, Samuel E. Moelius III wrote: > (snip) > > Here's another not-exactly-what-you-wanted solution. :) > (snip) > Do any of the experimental extensions to Haskell allow a > what-he-wanted solution? I couldn't arrange one in H98 without > something having an infinitely-recursive type signature. That's because the problem requires an infinitely-recursive type. > I'm sure it would have been easy in Lisp, and he already gave a Perl > equivalent, That's because both Lisp and Perl are weakly typed. Haskell is strongly typed. Consider Lisp: (defun self-apply (f) "Apply F to itself." (f f)) No problem (and I'm sure you can pull the same trick off in Perl). Consider Haskell: self-apply f = f f The *typing algorithm* (the thing that didn't complain in Lisp) proceeds roughly as follows: f is applied to at least one argument, so f must have type a -> b. Therefore, f's argument (f) must have type a. So, we conclude: f :: a -> b f :: a But f can only have one type, so we set its types equal: a = a -> b This is clearly recursive, right? > so I'm wondering if it could be at all sane for Haskell to allow > such stuff Sure. All it has to do is: 1. Create its own newtype in response to such things as `self-apply' above. 2. Ensure that self-apply f = f f and self-apply' g = g g have the same type. I would *love* to hear ideas on how to do that, but it's difficult. > and if Haskell is somehow keeping us on the straight and narrow by > disallowing the exact counter that was originally requested. Well, it's a more general problem than the `exact counter'. And, yes, Haskell is erring on the side of safety here; there's a reason it's called a ``statically typed language''. > The beauty of his request was that it was so simple and seemed to > make sense; I went ahead and tried to fulfill it before realising I > couldn't do it either. Well, it makes sense, yes. But I think learning to manually `unify' these things (add a newtype) is not hard, and probably useful --- Haskell is not the only statically-typed language out there. Learn how to solve this problem, and you understand the problem, the solution, typing, and life in general :) > -- Mark Jon Cast

3 2

Writing a counter function
by Shlomi Fish 01 Jul '02

01 Jul '02

I'm trying to write a counter function that would return a tuple whose first element is the current value and whose second element is a new counter. The following line: counter n = (n,(counter (n+1))) Generates the following error on Hugs and a similar one with ghci: ERROR "counter.hs":6 - Type error in function binding *** Term : counter *** Type : a -> (a,b) *** Does not match : a -> b *** Because : unification would give infinite type Is there any way to do it? I tried using data, type and newtype and none of them worked. Regards, Shlomi Fish ---------------------------------------------------------------------- Shlomi Fish shlomif(a)vipe.technion.ac.il Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: shlomif(a)iglu.org.il He who re-invents the wheel, understands much better how a wheel works.

11 20

Defining instances of superclasses
by Zdenek Dvorak 01 Jul '02

01 Jul '02

Hello. I've got the following problem: I have class Structure, that says that its members have some internal parts that can be read from/written to Strings: >data StrItem a=forall b c.(Show b,Parse c)=>StrItem String (a->b) (a->c->a) > >class Structure a where > strName::a->String > strEmpty::a > strItems::[StrItem a] Now I would like to use it to create instances of Show and Parse (and perhaps others (for input/output from various formats, ...)). The approaches I have tried: 1) >instance Structure a => Show a where > showsPrec _ w = > showsStruct (strName w) (map showsPair strItems) > where > showsPair (StrItem fName fGet _)=(fName,shows $ fGet w) This is nice, but it only works in ghc with allowed overlapping and undecidable instances. It may not seem too important, when I use existential types anyway, but existential types are supported by at least one more implementation (hugs) and they seem to me to be a well defined extension that has good chances to become part of standard Haskell later; handling of overlapping and undecidable instances in ghc seems quite too much ad-hoc and experimental for me. 2) >newtype Str a=Str a >instance Structure a => Show (Str a) where > showsPrec _ (Str w) = > showsStruct (strName w) (map showsPair strItems) > where > showsPair (StrItem fName fGet _)=(fName,shows $ fGet w) This seems to be a standard way how to do it. The problem is, that I don't get Show instance for a, but for isomorphic type Str a; this is a bit annoying when I want to use it; also I may no longer use deriving Show on types containing such structure. Is there some better way how to do this? Zdenek Dvorak _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

1 0