September 2009 - Haskell-Cafe

Re: [Haskell-cafe] accessible layout proposal?
by Jimmy Hartzell 23 Sep '09

23 Sep '09

> > On Sep 22, 2009, at 8:01 PM, Jimmy Hartzell wrote: > >> I am in love with this proposal: >> http://www.haskell.org/haskellwiki/Accessible_layout_proposal > > I hadn't read it before. Now that I have, I really do not like > it. "Syntactic sugar causes cancer of the semicolon" as Alan > Perlis once said, and to my taste this proposal definitely > counts as cancer of the semicolon. In effect, its purpose > is to overload vertical white space. > > Any time that you have something where you think you need > this, it's likely that a better solution is to break what > you are doing into smaller pieces. Well, look at code like this: wrapParens str = concat [ "(", str, ")" ] (And yes, I realize you can do something like this with 'printf "(%s)" str'.) First off, there is a serious issue with the commas. You should at least be allowed to have a comma after the last element, a la Python. Otherwise, the last one is randomly special in this list, and in a format like this, I regularly edit code accidentally leaving off commas, yielding stuff like: concat [ "(", str, ")" -- (oops, no comma!) lineEnd -- forgot I needed this ] which (of course) results in a very confusing type error. Meanwhile, you have to format your code very awkwardly, as the closing bracket can't be in the left-most column, and, all in all, you have lots and lots of commas cluttering up your otherwise clean-looking layout. You get humans reading the code based off of the physical layout, while the computer is interpreting it based on the presence of commas, which the human mind will naturally filter in favor of the layout. And as to the "simplifying your code" idea: however "pure" your code is, you will regularly have to embed lists of things in it (ADTs, export lists, data from the domain). And unless you're claiming it is *almost always bad style to have code looking like (from the proposal): main = do a <- getChar bracket_ (enter a) (exit a) (do putChar a putStrLn "hello") then the same argument holds for $# (which I expect is the most controversial part of the proposal): the humans read the layout, the computers read the parentheses, and there are many opportunities for error. I mean, probably in this case the code could stand to be changed to: with a = bracket_ (enter a) (exit a) main = do a <- getChar with a $ do putChar a putStrLn "hello" But I would *still* rather have: with a = bracket_ $# enter a exit a Layout is easier to read than parentheses. In summary, I have to spend a good portion of my time coding Haskell dealing with the fact that I have a lot of {'s, ['s, and ,'s to keep track of, and they rarely fit on one line (records, ADTs, lists). I have to spend a significant amount of my coding time finagling the layout to look sensible, and I don't think anyone would claim that I just shouldn't use records or ADTs.

3 4

Re: [Haskell-cafe] accessible layout proposal?
by Richard O'Keefe 23 Sep '09

23 Sep '09

