June 2007 - Haskell-prime

Newbie proposal: operator backquoting
by Dusty 26 Jun '07

26 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 26 Jun '07

26 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 20 Jun '07

20 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

type signatures in export lists
by Isaac Dupree 19 Jun '07

19 Jun '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 They're not implemented, but they won't be until we decide exactly what they mean - it's not simple. (at least the syntax is obvious: http://hackage.haskell.org/trac/haskell-prime/wiki/PermitSignaturesInExports ) One big question: can their presence have any effect? * on the module doing the exporting (conflict with the presence of in-module type-signature for the same thing; type restriction in-module; monomorphism-restriction-lifting or defaulting-removal of the named thing) * on modules importing this one (can a module re-export something, giving it a more restrictive type-signature?) Case study 1: module Foo1 (Foo(..), foo :: Foo) where data Foo = CFoo foo :: Foo foo = CFoo If we interpret it as an in-module type signature, it will be a problem because there already is one for foo. (unless we should relax the rules for uniqueness of type signatures anyway?) Case study 2: module Foo2 (foo :: Foo) where data Foo = CFoo foo :: Foo foo = CFoo The type doesn't need to be exported. (which is more likely if it's just a type synonym than a new type.) So what scope are the names in the export-list-type-signature drawn from? It would be odd if a type signature couldn't be given because some names weren't exported; but it would be odd if a module-user looking at the interface saw some types that weren't defined anywhere visible. This suggests that wildcards in type signatures could be helpful for this: module Foo3 (foo :: Int -> Foo -> Bool) versus module Foo4 (foo :: Int -> _ -> Bool) Open for discussion. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdmneHgcxvIWYTTURAlTpAJ425ZL8WPzkAeIxRbgGSOQFCKtrnwCeIG0P aawB6GDwSfiRNM20MErBj8E= =KCKj -----END PGP SIGNATURE-----

2 2

What separates lines in Haskell code?
by Isaac Dupree 18 Jun '07

18 Jun '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In the report, under the layout rule (section 9.3), "The characters newline, return, linefeed, and formfeed, all start a new line." (Which four characters are those? from http://en.wikipedia.org/wiki/Linefeed , I'm guessing "LF: Line Feed, U+000A", "CR: Carriage Return, U+000D", "FF: Form Feed, U+000C", and what's the fourth one? Newline usually refers to '\n', which is LF, but linefeed has a direct name correspondence to that also!) The literate haskell section 9.4 just talks about lines without being specific about how they're specified. My proposed sample implementation uses Prelude.lines ... Prelude.lines presumes that lines are separated only by '\n'. (Of course, for Prelude.unlines to be an inverse operation (which it's not anyway) there has to be only one character that makes a line-separation) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcT5vHgcxvIWYTTURAowrAJ4rz3/Sc763l8TEharcnWcma5BkBgCfRhAF XbfCIG8tnym1gZFRZf4KuRo= =it7M -----END PGP SIGNATURE-----

2 2

"qvars"? pragma syntax generally?
by Isaac Dupree 17 Jun '07

17 Jun '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For INLINE and NOINLINE the report uses "qvars" http://haskell.org/onlinereport/pragmas.html which is not defined in http://haskell.org/onlinereport/syntax-iso.html (although its meaning is obvious since var, qvar and vars are all defined). Is it permissible for compilers to die on pragma syntax they don't personally like? For example GHC chokes on {-# INLINE Ma-in.ma-in #-} at top level, but it would be worse with non-standardized pragmas. (the compiler giving a warning that it understands a pragma of that name, but not the syntax given, would be best.) "the pragma should be ignored if an implementation is not prepared to handle it." WHAT IS pragma syntax?? The report doesn't say how whitespace is handled. syntax-iso doesn't mention pragmas; in its opinion everything from {-# hi-} to {-#{-##-}#-} to {-# INLINE main #-} is a perfectly good comment. [1] But the report recommends some specific syntaxes. To all appearances, it is expected that they follow (guessing from other Haskell syntax) the form pragma -> {-# pragmaid (some pragma-specific syntax that is consistent with the whole thing being ncomment) #-} pragmaid -> (large|_) {large|_|'} Still... whitespace? GHC understands as a pragma {-# LINE 3 "foo.hs" #-} but not {-# {- nested comment -} LINE 3 "foo.hs" #-} ; I don't even know about inside or next to the (some pragma-specific syntax). Is the inside of pragmas supposed to be lexed somewhat the same way as the rest of the Haskell file, or "it can vary" because pragmas can be anything they want... hopefully the convention of beginning pragmas with a name cannot vary. [1] (hmm, maybe pragmas should be used to indicate haddock comments - too late now, and probably too verbose too) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdCuyHgcxvIWYTTURAnljAJ9NLJKW+CTroJ0Vg43bgGWZ3DXJHwCgp+Z3 SAX/cK5PSV7B4TBfwg664xM= =81g6 -----END PGP SIGNATURE-----

1 0

inits is too strict
by apfelmus 15 Jun '07

15 Jun '07

Hello, inits [] = [[]] inits (x:xs) = [[]] ++ map (x:) (inits xs) as specified in Data.List has a "semantic bug", namely it's too strict: inits (1:_|_) = []:_|_ as opposed to the expected inits (1:_|_) = []:[1]:_|_ A correct version would be inits xs = []:case xs of [] -> [] (x:xs) -> map (x:) (inits xs) The Haskell report specifies how inits has to behave, so this is a problem in the report, not in a concrete implementation. Where can I report a bug report for the report? ;) Regards, apfelmus

3 3