February 2006 - Haskell-prime

RE: Scoped type variables
by Simon Peyton-Jones 10 Feb '06

10 Feb '06

| > b) A pattern type signature may bring into scope a skolem bound | > in the same pattern: | > data T where | > MkT :: a -> (a->Int) -> T | > f (MkT (x::a) f) = ... | > | > The skolem bound by MkT can be bound *only* in the patterns that | > are the arguments to MkT (i.e. pretty much right away). | | I see -- my scheme was overly simple. But this too feels unsatisfactory. | What if we want to give signatures for both arguments? Will the a's | be the same? Yes f (MkT (x::a) (f::a->Int)) = ... You can imagine that either (a) both bind 'a' to the skolem, but must do consistently; or (b) that (x::a) binds 'a', and (f::a->Int) is a bound occurrence. It doesn't matter which you choose, I think. Simon

2 1

runtime reflection for classes
by Johannes Waldmann 10 Feb '06

10 Feb '06

With Data.Generics, we can get an object's type, constructor and fields. I think there should be way to get the object's class(es) and methods. E. g. I want to find out whether the object's type implements Show, and if so, call the show method (and if not, call some replacement). See http://www.haskell.org//pipermail/haskell/2005-November/016992.html see also http://java.sun.com/docs/books/tutorial/reflect/ I know this is again specific to one-parameter type classes. But still, these things occur frequently, don't they. As for classes with more parameters, I guess implementation-wise it is about how to get a representation of the dictionary, and syntax-wise it is about how to specify what dictionary we want. Also I know that Metaprogramming should be done at compile time rather than at run time (as far as possible), and I know that Template Haskell does offer a lot in that direction. But with TH, you construct an abstract source code representation. My idea here is different: I want to write concrete source code that inspects (runtime) type information. (So I don't have to worry about monads generating unique names etc.) Respectfully submitted, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

3 5

Fwd: [Haskell] context rules for "default"
by Bulat Ziganshin 10 Feb '06

10 Feb '06

it seems like a good question for committee ;) This is a forwarded message From: Doug McIlroy <doug(a)cs.dartmouth.edu> To: haskell(a)haskell.org Date: Thursday, February 09, 2006, 11:17:36 PM Subject: [Haskell] context rules for "default" ===8<==============Original message text=============== What is the rationale for the requirement that, in order for the ambiguous type of a numeric constant to be resolved by the default declaration, all classes in the context must be in the Standard Prelude or Standard Library (Revised Report 4.3.4)? This makes it hard to introduce new polymorphic functions whose domain includes the integers. Doug McIlroy _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell ===8<===========End of original message text=========== -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

First class labels
by Claus Reinke 10 Feb '06

10 Feb '06

[The reader will have noticed the absence of the words extensible polymorphic records in the subject line] If the long-overdue overhaul of Haskell's record system appears to be out of scope for Haskell' (??), I suggest to add some form of first-class labels to Haskell' (to be really useful, this depends on real type classes, not the cut-down version of Haskell 98). I often find myself coding up my own records, which is fairly quick and painless, though of course lacking the comfort of a real records systems (see code at bottom of this message; one might add some syntactic sugar, or not). The two main problems I have with this are (a) the need for so-called "extensions" (I see these features merely as removing needless restrictions, and will be very disappointed if Haskell' does not provide for them, not even optionally) (b) the need to declare my labels. it is not so much the typing, but: - possible namespace overlaps (someone might want to use my labels as constructor names) - the need for a common import origin (someone has to declare all those labels, and all users better agree on who that someone is) This suggestion is concerned with (b). I propose to add first class labels to Haskell' (every label is a constant, the only inhabitant of its type). I outline three options, of which option 1 is my personal favourite, followed by option 3: Option 1: remove the need to declare labels, make them identifiable as such in use. TREX demonstrates that this is possible. in the past (when I was using Hugs more than GHC), I have been known to abuse TREX, not for its records, but for its labels. In other words, I'd use single-field dummy records "(mylabel=())" as labels in constructions like the one at the bottom of this message. pro: simple in use, labels have their own namespace, no conflicting imports, known to work con: need to give up some identifiable space in the language for labels Option 2: add sharing imports to the module language. SML supports something like that, I think. that would allow importers to declare that the various imported declarations of a label are not in conflict, but refer to the very same type. pro: seems like a useful feature anyway con: more complex than needed for this proposal, and would be very verbose in use Option 3: add a "magic" standard module Data.Label, which implicitly exports all possible labels and only such. that would allow all importers to refer to a common origin for their label declarations. imports from that module would amount to declarations of shared label types: "import Data.Label(mylabel1,mylabel2)" pro: no syntax extension or separate label namespace, no problems with common imports con: no separate label namespace, labels still need to be declared, by means of import Either 1 or 3 should be much easier to implement than full records, and either option would be a small change, avoiding the main problem of a full records system: that noone can agree on what the ultimate form should look like. Either option would enable a pragmatic approach to the problem while we are waiting for the real records. What do you think? Claus related: - tweak the existing records system (none) http://hackage.haskell.org/trac/haskell-prime/ticket/27 - add overlapping or incoherent instances (probably no) http://hackage.haskell.org/trac/haskell-prime/ticket/54 - add FunctionalDependencies (probably no) http://hackage.haskell.org/trac/haskell-prime/ticket/36 - add multi parameter type classes (probably yes) http://hackage.haskell.org/trac/haskell-prime/ticket/49 ---------------------------------------- {-# OPTIONS -fglasgow-exts #-} {-# OPTIONS -fallow-overlapping-instances #-} -- poor man's records using nested tuples and declared labels: class Select label val rec | label rec -> val where sel :: rec -> label -> val instance Select label val ((label,val),r) where sel ((_,val),_) label = val instance Select label val r => Select label val (l,r) where sel (_,r) label = sel r label -- some labels and examples data A = A deriving Show data B = B deriving Show data C = C deriving Show data D = D deriving Show r1 = ((A,True),((B,'a'),((C,1),()))) r2 = ((A,False),((B,'b'),((C,2),r1))) x1 r = (r `sel` A, r `sel` B, r `sel` C)