On Sep 23, 2009, at 3:40 PM, James Hartzell wrote: >> I asked for the trailing comma in Erlang for _social_ reasons, >> not because I believed it would fix all problems of this type. > > What do you mean, for social reasons? The proposal is http://www.erlang.org/eeps/eep-0021.html The abstract says "Allow an extra comma at the end of a list or tuple. Darren New proposed this change; Richard O'Keefe, who doesn't like it very much, wrote it up as an EEP." Later on, we find the text "I don't actually feel any need for this proposal; I believe that the answer is better tool support. However, many people are wedded to their tools, even more than their programming languages. Darren New is not the only one to have asked for it, and with about 1 SLOC in 110 of the Erlang/OTP sources reflecting a list or tuple where this feature could have been used, it's very much a low cost high public appreciation feature." It was a feature that people *wanted* because they were used to in other languages and it could be added at comparatively low cost (there's only one Erlang implementation worth bothering about) without breaking existing tools. Adding it would please many existing and potential Erlang programmers without XXXXing off too many others (you don't _have_ to write the extra comma, and it's not that obtrusive when you read other people's code), and it would remove some complaints and criticisms from the mailing list, so, social reasons. I don't believe it solves any problem that can't be better solved any other way, but at least optional trailing commas don't *hurt* anything. This might actually be different in Haskell, which allows things like (,,). You can't add a trailing comma here without breaking things. The #( #[ #$ # proposal, on the other hand, WOULD break things. "#" is currently an 'ascSymbol', so the character sequences #( and #[ may occur in legal Haskell code. infix # x # y = (x,y) foo x y = x #( y ) bar x z = x #[ z ] > As for "all problems of this type", I agree in theory, but often > enough, > for an operator @@, you can use foldl1 (@@) [...] and reduce it to the > trailing comma problem (notable exceptions include (.) and ($) and > other > operators where the type is different for the intermediate return > values > -- and this, I take it, is why '$#' is in the proposal). I am a bit puzzled here. This seems to mean something like "If you take readable code using an operator you can make it less readable, and when you do that you create another problem as well, and an even less readable hack can fix that." "I know an old lady who swallowed a fly..." > I don't see how this is all that revolutionary, I don't think anyone claims that it is. The claims are that it is - not needed - not pleasant to look at - not good for existing syntax-(semi-)aware tools - not backwards compatible with existing code > I am not at all committed to the specifics. Would it be better if > there > were keywords like 'list#', 'tuple#', or maybe '(#)', '[#]' etc? But of course! > > I guess where I'm coming from is: I don't like my expressions to be > full > of parentheses or hard-to-track operator precedences, and find it > harder > to read, to write, and to maintain, even for toy examples like the > ones > we've been discussing. There's no accounting for taste. I find invisible operators much harder to deal with than parentheses. So we agree to differ. Changing the proposal to something that doesn't spoil bracket matching and doesn't break previously legal Haskell' code (note the prime; I'm not fighting old battles again) would make a huge difference. I still wouldn't _like_ it, but wouldn't have such strong reasons to _oppose_ it. For what it's worth, I've used an experimental language where - immediately after ( [ { or an infix or prefix operator, newlines were treated like any other white space - in other contexts, newlines inside ( [ were treated as commas - in other contexts, newlines were treated as semicolons - trailing commas and semicolons were allowed In Haskell terms, this would mean that ( 1 2 3 ) meant (1,2,3) and [ 1 2 3 ] meant [1,2,3] and 'do' and 'case' worked as now. By adding f $$ (x,y) = f x y f $$ (x,y,z) = f x y z f $$ (x,y,z,a) = f x y z a ... you could also have f $( 1 2 3 ) meaning f 1 2 3. I am aware that this is not backwards compatible with existing code, and I am not proposing this for adoption.

1 0

Re: [Haskell-cafe] accessible layout proposal?
by Richard O'Keefe 23 Sep '09

23 Sep '09

