February 2007 - Haskell-prime

Disjunctive tuples
by Thomas Davie 22 Feb '07

22 Feb '07

Hi, I have a rather late suggestion for addition to Haskell. To appease those who I know think that Haskell is over-complicated already and should be having things removed, I'd like to suggest something that I think makes the language rather more consistent, and thus simplifies it despite adding things to it. My suggestion is for a disjunctive tuple syntax using the | symbol. We might right functions as such: fromEither :: Either a b -> (a | b) fromEither (Left x) = (x | ) fromEither (Right x) = ( | x) toEither :: (a | b) -> Either a b toEither (x | ) = Left x toEither ( | x) = Right x makeMoreComplexDisjunction :: Int -> Bool -> Int -> Float -> (Bool | Int | Float) makeMoreComplexDisjunction 1 x _ _ = (x | | ) makeMoreComplexDisjunction 2 _ x _ = ( | x | ) makeMoreComplexDisjunction 3 _ _ x = ( | | x) Using the '|' character gives a nice obvious syntax, and does not (I believe) conflict with anything in the Haskell 98 definition, as '|' is currently reserved for guards. Tom Davie

2 1

Polymorphic components, so far
by Iavor Diatchki 20 Feb '07

20 Feb '07

Hello, Thanks to everyone who took time to comment on my notes. My & Isaac's previous post spawned a few separate discussions so I though I'd send a separate message to summarize the status of what has happened so far with regard to polymorphic components. * Rank-2 vs Rank-n types. I think that this is the most important issue that we need to resolve which is why I am placing it first :-) Here are our options: - option 1: Hugs style rank-2 types (what I described, very briefly) - option 2: GHC 6.4 style rank-2 types. As far as I understand, these are the details: * Based on "Putting Type Annotations to Work". * Predicative (type variables range only over simple (mono) types) We do not need to compare schemes for equality but, rather, we compare them for generality, using a kind of sub-typing. There * Notation for polymorphic types with explicit quantifiers. The main issue is if we should allow some corner case notational issues, such as empty quantifier lists, and quantified variables that are not mentioned in the type. - option 1: disallow these cases because they are likely to be accidental mistakes. - option 2: allow them because they make automatic program generation simpler. My initial proposal was suggesting 2 but I think that, having heard the arguments, I am leaning towards option 1. * Equality of schemes for labeled fields in different constructors. My suggestion did not seem to be too controversial. Stephanie is leaning towards a more semantic comparison of schemes. Indeed, just using alpha equivalence might be a bit too weak in some cases. Another, still fairly syntactic option, would be to pick a fixed order for the variables in quantifiers (e.g., alphabetic) for the purposes of comparison. * Pattern matching on polymorphic fields. This does not appear to be too controversial, although Atze had some reservations about this design choice. This is all that I recall, apologies if I missed something (if I did and someone notices, please post a replay so that we can keep track of what is going on). -Iavor

8 17

do-and-if-then-else modification
by isaac jones 19 Feb '07

19 Feb '07

Iavor and I just made the trivial modification for DoAndIfThenElse syntax as described here: http://hackage.haskell.org/trac/haskell-prime/wiki/DoAndIfThenElse You can see the change here: http://darcs.haskell.org/haskell-prime-report/report/haskell-report-html/ex… (Is there anything else that needs to change?) As always, we provide a quick view of the status of Haskell' here: http://hackage.haskell.org/trac/haskell-prime/wiki/Status%27 Any comments on this modification? How do people feel about the suggestion that we do it for case statements as well? peace, isaac

6 8

Fixity resolution, possible specification
by Twan van Laarhoven 19 Feb '07

19 Feb '07

