- Haskell-Cafe - Haskell.org

Revised numerical prelude, version 0.02
by Dylan Thurston 17 Feb '01

17 Feb '01

Here's a revision of the numerical prelude. Many thanks to all who helped. Changes include: * Removed "Powerful", replacing it with (^) in Num and (**) in Real. * Fixed numerous typos * Removed gcd and co. from Integral * Added shortcomings & limitation of scope * Added SmallIntegral, SmallReal * wrote skeleton VectorSpace, PowerSeries * Added framework to make it run under hugs. There are some usability issues. Any comments welcome! Best, Dylan Thurston

10 12

RE: Primitive types and Prelude shenanigans
by Simon Peyton-Jones 16 Feb '01

16 Feb '01

| On Mon, Feb 12, 2001 at 02:38:25PM -0800, William Lee Irwin III wrote: | > I had in mind looking within the compiler, actually. Where in the | > compiler? It's a big program, it might take me a while to do an | > uninformed search. I've peeked around a little bit and not gotten | > anywhere. | | If anyone else is pursuing thoughts along the same lines as I | am (and I | have suspicions), TysWiredIn.lhs appears quite relevant to the set of | primitive data types, though there is no obvious connection to the | module issue (PrelBase.Bool vs. Foo.Bool). PrelMods.lhs | appears to shed | more light on that issue in particular. $TOP/ghc/compiler/prelude/ was | the gold mine I encountered. Perhaps I should add something here. I'm very sympathetic to the idea of making it possible to do entirely without the standard Prelude, and to substitute a Prelude of one's own. The most immediate and painful stumbling block in Haskell 98 is that numeric literals, like 3, turn into (Prelude.fromInt 3), where "Prelude.fromInt" really means "the fromInt from the standard Prelude" regardless of whether the standard Prelude is imported scope. Some while ago I modified GHC to have an extra runtime flag to let you change this behaviour. The effect was that 3 turns into simply (fromInt 3), and the "fromInt" means "whatever fromInt is in scope". The same thing happens for - numeric patterns - n+k patterns (the subtraction is whatever is in scope) - negation (you get whatever "negate" is in scope, not Prelude.negate) (Of course, this is not Haskell 98 behaviour.) I think I managed to forget to tell anyone of this flag. And to my surprise I can't find it any more! But several changes I made to make it easy are still there, so I'll reinstate it shortly. That should make it easy to define a new numeric class structure. So much for numerics. It's much less obvious what to do about booleans. Of course, you can always define your own Bool type. But we're going to have to change the type that if-then-else uses, and presumably guards too. Take if-then-else. Currently it desugars to case e of True -> then-expr False -> else-expr but your new boolean might not have two constructors. So maybe we should simply assume a function if :: Bool -> a -> a -> a and use that for both if-then-else and guards.... I wonder what else? For example, can we assume that f x | otherwise = e is equivalent to f x = e That is, "otherwise" is a guard that is equivalent to the boolean "true" value. ("otherwise" might be bound to something else if you import a non-std Prelude.) If we don't assume this, we may generate rather bizarre code: f x y | x==y = e1 | otherwise = e2 ===> f x y = if (x==y) e1 (if otherwise e2 (error "non-exhaustive patterns for f")) And we'll get warnings from the pattern-match compiler. So perhaps we should guarantee that (if otherwise e1 e2) = e1. You may say that's obvious, but the point is that we have to specify what can be assumed about an alien Prelude. Matters get even more tricky if you want to define your own lists. There's quite a lot of built-in syntax for lists, and type checking that goes with it. Last time I thought about it, it made my head hurt. Tuples are even worse, because they constitute an infinite family. The bottom line is this. a) It's desirable to be able to substitute a new prelude b) It's not obvious exactly what that should mean c) And it may not be straightforward to implement It's always hard to know how to deploy finite design-and-implementation resources. Is this stuff important to a lot of people? If you guys can come up with a precise specification for (b), I'll think hard about how hard (c) really is. Simon

5 9

Re: Just for your fun and horror
by C.Reinke 16 Feb '01

16 Feb '01

> `return' in Haskell vs `return' in C,... Unless you're one of Asimov's technicians of eternity, it is a bit difficult to change the history of programming languages, and assuming that the students pay for the opportunity to learn, you can't really fire them either.. but I agree with Mathias' suggestion to go from the specific to the general. Before anyone complains that abstract and generalised concepts are so much more important and powerful that specific and simplified instances - if you believe this, you will also agree that giving students a chance to learn the general process of abstraction for themselves is more important and empowering than teaching them some specific abstractions. (I'm not sure whether it is even possible to reach all students in a course, but I will certainly not recommend to give up trying;-) One way to look at the problem is that some of your students have concrete experience with `return' in different contexts, and that Haskell tries to make different things look similar here. You say "we worked with monads for several weeks" but, you being yourself, this was probably at a fairly abstract and general level, right? My suggestion is to give your students some concrete experience to counter the one they bring into your course, by introducing the abstract monads via an intermediate step of concrete representations. As you're teaching programming language implementation anyway, why not have an algebraic datatype with return and bind *constructors*, together with some explicit *interpreters* (plural) for the language of structures built from those constructors (even as student exercises)? Perhaps we can gain a better understanding of the student perspective if we compare the situation with lists or other data structures: do we start teaching their folds and the fold-representation of data structures right away, or do we start with concrete intermediate structures, and move on to folds and deforestation later? Of course, with a concrete representation of monads, it is difficult to hold up the law, so after this intermediate step (in which students get their hands on `return' et.al., and in which interpreters can interpret `return a' in any way they please), one can move on to an abstract data type of monads. After all, that's what abstract data types are there for. Hth, Claus

1 0

Re: Just for your fun and horror
by Steinitz, Dominic J 16 Feb '01

16 Feb '01

I always liked unit rather than return. Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

Re: Primitive types and Prelude shenanigans
by Ketil Malde 16 Feb '01

16 Feb '01

William Lee Irwin III <wli(a)holomorphy.com> writes: > Some analysis of the value of the literal would need to be > incorporated so that something like the following happens: > literal "0" gets mapped to zero :: AdditiveMonoid t => t > literal "1" gets mapped to one :: MultiplicativeMonoid t => t Indeed. Is it a reasonable assumption that all values of literal "0" are intended to be the additive identity element? How about "1", might we not have it as a successor element in a group, where multiplication isn't defined? I guess other behaviour (e.g. using implicit fromInteger) assumes even more about the classes that can be represented by literal numbers, so it appears this would be an improvement, if it is at all workable. > literal "5" gets mapped to (fromPositiveInteger 5) Is something like (fromInteger 5) *> one (where *> is Module scalar multiplication from the left? Could we avoid having lots and lots of from* functions? I guess having to declare any datatype as Module is as bad as the explicit conversion functions... Anyway, I like it, especially the zero and one case. > I think Dylan Thurston's proposal is probably the best starting point > for something that should really get support. Indeed. How far are we from being able to import it, e.g. with "import DTlude as Prelude" or whatever mechanism, so that we can start to play with it, and see how it works out in practice? -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