On Sep 23, 2009, at 12:24 PM, James Hartzell wrote: >> Well, look at code like this: > > wrapParens str = concat [ > "(", > str, > ")" > ] I just did. I'd write it as wrap_parens s = "(" ++ s ++ ")" although I wouldn't use that name, because it's not the parentheses that are wrapped, it's s. > First off, there is a serious issue with the commas. > You should at least > be allowed to have a comma after the last element, a la Python. Oh, I agree about that. I've written an Erlang Extension Proposal for Erlang about that. > concat [ > "(", > str, > ")" -- (oops, no comma!) > lineEnd -- forgot I needed this > ] "(" ++ str ++ ")" ++ line_end I'm actually quite serious here. Using infix ++ we have the SAME problem about missing ++ as we do about mssing , After all, someone might have started with ( "(" ++ str ++ ")" ) and ended up with ( "(" ++ str ++ ")" -- (oops, no ++!) lineEnd -- forgot I needed this ) I asked for the trailing comma in Erlang for _social_ reasons, not because I believed it would fix all problems of this type. > And as to the "simplifying your code" idea: however "pure" your code > is, > you will regularly have to embed lists of things in it (ADTs, export > lists, data from the domain). And unless you're claiming it is *almost > always bad style to have code looking like (from the proposal): > > main = do > a <- getChar > bracket_ > (enter a) > (exit a) > (do > putChar a > putStrLn "hello") The thing about toy examples is that they are toy size. On an example this size, we don't NEED fancy new stuff. Actually, I'd write main = getChar >>= \a -> bracket_ (enter a) (exit a) (putChar a >> putStrLn "hello") so even _with_ this proposal, I'd still need exactly the same parentheses. One thing I might do is this: enter_exit_bracket a body = bracket_ (enter a) (exit a) body and then main = getChar >>= \a -> enter_exit_bracket a (putChar a >> putStrLn "hello") because it looks very much as if enter and exit exist only to be passed (with suitable parameters) to bracket_. > > > But I would *still* rather have: > with a = bracket_ $# > enter a > exit a > > Layout is easier to read than parentheses. It all depends on size (small things being easy pretty much no matter what you do) and tools (tools where you click just inside parentheses and the bracketed thing lights up, like the traditional Smalltalk interface make parentheses very very easy to read). > > In summary, I have to spend a good portion of my time coding Haskell > dealing with the fact that I have a lot of {'s, ['s, and ,'s to keep > track > of, and they rarely fit on one line (records, ADTs, lists). I have to > spend a significant amount of my coding time finagling the layout to > look > sensible, and I don't think anyone would claim that I just shouldn't > use > records or ADTs. For what it's worth, the editor I normally use has an "add new element to list" command. Where I'm coming from is this: I do not find meaningless jumbles of special characters combined with overloaded white space readable. It would be so much better if we could discuss a _real_ example.

2 2

Re: [Haskell-cafe] accessible layout proposal?
by Jimmy Hartzell 23 Sep '09

23 Sep '09

Richard O'Keefe wrote: > After all, someone might have started with > ( > "(" ++ > str ++ > ")" > ) > and ended up with > ( > "(" ++ > str ++ > ")" -- (oops, no ++!) > lineEnd -- forgot I needed this > ) > > I asked for the trailing comma in Erlang for _social_ reasons, > not because I believed it would fix all problems of this type. What do you mean, for social reasons? And are there any projects/feature requests to add the trailing comma to ghc? As for "all problems of this type", I agree in theory, but often enough, for an operator @@, you can use foldl1 (@@) [...] and reduce it to the trailing comma problem (notable exceptions include (.) and ($) and other operators where the type is different for the intermediate return values -- and this, I take it, is why '$#' is in the proposal). If I need to use 'a @@ b @@ c' for any operator @@, I rewrite it with a fold (if possible), because I find it more readable to not repeat the operator over and over again. I find lists more semantically appealing in this situation: you really are listing things. > Actually, I'd write > > main = > getChar >>= \a -> > bracket_ (enter a) (exit a) (putChar a >> putStrLn "hello") > > so even _with_ this proposal, I'd still need exactly the same > parentheses. Doing monads without do-notation gets me into precedence trouble pretty quickly -- I find myself adding lots and lots of parentheses, until it ends up looking like Lisp (which I've always found hard on the eyes, keeping track of how many layers you have -- indentation is better for this, in my opinion). The fact that $ can't be used for the last expression of the bracket_ is an example of the precedence trouble I get into. I agree that this proposal makes a lot less sense if you don't also use do-notation. > Where I'm coming from is this: > I do not find meaningless jumbles of special characters > combined with overloaded white space readable. I find the combination of characters very meaningful and intuitive, especially if '(#' is chosen over '#(': use an # if you want to put a list on separate lines (which you'd lay out like that anyway: why not give the compiler some extra knowledge), and don't use it if it fits on the same line. I don't see how this is all that revolutionary, especially as we already have whitespace-significant and non-whitespace-significant versions of 'case', 'do', etc. I don't even see it as syntactic sugar, but more as an alternative syntax -- with the exception of '$#' it parses pretty much directly to the same tree, does it not? It's just changing what's significant. I am not at all committed to the specifics. Would it be better if there were keywords like 'list#', 'tuple#', or maybe '(#)', '[#]' etc? I would suggest using colon like Python, except for it's taken by the (:) operator. I guess where I'm coming from is: I don't like my expressions to be full of parentheses or hard-to-track operator precedences, and find it harder to read, to write, and to maintain, even for toy examples like the ones we've been discussing.

