August 2001 - Haskell-Cafe

Modular arithmetic
by Dylan Thurston 21 Aug '01

21 Aug '01

They said it couldn't be done! They said Haskell didn't have dependent types! Here's a way to mimic dependent types using existential types, illustrated by an implementation of modular arithmetic. To try it out, load modulus.hs and try something like Modulus> inModulus (mkModulus (1234567890123::Integer)) (^98765432198765) 2 1160454313058 to compute 2 to the 98765432198765'th power modulo 1234567890123. The key is the definitions at the top of TypeVal.hs: > class TypeVal a t | t -> a where > -- typeToVal should ignore its argument. > typeToVal :: t -> a > > data Wrapper a = forall t . (TypeVal a t) => Wrapper t > > class ValToType a where > valToType :: a -> Wrapper a `valToType' takes a value `x' and returns a (wrapped version of a) fake value in a new type; from the new type, `x' can be recovered by applying typeToVal. This code works under ghc. It uses existentially quantified data constructors, scoped type variables, and explicit universal quantification. Enjoy, Dylan Thurston

1 1

Singular Type Constructor
by Ashley Yakeley 20 Aug '01

20 Aug '01

Consider: -- data T a = T -- Is there anything in the Prelude or a standard library that looks like this? Should there be? What should it be called? 'Singleton'? 'Reified'? 'T'? I looked but couldn't find anything. Such a simple type constructor is in fact very useful when you need to pass types around to disambiguate class instances. For instance: -- class HasTypeName t where getTypeName :: T t -> String instance HasTypeName Int where getTypeName T = "Int" instance HasTypeName () where getTypeName T = "()" intName = getTypeName (T :: T Int) -- -- Ashley Yakeley, Seattle WA

3 2

deriving
by Mark Carroll 20 Aug '01

20 Aug '01

Does anyone know of any Haskell texts that introduce 'deriving' fairly comprehensively? All I've been able to find out from what I have is that your type can derive Eq, Ord, Show etc. and then they'll magically work as if you'd written the instance declarations yourself. I've no idea how you can make your own type classes that types can 'derive' from, etc. IYSWIM, or really what's going on at all. -- Mark

2 2

Re: Subtyping
by Mansour Al-Mutairi 20 Aug '01

20 Aug '01

Hi, I am a newbie but I think that what you are proposing can be simulated in haskell. It is like subclassing in OOP. You can create a new type that is an extension of the older one. Unlike OOP overloading, you will need to create a new function that can work on the new type. >data SomeObject = SomeInt Int | SomeString String | _ will become: data SomeObject = SomeInt Int | SomeString String >...later... > >data SomeObject |= SomeReal Double will become: data SomeObject2 = SO SomeObject | SomeReal Double >same :: SomeObject -> SomeObject -> Bool >same (SomeInt a) (SomeInt b) = a == b >same (SomeString a) (SomeString b) = a == b >same _ _ = False > >...later... > >same (SomeReal a) (SomeReal b) = a == b will become: same :: SomeObject -> SomeObject -> Bool same (SomeInt a) (SomeInt b) = a == b same (SomeString a) (SomeString b) = a == b ...later... same2 :: SomeObject2 -> SomeObject2 -> Bool same2 (SomeReal a) (SomeReal b) = a == b same2 x y = same x y tell me if I am wrong. thanks. Mansour Al-Mutairi :) _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

2 1

Re: trying to run programs
by Patrik Jansson 20 Aug '01

20 Aug '01

