- Haskell-Cafe - Haskell.org

RE: [Haskell-cafe] Hiding functions
by Simon Peyton-Jones 14 Aug '04

14 Aug '04

It's an explicit Haskell 98 design choice http://haskell.org/onlinereport/modules.html "5.6.2 Shadowing Prelude Names The rules about the Prelude have been cast so that it is possible to use Prelude names for nonstandard purposes; however, every module that does so must have an import declaration that makes this nonstandard usage explicit." It's a decision one could debate, but it was an explicit choice. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Lyle | Kopnicky | Sent: 12 August 2004 20:23 | To: Haskell Cafe | Subject: [Haskell-cafe] Hiding functions | | Hi all, | | I'm working on a program that uses my own brand of exceptions, and I | created two functions called 'throw' and 'catch'. In order for this to | work, I hide the Prelude 'catch' in my module, called 'Cont.hs'. Thus: | | module Cont where | import Prelude hiding (catch) | ... | throw = ... | catch = ... | | This works hunky-dory until I create another file that imports Cont. I | get a conflict when I use 'catch', so I have to hide the Prelude one again: | | import Prelude hiding (catch) | import Cont | ... | ... throw ... | ... catch ... | | So I'm a bit annoyed by this 'propagation' of hiding clauses. Then I | created a new file, that redefined throw: | | module ResumableExceptions where | import Cont hiding (throw) | import qualified Cont (throw) | ... | throw = ... Cont.throw ... | | Finally, I created a file using ResumableExceptions: | | import Cont hiding (throw) | import ResumableExceptions | ... | ... throw ... | | If I wanted to also use 'catch' I'd have to hide that from the Prelude | as well. | | I can't use type classes to solve this problem, because the types of the | two 'throw' functions are different. | | Perhaps I should just make up new names for these things, eh? But there | might be code that uses 'throw' and doesn't really care which one is | used, and it would be nice to just modify the import line and be done | with it. | | Any opinions? | | Thanks, | Lyle | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

3 3

RE: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either]
by Simon Peyton-Jones 14 Aug '04

14 Aug '04

Closed classes are certainly interesting, but a better way to go in this case is to allow the programmer to declear new kinds, as well as new types. This is what Tim Sheard's language Omega lets you do, and I'm considering adding it to GHC. kind HNat = HZero | HSucc HNat class HNatC (a::HNat) instance HNatC HZero instance HNatC n => HNatC (HSucc n) Here the keyword 'kind' is like 'data', except that it introduces a new *kind* HNat with new *type* constructors HZero and HSucc, rather than a new *type* constructor with new *data* constructors. There is no way to construct a value of type HZero, or (HSucc HZero); these are simply phantom types. Today we are forced to say data HNat data HSucc a which loses the connection between the two. A merit of declaring a kind is that the kind is closed -- the only types of kind HNat are HZero, HSucc HZero, and so on. So the class doesn't need to be closed; no one can add new instances to HNatC because they don't have any more types of kind HNat. At the moment I'm only thinking of parameter-less kind declarations but one could easily imagine kind parameters, and soon we'll have kind polymorphism.... but one step at a time. Any thoughts? Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Duncan Coutts | Sent: 06 August 2004 15:11 | To: MR K P SCHUPKE | Cc: Haskell Cafe | Subject: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either] | | On Fri, 2004-08-06 at 14:05, MR K P SCHUPKE wrote: | > >You should include the definitions of the classes before saying | > | > HOrderedList l' just has to prove by induction that for any element | > in the list, the next element is greater, so the class is simply: | > | > class HOrderedList l | > instance HNil | > instance HCons a HNil | > instance (HOrderedList (HCons b l),HLe a b) => HCons a (HCons b l) | | Somewhat off-topic, | | It's when we write classes like these that closed classes would be | really useful. | | You really don't want people to add extra instances to this class, it'd | really mess up your proofs! | | I come across this occasionally, like when modelling external type | systems. For example the Win32 registry or GConf have a simple type | system, you can store a fixed number of different primitive types and in | the case of GConf, pairs and lists of these primitive types. This can be | modelled with a couple type classes and a bunch of instances. However | this type system is not extensible so it'd be nice if code outside the | defining module could not interfere with it. | | The class being closed might also allow fewer dictionaries and so better | run time performance. | | It would also have an effect on overlapping instances. In my GConf | example you can in particular store Strings and lists of any primitive | type. But now these two overlap because a String is a list. However | these don't really overlap because Char is not one of the primitive | types so we could never get instances of String in two different ways. | But because the class is open the compiler can't see that, someone could | always add an instance for Char in another module. If the class were | closed they couldn't and the compiler could look at all the instances in | deciding if any of them overlap. | | So here's my wishlist item: | | closed class GConfValue v where | ... | | Duncan | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

6 5

RE: [Haskell-cafe] Hiding functions
by Bayley, Alistair 13 Aug '04

13 Aug '04

What is wrong with creating your own catch and throw with different names? e.g. data MyException = MyException ... deriving (Typeable, Show) catchMyEx :: IO a -> (MyException -> IO a) -> IO a catchMyEx = catchDyn throwMyEx :: MyException -> a throwMyEx = throwDyn > But there might be code that uses 'throw' and doesn't really > care which one is used, and it would be nice to just modify > the import line and be done with it. Can you expand on this? (more example code?) If you want to throw your own exceptions, then you must use throwDyn/catchDyn, so you have to use something other than catch/throw anyway. Alistair. > -----Original Message----- > From: Lyle Kopnicky [mailto:lists@qseep.net] > Sent: 12 August 2004 20:23 > To: Haskell Cafe > Subject: [Haskell-cafe] Hiding functions > > Hi all, > > I'm working on a program that uses my own brand of > exceptions, and I created two functions called 'throw' and > 'catch'. In order for this to work, I hide the Prelude > 'catch' in my module, called 'Cont.hs'. Thus: > > module Cont where > import Prelude hiding (catch) > ... > throw = ... > catch = ... > > This works hunky-dory until I create another file that > imports Cont. I get a conflict when I use 'catch', so I have > to hide the Prelude one again: > > import Prelude hiding (catch) > import Cont > ... > ... throw ... > ... catch ... > > So I'm a bit annoyed by this 'propagation' of hiding clauses. > Then I created a new file, that redefined throw: > > module ResumableExceptions where > import Cont hiding (throw) > import qualified Cont (throw) > ... > throw = ... Cont.throw ... > > Finally, I created a file using ResumableExceptions: > > import Cont hiding (throw) > import ResumableExceptions > ... > ... throw ... > > If I wanted to also use 'catch' I'd have to hide that from > the Prelude as well. > > I can't use type classes to solve this problem, because the > types of the two 'throw' functions are different. > > Perhaps I should just make up new names for these things, eh? > But there might be code that uses 'throw' and doesn't really > care which one is used, and it would be nice to just modify > the import line and be done with it. > > Any opinions? > > Thanks, > Lyle ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

2 1

RE: [Haskell-cafe] Closed Classes
by MR K P SCHUPKE 13 Aug '04

13 Aug '04

>In my view without that simple defining >rule it is difficult to come up with a proposal that is simple, I think I have decided that it was not really closed world I was thinking of, but more along the lines of what Simon PJ posted... After all at some point the compiler _has_ to commit to an instance. If we leave everything as it is - unless the compiler cannot choose an instance due to unresolved overloading. In which case my suggestion is that the compiler trys unifying all instances with the environment, and if one and only one instance unifies then use that one... Keean.