1 0

Strange problem with type classes (ghc 6.8.2 looks allright and ghc 6.10.1 doesn't).
by Serguey Zefirov 22 Sep '09

22 Sep '09

(followup to my previous letter with the same subject) I found the way to break 6.8.2 type checker. It's as easy as to uncomment Div case alternative in valueIndex. Weird. I found a solution, though. Instead of (valueIndex (x_38,(x_36,x_37))) in that Div alternative I should create expression (valueIndex x_38*valuesCount x_36*valuesCount x_37 + valueIndex x_36 * valuesCount x_37+valueIndex x_37) which is equivalent to above one. Slightly more work. And I still cannot figure why valueIndex (a,(b,c)) works in one type and doesn;t in another.

1 0

Strange problem with type classes (ghc 6.8.2 looks allright and ghc 6.10.1 doesn't).
by Serguey Zefirov 22 Sep '09

22 Sep '09

I try to create yet another hardware description language embedded in Haskell and faced a (perceived) bug in ghc 6.10.1 type checker. In ghc 6.8.2 everything works fine. I need a type class that can express relationship between type and its' "size in wires" (the number of bits needed to represent any value of a type). The type class can be easily generalized to most haskell data types and it's easy to write instance derivation using Template Haskell. I used multiparameter type classes because support for type families in Template Haskell was incomplete in 6.10.1 and prior versions. The source code below. Do not forget to include -fcontext-stack=100 when trying to load the code into ghci. The problem lines are between "THE PROBLEM!!" comments. Please, tell me, is it geniune bug or I misunderstand something about Haskell type checker? How do you solve problems like that? and, btw, you can take a look on how we can describe something MIPS-alike in Haskell here: http://thesz.mskhug.ru/svn/hhdl/MIPS.hs it is not finished by any means, but it gives a feel on how it will look. I head to obtain (pretty) efficient simulation functions on infinite streams (almost done, transformations are very simple) and synthesable VHDL/Verilog description all from the same code that looks like ordinary Haskell code. ----------------------------------------------------------------------------------------------------------------------------- -- "A problem with functional dependencies. -- use -fcontext-stack=100 ghc switch. {-# LANGUAGE GADTs, FunctionalDependencies, MultiParamTypeClasses, TypeSynonymInstances, FlexibleInstances, FlexibleContexts, UndecidableInstances #-} module Problem where import Data.Bits import Data.Word ------------------------------------------------------------------------------- -- Type level arithmetic. data Zero = Zero data Succ n = Succ n type ZERO = Zero type ONE = Succ ZERO type TWO = Succ ONE type THREE = Succ TWO type FOUR = Succ THREE type FIVE = Succ FOUR type SIX = Succ FIVE type SEVEN = Succ SIX type EIGHT = Succ SEVEN type NINE = Succ EIGHT type SIZE10 = Succ NINE type SIZE11 = Succ SIZE10 type SIZE12 = Succ SIZE11 type SIZE13 = Succ SIZE12 type SIZE15 = Succ (Succ SIZE13) type SIZE16 = Succ SIZE15 type SIZE20 = Succ (Succ (Succ (Succ (Succ SIZE15)))) type SIZE25 = Succ (Succ (Succ (Succ (Succ SIZE20)))) type SIZE26 = Succ SIZE25 type SIZE30 = Succ (Succ (Succ (Succ (Succ SIZE25)))) type SIZE32 = Succ (Succ SIZE30) class Nat n where fromNat :: n -> Int instance Nat Zero where fromNat = const 0 instance Nat n => Nat (Succ n) where fromNat ~(Succ n) = 1+fromNat n class (Nat a, Nat b, Nat c) => CPlus a b c | a b -> c, a c -> b --instance Nat a => CPlus a Zero a instance Nat a => CPlus Zero a a instance (CPlus a b c) => CPlus (Succ a) b (Succ c) --instance (CPlus a b c) => CPlus (Succ a) b (Succ c) --instance (CPlus a b c) => CPlus a (Succ b) (Succ c) class (Nat a, Nat b, Nat c) => CMax a b c | a b -> c instance CMax Zero Zero Zero instance Nat a => CMax (Succ a) Zero (Succ a) instance Nat a => CMax Zero (Succ a) (Succ a) instance CMax a b c => CMax (Succ a) (Succ b) (Succ c) class (Nat a, Nat b) => CDbl a b | a -> b instance CPlus a a b => CDbl a b class (Nat a, Nat b) => CPow2 a b | a -> b instance CPow2 Zero (Succ Zero) instance (CPow2 a b, CDbl b b2) => CPow2 (Succ a) b2 ------------------------------------------------------------------------------- -- Sized integer. data IntSz n where IntSz :: Nat sz => Integer -> IntSz sz intSzSizeType :: IntSz n -> n; intSzSizeType _ = undefined intSzSize :: Nat n => IntSz n -> Int; intSzSize n = fromNat $ intSzSizeType n instance Nat sz => Eq (IntSz sz) where (IntSz a) == (IntSz b) = a == b instance Show (IntSz n) where show n@(IntSz x) = show x++"{"++show (intSzSize n)++"}" instance Nat sz => Num (IntSz sz) where fromInteger x = IntSz x (IntSz a) + (IntSz b) = IntSz $ a+b (IntSz a) - (IntSz b) = IntSz $ a-b (IntSz a) * (IntSz b) = IntSz $ a*b abs = error "No abs for IntSz." signum = error "No signum for IntSz." ------------------------------------------------------------------------------- -- ToWires class, the main source of problems. class Nat aSz => ToWires a aSz | a -> aSz where wireSizeType :: a -> aSz wireSizeType _ = undefined -- size of a bus to hold a value in bits. wireSize :: a -> Int wireSize x = fromNat $ wireSizeType x -- 2^wireSize, currently unused. wireMul :: a -> Integer wireMul x = Data.Bits.shiftL 1 (wireSize x) -- selector size for decode (unused). wireSelSize :: a -> Int wireSelSize = const 0 -- Integer should occupy no more than wireSize bits, the remaining bits should be 0 toWires :: a -> Integer -- fromWires should work with integers that have non-zero bits -- above wireSize index. fromWires :: Integer -> a -- enumeration. -- valuesCount of (Maybe a) returns 1+valuesCount (x::a) -- valuesCount of Either a b returns valuesCount (x::a) + valuesCount (yLLb) -- valuesCount of (a,b) returns valuesCoutn (x::a) * valuesCount (y::b) valuesCount :: a -> Integer -- valueIndex. -- get a value and return an index inside enumeration. valueIndex :: a -> Integer ------------------------------------------------------------------------------- -- Instances. instance (ToWires x a,ToWires y b, CPlus a b c) => ToWires (x,y) c where toWires (a,b) = Data.Bits.shiftL (toWires a) (wireSize b) .|. toWires b fromWires x = (a,b) where b = fromWires x a = fromWires $ Data.Bits.shiftR x (wireSize b) valuesCount (a,b) = valuesCount a*valuesCount b valueIndex (a,b) = valueIndex a*valuesCount b + valueIndex b instance (ToWires x1 a,ToWires x2 b,ToWires x3 c, CPlus b c bc, CPlus a bc abc) => ToWires (x1,x2,x3) abc where toWires (a,b,c) = toWires (a,(b,c)) fromWires abc = (a,b,c) where (a,(b,c)) = fromWires abc valuesCount (a,b,c) = valuesCount (a,(b,c)) valueIndex (a,b,c) = valueIndex (a,(b,c)) instance (ToWires x1 a,ToWires x2 b,ToWires x3 c,ToWires x4 d,ToWires x5 e, CPlus d e de, CPlus c de cde, CPlus b cde bcde, CPlus a bcde abcde) => ToWires (x1,x2,x3,x4,x5) abcde where toWires (a,b,c,d,e) = toWires (a,(b,(c,(d,e)))) fromWires abcde = (a,b,c,d,e) where (a,(b,(c,(d,e)))) = fromWires abcde valuesCount (a,b,c,d,e) = valuesCount (a,(b,(c,(d,e)))) valueIndex (a,b,c,d,e) = valueIndex (a,(b,(c,(d,e)))) instance CPow2 FIVE size32 => ToWires Int size32 where toWires n = fromIntegral n .&. 0xffffffff fromWires x = fromIntegral x valuesCount = const (Data.Bits.shiftL (1::Integer) 32) valueIndex = fromIntegral instance CPow2 FIVE size32 => ToWires Word32 size32 where toWires n = fromIntegral n .&. 0xffffffff fromWires x = fromIntegral x valuesCount = const (Data.Bits.shiftL (1::Integer) 32) valueIndex = fromIntegral instance Nat size => ToWires (IntSz size) size where toWires x@(IntSz n) = n .&. (Data.Bits.shiftL 1 (wireSize x) - 1) fromWires x = fromIntegral x valuesCount x = Data.Bits.shiftL (1::Integer) (wireSize x) valueIndex x = toWires x ------------------------------------------------------------------------------- -- Neccessary types for a problem. -- A hack around bugs (??) in ghc 6.10.1. data RI = RI (IntSz FIVE) deriving (Eq,Show) data Imm5 = Imm5 (IntSz FIVE) deriving (Eq,Show) data Imm16 = Imm16 (IntSz SIZE16) deriving (Eq,Show) data Imm26 = Imm26 (IntSz SIZE26) deriving (Eq,Show) instance ToWires RI FIVE where toWires (RI x) = toWires x fromWires x = RI $ fromWires x valuesCount = const 32 valueIndex (RI x) = toWires x instance ToWires Imm5 FIVE where toWires (Imm5 x) = toWires x fromWires x = Imm5 $ fromWires x valuesCount = const 32 valueIndex (Imm5 x) = toWires x instance ToWires Imm16 SIZE16 where toWires (Imm16 x) = toWires x fromWires x = Imm16 $ fromWires x valuesCount (Imm16 x) = valuesCount x valueIndex (Imm16 x) = valueIndex x instance ToWires Imm26 SIZE26 where toWires (Imm26 x) = toWires x fromWires x = Imm26 $ fromWires x valuesCount (Imm26 x) = valuesCount x valueIndex (Imm26 x) = toWires x instance ToWires a sz => ToWires (Maybe a) (Succ sz) where toWires Nothing = 0 toWires (Just x) = shiftL (toWires x) 1 .|. 1 fromWires = undefined valuesCount x = 1+valuesCount y where ~(Just y) = x valueIndex Nothing = 0 valueIndex (Just x) = 1+valueIndex x ------------------------------------------------------------------------------- -- And a problem itself. data Signed = Signed | Unsigned deriving (Eq,Show) data MIPSCmd regv = Nop | Trap -- we mark destination register with RI. It never gets fetched. -- we mark source registers as regv, because they can change their size -- at FETCH stage (became Word32). | AddU regv regv RI | And regv regv RI | Div Signed regv regv deriving (Eq,Show) instance ToWires Signed (Succ Zero) where toWires (Signed) = Data.Bits.shiftL 0 1 .|. 0 toWires (Unsigned) = Data.Bits.shiftL 0 1 .|. 1 fromWires x = undefined valuesCount x = 1 + (1 + 0) where ~(Signed) = x ~(Unsigned) = x valueIndex x = case x of Signed -> 0 + 0 Unsigned -> (0 + 0) + 0 where ~(Signed) = x ~(Unsigned) = x instance (ToWires regv_0 v_1, ToWires RI v_2, CPlus v_1 v_1 vCPlus_3, CPlus vCPlus_3 v_2 vCPlus_4, CPlus v_1 v_1 vCPlus_5, CPlus vCPlus_5 v_2 vCPlus_6, ToWires Signed v_7, CPlus v_7 v_1 vCPlus_8, CPlus vCPlus_8 v_1 vCPlus_9, CMax vCPlus_4 vCPlus_6 vCMax_10, CMax vCMax_10 vCPlus_9 vCMax_11) => ToWires (MIPSCmd regv_0) (Succ (Succ (Succ vCMax_11))) where toWires (Nop) = Data.Bits.shiftL 0 3 .|. 0 toWires (Trap) = Data.Bits.shiftL 0 3 .|. 1 toWires (AddU a_12 a_13 a_14) = Data.Bits.shiftL (Data.Bits.shiftL (Data.Bits.shiftL (Data.Bits.shiftL 0 (wireSize a_12) .|. toWires a_12) (wireSize a_13) .|. toWires a_13) (wireSize a_14) .|. toWires a_14) 3 .|. 2 toWires (And a_15 a_16 a_17) = Data.Bits.shiftL (Data.Bits.shiftL (Data.Bits.shiftL (Data.Bits.shiftL 0 (wireSize a_15) .|. toWires a_15) (wireSize a_16) .|. toWires a_16) (wireSize a_17) .|. toWires a_17) 3 .|. 3 toWires (Div a_18 a_19 a_20) = Data.Bits.shiftL (Data.Bits.shiftL (Data.Bits.shiftL (Data.Bits.shiftL 0 (wireSize a_18) .|. toWires a_18) (wireSize a_19) .|. toWires a_19) (wireSize a_20) .|. toWires a_20) 3 .|. 4 fromWires x = undefined valuesCount x = 1 + (1 + ((valuesCount x_21 * (valuesCount x_22 * (valuesCount x_23 * 1))) + ((valuesCount x_24 * (valuesCount x_25 * (valuesCount x_26 * 1))) + ((valuesCount x_27 * (valuesCount x_28 * (valuesCount x_29 * 1))) + 0)))) where ~(Nop) = x ~(Trap) = x ~(AddU x_21 x_22 x_23) = x ~(And x_24 x_25 x_26) = x ~(Div x_27 x_28 x_29) = x -- Please don't mind that code is wrong, I can't get past typechecker here. valueIndex x = case x of Nop -> 0 + 0 Trap -> (0 + 0) + 0 -- THE PROBLEM!!! AddU ax_30 ax_31 ax_32 -> ((0 + 0) + 0) + valueIndex (ax_32,(ax_30, ax_31)) -- /THE PROBLEM!!! {- And x_33 x_34 x_35 -> (((0 + 0) + 0) + valuesCount (x_32, (x_30, x_31))) + valueIndex (x_35, (x_33, x_34)) Div x_36 x_37 x_38 -> ((((0 + 0) + 0) + valuesCount (x_32, (x_30, x_31))) + valuesCount (x_35, (x_33, x_34))) + valueIndex (x_38, (x_36, x_37)) -} where ~(Nop) = x ~(Trap) = x ~(AddU x_30 x_31 x_32) = x ~(And x_33 x_34 x_35) = x ~(Div x_36 x_37 x_38) = x -----------------------------------------------------------------------------------------------------------------------------

1 0

What is
by DavidA 22 Sep '09

22 Sep '09

Hi, When I try to build my HaskellForMaths library (http://hackage.haskell.org/package/HaskellForMaths) using GHC6.10.4 on Mac OS X (Leopard), I get several "ld warning: atom sorting error" (see below). The same code built without problems under GHC6.10.3 on Windows. The code in question is using phantom types to parameterise type constructors. Should I be worried? (It's only a warning - I believe the build is fine.) ld warning: atom sorting error for _HaskellForMathszm0zi1zi8_MathziAlgebrazi CommutativeziMonomial_Grevlex_closure_tbl and _HaskellForMathszm0zi1zi8_MathziAlgebrazi CommutativeziMonomial_Lex_closure_tbl in dist/build/Math/Algebra/Commutative/Monomial.o ld warning: atom sorting error for _HaskellForMathszm0zi1zi8_MathziAlgebrazi CommutativeziMonomial_Glex_closure_tbl and _HaskellForMathszm0zi1zi8_MathziAlgebrazi CommutativeziMonomial_Grevlex_closure_tbl in dist/build/Math/Algebra/Commutative/Monomial.o ld warning: atom sorting error for _HaskellForMathszm0zi1zi8_MathziAlgebrazi CommutativeziMonomial_Elim_closure_tbl and _HaskellForMathszm0zi1zi8_MathziAlgebrazi CommutativeziMonomial_Glex_closure_tbl in dist/build/Math/Algebra/Commutative/Monomial.o ld warning: atom sorting error for _HaskellForMathszm0zi1zi8_MathziAlgebrazi CommutativeziMonomial_Grevlex_closure_tbl and _HaskellForMathszm0zi1zi8_MathziAlgebrazi CommutativeziMonomial_Lex_closure_tbl in dist/build/Math/Algebra/Commutative/Monomial.o ld warning: atom sorting error for _HaskellForMathszm0zi1zi8_MathziAlgebrazi CommutativeziMonomial_Glex_closure_tbl and _HaskellForMathszm0zi1zi8_MathziAlgebrazi CommutativeziMonomial_Grevlex_closure_tbl in dist/build/Math/Algebra/Commutative/Monomial.o ld warning: atom sorting error for _HaskellForMathszm0zi1zi8_MathziAlgebrazi CommutativeziMonomial_Elim_closure_tbl and _HaskellForMathszm0zi1zi8_MathziAlgebrazi CommutativeziMonomial_Glex_closure_tbl in dist/build/Math/Algebra/Commutative/Monomial.o

2 1

Cabal packages -> cabbages
by Jason Dusek 22 Sep '09

22 Sep '09

Some day, we're going to need a short, catchy name for Cabal packages. Let's call them cabbages. -- Jason Dusek

9 15

Building com-1.2.3
by Andrew Coppin 22 Sep '09

22 Sep '09

C:\com-1.2.3>runhaskell Setup configure Configuring com-1.2.3... Setup: Missing dependencies on foreign libraries: * Missing header file: include/WideStringSrc.h * Missing C libraries: kernel32, user32, ole32, oleaut32, advapi32 This problem can usually be solved by installing the system packages that provide these libraries (you may need the "-dev" versions). If the libraries are already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are. Any hints? (It is conspicuous that the "hissing header file" is actually present at the exact path indicated... WTH?)

3 6

Problem with type families
by Victor Nazarov 21 Sep '09

21 Sep '09

I've tried to reimplement code presented in the following blog post: http://cdsmith.wordpress.com/2009/09/20/side-computations-via-type-classes/ But I've got stuck with the following error: Triangulable.hs:41:8: `addRows' is not a (visible) method of class `Triangulable' Triangulable.hs:43:8: `addCols' is not a (visible) method of class `Triangulable' I think the minimal example to reproduce this error is the following: ... class Triangulable m where type Elem m (@@) :: m -> (Int, Int) -> Elem size :: m -> Int swapRows :: Int -> Int -> m -> m swapCols :: Int -> Int -> m -> m addRow :: (Num Elem) => Elem -> Int -> Int -> m -> m addCol :: (Num Elem) => Elem -> Int -> Int -> m -> m newtype ListMatrix a = ListMatrix [[a]] instance Num a => Triangulable (ListMatrix a) where type Elem (ListMatrix a) = a (ListMatrix xs) @@ (i, j) = xs !! i !! j size (ListMatrix xs) = size xs swapRows m n (ListMatrix xs) = ListMatrix $ swap m n xs swapCols m n (ListMatrix xs) = ListMatrix $ map (swap m n) xs addRows q m n (ListMatrix xs) = ListMatrix $ modifyNth n (zipWith comb (xs !! m)) where comb a b = q * a + b addCols q m n (LisMatrix xs) = ListMatrix $ map (\row -> modifyNth n (comb (row !! m)) row) where comb a b = q * a + b ... How can I fix this? -- Victor Nazarov

2 2