RE: need help w/ monad comprehension syntax
by Konst Sushenko 16 Feb '01

16 Feb '01

thanks, did not know that. the articles that i read are outdated in that respect... using the "do" notation is just fine. with the list notation not working i thought that i musunderstand something about monads. ;-) konst -----Original Message----- From: Tom Pledger [mailto:Tom.Pledger@peace.com] Sent: Thursday, February 15, 2001 5:22 PM To: haskell-cafe(a)haskell.org Subject: need help w/ monad comprehension syntax Konst Sushenko writes: | what am i missing? : | > --g :: State String Char | > g = [ x | x <- return 'a' ] Hi. The comprehension syntax used to be for monads in general (in Haskell 1.4-ish), but is now (Haskell 98) back to being specific to lists. Does it help if you use do-notation instead? Regards, Tom _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

need help w/ monad comprehension syntax
by Konst Sushenko 16 Feb '01

16 Feb '01

hello, i am having trouble getting my program below to work. i think i implemented the monad methods correctly, but the function 'g' does not type as i would expect. Hugs thinks that it is just a list (if i remove the explicit typing). i want it to be functionally identical to the function 'h'. what am i missing? thanks konst > newtype State s a = ST (s -> (a,s)) > > unST (ST m) = m > > instance Functor (State s) where > fmap f m = ST (\s -> let (a,s') = unST m s in (f a, s')) > > instance Monad (State s) where > return a = ST (\s -> (a,s)) > m >>= f = ST (\s -> let (a,s') = unST m s in unST (f a) s') > > --g :: State String Char > g = [ x | x <- return 'a' ] > > h :: State String Char > h = return 'a'

2 1

Downloading Hugs
by zulf jafferi 15 Feb '01

15 Feb '01

hi, I tried to download the Hugs 98.after downloading Hugs 98,when i try to click on the Hugs icon it gives me an error saying COULD NOT LOAD PRELUDE.i am using Windows 2000. I would be much obliged if you could help me solve the problem. cheers!! _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

1 0

Re: framework for composing monads?
by Jan Kort 15 Feb '01

15 Feb '01

Andy Gill's Monad Template Library is good for that, but the link from the Haskell library page is broken: http://www.cse.ogi.edu/~andy/monads/doc.htm Jan

1 0

RE: Primitive types and Prelude shenanigans
by Simon Marlow 15 Feb '01

15 Feb '01

> (Of course, this is not Haskell 98 behaviour.) I think I > managed to forget > to tell anyone of this flag. And to my surprise I can't find > it any more! It's lumped in with -fno-implicit-prelude, but the extra functionality isn't supported in 4.08.2 (but hopefully will be in 5.00). Cheers, Simon

1 0

RE: Typing units correctly
by Andrew Kennedy 14 Feb '01

14 Feb '01

To be frank, the poster that you cite doesn't know what he's talking about. He makes two elementary mistakes: (a) attempting to encode dimension/unit checking in an existing type system; (b) not appreciating the need for parametric polymorphism over dimensions/units. As others have pointed out, (a) doesn't work because the algebra of units of measure is not free - units form an Abelian group (if integer exponents are used) or a vector space over the rationals (if rational exponents are used) and so it's not possible to do unit-checking by equality-on-syntax or unit-inference by ordinary syntactic unification. Furthermore, parametric polymorphism is essential for code reuse - one can't even write a generic squaring function (say) without it. Best to ignore the poster and instead read the papers that contributors to this thread have cited :-) To turn to the original question, I did once give a moment's thought to the combination of type classes and types for units-of-measure. I don't think there's any particular problem: units (or dimensions) are a new "sort" or "kind", just as "row" is in various proposals for record polymorphism in Haskell. As long as this is tracked through the type system, everything should work out fine. Of course, I may have missed something, in which case I'd be very interested to know about it. - Andrew Kennedy. > -----Original Message----- > From: andrew(a)andrewcooke.free-online.co.uk > [mailto:andrew@andrewcooke.free-online.co.uk] > Sent: Wednesday, February 14, 2001 5:02 PM > To: haskell-cafe(a)haskell.org > Subject: Re: Typing units correctly > > > > Hi, > > I don't know if this is useful, but in response to a link to that > article that I posted on Lambda, someone posted a link arguing that > such an approach (at least in Ada) was impractical. To be honest, I > don't find it very convincing, but I haven't been following this > discussion in detail. It might raise some problems you have not > considered. > > Anyway, if you are interested, it's all at > http://lambda.weblogs.com/discuss/msgReader$818 > > Apologies if it's irrelevant or you've already seen it, > Andrew > > On Mon, Feb 12, 2001 at 01:51:54PM -0500, Dylan Thurston wrote: > [...] > > The papers I could find (e.g., > > http://citeseer.nj.nec.com/kennedy94dimension.html, > "Dimension Types") > > mention extensions to ML. I wonder if it is possible to work within > > the Haskell type system, which is richer than ML's type system. > [...] > > -- > http://www.andrewcooke.free-online.co.uk/index.html >

2 1

A sample revised prelude for numeric classes
by Dylan Thurston 14 Feb '01

14 Feb '01

I've started writing up a more concrete proposal for what I'd like the Prelude to look like in terms of numeric classes. Please find it attached below. It's still a draft and rather incomplete, but please let me know any comments, questions, or suggestions. Best, Dylan Thurston

10 24

Primitive types and Prelude shenanigans
by William Lee Irwin III 14 Feb '01

14 Feb '01

It seems to me that some additional primitive types would be useful, most of all a natural number type corresponding to an arbitrary- precision unsigned integer. Apparently Integer is defined in terms of something else in the GHC Prelude, what else might be needed to define it? Some of my other natural thoughts along these lines are positive reals and rationals, and nonzero integers. Rationals I have an idea that they might be similar to natural numbers and nonzero integers, though the nonzero and positive reals pose some nasty problems (try underflow). Would such machinations be useful to anyone else? Further down this line, I've gone off and toyed with Bool, and discovered GHC doesn't like it much. Is there a particular place within GHC I should look to see how the primitive Boolean type, and perhaps other types are handled? I'd also like to see where some of the magic behind the typing of various other built-in constructs happens, like list comprehensions, tuples, and derived classes. Cheers, Bill

2 3

Re: Revamping the numeric classes
by Dylan Thurston 13 Feb '01

13 Feb '01

Other people have been making great points for me. (I particularly liked the example of Dollars as a type with addition but not multiplication.) One point that has not been made: given a class setup like class Additive a where (+) :: a -> a -> a (-) :: a -> a -> a negate :: a -> a zero :: a class Multiplicative a where (*) :: a -> a -> a one :: a class (Additive a, Multiplicative a) => Num a where fromInteger :: Integer -> a then naive users can continue to use (Num a) in contexts, and the same programs will continue to work.[1] (A question in the above context is whether the literal '0' should be interpreted as 'fromInteger (0::Integer)' or as 'zero'. Opinions?) On Wed, Feb 07, 2001 at 06:27:02PM +1300, Brian Boutel wrote: > * Haskell equality is a defined operation, not a primitive, and may not > be decidable. It does not always define equivalence classes, because > a==a may be Bottom, so what's the problem? It would be a problem, > though, to have to explain to a beginner why they can't print the result > of a computation. Why doesn't your argument show that all types should by instances of Eq and Show? Why are numeric types special? Best, Dylan Thurston Footnotes: [1] Except for the lack of abs and signum, which should be in some other class. I have to think about their semantics before I can say where they belong.

9 30

RE: Revamping the numeric HUMAN ATTITUDE
by Simon Peyton-Jones 13 Feb '01

13 Feb '01

| I'm seeing a bit of this now, and the error messages GHC spits out | are hilarious! e.g. | | My brain just exploded. | I can't handle pattern bindings for | existentially-quantified constructors. | | and | | Couldn't match `Bool' against `Bool' | Expected type: Bool | Inferred type: Bool | The first of these is defensible, I think. It's not at all clear (to me anyway) what pattern bindings for existentially-quantified constructors should mean. The second is plain bogus. GHC should never give a message like that. Which version of the compiler are you using? If you can send a small example I'll try it on the latest compiler. Simon

1 0

Re: A sample revised prelude for numeric classes
by Ashley Yakeley 12 Feb '01

12 Feb '01

At 2001-02-11 14:42, Dylan Thurston wrote: >I've started writing up a more concrete proposal for what I'd like the >Prelude to look like in terms of numeric classes. Please find it >attached below. It's still a draft and rather incomplete, but please >let me know any comments, questions, or suggestions. Apologies if this has been discussed and I missed it. When it comes to writing a 'geek' prelude, what was wrong with the Basic Algebra Proposal found in <ftp://ftp.botik.ru/pub/local/Mechveliani/basAlgPropos/> ? Perhaps it could benefit from multi-parameter classes? -- Ashley Yakeley, Seattle WA

5 5

Re: A sample revised prelude for numeric classes
by Ashley Yakeley 12 Feb '01

12 Feb '01

At 2001-02-11 21:18, Tom Pledger wrote: >The main complication is that the type system needs to deal with >integer exponents of dimensions, if it's to do the job well. Very occasionally non-integer or 'fractal' exponents of dimensions are useful. For instance, geographic coastlines can be measured in km ^ n, where 1 <= n < 2. This doesn't stop the CIA world factbook listing all coastline lengths in straight kilometres, however. More unit weirdness occurs with logarithms. For instance, if y and x are distances, log (y/x) = log y - log x. Note that 'log x' is some number + log (metre). Strange, huh? Interestingly, in C++ you can parameterise types by values. For instance: -- // Mass, Length and Time template <long M,long L,long T> class Unit { public: double mValue; inline explicit Unit(double value) { mValue = value; } }; template <long M,long L,long T> Unit<M,L,T> operator + (Unit<M,L,T> a,Unit<M,L,T> b) { return Unit<M,L,T>(a.mValue + b.mValue); } template <long Ma,long La,long Ta,long Mb,long Lb,long Tb> Unit<Ma+Mb,La+Lb,Ta+Tb> operator * (Unit<Ma,La,Ta> a,Unit<Mb,Lb,Tb> b) { return Unit<Ma+Mb,La+Lb,Ta+Tb>(a.mValue * b.mValue); } // etc. int main() { Unit<0,1,0> oneMetre(1); Unit<0,1,0> twoMetres = oneMetre + oneMetre; Unit<0,2,0> oneSquareMetre = oneMetre * oneMetre; } -- Can you do this sort of thing in Haskell? -- Ashley Yakeley, Seattle WA

4 3

Re: A sample revised prelude for numeric classes
by Ketil Malde 12 Feb '01

12 Feb '01

qrczak(a)knm.org.pl (Marcin 'Qrczak' Kowalczyk) writes: >> Why do you stop at allowing addition on Dollars and not include >> multiplication by a scalar? > Perhaps because there is no good universal type for (*). > Sorry, it would have to have a different symbol. Is this ubiquitous enough that we should have a *standardized* different symbol? Any candidates? >> Having Units as types, with the idea of preventing adding Apples to >> Oranges, or Dollars to Roubles, is a venerable idea, but is not in >> widespread use in actual programming languages. Why not? > It does not scale to more general cases. (m/s) / (s) = (m/s^2), > so (/) would have to have the type (...) => a -> b -> c, which is not > generally usable because of ambiguities. Haskell's classes are not > powerful enough to define full algebra of units. While it may not be in the language, nothing's stopping you from - and some will probably encourage you to - implementing e.g. financial libraries with different data types for different currencies. Which I think is a better way to handle it, since when you want m to be divisible by s is rather application dependent. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 1

Show, Eq not necessary for Num [Was: Revamping the numeric classes]
by Patrik Jansson 11 Feb '01

11 Feb '01

{I'm diverting this discussion to haskell-cafe.} [I am not sure a more mathematically correct numeric class system is suitable for inclusion in the language specification of Haskell (a library would certainly be useful though). But this is not my topic in this letter.] On Wed, 7 Feb 2001, Brian Boutel wrote: > * Haskell equality is a defined operation, not a primitive, and may not > be decidable. It does not always define equivalence classes, because > a==a may be Bottom, so what's the problem? It would be a problem, > though, to have to explain to a beginner why they can't print the result > of a computation. The fact that equality can be trivially defined as bottom does not imply that it should be a superclass of Num, it only explains that there is an ugly way of working around the problem. Neither is the argument that the beginner should be able to print the result of a computation a good argument for having Show as a superclass. A Num class without Eq, Show as superclasses would only mean that the implementor is not _forced_ to implement Eq and Show for all Num instances. Certainly most instances of Num will still be in both Show and Eq, so that they can be printed and shown, and one can easily make sure that all Num instances a beginner encounters would be such. As far as I remember from the earlier discussion, the only really visible reason for Show, Eq to be superclasses of Num is that class contexts are simpler when (as is often the case) numeric operations, equality and show are used in some context. f :: Num a => a -> String -- currently f a = show (a+a==2*a) If Show, Eq, Num were uncoupled this would be f :: (Show a, Eq a, Num a) => a -> String But I think I could live with that. (In fact, I rather like it.) Another unfortunate result of having Show, Eq as superclasses to Num is that for those cases when "trivial" instances (of Eq and Show) are defined just to satisfy the current class systems, the users have no way of supplying their own instances. Due to the Haskell rules of always exporting instances we have that if the Num instance is visible, so are the useless Eq and Show instances. In the uncoupled case the users have the choice to define Eq and Show instances that make sense to them. A library designer could provide the Eq and Show instances in two separate modules to give the users maximum flexibility. /Patrik Jansson

9 12

Re: Show, Eq not necessary for Num [Was: Revamping the numeric classes]
by Ketil Malde 11 Feb '01

11 Feb '01

Brian Boutel <brian(a)boutel.co.nz> writes: >> The fact that equality can be trivially defined as bottom does not imply >> that it should be a superclass of Num, it only explains that there is an >> ugly way of working around the problem. > There is nothing trivial or ugly about a definition that reflects > reality and bottoms only where equality is undefined. I think there is. If I design a class and derive it from Num with (==) is bottom, I am allowed to apply to it functions requiring a Num argument, but I have no guarantee it will work. The implementor of that function can change its internals (to use (==)), and suddenly my previously working program is non-terminating. If I defined (==) to give a run time error, it'd be a bit better, but I'd much prefer the compiler to tell me about this in advance. > Of course, if you do not need to apply equality to your "numeric" type > then having to define it is a waste of time, but consider this: It's not about "needing to apply", but about finding a reasonable definition. > - Having a class hierarchy at all (or making any design decision) > implies compromise. I think the argument is that we should move Eq and Show *out* of the Num hierarchy. Less hierarchy - less compromise. > - The current hierarchy (and its predecessors) represent a reasonable > compromise that meets most needs. Obviously a lot of people seem to think we could find compromises that are more reasonable. > - Users have a choice: either work within the class hierarchy and > accept the pain of having to define things you don't need in order > to get the things that come for free, Isn't it a good idea to reduce the amount of pain? > or omit the instance declarations and work outside the hierarchy. In > that case you will not be able to use the overloaded operator > symbols of the class, but that is just a matter of concrete syntax, > and ultimately unimportant. I don't think syntax is unimportant. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

5 10

Mondrian question
by Bill Halchin 10 Feb '01

10 Feb '01

Hello, Is this the right place to ask Mondrian questions? I will assume so. Is Mondrian only meant to work with .NET?? If so, what good is it as an Internet scripting language? I.e. what good is it as a language if it only runs in Microsoft's .NET environment?? I tried to download but I found I would have to have Win2000 installed. I want to run on Linux. Regards, Bill Halchin _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

Re: Revamping the numeric classes
by Ketil Malde 10 Feb '01

10 Feb '01

Dylan Thurston <dpt(a)math.harvard.edu> writes: > On Wed, Feb 07, 2001 at 01:57:41PM -0500, Dylan Thurston wrote: > > ... One point that has not been made: given a class > > setup like > > <deleted> > > then naive users can continue to use (Num a) in contexts, and the same > > programs will continue to work. > I take that back. Instance declarations would change, so this isn't > a very conservative change. Would it be a terribly grave change to the language to allow leaf class instance declarations to include the necessary definitions for dependent classes? E.g. class foo a where f :: ... class (foo a) => bar a where b :: ... instance bar T where f = ... b = ... -kzm -- If I haven't seen further, it is by standing in the footprints of giants

4 5

RE: Haskell Implemetors Meeting
by Simon Peyton-Jones 10 Feb '01

10 Feb '01

GHC transforms Haskell into "Core", which is roughly the second-order lambda calculus, augmented with let(rec), case, and constructors. This is an a small explicitly-typed intermediate language, in contrast to Haskell which is a very large, implicitly typed language. Getting from Haskell to Core is a lot of work, and it might be useful to be able to re-use that work. Andrew's proposal (which he'll post to the Haskell list) will define exactly what "Core" is. Simon | -----Original Message----- | From: Timothy Docker [mailto:timd@macquarie.com.au] | Sent: 05 February 2001 22:16 | To: haskell-cafe(a)haskell.org | Subject: Haskell Implemetors Meeting | | | | > We agreed that it would be a Jolly Good Thing if GHC could | > be persuaded to produce GHC-independent Core output, | > ready to feed into some other compiler. For example, | > Karl-Filip might be able to use it. | > ANDREW will write a specification, and implement it. | | A quick question. What is meant by "Core output"? Subsequent posts | seem to suggest this is some "reduced Haskell", in which full Haskell | 98 can be expressed. Am I completely off beam here? | | Tim Docker | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe |

2 1

Re: 'Convertible' class?
by Dylan Thurston 09 Feb '01

09 Feb '01

You make some good arguments. Thanks. Let me ask about a few of them. On Thu, Feb 08, 2001 at 04:06:24AM +0000, Marcin 'Qrczak' Kowalczyk wrote: > Wed, 7 Feb 2001 15:43:59 -0500, Dylan Thurston <dpt(a)math.harvard.edu> pisze: > > > class Convertible a b where > > convert :: a -> b > > > > So, e.g., fromInteger and fromRational could be replaced with > > convert. (But if you did the same thing with toInteger and toRational > > as well, you run into problems of overlapping instances. > > ... > And convert cannot be a substitute for fromIntegral/realToFrac, > because it needs a definition for every pair of types. Right. Those could still be defined as appropriately typed versions of 'convert . convert'. > You can put Num a in some instance's context, but you can't > put Convertible Integer a. It's because instance contexts must > constrain only type variables, which ensures that context reduction > terminates (but is sometimes overly restrictive). There is ghc's > flag -fallow-undecidable-instances which relaxes this restriction, > at the cost of undecidability. Ah! Thanks for reminding me; I've been using Hugs, which allows these instances. Is there no way to relax this restriction while maintaining undecidability? Best, Dylan Thurston

1 1

RE: GHC Core output
by Andrew Tolmach 09 Feb '01

09 Feb '01

Timothy Docker [mailto:timd@macquarie.com.au] writes: > > > We agreed that it would be a Jolly Good Thing if GHC could > > be persuaded to produce GHC-independent Core output, > > ready to feed into some other compiler. For example, > > Karl-Filip might be able to use it. > > ANDREW will write a specification, and implement it. > > A quick question. What is meant by "Core output"? Subsequent posts > seem to suggest this is some "reduced Haskell", in which full Haskell > 98 can be expressed. Am I completely off beam here? > Not at all. "Core" is an intermediate language used internally by the GHC compiler. It does indeed resemble a reduced Haskell (but with explicit higher-order polymorphic types) and GHC translates full Haskell 98 into it. Currently Core has no rigorously defined external representation, although by setting certain compiler flags, one can get a (rather ad-hoc) textual representation to be printed at various points in the compilation process. (This is usually done to help debug the compiler). What we hope to do is: - provide a formal definition of Core's external syntax; - give a precise definition of its semantics (both static and dynamic); - modify GHC to produce external Core files, if so requested, at one or more useful points in the compilation sequence -- e.g., just before optimization, or just after. - modify GHC to accept external Core files in place of Haskell source files, again at one or more useful points. The first three facilities will let one couple GHC's front-end (parser, type-checker, etc.), and optionally its optimizer, with new back-end tools. Adding the last facility will let one implement new Core-to-Core transformations in an external tool and integrate them into GHC. It will also allow new front-ends to generate Core that can be fed into GHC's optimizer or back end; however, because there are many (undocumented) idiosynracies in the way GHC produces Core from source Haskell, it will be hard for an external tool to produce Core that can be integrated with GHC-produced core (e.g., for the Prelude), and we don't aim to support this.

2 1

RE: Revamping the numeric classes
by Peter Douglass 08 Feb '01

08 Feb '01

Marcin Kowalczyk wrote: > Wed, 7 Feb 2001 16:17:38 -0500, Peter Douglass > <peterd(a)availant.com> pisze: > > > What I have in mind is to remove division by zero as an untypable > > expression. The idea is to require div, /, mod to take > NonZeroNumeric > > values in their second argument. NonZeroNumeric values > could be created by > > functions of type: > > Number a => a -> Maybe NonZeroNumeric > > or something similar. > > IMHO it would be impractical. > The first part of my question (not contained in your reply) is whether it is feasible to disable a developer's access to the "unsafe" numerical operations. Whether or not an individual developer chooses to do so is another matter. > Often I know that the value is non-zero, but it is not > statically determined, If you "know" the value is non-zero before run-time, then that is statically determined. Otherwise, you don't "know" that. > so it would just require uglification by > doing that conversion and then coercing Maybe NonZeroNumeric to > NonZeroNumeric. Ugliness is in the eye of the beholder I suppose. For some applications, every division should be preceded by an explicit test for zero, or the denominator must be "known" to be non-zero by the way in which it was created. Forcing a developer to extract a NonZeroNumeric value from a Maybe NonZeroNumeric value seems equivalent to me. > It's bottom anyway when the value is 0, but bottom > would come from Maybe coercion instead of from quot, so it only gives > a worse error message. > It is possible that the developer writes a function which returns a nonZeroNumeric value which actually has a value of zero. However, the value of requiring division to have a nonZeroNumeric denominator is to catch at compile time the "error" of failing to scrutinize (correctly or incorrectly) for zero. For most commercial software, the quality of run-time error messages is far less important than their absence. > It's so easy to define partial functions that it would not buy much > for making it explicit outside quot. > > Haskell does not have subtypes so a coercion from NonZeroNumeric to > plain Numbers would have to be explicit as well, even if logically > it's just an injection. If one is aiming to write code which cannot fail at run-time, then extra work must be done anyway. The only question is whether the language will support such a discipline. > Everybody assumes that quot has a symmetric > type as in all other languages, but in your proposal quot's arguments > come from completely disjoint worlds. If it is optional but not required that a developer may disable unsafe division, then developers who expect arithmetic to work in the usual way will not be disappointed. > Moreover, 1/0 is defined on IEEE Doubles (e.g. in ghc): infinity. This solution doesn't always help with code safety. Thanks for the response. --PeterD

2 1

Please help me
by FAIZAN RAZA 08 Feb '01

08 Feb '01

Hello Please help me to solve this questions Question Cartesian Product of three sets, written as X x Y x Z is defined as the set of all ordered triples such that the first element is a member of X, the second is member of Y, and the thrid member of set Z. write a Haskell function cartesianProduct which when given three lists (to represent three sets) of integers returns a list of lists of ordered triples. For examples, cartesianProduct [1,3][2,4][5,6] returns [[1,2,5],[1,2,6],[1,4,5],[1,4,6],[3,2,5],[3,2,6],[3,4,5],[3,4,6]] Please send me reply as soon as possible Ok I wish you all the best of luck

1 0

RE: Please help me
by Chris Angus 08 Feb '01

08 Feb '01

Faizan, A clue is to use list comprehensions (which are very like ZF set notation) First think how you would define a cartesian product in set notation X x Y x Z = {(x,y,z) | ...} and then think how this is written in list comprehension notation Chris > -----Original Message----- > From: FAIZAN RAZA [mailto:k19990158@192.168.1.4] > Sent: 08 February 2001 13:49 > To: haskell-cafe(a)haskell.org > Subject: Please help me > > > Hello > > > Please help me to solve this questions > > > Question > > Cartesian Product of three sets, written as X x Y x Z is > defined as the set > of all ordered triples such that the first element is a > member of X, the > second is member of Y, and the thrid member of set Z. write a Haskell > function cartesianProduct which when given three lists (to > represent three > sets) of integers returns a list of lists of ordered triples. > > For examples, cartesianProduct [1,3][2,4][5,6] returns > [[1,2,5],[1,2,6],[1,4,5],[1,4,6],[3,2,5],[3,2,6],[3,4,5],[3,4,6]] > > > > Please send me reply as soon as possible > > Ok > > I wish you all the best of luck > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Re: Please help me
by Ashley Yakeley 08 Feb '01

08 Feb '01

At 2001-02-08 02:04, Ashley Yakeley wrote: >That's easy. Just define 'product' as a function that finds the cartesian >product of any number of lists, and then once you've done that you can >apply it to make the special case of three items like this: > >cartesianProduct a b c = product [a,b,c] > >At least, that's how I would do it. eesh, 'product' is something else in the Prelude. Better call it 'cartprod' or something. -- Ashley Yakeley, Seattle WA

1 0

Re: Please help me
by Ashley Yakeley 08 Feb '01

08 Feb '01

At 2001-02-08 13:49, FAIZAN RAZA wrote: >write a Haskell >function cartesianProduct which when given three lists (to represent three >sets) of integers returns a list of lists of ordered triples. That's easy. Just define 'product' as a function that finds the cartesian product of any number of lists, and then once you've done that you can apply it to make the special case of three items like this: cartesianProduct a b c = product [a,b,c] At least, that's how I would do it. -- Ashley Yakeley, Seattle WA

1 0

RE: Revamping the numeric classes
by Peter Douglass 08 Feb '01

08 Feb '01

I have some questions about how Haskell's numeric classes might be revamped. Is it possible in Haskell to circumscribe the availability of certain "unsafe" numeric operations such as div, /, mod? If this is not possible already, could perhaps a compiler flag "-noUnsafeDivide" could be added to make such a restriction? What I have in mind is to remove division by zero as an untypable expression. The idea is to require div, /, mod to take NonZeroNumeric values in their second argument. NonZeroNumeric values could be created by functions of type: Number a => a -> Maybe NonZeroNumeric or something similar. Has this been tried and failed? I'm curious as to what problems there might be with such an approach. --PeterD

2 1

Re: Revamping the numeric classes
by andrew＠andrewcooke.free-online.co.uk 07 Feb '01

07 Feb '01

On Wed, Feb 07, 2001 at 11:47:11AM +0100, Ketil Malde wrote: > "Ch. A. Herrmann" <herrmann(a)infosun.fmi.uni-passau.de> writes: [...] > > the problem is that the --majority, I suppose?-- of mathematicians > > tend to overload operators. They use "*" for matrix-matrix > > multiplication as well as for matrix-vector multiplication etc. > Yes, obviously. On the other hand, I think you could get far by > defining (+) as an operator in a Group, (*) in a Ring, and so forth. As a complete newbie can I add a few points? They may be misguided, but they may also help identify what appears obvious only through use... - understanding the hierarchy of classes (ie constanly referring to Fig 5 in the report) takes a fair amount of effort. It would have been much clearer for me to have classes that simply listed the required super classes (as suggested in an earlier post). - even for me, no great mathematician, I found the forced inclusion of certain classes irritating (in my case - effectively implementing arithmetic on tuples - Enum made little sense and ordering is hacked in order to be total; why do I need to define either to overload "+"?) - what's the deal with fmap and map? > Another problem is that the mathematical constructs include properties > not easily encoded in Haskell, like commutativity, associativity, etc. > > > I don't think that it is acceptable for a language like Haskell > > to permit the user to overload predefined operators, like "*". Do you mean that the numeric classes should be dropped or are you talking about some other overloading procedure? Isn't one popular use of Haskell to define/extend it to support small domain-specific languages? In those cases, overloading operatores via the class mechanism is very useful - you can give the user concise, but stll understandable, syntax for the problem domain. I can see that overloading operators is not good in general purpose libraries, unless carefully controlled, but that doesn't mean it is always bad, or should always be strictly controlled. Maybe the programmer could decide what is appropriate, faced with a particular problem, rather than a language designer, from more general considerations? Balance, as ever, is the key :-) [...] > >From experience, I guess there are probably issues that haven't > crossed my mind. :-) This is certainly true in my case - I presumed there was some deep reason for the complex hierarchy that exists at the moment. It was a surprise to see it questioned here. Sorry if I've used the wrong terminology anywhere. Hope the above makes some sense. Andrew -- http://www.andrewcooke.free-online.co.uk/index.html ----- End forwarded message ----- -- http://www.andrewcooke.free-online.co.uk/index.html

2 1

Re: Revamping the numeric classes
by Ketil Malde 07 Feb '01

07 Feb '01

"Ch. A. Herrmann" <herrmann(a)infosun.fmi.uni-passau.de> writes: > moved to haskell-cafe No, but *now* it is. (Does haskell@ strip Reply-To? Bad list! Bad!) > the problem is that the --majority, I suppose?-- of mathematicians > tend to overload operators. They use "*" for matrix-matrix > multiplication as well as for matrix-vector multiplication etc. Yes, obviously. On the other hand, I think you could get far by defining (+) as an operator in a Group, (*) in a Ring, and so forth. Another problem is that the mathematical constructs include properties not easily encoded in Haskell, like commutativity, associativity, etc. > I don't think that it is acceptable for a language like Haskell > to permit the user to overload predefined operators, like "*". Depends on your definition of overloading. Is there a difference between overloading and instantiating a class? :-) > A cheap solution could be to define a type MathObject and operators like > :*: MathObject -> MathObject -> MathObject > Then, the user can implement: > a :*: b = case (a,b) of > (Matrix x, Matrix y) -> foo > (Matrix x, Vector y) -> bar Yes. If it is useful to have a fine granularity of classes, you can imagine doing: class Multiplicative a b c where (*) :: a -> b -> c now I can do instance Multiplicative (Vector a) (Vector a) (Vector a) where x * y = ... but also scalar multiplication instance Multiplicative a (Vector a) (Vector a) where a * x = .... Also, I think I can define Group a to be Additive a a a => class Group a where -- inherits plus from "Additive" zero :: a instance Group Int where (+) = built_in_int_addition zero = 0::Int Long qualifier lists might be countered by having Classes -- Num, say -- that just serve to include other classes in reasonable collections. Funny mathematical names would - at least to some extent - be avoided by having simple names for the classes actually defining the operators, so that errors will warn you about missing "Multiplicative" rather than Field or Ring or what have you. >From experience, I guess there are probably issues that haven't crossed my mind. :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 1

(no subject)
by Dylan Thurston 07 Feb '01

07 Feb '01

1 0

RE: GHC Core Language
by Andrew Tolmach 07 Feb '01

07 Feb '01

[moving to haskell-cafe] > From: matt hellige [mailto:matt@immute.net] > a quick question re: ghc's Core language... is it still very similar > to the abstract syntax given in, for example, santos' "compilation by > transformation..." (i think it was his dissertation?) and > elsewhere, or > has it changed significantly in the last couple of years? i only ask > because i know the language used in that paper is somewhat > different from > the Core language given in peyton jones and lester's > "implementing functional > languages" from 92, and includes type annotations and so on. > > m > The current Core language is still quite similar to what is described in Santos' work; see SL Peyton Jones and A Santos, "A transformation-based optimiser for Haskell," Science of Computer Programming 32(1-3), pp3-47, September 1998. http://research.microsoft.com/Users/simonpj/papers/comp-by-trans-scp.ps.gz But there have been some noticeable changes; for example, function arguments are no longer required to be atomic. A more recent version of Core is partially described (omitting types) in SL Peyton Jones & S Marlowe, "Secrets of the Glasgow Haskell Compiler Inliner," IDL'99. http://research.microsoft.com/Users/simonpj/papers/inline.ps.gz

1 0

Re: Revamping the numeric classes
by Ch. A. Herrmann 07 Feb '01

07 Feb '01

moved to haskell-cafe Ketil> E.g. way back, I wrote a simple differential equation solver. Ketil> Now, the same function *could* have been applied to vector Ketil> functions, except that I'd have to decide on how to implement Ketil> all the "Num" stuff that really didn't fit well. Ideally, a Ketil> nice class design would infer, or at least allow me to Ketil> specify, the mathematical constraints inherent in an Ketil> algorithm, and let my implementation work with any data Ketil> satisfying those constraints. the problem is that the --majority, I suppose?-- of mathematicians tend to overload operators. They use "*" for matrix-matrix multiplication as well as for matrix-vector multiplication etc. Therefore, a quick solution that implements groups, monoids, Abelian groups, rings, Euclidean rings, fields, etc. will not be sufficient. I don't think that it is acceptable for a language like Haskell to permit the user to overload predefined operators, like "*". A cheap solution could be to define a type MathObject and operators like :*: MathObject -> MathObject -> MathObject Then, the user can implement: a :*: b = case (a,b) of (Matrix x, Matrix y) -> foo (Matrix x, Vector y) -> bar -- Christoph Herrmann E-mail: herrmann(a)fmi.uni-passau.de WWW: http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html

1 0

RE: binary files in haskell
by Simon Marlow 07 Feb '01

07 Feb '01

> > How about this slightly more general interface, which works > with the new > > FFI libraries, and is trivial to implement on top of the > primitives in > > GHC's IOExts: > > > > hPut :: Storable a => Handle -> a -> IO () > > hGet :: Storable a => Handle -> IO a > > What about endianess? In which format are Floats or even just Bools > stored? For a file which probably shall be read from > different machines > this is not clear at all. The behaviour is defined by the Storable instances for each type. The endianness for writing say an Int32 would be the same as the host architecture, for instance. If you want to work with just bytes, you can always just use hPut and hGet at type Word8. Overloading with Storable gives you more flexibility, since if you have a way to serialise an object in memory for passing to a foreign function, you also have a way to store it in binary format in a file (modulo problems with pointers, of course). In the long term, we'll want to be able to serialise more than just Storable objects (c.f. the other overloaded binary I/O libraries out there), and possibly make the output endian-independent - but after all there's no requirement that Haskell's Int has the same size on all implementations, so there's no guarantee that binary files written on one machine will be readable on another, unless they only use explicitly sized types or Integer. Perhaps these should be called hPutStorable and hGetStorable so as not to prematurely steal the best names. > I think John is right that there needs to be a primitive interface for > just writing bytes. You can then build anything more > complicated on top > (probably different high-level ones for different purposes). > > I just see one problem with John's proposal: the type Byte. It is > completely useless if you don't have operations that go with it; > bit-operations and conversions to and from Int. The FFI > already defines > such a type: Word8. So I suggest that the binary IO library > explicitely > reads and writes Word8's. yup, that's what I had in mind. Cheers, Simon

2 1

Re: binary files in haskell
by malcolm-haskell＠cs.york.ac.uk 06 Feb '01

06 Feb '01

John Meacham wrote: > I wrote up a proposal for a binary file IO mechanism to be added > as a 'blessed addendum' to the standard at best and as a commonly > implmented extension (in hslibs) at least.. I have looked at your proposal. If you would like it to be widely available, you will need to write an implementation of the library, or find someone who can write it for you. Type signatures are great as documentation, but they are not directly executable. :-) Regards, Malcolm

1 0

Haskell Implemetors Meeting
by Timothy Docker 05 Feb '01

05 Feb '01

> We agreed that it would be a Jolly Good Thing if GHC could > be persuaded to produce GHC-independent Core output, > ready to feed into some other compiler. For example, > Karl-Filip might be able to use it. > ANDREW will write a specification, and implement it. A quick question. What is meant by "Core output"? Subsequent posts seem to suggest this is some "reduced Haskell", in which full Haskell 98 can be expressed. Am I completely off beam here? Tim Docker

1 0

Knight
by Christoph M. 05 Feb '01

05 Feb '01

Hi ! Yes, I meant the Knight's Tour problem. Could anybody post me a solve of this problem in haskell ? Thanks a lot, Christoph

2 1

Provider / Haskell-CGI's
by Claudius Heitz 03 Feb '01

03 Feb '01

Hello! Does anybody know a provider, where I can run Haskell-CGI's? I mean, in standard webhosting package? And are there any in Germany? TIA! Claudius _______________________________________________________________________________ Alles unter einem Dach: Informationen, Fun, E-Mails. Bei WEB.DE: http://web.de Die große Welt der Kommunikation: E-Mail, Fax, SMS, WAP: http://freemail.web.de

1 0

Fundeps and quantified constructors
by Tom Pledger 03 Feb '01

03 Feb '01

nubie nubie writes: | So I want to have a polymorphic Collection type, just because. | | > class Collection c e | c -> e where | > empty :: c | > put :: c -> e -> c | | > data SomeCollection e = forall c . Collection c e => MakeSomeCollection c | | Hugs (February 2000) doesn't like it. It says | Variable "e" in constraint is not locally bound | | I feel that e *is* bound, sort of, because c is bound and there's a | fundep c->e. That line of reasoning establishes that e is constrained on the right hand side of the "=". However, it's still bound (by an implicit "forall e") on the left hand side of the "=". The problem is that e can leak details about c to parts of the program outside the "forall c". It's still a problem if you remove the "| c -> e" fundep. A more common use of a "Collection c e | c -> e" class is: data SomeCollection e = --some data structure involving e instance SomeContext e => Collection (SomeCollection e) e where --implementations of empty and put, for the aforementioned --data structure, and entitled to assume SomeContext Is that collection type polymorphic enough for your purposes? : | The following things work as expected: | | > data IntCollection = forall c . Collection c Int => MakeIntCollection c | > data AnyCollection = forall c e . Collection c e => MakeAnyCollection c Neither of them has a type variable tunnelling through the local quantifier. HTH. Tom

1 0

Various software and a question
by Ian Lynagh 02 Feb '01

02 Feb '01

Hi all First a brief question - is there a nicer way to do something like #ifdef __GLASGOW_HASKELL__ #include "GHCCode.hs" #else > import HugsCode #endif than that (i.e. code that needs to be different depending on if you are using GHC or HUGS)? Secondly, I don't know if this sort of thing is of interest to anyone, but inspired by the number of people who looked at the MD5 stuff I thought I might as well mention it. I've put all the Haskell stuff I've written at http://c93.keble.ox.ac.uk/~ian/haskell/ (although I'm new at this game so it may not be the best code in the world). At the moment this consists of a (very nearly complete) clone of GNU ls, and MD5 module and test program and the smae for SHA1 and DES. The ls clone needs a ptch to GHC for things like isLink (incidentally, would it be sensible to try and get this included with GHC? It is basically a simple set of changes to the PosixFiles module, but needs __USE_BSD defined (which I guess is the reason it is not in there, but it could have it's own file?)). Have fun Ian, wondering how this message got to be so long

2 1

Source tar ball for Simon Marlow's Haskell Web Server??
by Bill Halchin 01 Feb '01

01 Feb '01

Hello, I looked on www.haskell.org for the Simon Marlow's Web Server, but couldn't find. Did I overlook it? Regards, Bill Halchin _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

Re: Type Pattern-Matching for Existential Types
by Ashley Yakeley 31 Jan '01

31 Jan '01

At 2001-01-30 22:16, Lennart Augustsson wrote: >It has large and horrible implications. To do dynamic type tests you need >to carry around the types at runtime. This is not something that Haskell >does (at least you don't have to). Hmm. In this: -- data Any = forall a. Any a a1 = Any 3 a2 = Any 'p' -- ...are you saying that a1 and a2 do not have to carry types at runtime? -- Ashley Yakeley, Seattle WA

3 2

Re: Type Pattern-Matching for Existential Types
by C.Reinke 31 Jan '01

31 Jan '01

> > > data Any = forall a. Any a > > > > > > get :: Any -> Maybe Char > > > get (Any (c::Char)) = Just c -- bad > > > get _ = Nothing .. > It can also be questioned from a software engineering standpoint. Much > of the purpose with existential types is to provide information hiding; > that is, the user of an existentially quantified type is not supposed to > know its concrete representation. The merits of an information hiding > dicipline is probably no news to anybody on this list. This discussion reminds me of an old paper by MacQueen: David MacQueen. Using dependent types to express modular structure. In Proc. 13th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 277--286, January 1986. He discusses some of the disadvantages of using plain existential quantification for modular programming purposes and proposes an alternative based on dependent sums, represented as pairing the witness type with the expression in which it is used, instead of existentials, where there is no witness for the existentially quantified type. See CiteSeer for some of the follow-on work that references MacQueen's paper: http://citeseer.nj.nec.com/context/32982/0 Some of that work tried to find a balance between having no witness types and carrying witness types around at runtime. In this context, Claudio Russo's work might be of interest, as he proposes to avoid the problems of existentials without going into (value-)dependent types: http://www.dcs.ed.ac.uk/home/cvr/ Claus

1 0

Type Pattern-Matching for Existential Types
by Ashley Yakeley 31 Jan '01

31 Jan '01

At 2001-01-30 19:52, Fergus Henderson wrote: >On 30-Jan-2001, Ashley Yakeley <ashley(a)semantic.org> wrote: >> At 2001-01-30 02:37, Fergus Henderson wrote: >> >> >class BaseClass s where >> > downcast_to_derived :: s -> Maybe Derived >> >> Exactly what I was trying to avoid, since now every base class needs to >> know about every derived class. This isn't really a practical way to >> build an extensible type hierarchy. > >Right. > >I don't know of any way to do that in Hugs/ghc without the problem that >you mention. Really it needs language support, I think. >(I have no idea if you can do it in O'Haskell.) It can't be done in O'Haskell either... Given that we have existential types, it would be nice to have a pattern-matching mechanism to get at the inside value. Something like... -- data Any = forall a. Any a get :: Any -> Maybe Char get (Any (c::Char)) = Just c -- bad get _ = Nothing -- ...but as it stands, this is not legal Haskell, according to Hugs: ERROR "test.hs" (line 4): Type error in application *** Expression : Any c *** Term : c *** Type : Char *** Does not match : _0 *** Because : cannot instantiate Skolem constant This, of course, is because the '::' syntax is for static typing. It can't be used as a dynamic pattern-test. Question: how big of a change would it be to add this kind of pattern matching? Is this a small issue, or does it have large and horrible implications? -- Ashley Yakeley, Seattle WA

4 4

Re: Type Pattern-Matching for Existential Types
by Ashley Yakeley 31 Jan '01

31 Jan '01

At 2001-01-30 23:11, Johan Nordlander wrote: >However, this whole idea gets forfeited if it's possible to look behind >the abstraction barrier by pattern-matching on the representation. Isn't this information-hiding more appropriately achieved by hiding the constructor? -- data IntOrChar = MkInt Int | MkChar Char data Any = forall a. MkAny a -- Surely simply hiding MkInt, MkChar and MkAny prevents peeking? -- Ashley Yakeley, Seattle WA

2 1

Re: O'Haskell OOP Polymorphic Functions
by Ashley Yakeley 31 Jan '01

31 Jan '01

At 2001-01-30 02:37, Fergus Henderson wrote: >class BaseClass s where > downcast_to_derived :: s -> Maybe Derived Exactly what I was trying to avoid, since now every base class needs to know about every derived class. This isn't really a practical way to build an extensible type hierarchy. -- Ashley Yakeley, Seattle WA

2 1

Re: O'Haskell OOP Polymorphic Functions
by Ashley Yakeley 31 Jan '01

31 Jan '01

At 2001-01-17 17:03, Lennart Augustsson wrote: >You seem to want dynamic type tests. This is another feature, and >sometimes a useful one. But it requires carrying around types at >runtime. Yes. I tried to do that myself by adding a field, but it seems it can't be done. >You might want to look at existential types; it is a similar feature. I seem to run into a similar problem: -- class BaseClass s data Base = forall a. BaseClass a => Base a class (BaseClass s) => DerivedClass s data Derived = forall a. DerivedClass a => Derived a upcast :: Derived -> Base upcast (Derived d) = Base d downcast :: Base -> Maybe Derived -- How do I define downcast? -- Ashley Yakeley, Seattle WA

3 3