1 0

RE: [Haskell-cafe] Closed Classes
by MR K P SCHUPKE 13 Aug '04

13 Aug '04

>add the extra rule that if there is only one possible instance the >compiler should use it. Yes, I think that is what I am saying. The closed class assumption alters the types of exported functions by applying improvements to them - that is not what I meant at all. I think what is confusing me is the 'possible' part. I was thinking about applying type improvement to effectively determine which instance to choose. (I think this is an error on my part - I get the impression type improvement cannot be used for this) ... would a possibel instance be something like: assuming you are resolving instances lazily at the last possible moment, you try to unify all instances and if one and only one unifies - use that instance. Keean.

2 1

Re: [Haskell-cafe] puzzle: prove this floorSqrt correct
by blaetterrascheln＠web.de 13 Aug '04

13 Aug '04

Christian Sievers <sievers(a)math2.nat.tu-bs.de> wrote on 12.08.04 19:00:00: > sqrtInt n = help n where help x = let y = ((x + (n `div` x)) `div` 2) in if y<x then help y else x > > following p. 38f of Henri Cohen, A Course in Computational Algebraic Number Theory That bailout test is better than mine, and the book is in my local library. Thank you very much. ________________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

1 0

Re: [Haskell-cafe] Closed Classes
by MR K P SCHUPKE 13 Aug '04

13 Aug '04

>that g::Int (or, rather, Int->Int) No, because instances are considered wherever they are defined (as long as they are in _this_ file or an imported one). The point of the example was to show that it is the instances visible in the transitive closure that are considered. Basically the type of g will be g :: A a => a -> a In the end functions have to be called, and it is the ultimate call site for the whole chain of functions where grounded types and concrete values are provided that instance resolution occurs. In the end we can call > g (3::Int) 4 In effect it is the extra parameter (A a) that contains the dictionary for 'A'. We can only choose a dictionary when we know the type of 'a', and we can choose between all instances visible at the call site, not where the function was originally defined. Keean.

1 0

Re: [Haskell-cafe] Closed Classes
by MR K P SCHUPKE 13 Aug '04

13 Aug '04

>Informally, what I see as the defining rule for "closed world" is: But that would break existing programs. You would need a language extension so the feature could be selectively enabled. There are plenty of proposals for how to do this (from closed class keywords to 'kind' statements)... I think however that you can get the benefits of better improvement rules without going all the way to a closed world. My question in the last post was: what if we assume an open world whilst type-checking and generating function type signatures, but assume closed world when resolving instances? Keean.

1 0

Closed Classes
by MR K P SCHUPKE 13 Aug '04

13 Aug '04

Okay (thanks to Simon PJ) - the problem appears to be that applying the improvement rules could result in a function being exported with an incorrect type signature (if a later module defines additional instances): module X (f,g) where class A a where f :: a -> a instance A Int where f = id g x = f x After appling improvement 'g's type would be "g::Int -> Int", however if we now do: module Y where import X instance A Float where f x = x + 1.0 h x = g x Then after the type sig exported for 'g' is wrong ... So my question is now: What if we don't improve the types of 'f' at all and leave it at its most general: "g :: A a => a -> a", and instead wait until we are tring to resolve overloading to apply improvement. IE at some point we must decide which dictionary to pass in, to the top level function (with a constraint "A a =>") what happens if we defer improvement till this point? Surely it must be safe to assume a closed class at the top level? Keean.

6 5

Hiding functions
by Lyle Kopnicky 12 Aug '04

12 Aug '04

Hi all, I'm working on a program that uses my own brand of exceptions, and I created two functions called 'throw' and 'catch'. In order for this to work, I hide the Prelude 'catch' in my module, called 'Cont.hs'. Thus: module Cont where import Prelude hiding (catch) ... throw = ... catch = ... This works hunky-dory until I create another file that imports Cont. I get a conflict when I use 'catch', so I have to hide the Prelude one again: import Prelude hiding (catch) import Cont ... ... throw ... ... catch ... So I'm a bit annoyed by this 'propagation' of hiding clauses. Then I created a new file, that redefined throw: module ResumableExceptions where import Cont hiding (throw) import qualified Cont (throw) ... throw = ... Cont.throw ... Finally, I created a file using ResumableExceptions: import Cont hiding (throw) import ResumableExceptions ... ... throw ... If I wanted to also use 'catch' I'd have to hide that from the Prelude as well. I can't use type classes to solve this problem, because the types of the two 'throw' functions are different. Perhaps I should just make up new names for these things, eh? But there might be code that uses 'throw' and doesn't really care which one is used, and it would be nice to just modify the import line and be done with it. Any opinions? Thanks, Lyle

1 0

Combination-lock problem
by Florian Boehl 12 Aug '04

12 Aug '04

Hi, I'ld like to generate a list (of lists) that contains all combinations of natural numbers stored in another list. It should work like a combination-lock. E.g.: [2,2] -> [[0,0],[0,1],[0,2],[1,0],[1,1],[1,2],[2,0],[2,1],[2,2]] If I know the length 'l' of the 'locklist', I can solve the problem via generators. E.g.: l = 2: [[a,b] | a <- [0..locklist!!0], b <- [0..locklist!!1]] But if the length is unknown (because it's dynamic) this solutions (of course) fails. Is it possible to solve this problem in haskell in an elegant way? Thanks Flo

10 13

RE: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either]
by MR K P SCHUPKE 12 Aug '04

12 Aug '04

>but if f is exported, that's probably not what you want. Why... Read my post carefully - I am suggesting that you close the class on IMPORT so module X import a import b import c So we close the class here - after reading all possible instances from imported files a,b, and c Keean.

1 0

RE: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either]
by Simon Peyton-Jones 12 Aug '04

12 Aug '04

but if f is exported, that's probably not what you want. And if you give a type sig to f, f:: forall a. C a => a -> Maybe a the type sig will say it's polymorphic, while the improvement rule will say that a must be Int. Simon | -----Original Message----- | From: André Pang [mailto:ozone@algorithm.com.au] | Sent: 12 August 2004 14:52 | To: Simon Peyton-Jones | Cc: MR K P SCHUPKE; haskell-cafe(a)haskell.org; qrczak(a)knm.org.pl | Subject: Re: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either] | | On 12/08/2004, at 11:05 PM, Simon Peyton-Jones wrote: | | > module M where | > | > class C a where | > op :: a -> a | > | > instance C Int where | > op x = x+1 | > | > f x = Just (op x) | > | > Under your proposal, I'd infer f :: Int -> Maybe Int, on the grounds | > that C is closed and there is only one instance. | | If I'm reading Keean's posts right, that's exactly his point: if you | only have one instance of class C, then it's valid to improve f's type | to :: Int -> Maybe Int, right? | | If, on the other hand, you had another instance (e.g. instance C Bool), | then the signature of f would have to remain polymorphic. | | | -- | % Andre Pang : trust.in.love.to.save

1 0

RE: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either]
by Simon Peyton-Jones 12 Aug '04

12 Aug '04