Hello, I just came up with a (in my opinion) quite elegant description of fixity resolution as proposed here: http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution Any comments on this idea (see below)? Also, I realize that I am not a member of the H' committee, but I see no reason why I can't try help out. Twan Changes to the report: == 3 Expressions == The lexical syntax is changed to: oexp -> pexp [ qop_1 pexp_1 ... qop_{n-1} pexp_{n-1}] & (\tr{expression with operators}, n>=0) | @-@ oexp & (\tr{negation}) aexp -> ... | @(@ pexp_1 qop_1 ... pexp_n qop_n @)@ & (\tr{left section}, n>=1) | @(@ qop_1 pexp_1 ... qop_n pexp_n @)@ & (\tr{right section}, n>=1) oexp replaces exp^0, pexp replaces exp^10: exp -> oexp @::@ [context @=>@] type & (\tr{expression type signature}) | oexp pexp -> @\@ apat_1 ... apat_n @->@ exp & (\tr{lambda abstraction}, n>=1) ... lexp and rexp are no longer needed. (Perhaps all but the last element of these operator chains can be restricted so they do not contain lambda, let or if. This would mean that the longest parse rule is not needed there. ) The part after "A note about parsing" is dropped. === 3.4 Operator Applications === After: The form e1 qop e2 is the infix application of binary operator qop to expressions e1 and e2. Add: If after parsing there are operator applications containing more then one operator, then fixity resolution (see Section 3.4.1) has to be performed. Add subsection: === 3.4.1 Fixity Resolution === Fixity resolution is applied after parsing to convert all operator applications to the form @e1 qop e2@. Fixity resolution is specified by the following algorithm: Let $e$ be an expression anywhere in the parse tree consisting of alternating operators and expressions. Let $O$ be the list of operator with the lowest precedence level among those in $e$. If all operators in $O$ are declared left-associative (@infixl@), then: -> $e$ is split at the rightmost element $o$ of $O$. Splitting means that in the parse tree, $e$ is replaced by @(everything in $e$ before $o$) $o$ (everything in $e$ after o)@. If all operators in $O$ are declared right-associative (@infixr@), then: -> $e$ is split at the leftmost element of $O$. If $O$ contains a single operator which is declared non-associative (@infix@), then: -> $e$ is split at that operator. In all other cases -> an error is reported. This process is repeated until all expressions contain a single operator. The fixity resolution is also applied to sections (see Section 3.5). === 3.5 Sections === Add: Just like operator applications, sections containing multiple operators are resolved using fixity resolution (see Section 3.4.1). Remove: The example about the let/lambda meta rule.

2 1

Polymorphic Components
by Iavor Diatchki 06 Feb '07

06 Feb '07

Hello, I have written some notes about changes to Haskell 98 that are required to add the "polymorphic components" extension. The purpose of the notes is to enumerate all the details that need to be specified in the Haskell report. I don't have access to the haskell-prime wiki so I attached the notes to the ticke for polymorphic components: http://hackage.haskell.org/trac/haskell-prime/ticket/57 When there are different ways to do things I have tried to enumerate the alternatives and the PROPOSAL paragraph marks the choice that I favor. -Iavor

20 45

self moderation (or, what is Haskell' about)
by isaac jones 03 Feb '07

03 Feb '07

Folks, We all love to talk about fun and exciting new things, and I really don't like to "change the subject", as it were, of a mailing list conversation unless it's very necessary. This list is unmoderated, and will stay unmoderated. Anyone can post whatever they want, and it's up to the community of the list to decide what's appropriate and what's off topic. If you see stuff that you think is off topic, please invite that discussion to move over to haskell-cafe or what-have-you. If you start a discussion about something core to Haskell', especially the "definitely in" topics, and the conversation wanders into strange and unknown territory, please, please re-focus your thread to get back to the important topics. Start a new thread if necessary with a summary of the discussion so far and the open questions. We've had a lot of people unsubscribing from the list in the last few days, for what it's worth. People get a mistaken impression about "What Haskell' is about" based on the discussions of the list, and sometimes it scares people :) So just be aware that the unmoderated list is _not_ a good way to get a sense of what's going on in Haskell'. Watch for announcements from the committee and requests for help from me and others for actually writing the report. Also, keep an eye on the status page of the wiki: http://hackage.haskell.org/trac/haskell-prime peace, isaac

1 0

ADT views Re: [Haskell] Views in Haskell
by Bulat Ziganshin 03 Feb '07

03 Feb '07