1 1

RE: Re[2]: Tuple-like constructors
by Simon Peyton-Jones 09 Feb '06

09 Feb '06

| There has been a suggestion that the 'deriving' mechanism be de-coupled | from the datatype declaration. Together with a generic default | definition, that means you could write something like | | deriving Bin for (,,,,,,,,,,,,,,,,,,,,) | | and hence not need to write the tedious instance header yourself, | since the compiler can easily infer it. Yes -- a couple of times I've nearly gotten down to implementing this. Given that we have the deriving mechanism at all, we might as well make it a bit more useful. The only real obstacle is defining a suitable syntax. It makes the language bigger, but not in a deep way. Simon

2 1

LIbraries? Matrices?
by Jim Apple 09 Feb '06

09 Feb '06

Is this the appropriate place to discuss libraries for HPrime? Clearly, we can't really be sure what changes (if any) can be made to existing libraries until the core language is decided upon. On the other hand, we might agree that some libraries should be added, though their interface must wait until the language solidifies. I'm thinking here of a standard matrix library. Please excuse me if this is the wrong forum. Jim

1 0

RE: Priorities
by Simon Peyton-Jones 09 Feb '06

09 Feb '06

| Some experts (like Hans Boehm) argue, that concurrency can't be added to | the language as a library. | http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf | | This is true for many imperative programming languages. Haskell seems | to be an exception: | http://www.haskell.org//pipermail/glasgow-haskell-users/2005-December/00 9417.html The interface can be a library, but (a) what libraries are available is part of the language definition and (b) it's hard to build a good implementation without runtime support. And the nature of the runtime support depends on what the library interface is. So a programmer asks "can I write my Haskell' program using concurrency?". To answer that question, concurrency needs to be specified as part of Haskell', just as (say) Integer and its operations do. [Of course, we can choose not to; and then Haskell' programs will be single-threaded.] Simon

8 14

RE: Scoped type variables
by Simon Peyton-Jones 08 Feb '06

08 Feb '06

| I think we should "do the simplest thing that could possibly work", | and then see if we really need more. By "work", I mean a compatible | extension of H98 that makes it possible to add type signatures for | local bindings (which isn't always possible in H98). How about: | | * no implicit binding of type variables: to bind, use "forall". | | * pattern type annotations allowed only at the top level of pattern | bindings and lambda arguments (not on sub-patterns or arguments of | function bindings). | | * no result type annotations (except on pattern bindings, where they're | equivalent to top-level pattern type annotations). | I agree with the "simplest thing" plan. But if HPrime is to include existentials, we MUST have a way to name the type variables they bind, otherwise we can't write signatures that involve them. Stephanie and Dimitrios and I are working on this scheme: * Scoped type variables stand for type *variables*, not types. * Type variables are brought into scope only by one of two ways: a) The forall'd variables of a declaration type signature f :: forall a b. <type> f x y = e b) A pattern type signature may bring into scope a skolem bound in the same pattern: data T where MkT :: a -> (a->Int) -> T f (MkT (x::a) f) = ... The skolem bound by MkT can be bound *only* in the patterns that are the arguments to MkT (i.e. pretty much right away). The idea is that scoped type variables can be bound either at, or very close to, the point at which they are actually abstracted. This is a good topic to debate. S+D+I will try to put forth a set of rules shortly. Simon

3 2

Java-like
by Bulat Ziganshin 08 Feb '06

08 Feb '06