module M where class C a where op :: a -> a instance C Int where op x = x+1 f x = Just (op x) Under your proposal, I'd infer f :: Int -> Maybe Int, on the grounds that C is closed and there is only one instance. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of MR | K P SCHUPKE | Sent: 12 August 2004 14:03 | To: haskell-cafe(a)haskell.org; qrczak(a)knm.org.pl | Subject: Re: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either] | | Okay anybody whish to argue against these points: | | 1) closed or open is the same if no instances overlap | | 2) overlapping instances (open or closed) can break | code in modules which import the defining module | if a new instance is declared in any imported | module. | | 3) code changes in non-imported modules cannot have | any affect on _this_ module. (And here I count | any module in the import tree as imported - at | least in terms of recompilation dependancies) | | The conclusion appears to be it is overlapping instances | that cause code to be 'breakable' by simply defining a new | instance and not closing the class. Closing the class | would appear to have no adverse affects on existing | programs (as it allows better improvement rules) all existing | programs that compile without the better improvement rules | should still compile - just a few more programs will be | valid with the closed assumption? | | Keean. | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

Re: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either]
by MR K P SCHUPKE 12 Aug '04

12 Aug '04

Okay anybody whish to argue against these points: 1) closed or open is the same if no instances overlap 2) overlapping instances (open or closed) can break code in modules which import the defining module if a new instance is declared in any imported module. 3) code changes in non-imported modules cannot have any affect on _this_ module. (And here I count any module in the import tree as imported - at least in terms of recompilation dependancies) The conclusion appears to be it is overlapping instances that cause code to be 'breakable' by simply defining a new instance and not closing the class. Closing the class would appear to have no adverse affects on existing programs (as it allows better improvement rules) all existing programs that compile without the better improvement rules should still compile - just a few more programs will be valid with the closed assumption? Keean.

1 0

Re: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either]
by MR K P SCHUPKE 12 Aug '04

12 Aug '04

Just wondering, but what exacly is the problem with this open/closed stuff? As far as I understand it new instances can be added to classes in Haskell (because they are open)... But its not like instances can be added at link time, and all the instances that you wish to be considered _must_ be imported into the current module! That means if we (for example) used two pass compilation we could gather all the instances together first and know that we have all instances for a given class before considering any resolution of overlapping instances. Why is this not done? (personally I don't mind if compilation takes longer if it makes coding easier...) Keean.

3 2

Re: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either]
by MR K P SCHUPKE 12 Aug '04

12 Aug '04

>If the compiler treated instances as closed in this way, then adding a >new instance to the program could break existing parts of the program. But there are many ways to do this... and besides this doesn't really make sense... consider the following: module A defines class X module B imports class X defines some instances module C imports A & B Now, you can add any instance you like to module C and it is never seen by modules A and B... In other words even if you assume closed classes you cannot break an existing module without editing that module or one imported by it (in which case you can break _anything_ by deleting a function) If you don't allow overlapping instances none of this makes any difference anyway - closed or open ... (instance selection cannot change if no instances are allowed to overlap) Finally if you allow overlapping instances you can break existing code (without the closed assumption) just by putting in a more specific instance in a module included in some module using the more general instance. Thoughts? What is the problem with assuming all classes are closed within the available context (imported modules) Keean.

1 0

closed classes [was: Re: exceptions vs. Either]
by Martin Sulzmann 12 Aug '04

12 Aug '04

Hi, here's my take on closed classes versus kinds. 1) Closed classes: Consider class Foo x instance Foo Int instance Foo Bool Assume we'd like to prevent that Foo has any other members besides Int and Bool. Haskell follows the open-world assumption. Hence, Foo t is assumed to be true for any type t unless otherwise stated. Oleg suggests to use functional dependency style improvement. Indeed, we'd like to state that "Foo x improves to False for any x different from Int and Bool". The question is how to enforce this condition? I don't think you can by just relying on functional dependencies. 1a) Closed classes in Chameleon: E.g., in Chameleon we can enumerate all cases which should yield False rule Foo Char ==> False rule Foo (a,b) ==> False rule Foo (a->b) ==> False ... But what happens if we define a new type such as data Erk = ...? Well, we'll need to add a new improvement rule rule Foo Erk ==> False 1b) Closed-world assumption: Alternatively, we might want to abandon the open-world assumption and switch to a Prolog-like closed world approach. See section 4.2 in [1] and section 8.1 in [2] for a discussion. Essentially, we impose that Foo x improves to x=Int or x=Bool We can close classes once and for all, however, we're in trouble in case instance declarations are recursive (e.g., Simon's example involves a recursive instance declaration!) Ref: [1] Object-Oriented Style Overloading for Haskell by Mark Shields and Simon Peyton Jones. [2] A Theory of Overloading by Peter J. Stuckey and Martin Sulzmann b) Kinds There's certainly a connection between closed classes and kinds. Assume we have a system that supports closed classes (either by following (1a) or (1b)). Then kind K = T1 | T2 class C (a::K) can be encoded by closed class K x instance K T1 instance K T2 -- T1 and T2 are the only members of K class K a => C a -- C t implies K t which yields failure if t differs from T1 or T2 Martin Oleg wrote: > Simon Peyton-Jones wrote: > > > kind HNat = HZero | HSucc HNat > > > > class HNatC (a::HNat) > > > > instance HNatC HZero > > instance HNatC n => HNatC (HSucc n) > > > > There is no way to construct a value of type HZero, or (HSucc HZero); > > these are simply phantom types. ... A merit of declaring a kind > > is that the kind is closed -- the only types of kind HNat are HZero, > > HSucc HZero, and so on. So the class doesn't need to be closed; no one > > can add new instances to HNatC because they don't have any more types of > > kind HNat. > > With the flag -fallow-overlapping-instances, could I still add an instance > instance HNatC n => HNatC (HSucc (HSucc n)) > or > instance HNatC (HSucc HZero) > ?? > > > If I may I'd like to second the proposal for closed classes. In some > sense, we already have them -- well, semi-closed. Functional > dependencies is the way to close the world somewhat. If we have a > class > class Foo x y | x -> y > instance Foo Int Bool > we are positive there may not be any instance 'Foo Int <anything>' > ever again, open world and -fallow-overlapping-instances > notwithstanding. In fact, it is because we are so positive about that > fact that we may conclude that "Foo Int x" implies x = Bool. At least > in the case of functional dependencies, the way to close the world gives > us type improvement rules. One might wonder if there are other ways > to (semi-)close the world with similar nice properties.

1 0

Leo editor for literate programing
by Gour 11 Aug '04

11 Aug '04

Hi! I've just stumbled upon Leo outline editor which looks great as a tool for literate programming (see http://webpages.charter.net/edreamleo/front.html) Since lp is a (wide) accepted practice in the Haskell community, I'm wondering whether someone is using it in a daily programming? (however, I've noticed there is no support for Haskell yet, although there are plugins for emacs/vim.) Sincerely, Gour -- Gour | gour(a)mail.inet.hr Registered Linux User | #278493 GPG Public Key | 8C44EDCD

2 3

RE: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either]
by MR K P SCHUPKE 09 Aug '04

09 Aug '04

>Is there any possibility of a theory that will avoid the need to replicate >features at higher and higher levels? If we consider types, types are a collection of values, for example we could consider Int to be: data Int = One | Two | Three | Four ... Okay, so the values in an integer are connected by functions (operations like plus, multiply) - but we can consider these externally defined (as they are primitives). Also we have special symbols for the values of this type (type constructors are 'values') like 1, 2, 3... etc. Likewise Char is effectively an enumeration of ascii values (or Unicode values). All these standard types behave like enumerations of values. Lists are effectively nested binary products: data List a = Cons a (List a) But I digress, my point is that types are a 'set' of values, and so we can consider the simplest example: data Bool = True | False So bool is a type and True and False are the values 'in' that type - _but_ we can also write: kind Bool = True | False Where Bool is a kind and True and False are values, Kinds are really a different name for "type_of_types"... and this continues upwards forever (a type_of_type_of_types) ... we can effectively flatten this by considering types as values and kinds as types. What is the difference between a type and a value? So we can consider: "data Bool = True | False" to be a relationship between elements at the Nth level (the RHS) and the N+1th level (the LHS). This relationship could be applied at any level, and it should be possible to detemine the level at which we wish to apply this relationship by the context in which it is used. Imagine a function 'not': not :: Bool -> Bool not True = False not False = True we could apply this at the values level: > not True False The type level: class (Bool a,Bool b) => Not a b | a -> b instance True False instance False True How does this differ from the original functional form? can we imagine doing: not' :: Not a b => a -> b but perhaps writing it: not' :: Bool a => a -> not a After all is not 'not' a complete function from Bool to Bool, whatever Bool is? (Bool could be a type or a type of types, or a type of type of types...) Would this not result in greater code re-use? Perhaps classes would become redundant (apart from being used to allow overloading...) My theory here is a bit shakey - but the name Martin Lof springs to mind. Keean. *errata - when I said "Where Bool is a kind and True and False are values" I of course meant w true and false are types!

1 0

RE: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either]
by Graham Klyne 09 Aug '04