Hello Simon, Monday, January 22, 2007, 5:57:27 PM, you wrote: > adding "view patterns" to Haskell. many of us was attracted to Haskell because it has clear and simple syntax. but many Hugs/GHC extensions done by independent developers differ in the syntax they used, because these developers either has their own taste or just don't bother with syntax issues. you may remember my examples of how the guards syntax may be reused for GADTs and class declarations: data T a = C1 a | Show a || C2 a | Read a instance Binary a | Storable a where ... but unfortunately we've finished with 3 different syntax for the same things i'm sorry for so big introduction but this shows why i don't like the *syntax* you've proposed. you wrote "The key feature of this proposal is its modesty, rather than its ambition..." that means that this proposal is great for you as implementor - you should write a minimal amount of code to add this to GHC. but let's look at this from viewpoint of one who learn and then use Haskell: first, he should learn two syntax to do matching instead of one. second, he should learn how to implement them both. third, he need to make decision of whether to provide abstract interface to his datatypes or not. if he make a bad decision, he will end either in rewriting lot of code (and change is not s///-style !) or having a lots of trivial definitions like data List a = Nil | Cons a (List a) nil Nil = Just Nil nil _ = Nothing cons (Cons a b) = Just (a,b) cons _ = Nothing then IDEs will automate this code generation and "refactoring" of code, etc, etc :) >On the other hand, view patterns can do arbitrary computation, >perhaps expensive. So it's good to have a syntactically-distinct >notation that reminds the programmer that some computation beyond >ordinary pattern matching may be going on. *you* said :) are you don't know that explicit control of generated code is "advantage" of low-level languages? we use higher-level languages exactly to avoid dealing with implementation details. as far as we can describe algorithm in some form understandable by computer, we are done. lazy evaluation, classes and even plain functions are the tools to describe algorithm without having any guarantees about its efficiency so, i propose to define views in a way that 1) preserves syntax compatibility with existing patterns 2) allow to define "class of views" to provide common interface to all sequences, for example 3) old-good guards may be used instead of Nothing to provide "backtacking" (are you don't think that we already have full Prolog power between "|" and "="? :) something like this: data Coord = Coord Float Float view of Coord = Polar Float Float where Polar r d = Coord (r*d) (r+d) -- construction Coord x y | x/=0 || y/=0 = Polar (x*y) (x+y) -- matching f :: Coord -> Float f (Polar r _) = r f (Coord 0 0) = error "..." class ListLike c e where head :: c -> e tail :: c -> c class view of ListLike where Cons :: e -> e -> c Nil :: c instance ListLike [a] a where head (x:xs) = x tail (x:xs) = xs instance view ListLike [a] a where Cons x xs = x:xs -- for constructing new values using Cons (x:xs) = Cons x xs -- used to match Cons in patterns Nil = xs xs | null xs = Nil i know that this is longer way (and probably will be never implemented) but the language should remain orthogonal. otherwise it will dead in terrible tortures :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

6 11

RE: List syntax (was: Re: help from the community?)
by Sittampalam, Ganesh 02 Feb '07

02 Feb '07

On 2/2/07, Kirsten Chevalier <catamorphism(a)gmail.com> wrote: > On the other hand, with constant lists and tuples, you're probably not > going to frequently edit the same constant list value. Am I missing > something? Sometimes people maintain static configuration items and the like in lists. I've certainly found myself wishing for the trailing ',' to be allowed on some occasions, though it's not a big enough deal for me to argue for it strongly if there is significant opposition. I think record syntax is the other significant place where it'd be useful (more so than tuples, given that adding an item to a tuple generally involves a type change that has an impact in many other places, whereas adding a record item is often just a question of adding it to the type and to a few other locations.) Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

1 0

Global variables
by Yitzchak Gale 02 Feb '07

02 Feb '07

The trick of controlling allocation of external resources by using NOINLINE, unsafePerfromIO, and IORef to create global variables has become an indispensable technique in Haskell. It seems to work well enough with most current compilers. However, it is well known that the semantics of NOINLINE are not sufficient to guarantee that this is safe. In principle, the runtime is permitted to GC and reinstantiate these things at any time. Also, it would be nice if we could have a guarantee that global constants are not instantiated until first use. That would allow us to skip the IORef in some cases. I think this issue needs to be addressed in Haskell'. (If it has already, please accept my apologies.) Since NOINLINE has more general use, perhaps there should be a new pragma for this purpose. Thanks, Yitz

6 7

Re: Global variables
by David House 01 Feb '07

01 Feb '07

(CCing the list as this is of general concern.) On 01/02/07, Yitzchak Gale <gale(a)sefer.org> wrote: > Why is this unsafe? What could go wrong? It could segfault due to the type safety properties that unsafePerformIO breaks: import System.IO.Unsafe import Data.IORef ref :: IORef [a] ref <- newIORef [] main = do writeIORef ref [42] val <- readIORef ref print (val :: [Char]) If you use the pragma you're forced to import unsafePerformIO and hopefully check the haddock docs [1] where this issue is listed. [1]: http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO-Unsafe.html -- -David House, dmhouse(a)gmail.com

2 1