July 2007 - Haskell-prime

Re: Make it possible to evaluate monadic actions when assigning record fields
by Adde 17 Jul '07

17 Jul '07

Monads are a part of Haskell. The more tiresome monads are to use, the more tiresome Haskell is to use. I suggest we leave the decision of where and when to use them to each individual user of the language. /Adde > In any case, I'm *strongly against* further syntactic sugar for > monads, > including #1518. The more tiresome monads are, the more incentive you > have to avoid them. > > Regards, > apfelmus

9 10

(Succ Haskell') `and` $ dependent types
by Vivian McPhail 14 Jul '07

14 Jul '07

Hello, As the authors point out [1], coal-face time needs to be expended before real world adoption of Dependently-Typed functional programming. But let's get the ball rolling. They say that haskell programmers are normally averse to dependent types. Is this true? It seems to me that one of the appeals of Haskell is the ability to program in a "prove perfect, write once" (elegant) style. Is not dependent typing a good move towards this goal?. It addresses a problem [2] with which we, in our everyday common inter-hominem usage, can deal -- with which (ideal) Haskell should deal. While the major Haskell implementations would require a substantial overhaul, the change at the syntactic level appears to be minimal. There also needs to be advance with respect to programmer development (automatic edit-time inference of (some) types). What are peoples' thoughts on adding dependent types to haskell as a non-incremental evolutionary step? Does the haskell community want to stick with conservative additions to Haskell and a static base, or does the haskell community want to stay in step with the best theoretical developments? Vivian [1] http://www.informatik.uni-bonn.de/~loeh/LambdaPi.html [2] http://thread.gmane.org/gmane.comp.lang.haskell.cafe/21314

2 1

Make it possible to evaluate monadic actions when assigning record fields
by Adde 11 Jul '07

11 Jul '07

Hi, I'm forwarding this feature request as is on the advice of Neil Mitchel for discussion / possible inclusion in future versions of Haskell. #1518: Make it possible to evaluate monadic actions when assigning record fields (<-) ---------------------------------+------------------------------------------ Reporter: adde(a)trialcode.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ---------------------------------+------------------------------------------ It is currently not possible to build records from values resulting from monadic actions while still using the field-specifiers. foo :: IO Int ... data Bar = Bar { barFoo :: Int } buildBar :: IO () buildBar = do return Bar { barFoo <- foo --Evaluate foo to get the Int-value } I've found two possible ways of doing this: 1) Using temporaries to evaluate the actions before assigning which doubles the number of lines: tmp <- foo return Bar { barFoo = tmp } 2) Lifting the record constructor which prevents you from using field specifiers (and you really need field specifiers when dealing with larger records): liftM Bar foo Thanks, Adde

10 10

monomorphism restriction confusions
by Isaac Dupree 09 Jul '07

09 Jul '07

Haskell98's monomorphism restriction is too confusing! See my mistaken GHC bug report <http://hackage.haskell.org/trac/ghc/ticket/1503>. Whether a binding is monomorphic depends not just on syntax, but on the amount of type constraints on the right-hand side of a binding - and I didn't realize, because this issue usually doesn't come up (usually types are already monomorphic or are at least typeclass qualified, or at least don't have to be monomorphic to prevent a type error). Although this finally convinces me that we should dump H98 m-r in favor of the very straightforward "monomorphic pattern bindings", if we don't, at least I believe that Report Section 4.5.5, Rule 1 needs a reword. It uses "(un) restricted" to mean "restricted (to be monomorphic) IN SOME CASES". Maybe a word like "suspicious" would be less misleading than "restricted" there? Isaac

1 0

Re: [Haskell-cafe] Haskell's prefix exprs
by Stefan O'Rear 09 Jul '07

09 Jul '07