09 Aug '04

At 16:00 09/08/04 +0100, Simon Peyton-Jones wrote: >Any thoughts? Well, a thought, but I'm not sure that it leads anywhere useful. In the process of learning Haskell, I've vaguely observed to myself that features introduced for describing data (i.e. type expressions) seem to also be usable in higher form to describe types. Mostly, the Haskell language definition resists such extension, by sticking with a very simple notion of kind and type construction (or is that a fundamental restriction of Hindley-Milner?). For example, if I choose the "wrong" parameter ordering for a type constructor in a class declaration, I sometimes find the resulting class cannot be used in the ways intended --only one possible sequence of partial instantiation is possible-- and have found myself wondering if type-level lambda abstraction wouldn't be a useful feature to overcome this. Your suggestion seems to be another feature in the same vein: extending data features to types. I find myself wondering where this might all end. If types acquire many of the manipulations that are available for data values, then might one find that, in turn, cases will be found that seem to require similar capabilities for kinds? Is there any possibility of a theory that will avoid the need to replicate features at higher and higher levels? (This all seems vaguely reminiscent of the theoretical issues that faced denotational program semantics --which I don't claim to understand-- until Dana Scott's work showed that there was a logical foundation for treating functions as values. [er, did I get that right?].) #g -- >Closed classes are certainly interesting, but a better way to go in this >case is to allow the programmer to declear new kinds, as well as new >types. This is what Tim Sheard's language Omega lets you do, and I'm >considering adding it to GHC. > > kind HNat = HZero | HSucc HNat > > class HNatC (a::HNat) > > instance HNatC HZero > instance HNatC n => HNatC (HSucc n) > >Here the keyword 'kind' is like 'data', except that it introduces a new >*kind* HNat with new *type* constructors HZero and HSucc, rather than a >new *type* constructor with new *data* constructors. > >There is no way to construct a value of type HZero, or (HSucc HZero); >these are simply phantom types. Today we are forced to say > data HNat > data HSucc a >which loses the connection between the two. A merit of declaring a kind >is that the kind is closed -- the only types of kind HNat are HZero, >HSucc HZero, and so on. So the class doesn't need to be closed; no one >can add new instances to HNatC because they don't have any more types of >kind HNat. > >At the moment I'm only thinking of parameter-less kind declarations but >one could easily imagine kind parameters, and soon we'll have kind >polymorphism.... but one step at a time. > >Any thoughts? > >Simon > > >| -----Original Message----- >| From: haskell-cafe-bounces(a)haskell.org >[mailto:haskell-cafe-bounces@haskell.org] On Behalf Of >| Duncan Coutts >| Sent: 06 August 2004 15:11 >| To: MR K P SCHUPKE >| Cc: Haskell Cafe >| Subject: [Haskell-cafe] closed classes [was: Re: exceptions vs. >Either] >| >| On Fri, 2004-08-06 at 14:05, MR K P SCHUPKE wrote: >| > >You should include the definitions of the classes before saying >| > >| > HOrderedList l' just has to prove by induction that for any element >| > in the list, the next element is greater, so the class is simply: >| > >| > class HOrderedList l >| > instance HNil >| > instance HCons a HNil >| > instance (HOrderedList (HCons b l),HLe a b) => HCons a (HCons b l) >| >| Somewhat off-topic, >| >| It's when we write classes like these that closed classes would be >| really useful. >| >| You really don't want people to add extra instances to this class, >it'd >| really mess up your proofs! >| >| I come across this occasionally, like when modelling external type >| systems. For example the Win32 registry or GConf have a simple type >| system, you can store a fixed number of different primitive types and >in >| the case of GConf, pairs and lists of these primitive types. This can >be >| modelled with a couple type classes and a bunch of instances. However >| this type system is not extensible so it'd be nice if code outside the >| defining module could not interfere with it. >| >| The class being closed might also allow fewer dictionaries and so >better >| run time performance. >| >| It would also have an effect on overlapping instances. In my GConf >| example you can in particular store Strings and lists of any primitive >| type. But now these two overlap because a String is a list. However >| these don't really overlap because Char is not one of the primitive >| types so we could never get instances of String in two different ways. >| But because the class is open the compiler can't see that, someone >could >| always add an instance for Char in another module. If the class were >| closed they couldn't and the compiler could look at all the instances >in >| deciding if any of them overlap. >| >| So here's my wishlist item: >| >| closed class GConfValue v where >| ... >| >| Duncan >| >| _______________________________________________ >| Haskell-Cafe mailing list >| Haskell-Cafe(a)haskell.org >| http://www.haskell.org/mailman/listinfo/haskell-cafe >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

Constructing a 'State Cover' for a FSM
by Stu White 09 Aug '04

09 Aug '04

Hi all I'm trying to construct a cover for a finite state machine and need to devise a strategy beforehand. Thing is I'm having a little trouble. Could anyone suggest a generic strategy that can be used for constructing a cover (things like how I would identify the machines alphabet and so on). Not sure if everyone else calls them covers, so a quick description:- FSM (M) has a finite number of states, so it should be possible to find a finite set of strings (C) which lets you reach each and every state in M from the initial state. ie given any state s you can find a string w = a1a2....am in C for which initial state -> a1.....->am s is a path in M. Any stratagies would be greatly appreciated, thanks Stu --------------------------------- ALL-NEW Yahoo! Messenger - all new features - even more fun!

1 0

RE: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either]
by MR K P SCHUPKE 09 Aug '04

09 Aug '04

kind statements sound like a good idea - a couple of questions spring to mind - what is the parameter of a kind statement (a type or a kind... a kind makes more sense) ... do we have to stop with kinds what about "kinds of kinds" - the statement has identical syntax to a data declaration, is there no way to combine the two, with perhaps a level value? An example of where you may need kinds-of-kinds (etc) is consider peano numbers (declared as a kind) ... now consider we have several implementations (unary - binary etc) which we wish to group together as an equivalent to the Num class. I accept the above is not a good example as this is better served by a class (as you may well want it 'open')... It seems from a theoretical point of view easy to add multiple levels of kinds instead of one level... of course it is probably much more difficault to do this to GHC? Of course with kinds of kinds you either have to annotate the statement with the level - or let the compiler infer the level. The latter seems much more difficault as the same 'level-less-kind statement' could be used on multiple levels... Keean.