Hello haskell-prime, about limiting variable usage inside a function to some interface - it is possible, although is not pleasant :) {-# OPTIONS_GHC -fglasgow-exts #-} main = do return "xx" >>= ((\x -> print x) :: Show a => a -> IO ()) main2 = do return "xx" >>= (\(x:: (forall a . (Show a) => a)) -> print x) main3 = do (x :: forall a . Show a => a) <- return "xx" print x in this module, only "main" compiles ok -- Best regards, Bulat mailto:bulatz@HotPOP.com

4 9

Restricted Data Types: A reformulation
by John Meacham 08 Feb '06

08 Feb '06

I am trying to reformulate restricted data types such that they can easily be implemented by jhc and possibly standardized independent of the implementation method and would like to run what I have so far by the list. Unlike the original paper, I will treat the user-visible changes to the type system and the implementation as completely separate. (partially because there is a range of implementations) some set up: newtype Eq a => Set a = Set (List a) singleton :: Eq a => a -> Set a class Monad m where return :: a -> m a instance Monad Set where return x = singleton x okay, our goal is to make this typesafe. I think we can do with with only two changes to the inferencer algorithm. when checking instance declarations, usually we just check that the type of the body is subsumed by the type of the method instantiated to the head of the instance declaration, so we would check that singleton :: Eq a => a -> Set a is at least as general as "return :: a -> Set a" normally this would fail since there is no Eq constraint on the right, however the 'Set a' in returns type implies Eq a is satisfied. so the first rule is *** 1. check compatability of the body of an instance against the specialized method type with any context's implied by the type constructors added. so although the straight substitution is return :: a -> Set a we actually compare against Eq a => a -> Set a since the Eq a is added due to the Set a. and now it typechecks just fine now we just need to make sure that it is impossible to form a Set a for an a that is not an instance of Eq. The invarient that Set a implies Eq a must be maintained. fortunatly, there are only two base ways 'Set a' can come about, the application of the 'Set' constructor and a type signature. haskell 98 already adds Eq a to the context of the constructor so that is fine so we just need to make the following rule *** 2. type signatures that contain the term 'Set a' for any a must also have an Eq a constraint or it is a static error. (or if a is a concrete type, then an appropriate instance must be in scope) now, there is no way for a 'Set a' to come about without an Eq a being added, inductively, the constraints will never be dropped so the invarient is maintained that any type containing a 'Set a' _always_ comes with an 'Eq a' in its context. I believe these two rules are the only user visible changes needed to the haskell type system and are quite straightforward. someone please check me on this though, I could have missed some cases in rule 2, but I do believe a varient of these rules will do. the important thing is that it is completely independent of the implementation. Implementation: typecase based classes such as jhc: done! no need to do anything, all class typechecking is purely for the generation of error messages as there is no dictionary transformation that needs to be applied. Dictionary passing implemantions such as ghcs are a little trickier, but I think it is simpler than in the original paper. first, lets degusar the classes away, our dictionaries: data EqDict a = ... data MonadDict m = MonadDict { return :: forall a . a -> m a } eqDictInt :: EqDict Int eqDictInt = ... monadDictIO :: MonadDict IO monadDictIO = ... return :: MonadDict m -> a -> m a singleton :: EqDict a -> a -> Set a so, the specialized return for IO is defined as follows: returnIO :: a -> IO a returnIO = return monadDictIO all is well an good, each class turns into a dictionary data type, each instance declares a global dictionary for that type/class pair and instantiating a method is as simple as applying it to the right global dictionary. now the trouble comes into the following the obvoious thing to do: monadDictSet :: MonadDict Set monadDictSet = MonadDict { return = singleton -- ^ type error! } which is a type errror! singleton needs an EqDict argument. now the solution becomes clear! rather than define a global monadDictSet, define a function that generates an appropriate monadDictSet given an appropriate Eq instance, so instead we have mkMonadDictSet :: EqDict a -> MonadDict Set mkMonadDictSet eqDict = MonadDict { return = singleton eqDict } now, everything typechecks just fine! but what do we do when we need a MonadDictSet? we simply apply mkMonadDictSet to the EqDict which we _know_ is available because rule #2 above guarentees that whenever a 'Set a' occurs, an 'Eq a' context is there and hence the right 'Eq a' dictionary is available. so, the following instantiation of return return :: Int -> Set Int gets desugared to: return (mkMonadDictSet eqDictInt) I belive this makes intuitive sense to, the class constraint on the data type basically means that "dictionaries for this type may be dependent on dictionaries in my constraint" This introduces no overhead in the normal case, and very minimal constant time overhead when restricted types are used. The main issue I can think of is that you would definitly want to do a full-lazyness pass after this desugaring to pull the dictionary creation out as far as possible to avoid adversly affecting memory usage. Let me know what you think. I could be missing something. but if we are going to standardize something like restricted types, seperating out the 'user visible' type system changes and the implementation would definitly be something we want to do. John -- John Meacham - ⑆repetae.net⑆john⑈

4 10