On Mon, Jul 09, 2007 at 03:55:52PM +0200, Christian Maeder wrote: > Hi, > > I would like haskell to accept the following (currently illegal) > expressions as syntactically valid prefix applications: > > f = id \ _ -> [] > g = id let x = [] in x > h = id case [] of [] -> [] > i = id do [] > j = id if True then [] else [] > > The rational is that expressions starting with a keyword should extend > as far as possible (to the right and over several lines within their > layout). > > In this case the above right hand sides (rhs) are unique juxtapositions > of two expressions. (This extension should of course apply to more than > two expressions, i. e. "f a do []") > > Furthermore the above rhs are all valid if written as infix expressions: > > f = id $ \ _ -> [] > g = id $ let x = [] in x > h = id $ case [] of [] -> [] > i = id $ do [] > j = id $ if True then [] else [] False. f = runST $ do return () is a type error. f = runST (do return ()) is legal. So your proposal isn't as pointless as you think :) > (In fact, maybe for haskell-prime "$" could be changed to a keyword.) > > Does this pose any problems that I haven't considered? Not that I know of. Indeed, the status quo is a (minor) pain to parse, and in my Haskell compiler project I *wanted* to implement your proposal. > I think only more (and shorter) illegal haskell programs will become legal. > > Cheers Christian > > Maybe someone else can work out the details for Haskell's grammar Not hard at all. In http://haskell.org/onlinereport/syntax-iso.html, change: exp^10 -> \ apat[1] ... apat[n] -> exp (lambda abstraction, n>=1) | let decls in exp (let expression) | if exp then exp else exp (conditional) | case exp of { alts } (case expression) | do { stmts } (do expression) | fexp fexp -> [fexp] aexp (function application) aexp -> qvar (variable) | gcon (general constructor) | literal | ( exp ) (parenthesized expression) | ( exp[1] , ... , exp[k] ) (tuple, k>=2) | [ exp[1] , ... , exp[k] ] (list, k>=1) | [ exp[1] [, exp[2]] .. [exp[3]] ] (arithmetic sequence) | [ exp | qual[1] , ... , qual[n] ] (list comprehension, n>=1) | ( exp^i+1 qop^(a,i) ) (left section) | ( lexp^i qop^(l,i) ) (left section) | ( qop^(a,i)[<->] exp^i+1 ) (right section) | ( qop^(r,i)[<->] rexp^i ) (right section) | qcon { fbind[1] , ... , fbind[n] } (labeled construction, n>=0) | aexp[<qcon>] { fbind[1] , ... , fbind[n] } (labeled update, n >= 1) to: exp^10 -> [exp^10] aexp (function application) aexp -> \ apat[1] ... apat[n] -> exp (lambda abstraction, n>=1) | let decls in exp (let expression) | if exp then exp else exp (conditional) | case exp of { alts } (case expression) | do { stmts } (do expression) | qvar (variable) | gcon (general constructor) | literal | ( exp ) (parenthesized expression) | ( exp[1] , ... , exp[k] ) (tuple, k>=2) | [ exp[1] , ... , exp[k] ] (list, k>=1) | [ exp[1] [, exp[2]] .. [exp[3]] ] (arithmetic sequence) | [ exp | qual[1] , ... , qual[n] ] (list comprehension, n>=1) | ( exp^i+1 qop^(a,i) ) (left section) | ( lexp^i qop^(l,i) ) (left section) | ( qop^(a,i)[<->] exp^i+1 ) (right section) | ( qop^(r,i)[<->] rexp^i ) (right section) | qcon { fbind[1] , ... , fbind[n] } (labeled construction, n>=0) | aexp[<qcon>] { fbind[1] , ... , fbind[n] } (labeled update, n >= 1) All new ambiguities are resolved adequately by the let/lambda meta rule. > (I've posted this message to glasgow-haskell-users before, but it > applies to every Haskell implementation and should be discussed here.) haskell-prime(a)haskell.org would be even better. Stefan

2 1

Nested pattern binding translates to outermost binding?
by Dan Weston 09 Jul '07

09 Jul '07

From Haskell' ticket #76: http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns > The main idea is to add a single new production to the syntax > of patterns > pat ::= !pat Experiments (ghci -fbang-patterns -O2 -S, rename identifiers, then diff) shows that nested pattern bindings are equivalent to the outermost binding: !(!pat) ==> !pat !(~pat) ==> !pat ~(~pat) ==> ~pat ~(!pat) ==> ~pat but I do not see any wording to that effect either in the Haskell 98 report, the GHC documentation, or the Haskell' wiki. Have I overlooked it, or does it follow from the existing language definition? Dan

4 4