1 0

Re: exceptions vs. Either
by MR K P SCHUPKE 09 Aug '04

09 Aug '04

>After all, Java basically does exactly what you're asking for with Java's head/tail would be doing runtime checks if they are throwing exceptions, static guarantees mean the program would not be allowed to compile if it broke the static guarantees. >end-programmers have to worry much less about handling errors properly. Which is a bad thing! All programmers always have to consider error conditions, if they don't they write buggy code - that's the nature of the beast. I prefer making programmers expicitly face the decisions they are making, rather than have things implicitly handled in a way that hides what is going on from the programmer. Keean.

5 6

Re: [Haskell-cafe] Re: exceptions vs. Either
by MR K P SCHUPKE 07 Aug '04

07 Aug '04

>Sounds like a job for...Type Inference! In Olegs post where he gave examples of how to make exceptions explicit in type signatures: oleg said: > {-# OPTIONS -fglasgow-exts #-} > {-# OPTIONS -fallow-undecidable-instances #-} > > module TER where > > class CERROR a c where > darn:: a -> c-> String -> b > > instance Show a => CERROR a c where > darn label _ msg = error $ "Error: " ++ (show label) ++ " " ++ msg > > > data EHead = EHead deriving Show > data ETail = ETail deriving Show > data EJust = EJust deriving Show > > myhead x@([]) = darn EHead x "head of an empty list" > myhead (x:_) = x > > mytail x@([]) = darn ETail x "tail of an empty list" > mytail (_:xs) = xs Now, if we ask GHCi for the type of myhead, we get *TER> :t myhead myhead :: forall a. (CERROR EHead [a]) => [a] -> a ---------------------------------------------------------- As you can see you get the advantage of explicit exceptions, but with type inference. Keean.

1 0

Re: [Haskell-cafe] Type classes... popular for newbies, isn't it?
by Arjun Guha 07 Aug '04

07 Aug '04

I'd rather not do that, but even if I did, the type-variable action would not be reachable in the terminal function. I could specify a functional dependency st -> action (though I've never used it, it would be a fun to learn). I'm curious as to why my class declaration compiles in GHC, as there doesn't seem to be any way to use it. -Arjun On Aug 7, 2004, at 01:06, camarao(a)dcc.ufmg.br wrote: > Hi Arjun. > > How about inserting one more parameter, "action", in your class > definition: > > class (Ord st) => MinimaxState st action where > successors:: st -> [(action,st)] > terminal:: st -> Bool > > instance MinimaxState Int Int where > terminal i = i == 0 > successors i = [(1,i+1), (-1,i-1)] > > Then don't forget to start the compiler/interpreter with > -fglasgow-exts. > > Hope this helps. > > Regards, > > Carlos > >

4 3

Type classes... popular for newbies, isn't it?
by Arjun Guha 07 Aug '04

07 Aug '04

This class definition is giving me a lot of problems with the successor function: class (Ord st) => MinimaxState st where successors:: st -> [(action,st)] terminal:: st -> Bool A trivial example would be: instance MinimaxState Int where terminal i = i == 0 successors i = [(1,i+1), (-1,i-1)] However, I get this error in GHC: Could not deduce (Num action) from the context (MinimaxState Int, Ord Int) arising from the literal `1' at AbTest.hs:7 Probable fix: Add (Num action) to the class or instance method `successors' In the first argument of `negate', namely `1' In the list element: (- 1, (- i) - 1) In the definition of `successors': successors i = [(1, i + 1), (- 1, (- i) - 1)] I have the class definition and the instance definition in seperate files. I don't understand where I'm supposed to put the "probable fix." I don't want it to be in the class definition, since action should be fairly arbitrary. In fact, no matter what I try, I get errors, for example: instance MinimaxState Int where terminal i = i == 0 successors i = [("action",i+1), ("action",i-1)] Cannot unify the type-signature variable `action' with the type `[Char]' Expected type: action Inferred type: [Char] In the list element: ("action", i + 1) In the definition of `successors': successors i = [("action", i + 1), ("action", (- i) - 1)] Any suggestions? -Arjun

3 2

Re: [Haskell-cafe] Re: exceptions vs. Either
by MR K P SCHUPKE 07 Aug '04

07 Aug '04

>You should include the definitions of the classes before saying HOrderedList l' just has to prove by induction that for any element in the list, the next element is greater, so the class is simply: class HOrderedList l instance HNil instance HCons a HNil instance (HOrderedList (HCons b l),HLe a b) => HCons a (HCons b l) which is the equivalent type level program to ordered :: [Int] -> Bool ordered [] = True ordered [a] = True ordered (a:(b:l)) = if a<=b then ordered (b:l) else False ordered _ = False It is obvious by observation that the a<=b ensures order. This is a lot simpler than say a heap-sort. I suppose you could contend that there are some classes above I still haven't defined - but you wouldn't expect to see definitions for (<=) which is defined in the prelude. Of course to show statically that order is preserved the 'value' of the elements to be ordered must be visible to the type system - so the values must be reified to types... This can be done for any Haskell type, but for numbers we would use Peano numbers - the HLe class for these is again easily defined by induction: class HLe n n' instance HLe HZero HZero instance HLe x y => HLe (HSucc x) (HSucc y) Keean.

5 6

Re: [Haskell-cafe] closed classes
by MR K P SCHUPKE 06 Aug '04

06 Aug '04

Closed t => ???? You want a closed type? The parameter to a class is a type... Actually if you allow undecidable instances you can use the generic instance to close the class class OnlyInt a instance OnlyInt Int instance Fail () => OnlyInt x Where Fail is a class with no instances, that is not exported! If you try and add an instance to OnlyInt the program will fail with overlapping instances. Keean.

2 1

Re: [Haskell-cafe] Re: exceptions vs. Either
by MR K P SCHUPKE 06 Aug '04

06 Aug '04

>class HLe n n' >instance HLe HZero HZero >instance HLe x y => HLe (HSucc x) (HSucc y) Erm of course this was the definition for Equals, not less than or equals! class HLe n n' instance HLe HZero x instance HLe x y => HLe (HSucc x) (HSucc y) Is the definition for less than or equals... but it took me all of 5 seconds to realise the first definition I gave was wrong - because it is so simple... Keean.

1 0

Re: [Haskell-cafe] Re: exceptions vs. Either
by MR K P SCHUPKE 06 Aug '04

06 Aug '04

>>Static guarantees are great, but if you have to explicitly change your >>style of coding to cope with those extra constraints, it can become (very) >>cumbersome. I had to change coding style moving from imperative to declarative languages, but I think it was worth it... Likewise I think having the ability to make strong static guaranees is worth it - you may not, which is why it is important not to break any existing programs with language extensions (if any are necessary). My programs will have less bugs though! >"worse-is-better, even in its strawman form, has better survival I fully subscribe to the 'worse is better' approach, but I don't see how it contradicts the principle of static guarantees - you can have both. Simplicity is about algorithmic complexity not about whether type signatures are provided by the programmer. Infact type signatures are in themselves an embodyment of the simple is better principle. A type signature expresses certain static guarantees about the function in a vary compact way. Consider the sort example... being able to declare a type signature on a sort algorith that enforces ordering of the output would prove the sort algorithm can _only_ output correctly sorted lists under _all_ circunstances. This type signature is much simpler than the actual sort - hence is useful. sort :: (HList l,HOrderedList l') => l -> l' Nice and readable, and much simpler than the actual algorithm (be it bubble sort, or a quick sort) Keean.

