- Haskell-prime - Haskell.org

default for quotRem in terms of divMod?
by Isaac Dupree 07 Aug '07

07 Aug '07

In class Integral, divMod has a default in terms of quotRem. (quot,rem,div,mod all have defaults as the both-function they're part of.) I'm sure divMod is more natural than quotRem to implement for some types... so why doesn't quotRem have a default in terms of divMod? it has no default! Then the "minimal to implement" will change from (toInteger and quotRem) to (toInteger and (quotRem or divMod)). Isaac

1 0

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

Newbie proposal: operator backquoting
by Dusty 25 Jun '07

25 Jun '07

Hello, dear list members! I'm just a Haskell newbie, but I want to make some proposal to Haskell'. There are some tickets in tracking system, that inspired by conflict between binary operators and other use of the same lexeme. At least I found 3 of that: "get rid of unary '-' operator" (http://hackage.haskell.org/trac/haskell-prime/ticket/50) "Eliminate . as an operator" (http://hackage.haskell.org/trac/haskell-prime/ticket/20) and "Replace the array indexing operator, '!'" (http://hackage.haskell.org/trac/haskell-prime/ticket/96) IMHO, all specified problems may be made less embarrassing - if not completly solved - if Haskell' have some way to solve lexical ambiguity in concrete position. As for those problems have similar lexical construct (binary operator) on one side - and different construct on other side: so this solution must take place over binary operators. I propose to use the same construct, that always used to convert function application to binary operator: backquoting. Any lexeme, bounded by backquotes, will be treated by grammar as binary operator; and no special grammatic case can be applied. So: ('-'1) is operator section, \x -> x-1, while (-1) is negative number ('-'y) is operator section, \x -> x-y, while (-y) is unary function application, negate y foo '-'1 has two arguments, (-) and 1, while foo -1 has one argument, -1 F'.'g is composition of function and constructor, while F.g is qualified function name ('!'x) is operator section, while !x is bang pattern (or strictness annotation). I think, this proposal does not require neither big changes in Haskell grammar, nor it ruins any existing code. Alexander Dakhov.

5 6

Re: Newbie proposal: operator backquoting
by Dusty 25 Jun '07

25 Jun '07

> On Thu, Jun 21, 2007 at 09:14:55AM +0400, Dusty wrote: > > > > foo '-'1 has two arguments, (-) and 1, while foo -1 has one argument, -1 > You mean > foo '-'1 > is parsed as > (-) foo 1 > and > foo -1 > is parsed as > foo (-1) > right? Yes! It was my mistake... > What would > foo - 1 > mean? If it means > (-) foo 1 > then putting the extra space in looks a lot nicer to me than using > backquotes. If it means > foo (-1) > then I think this will break a lot of code, and is also very > unintuitive. As for me, it must still parse as foo (-1). While this solution _is_ contra-intuitive, any other variant is _worse_. I suppose, parsing can take differently 0 and 1 spaces, but not 1 and 2... Alexander Dakhov.

1 0

default fixity for `quotRem`, `divMod` ??
by Isaac Dupree 19 Jun '07

19 Jun '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was just bitten in ghci by `divMod` being the default infixl 9 instead of the same as `div` and `mod`. Sure enough, the standard prelude doesn't specify a fixity for `quotRem` and `divMod` even though `quot`, `rem`, `div`, and `mod` are all infixl 7. I propose that `quotRem` and `divMod` also become infixl 7. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdr7dHgcxvIWYTTURAu07AKCb0RAI343lnRlH1FgI1rMy0dx1FQCfcnsV g6HUB5vDVbk9LPGi51WpY+o= =iESL -----END PGP SIGNATURE-----

3 3