[I move this thread to haskell-cafe.] On Mon, 20 Aug 2001, Johansson Mikael wrote: > I'm starting up using a GHC-compiler and have successfully compiled a simple > "Hello World" program. Thanks for the responses. > Now I'm trying to use some simple programs from haskell.org/hugs but there are > problems. > > AnsiDemo.hs:10: Variable not in scope: `writeStr' > > It seems some object are missing. I have tried to find them > in ghc/lib/imports and others but haven't succeded. > Is there some libraries I need to run these hugs-files on > my ghc-compiler? AnsiDemo.hs imports some hugs-specific files (AnsiInteract.hs, ...) which are also available in the hugs distribution but (somewhat confusing for your use) not in the demos directory. [Maybe the hugs example suite could be transformed into a stand-alone Haskell example suite? Any takers?] If you have hugs installed, then the necessary files are in ../lib/hugs (seen from the demos directory). I think the files for AnsiDemo are propoer Haskell 98 and not using any hugs-extensions so it should work. (Using ghci-5.0 it "compiles" OK, but on my Solaris xterm the printing is delayed - that might work better under Window$.) For use with ghc the required files could either be copied/moved into the demos directory, or you could start ghc with -i../lib/hugs added to the command line (so that it searches theat directory as well). I attach a tarball with the directory tree including lib and demos from my installation of hugs. Good luck, Patrik Jansson

1 0

Need help to get GTK bindings working
by mgross＠dorsai.org 19 Aug '01

19 Aug '01

I've got ghc5 running, have downloaded all the documented bits and pieces for the GTK bindings, done the compiles, modifed the package.conf file (probably incorrectly, since I haven't been able to find complete documentation on the contents of that file), and am having a variety of difficulties--like reported missing exports (which aren't missing from the .hi file), etc. Would some kind soul out there be willing to do a bit of hand holding off list to get this thing working? After the job is done, we can post the results as instructions for others to follow. Thanks in advance. Murray Gross mgross(a)dorsai.org

2 1

Re: Subtyping
by Ashley Yakeley 18 Aug '01

18 Aug '01

At 2001-08-18 17:29, Mansour Al-Mutairi wrote: >data SomeObject2 = SO SomeObject | SomeReal Double ... >same2 :: SomeObject2 -> SomeObject2 -> Bool >same2 (SomeReal a) (SomeReal b) = a == b >same2 x y = same x y This won't help you if you already have modules that use 'SomeObject' and 'same'. In OOP you can extend a 'Base' class in module M1 with a 'Derived' class in module M2. M1 knows nothing about 'Derived', and yet code in M1 that manipulates 'Base' objects will be able to handle 'Derived' objects, since every 'Derived' object is also a 'Base' (upcasting). Furthermore it is possible for M2 to determine whether a 'Base' object from a function or structure in M1 is also a 'Derived' object and use it appropriately (downcasting). You can't do this in Haskell (or O'Haskell for that matter), though you could with extensible data-types: module M1 where data Base = _ foo :: Base -> Integer foo _ = 0 module M2 where data Derived = MyDerived Int Char data Base |= DerivedBase Derived foo (DerivedBase (MyDerived i _)) = i upcast :: Derived -> Base upcast = DerivedBase downcast :: Base -> Maybe Derived downcast (DerivedBase d) = Just d downcast _ = Nothing -- Ashley Yakeley, Seattle WA

1 0

Re: Subtyping
by Ashley Yakeley 18 Aug '01

18 Aug '01

At 2001-08-18 06:15, Marcin 'Qrczak' Kowalczyk wrote: >Later additions to the function would have to be restricted to match >at least one constructor defined in the current module, to make the >combined definition independent of the order of additions - modules >are by nature unordered. Agreed. >And something more - this is not enough for >unambiguous definition: > -- Base definition > foo :: SomeObject -> SomeObject -> Int > foo _ _ = 0 > -- Module 1 > foo (SomeInt a) _ = 1 > -- Module 2 > foo _ (SomeString a) = 2 > -- Which argument is evaluated as the first? > -- What is called for foo (SomeInt 0) (SomeString "")? The first argument would take priority. So Haskell would assemble these cases in this order: foo (SomeInt a) _ = 1 foo _ (SomeString a) = 2 foo _ _ = 0 If Module 2 included Module 1, it could do this: -- Module 2 foo _ (SomeString a) = 2 foo (SomeInt a) (SomeString a) = 2 In which case, the cases would be assembled in this order: foo (SomeInt a) (SomeString a) = 2 foo (SomeInt a) _ = 1 foo _ (SomeString a) = 2 foo _ _ = 0 -- Ashley Yakeley, Seattle WA

1 0

Re: Subtyping
by Marcin 'Qrczak' Kowalczyk 18 Aug '01

18 Aug '01

Sat, 18 Aug 2001 01:05:17 -0700, Ashley Yakeley <ashley(a)semantic.org> pisze: > One possible solution would be to extend Haskell with "open" > algebraic data types. > This seems to me straightforward, but perhaps not very useful unless > there's a way of declaring "generic" functions on these types that > can be extended somehow later: Indeed. Later additions to the function would have to be restricted to match at least one constructor defined in the current module, to make the combined definition independent of the order of additions - modules are by nature unordered. And something more - this is not enough for unambiguous definition: -- Base definition foo :: SomeObject -> SomeObject -> Int foo _ _ = 0 -- Module 1 foo (SomeInt a) _ = 1 -- Module 2 foo _ (SomeString a) = 2 -- Which argument is evaluated as the first? -- What is called for foo (SomeInt 0) (SomeString "")? > But would this sort of thing solve your problem? Yes, although now I think that this use would be equivalent to using Dynamic, only with a prettier syntax. There is a particular case which could make use of extensible functions and can't be simulated with Dynamic, but I would use a different solution anyway (the same as I would use now with Dynamic) - for speed. The situation is as follows: The interpreted language (BTW, designed and implemented purely for fun, no serious external reason) introduces the concept of type in the standard library. A type is represented as a symbol (term without arguments). Unique symbols are born by calling a builtin function, and obtaining bindings is generally associated with executing some code (like value bindings in ML). How a type is determined: - Function is called with a distinguished argument (Type) and is supposed to return its type. - Terms have types depending on their symbol, looked up in a dictionary. - Integers and strings have types Integer_t, String_t. Type are used to look up definitions of generic functions in dictionaries, usually depending on the first argument. There is also a dictionary of supertypes, so e.g. equality on Bool_t uses the implementation of equality on Term_t if not defined directly. Suppose that arbitrary foreign Haskell objects would be included in values, wrapped as Dynamic. How to determine the type of such an object? It's trivial to return a generic Haskell_t, but there is no way to make further classification otherwise than invoking foreign functions checking for particular Haskell types in sequence (the functions would have to be registered somehow). With open algebraic types it can be done. Just define a generic function for returning the type, and populate its definition in modules providing particular foreign object types. Fortunately it can be done better than both solutions and it's compatible with Dynamic. Just include a representation of type in the value, along with Dynamic holding the actual object. Since most actions on such object would begin with determining its type, it's good to have it ready instead of looking it up in a dictionary. It requires foresight that checking types of foreign objects will be needed, but well, I indeed know now that it's needed. And it's enough. Since type is used for classification to the granularity equivalent to Haskell types sitting inside the Dynamic, further dispatching can be done in the language proper, looking up the type in dictionaries, as for all its generic functions, and they will usually assume a concrete Haskell type inside the Dynamic. It happens that the language uses open algebraic types itself, only without static typechecking. All algebraic types are open: one can always register more symbols for a particular type, or produce functions which return such type for a Type request (it can be considered lying about their types). But expect that registering something non-standard as a Bool_t and passing it to functions expecting a Bool_t will usually surprise these functions and many of them will refuse to work. There is a continuum between making new types and using open algebraic types. Constructors for exceptions are born as other terms with unique symbols. You can either register them under a generic Exception_t type or give them new types; it doesn't matter for how they are caught if all these types use the same generic pattern matching implementation for Term_t. Either way you can implement patterns which perform matching in any fancy way (e.g. look up in a hierarchy of exception symbols they maintain). -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Subtyping
by Ashley Yakeley 18 Aug '01

18 Aug '01

At 2001-08-14 03:46, Marcin 'Qrczak' Kowalczyk wrote (on the Libraries list): >> I've noticed that the more I use Haskell, the less I miss >> subtyping... classes and "data" unions are almost always sufficient. > >They are sometimes a better match than subtyping (e.g. parametrizing >a gcd algorithm by a type) and sometimes they are not capable at all >(e.g. heterogeneous collections when the set of possible types is >open). I'm a big fan of Haskell's typing and I'm not a fan of OOP, >but Haskell is sometimes not as expressible as the OO way. One possible solution would be to extend Haskell with "open" algebraic data types. For instance: data SomeObject = SomeInt Int | SomeString String | _ ...later... data SomeObject |= SomeReal Double The "_" would mark a data type as 'open', and the "|=" syntax would be used to extend it in another module. This seems to me straightforward, but perhaps not very useful unless there's a way of declaring "generic" functions on these types that can be extended somehow later: same :: SomeObject -> SomeObject -> Bool same (SomeInt a) (SomeInt b) = a == b same (SomeString a) (SomeString b) = a == b same _ _ = False ...later... same (SomeReal a) (SomeReal b) = a == b -- this case needs to be "inserted" somehow But would this sort of thing solve your problem? -- Ashley Yakeley, Seattle WA

1 0