2 1

Re: exceptions vs. Either
by MR K P SCHUPKE 06 Aug '04

06 Aug '04

What can I say... Static typing guarantees is what made me switch from object oriented languages like C++/ObjectiveC/Java (that and the availability of a good compiler) - So I am obviously in favour of more static guarantees - I believe programming by contract is the way to reliable _engineered_ software, so the more contractual obligations that can be concisely and clearly expressed in the type system the better. I think Haskell should support dependant types, after all if you don't want to use them you don't have to... (backwards compatability and all that) although it would be useful to have a replacement prelude that used dependant types versions of head etc... I have a hard time understanding why functional programmers would not want more static typing guarantees, after all they can always use C if they dont like type systems! Keean.

5 4

Re: [Haskell-cafe] Re: exceptions vs. Either
by MR K P SCHUPKE 06 Aug '04

06 Aug '04

>Not so. In Java, the programmer is forced to handle most exceptions I forgot you had to do that... Exceptions are explicit in the type signatures. I think Oleg posted a message a while back about how to make exceptions explicit in haskell type signatures... But I would rather use static guarantees where possible, and exceptions where necessary. I haven't really tried using the techniques for explicit exceptions, but on consideration I might see if it is practical to code in that style... Keean.

1 0

Re: [Haskell-cafe] introspection | meta data
by Crypt Master 05 Aug '04

05 Aug '04

>Can you name these fields? If so, haskell has (sorta clumsy) named >records, >and you can select and update fields by name, and you can replace >'setSFField 3 sf x' with 'sf {somefield=x}' I did think of this, but unfortunatly my algorithm cant use names (without hard coding all possible combinations ) > > So what is the general haskell approach to this type of >introspection/meta > > data problem... ? >A C array of pointers maps closest to a MutableArray, which is mostly a >list >with different performance. Unless you're casting pointers, in which case >Dynamic types or the Generic stuff is maybe what you want. Or a redesign >;) I looked at haskell arrays, but since I cant point to an element in my tuple it wont work out. The ANSI C use of arrays is a really simple (but nasty) way to provide a means for me to loop over a fixed struct record. The Generic library looks super, only had time to browse some slides thus far, but will defiantly try understand that. As for a redesign and >Others have given good answers for this, but I suspect you may have chosen >the >wrong data structure... I would be keen on any ideas you have on how to design this in haskell. Learning to think in haskell is after all the goal :-) The example below is trivial and real world, both reasons why I chose to use it. Any comments welcome, none expected :-) Thanks, -- I idea is to perform a search over a number fields in a hierachical fashion where each field can have a wild card. The real world example is printer selection. In a multi-national company all users tend to be on one (or a few) central servers, but require there printouts to come to them locally whereever they are. Users typically range in 1000s and so "by user" defintions are out. Simplified Search fields: Environemnt, Users, Report, Version, Host Printer ---------------------------------------------------------- ---------- The "most" speicific field is host on the right with it becomming more general moving to towards the left. Setup data could choose to override all of report "RPT1" version "Ver1" to Printer "Bobs Printer" *ALL, *ALL, "RPT1", "Ver1", "*ALL", "Bobs Printer" but Simon may be an exception, then a record could be added like so: *ALL, "SIMON", "RPT1", "Ver1", *ALL, "Simons Printer" This record would be found first for simon, but former found found for everyone else. A search starts from fully specific data i.e no wild cards. The basic algortihm I worked out is: 1. Search setup data 2. If no record found 2a: Set current field to most specific field (host in this case) 2b: Toggle current field ( if Wildcard then make it value, if value make it wildcard ) 2c: if current field is *ALL goto 1 above (we stop here to perform a search on the current permutation) 2d: Loop to 2b until no more fields And my haskell working proto type is this: module Main where -- Env User Report Version Host Printer egdata1 = [(("PD7334EU", "*ALL", "*ALL", "*ALL", "*ALL"), "Default Printer"), (("PD7334EU", "USER1", "*ALL", "*ALL", "*ALL"), "User1Printer"), (("PD7334EU", "USER2", "Report1", "Version1", "*ALL"), "User1Report1Printer"), (("PD7334EU", "*ALL", "Report2", "*ALL", "*ALL"), "Report2Printer")] type SearchFilter = (String, String, String, String, String) type Record = (SearchFilter, String) findPrinter :: String -> String -> String -> String -> String -> [Record] -> String findPrinter env user report version host printerdata = findPrinter' sf sf printerdata where sf = (env, user, report, version, host) findPrinter' :: SearchFilter -> SearchFilter -> [Record] -> String findPrinter' ("*ALL", "*ALL", "*ALL", "*ALL", "*ALL") _ _ = "" findPrinter' sf origsf printerdata | printer == "" = findPrinter' (toggle sf origsf 5) origsf printerdata | otherwise = printer where printer = searchPrinter sf printerdata searchPrinter :: SearchFilter -> [Record] -> String searchPrinter _ [] = "" searchPrinter sf ((x,p):xa) | sf == x = p | otherwise = searchPrinter sf xa toggle :: SearchFilter -> SearchFilter -> Int -> SearchFilter toggle sf origsf 0 = sf toggle sf origsf n | newValue == "*ALL" = newSF | otherwise = toggle newSF origsf (n-1) where newValue = toggleField (getSFField n sf) (getSFField n origsf) newSF = setSFField n sf newValue toggleField :: String -> String -> String toggleField "*ALL" x = x toggleField _ _ = "*ALL" getSFField :: Int -> SearchFilter -> String getSFField 1 (x,_,_,_,_) = x getSFField 2 (_,x,_,_,_) = x getSFField 3 (_,_,x,_,_) = x getSFField 4 (_,_,_,x,_) = x getSFField 5 (_,_,_,_,x) = x setSFField :: Int -> SearchFilter -> String -> SearchFilter setSFField 1 (a,b,c,d,e) f = (f,b,c,d,e) setSFField 2 (a,b,c,d,e) f = (a,f,c,d,e) setSFField 3 (a,b,c,d,e) f = (a,b,f,d,e) setSFField 4 (a,b,c,d,e) f = (a,b,c,f,e) setSFField 5 (a,b,c,d,e) f = (a,b,c,d,f) main = putStrLn (findPrinter "PD7334EU" "USER2" "Report2" "Version3" "SomeHost" egdata1) _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

introspection | meta data
by Crypt Master 05 Aug '04

05 Aug '04

Hi I recently had to implement an algorthm in C, and found the time to give it a go in Haskell to aid in learning haskell. I found myself "needing" runtime meta information on data types (well tuples which are data (a,b) = (a,b)). Does haskell allow this ? Basically I need to loop over the fields in my record. I came up with functions like this: -- Toggle fields to/from generic value toggle sf origsf 0 = sf toggle sf origsf n | newValue == "*ALL" = newSF | otherwise = toggle newSF origsf (n-1) -- <--------- Loop through fields by No where newValue = toggleField (getSFField n sf) (getSFField n origsf) -- <---- accessor functions newSF = setSFField n sf newValue .... getSFField :: Int -> SearchFilter -> String getSFField 1 (x,_,_,_,_) = x getSFField 2 (_,x,_,_,_) = x .... setSFField :: Int -> SearchFilter -> String -> SearchFilter setSFField 1 (a,b,c,d,e) f = (f,b,c,d,e) setSFField 2 (a,b,c,d,e) f = (a,f,c,d,e) .... The only problem with this is that if I want to add or remove a field, I need to change a lot of code. In most OO lanaguages I could use "reflection" to loop through my fields. In C (which also doesnt have meta data) I got round it by using pointers in an array. To add or remove a field just requires adding or removing a pointer to my array which is one line of code. The only thought I had was of using lists, but the this would mean I loose pattern matching against all values at once which is appealing for calrify of code. So what is the general haskell approach to this type of introspection/meta data problem... ? Thanks, _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 1

Re: [Haskell-cafe] introspection | meta data
by MR K P SCHUPKE 05 Aug '04

05 Aug '04

>Introspection in Haskell is provided by the Data.Generics module. The difference between the Data.Typeable and HList approach is that Generics use run-time information to make choises, HLists use the type system to make static guarantes. You can actually combine the two quite nicely and end up with statically constrained dynamics (or Stanamics as Ralf calls them) ... That is a dynamic opaque container constrained to contain only a certain group of types statically! Keean.

1 0

Re: [Haskell-cafe] introspection | meta data
by Jon Cast 05 Aug '04

05 Aug '04

Crypt Master <cryptmaster(a)hotmail.com> wrote: > I recently had to implement an algorthm in C, and found the time to > give it a go in Haskell to aid in learning haskell. > > I found myself "needing" runtime meta information on data types (well > tuples which are data (a,b) = (a,b)). Does haskell allow this ? <snip absolutely normal example> > So what is the general haskell approach to this type of > introspection/meta data problem... ? Introspection in Haskell is provided by the Data.Generics module. Try `deriving Data' and go wild (everybody else has). Jon Cast

1 0

Re: [Haskell-cafe] introspection | meta data
by MR K P SCHUPKE 05 Aug '04

05 Aug '04

>In most OO lanaguages I could use "reflection" to loop through my fields. You could try a heterogeneous list, see: http://homepages.cwi.nl/~ralf/HList/ Keean/ ,.

1 0

Re: [Haskell-cafe] Re: humor
by Jon Cast 05 Aug '04

05 Aug '04

Sean Perry <sean.perry(a)intransa.com> wrote: > Jon Cast wrote: > > > > Obviously you haven't realized the great beauty of $. You cannot like $ > > to much. foldr should be defined as follows: > > > > foldr f z [] = id $ z > > foldr f z (x:xn) = (f $ x) $ foldr f z xn > > > > etc. :) > > Am I to assume there is some sarcasm here? Hope so (-: > > (Sorry, still new to the list, learning the idioms and mannerisms) Yes. Much sarcasm (which I considered appropriate given the official subject). And one :) Jon Cast

1 0

Re: [Haskell-cafe] Re: exceptions vs. Either
by MR K P SCHUPKE 05 Aug '04

05 Aug '04

>specify that a sort function (say) returns an ordered list Fistly this is already possible in Haskell - see Oleg, Ralf and My paper: @misc{KLS04, author = "Oleg Kiselyov and Ralf L{\"a}mmel and Keean Schupke", title = "{Strongly typed heterogeneous collections}", booktitle = "{ACM SIGPLAN Workshop on Haskell}", year = 2004, month = sep, publisher = "ACM Press", notes = "To appear" } http://homepages.cwi.nl/~ralf/HList/ Here we show constrained heterogeneous lists (but you can also constrain the type in the list to turn it into a homogeneous list) that includes the ability to impose ordering constraints... Writing the constraint classes is a little involved but using it is as simple as: sort :: (HList l,HOrderedList l') => l -> l' and supposing you dont like having to write the complete type, you can use: ordered :: HOrderedList l => l -> l ordered = id then you can use this in a function with no type given: sort = ordered . sort' So my point is this can be added to haskell _without_ breaking any existing functionality - it is not either/or it is both/and! Keean.

1 0

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 05 Aug '04

05 Aug '04

>f (case xs of (x:_) -> x; [] -> error "whoops") -- direct style Yup, this is how I do it... I never use head! I like to pass failures back up to the level where some kind of sensible error message can be generated. In your example the error is no better than with 'head' - the point is a Nothing can be 'caught' outside of an IO monad. I would suggest using the type system as I said earlier so: toNonEmptyList :: [a] -> Maybe (NonEmpty a) toNonEmptyList (a0:_) = Just (NonEmpty a) toNonEmptyList _ = Nothing Then redefine head: head :: NonEmpty a -> a head (NonEmpty (a0:_)) = a0 Keean/

3 2

exceptions vs. Either
by Evan LaForge 04 Aug '04

04 Aug '04

Exceptions are convenient in that you can rely on libraries throwing them instead of prechecking for valid values yourself (for instance, why check that the argument to Char.digitToInt is valid if digitToInt does so already), and you don't have to modify a lot of function signatures. Unfortunately, in the face of lazy evaluation, they can get thrown in unexpected places. Even with Exception.evaluate, or code which is already explicitly sequenced in the IO monad, like "t <- Exception.evaluate (map Char.digitToInt ['a'..'g'])" an exception will only be thrown when you inspect the last element of 't'. (digitToInt confusingly accepts hex "digits"---shouldn't it be "higitToInt" then?). So it seems to me that if you are, say, checking input, the options are to handle exceptions from the checking code but expect them to come from the processing code, or decorate all checking code with Rights and Lefts. Problems with the first option are that checking code could also trigger some exceptions, and Prelude functions throw undescriptive errors like "user error" or low level ones like "refuted pattern match" and catching them over the entire program means you could stifle a lot of real errors. This implies that you have to make specific exceptions and convert Prelude and library exceptions into yours as low down as possible, which is cluttering but maybe not as cluttering as Either. Problems with the second option are many of the problems that lead to us wanting exceptions in the first place. Using Either seems much simpler and functional-friendly. So then, in what contexts are exceptions appropriate in haskell?

9 12

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>No, I don't think so. I only want the bug to be reported I think preventing the bug using the type system if possible is a good idea... something that should be encouraged! >and not a "corner case" that should be "handled". So if the list depends on user input is not the empty list a corner case of the function on user input? >write small leaf functions like these with an implicit file/line This is a good idea - If I have given the impression I am opposed to it then I have not expressed myself very well. I just think where this can be avoided using the type system in the first place is an even better idea. Design by contract is the way forward for large complex systems, and where that contract can be expressed using the type system is a selling point for Haskell in such applications. >It seems difficult to generalize this, though. Again for read you can use "reads"... Sven Panne said: "reads" is probably what you are looking for: Prelude> (reads :: ReadS Integer) "" [] Prelude> (reads :: ReadS Integer) "a" [] Prelude> (reads :: ReadS Integer) "2" [(2,"")] Prelude> (reads :: ReadS Integer) "123blah" [(123,"blah")] Keean.

1 0

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>Yes, in principle. But that means you still need to write more and >tedious code to deal with it. Just because code is tedious does not mean it is not necessary to handle all corner cases. A robust application does not fail when given unexpected input. >Are you going to discard lists in favor of tuples, Of course not... You can actually define constrained datatypes where the maximum length is a parameter of the type. Unfortunately in haskell because these values have to be at the type level we end up encoding them as Peano numbers... See Conor McBrides "Faking It" paper for some examples of how to do this. Also see Oleg, Ralf and My paper "Stronly Typed Heterogeneous Lists" to se how far you can get with these techniques (we define a heterogeneous list that can be constrained in many ways, including by length, or content type). I guess in a way you are nearly right as these techniques fundamentaly us binary products like (,) - but thats also exactly what any binary constructor including ':' is anyway... >The only difference is that I want to do it automatically My point was that you can manually label some functions, but to automatically do it for all functions is going to cause big stack space problems - think about recursive functions... or mutually recursive functions... Keean.

2 1

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>Sometimes the qualification of an error changes while it is propagated. There was a discussion about this recently (on the ghc list I think)( The proposed (partial) solution is to use mapException: mapExceptionIO :: (Exception -> Exception) -> IO a -> IO a mapExceptionIO f io = Exception.catch io (\e -> throw $ f e) which would be used like: main = mapExceptionIO (\x -> ErrorCall $ showString "in main: " $ show x) $ do Exceptions can be thrown from anywhere, but can only be caught in the IO monad hence mapException must be in the IO monad. Map exception allows a kind of 'backtrace' allowing all functions in the call stack of a function which throws an exception to annotate the error message. Exceptions should only really be used for unpredictcable events, I find that the defintion of functions like head is lacking rigor... I would prefer to see: head :: [a] -> Maybe a head (a0:_) = Just a0 head _ = Nothing I think functions should only throw an exception if they are subject to the halting problem (the only way to tell if an algorith will fail is to run that algorith) - head and lots of other functions in the prelude are not subject to this, and in my opinion should really be returning Maybe... nobody said anything about me previous post about using the type system to have 'validated' types - does this mean everyone thinks its a good idea, or was it too off topic - too obvious? Keean.

4 3

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>mins = map ((\(x:_)->x).sort) maybe what you meant was: case sort x of (x:_) -> ... do whatever with x ... _ -> ... do failure conition ... As I said, if you can _guarantee_ non failure I guess head is okay, but the fact that this thread started with the observation that the error produced by head is difficault to track dow n we must conclude that programmers make mistakes and cannot be trusted to make such guarantees .... Hence my suggestion to use the type system. Effectively the 'case' forms a guarantee of non-emtyness for the stuff in the case... but you cannot pass this guarantee into functions like 'head' Using the type system to encode such things allows this 'guarantee' to be passed into functions... Keean.

1 0

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>As for head, I think it's fine that it throws an error because it is >specified to be defined for only non-empty lists. But surely it is better to encode this fact in the type system by useing a separate type for non-empty lists. >Argh, no! Violating the precondition of head is a bug in the caller, >I want it to crash, Again by encoding this at the type level the compiler can guarantee that that it is not going to crash or return a compile time error... also by forcing the programmer to deliberatly cast to a non-empty list you make explicit the 'non-emptyness'... also the type signature of head contains the 'contract' that the list must be non empty. >A mechanism for a function to report the caller site would obliviate >the need for all this ugliness Unfortunately the cost of this is prohabative as the call stack would have to contain backtrace information. Also due to lazy evaluation the 'call site' may not be what you expect. I guess we just have to disagree I find very little cause to use head. Here's what John Meacham had to say: ----------------------------------- Note that pattern matching rather than deconstruction functions have a number of benefits, not just relating to error messages, consider two functions which use the head of their argument. f xs =3D ... head xs ...=20 g (x:_) =3D ... x ... now, g is superior to f in several ways,=20 1) the error message generated if the pattern fails will have the file name, line number and name of function 2) everything but the head of xs may be garbage collected right away since there is no reference to the rest of the list! This can cure some nasty space leaks and is vital in certain cases.=20 3) even the simplest compiler will realize g is stirct in its first argument and take advantage of the numerous optimizations that entails.=20 A good compiler may figure out 2 and 3 with f, but it can't always, and w= hy take the chance it won't? All of these benefits apply to deconstructing more complicated types too, so using pattern matching for deconstruction is just a good habit to get into. -------------------------------------- Keean.

2 1

Re: [Haskell-cafe] exceptions vs. Either
by David Menendez 04 Aug '04

04 Aug '04

David Menendez writes: > MR K P SCHUPKE writes: > > > I would suggest using the type system as I said earlier so: > > > > toNonEmptyList :: [a] -> Maybe (NonEmpty a) > > toNonEmptyList (a0:_) = Just (NonEmpty a) > > toNonEmptyList _ = Nothing > > > > Then redefine head: > > > > head :: NonEmpty a -> a > > head (NonEmpty (a0:_)) = a0 > > Oleg described a similar technique a few months ago. > > From <http://haskell.org/pipermail/haskell/2004-June/014271.html>: > > |> newtype NonEmpty a = NonEmpty [a] -- the NonEmpty constructor should > |> -- be hidden (not exported from its module) > |> > |> head' (NonEmpty a) = head a -- no error can occur! Can use unsafe > version > |> tail' (NonEmpty a) = tail a -- no error can occur! Can use unsafe > version > |> > |> -- trusted function: the only one that can use NonEmpty constructor. > |> fork_list_len f g x = if null x then f else g (NonEmpty x) > |> > |> revers x = revers' x [] > |> where > |> revers' x accum = fork_list_len accum (g accum) x > |> g accum x = revers' (tail' x) ((head' x):accum) > > We have these equivalences: > > toNonEmptyList == fork_list_len Nothing Just > fork_list_len d f == maybe d f . toNonEmptyList > > I think defining 'toNonEmptyList' in terms of 'fork_list_len' is > cleaner, but that's just my personal taste. (As it happens, I ended up > defining a very similar function 'cons' in my recursion module[1]). > > [1] > <http://www.eyrie.org/~zednenem/2004/hsce/Control.Recursion.html#v% > 3Acons> -- David Menendez <zednenem(a)psualum.com> <http://www.eyrie.org/~zednenem/>

1 0

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 03 Aug '04

03 Aug '04

A lot of programming errors come from failure to correctly validate. I remember being taught to validate on input _and_ validate when you use a value. So I would say do both - use maybe for input functions, and exceptions for when you use a value. You can use the type system to make this more efficient. Imagine you want an integer between 10 and 20, you have a function like: newtype ValidInt = Valid Int validateInt :: Int -> Maybe ValidInt validateInt x | x>=10 && x<=20 = Just (Valid x) validateInt _ = Nothing Now when you validate on input - you produce an error if you get "Nothing" and in all the functions you use the value you use ValidInt instead of Int. This way you use the type system to differentiate between a valid int (does not need to be rechecked) and a normal int (which would need to be validated). Of course you must make sure you don't write more than one constructor function for ValidInt. This suggests a form of constrained constructor would be useful... Whilst this can be done in Haskell, it is not easy and involves reifying the value to a type, and using a type class to constrain the data statement. Really here we are dealing with dependant types, and this is much easier in a dependantly typed language like Epigram. Keean.

3 2

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 03 Aug '04

03 Aug '04

>> Is there any easy way (TH?) to amend these to output the line number Or use GHC's reifyLocation 'function' in a mapException. Keean.

1 0