Re: strange behavior of let in ghci
Antoine, > You're running into the monomorphism restriction: > http://www.haskell.org/haskellwiki/Monomorphism_restriction Oh. Thanks. > You can also turn off the restriction at the command-line with the > argument '-XNoMonomorphismRestriction', I think. I will use "ghci -XNoMonomorphismRestriction" in my tutorial. Thank you again. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: strange behavior of let in ghci
On Thu, Jan 19, 2012 at 10:55 PM, Kazu Yamamoto wrote: > Hello, > > I met strange behavior of let in ghci 7.0.4. The following works well. > You're running into the monomorphism restriction: http://www.haskell.org/haskellwiki/Monomorphism_restriction > >> let chooseMax = maximumBy compFst If you re-define this to be: > let chooseMax x = maximumBy compFst x you'll get around it in the easiest way. You can also turn off the restriction at the command-line with the argument '-XNoMonomorphismRestriction', I think. Antoine ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
strange behavior of let in ghci
Hello, I met strange behavior of let in ghci 7.0.4. The following works well. > :m Data.List > let compFst (n1,s1) (n2,s2) = compare n1 n2 > maximumBy compFst [(1, "boo"), (3, "foo"), (2, "woo")] (3,"foo") But if I bind "maximumBy compFst" to "chooseMax" with "let", it causes error: > let chooseMax = maximumBy compFst > chooseMax [(1,"boo"),(3,"foo"),(2,"woo")] :1:33: No instance for (Num ()) arising from the literal `2' Possible fix: add an instance declaration for (Num ()) In the expression: 2 In the expression: (2, "woo") In the first argument of `chooseMax', namely `[(1, "boo"), (3, "foo"), (2, "woo")]' It's very strange to me. Why does this happen? ":t" says: > :t maximumBy compFst maximumBy compFst :: Ord a => [(a, t)] -> (a, t) > :t chooseMax chooseMax :: [((), t)] -> ((), t) I'm writing a tutorial of Haskell and I would like to define chooseMax in ghci with "let" without specifying its signature. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type operators in GHC
On 19/01/2012, Ian Lynagh wrote: > Do you mean that in > > f :: (x, X, (+), (:+)) > > only x would be a type variable and X, (+), (:+) would be type > constructors, but that in > > g :: forall y, Y, (*), (:*) . > (x, X, (+), (:+), y, Y, (*), (:*)) > > y, Y, (*), (:*) would be type variables and x, X, (+), (:+) would be > whatever is in scope (constructors, unless there is an enclosing forall > that binds them)? Just so. > Perhaps we should be heading towards a case-insensitive syntax for type > names. I've often had that thought myself, for types and terms both. It would make it much nicer to do general numeric computations in Haskell (e.g. fluid mechanics) since one could use upper-case term names, which are often customary. I actually designed a compiled-to-Haskell language for just this reason (for fluid mechanics lab), but it's very crude. That said, for word-names, the case-sensitive system we have is nice and brief. > > Thanks > Ian > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: named pipes
To my >> Dear GHC team, >> I am testing the IO operations of GHC with the Unix named pipes >> [..] Albert Y. C. Lai writes on 19 Jan 2012 > Main.hs does not open fromA at all. (fromA_IO is dead code.) This causes > fifo2.c to be hung whenever it opens fromA. From the man page of mkfifo(3) > on Linux: > "Opening a FIFO for reading normally blocks until some other process opens > the same FIFO for writing, and vice versa. See fifo(7) for nonblocking > handling of FIFO special files." I see now. Thank you. The intitial example was with a real usage of toA and fromA, and it did not work as expected. Then, I simplified it, but just missed the point that ./Main does not really open fromA. Now, I provide below the initial example. Can people explain, please, why it performs so? > In the sister thread in haskell-cafe, the addition of unsafePerformIO > throws further disorder into these highly order-sensitive operations. By the way, can you respond (if not to `glasgow' then to mech...@botik.ru) to my last simple and concrete question to cafe on the subject of unsafePerformIO ? Anyway, the below example is free of unsafePerformIO. And I need to delay the remaining questions on unsafePerformIO (for myself and maybe, for `cafe') until the current example is fixed. Regards, -- Sergei mech...@botik.ru I am testing the IO operations of GHC with the Unix named pipes -- (in ghc-7.01 under Debian Linux). In the below example, the pipe pair are created by > mkfifo toA > mkfifo fromA, `main' in Main.hs opens toAfor writing, opens fromA for reading, outputs "A1" to toA, inputs the respond string str' from fromA, prints str' to the screen. The C program fifo2 opens toAfor reading, opens fromA for writing, inputs a string str from toA, converts str to the lower case, obtaining str' outputs str' to fromA. Main.hs is built by ghc --make Main, The C program is built by gcc -o fifo2 fifo2.c First, ./fifo2 is run on terminal-2, then./Mainis run on terminal-1. The effect is that fifo2(on terminal-2) hangs silent, and Main.hs (on terminal-1) reports only "str1 --> hFlush done", and then hangs. This contradicts to that ./Main must print str' to the screen. The modules are as follows. -- Main.hs - import System.IO (IOMode(..), IO(..), Handle, openFile, hPutStr, hFlush, hGetLine) dir = showString "/home/mechvel/ghc/notes/npipe/" toA_IO = openFile (dir "toA") WriteMode :: IO Handle fromA_IO = openFile (dir "fromA") ReadMode axiomIO :: Handle -> Handle -> String -> IO String axiomIOh1h2str = do hPutStr h1 str hFlush h1 putStr "hFlush done\n" str' <- hGetLine h2 putStr (concat ["hGetLine -> ", str', "\n"]) return str' main = do h1 <- toA_IO h2 <- fromA_IO putStr "str1 --> " str1' <- axiomIO h1 h2 "A1" putStr (str1' ++ "\n") --- fifo2.c - #include #include #define BOUND 64 static char str[BOUND]; main() { int l, i; FILE *toA, *fromA; toA = fopen("/home/mechvel/ghc/notes/npipe/toA", "r"); if (toA == NULL) {perror("fopen(toA, r) failed: "); return;}; fromA = fopen("/home/mechvel/ghc/notes/npipe/fromA", "w"); if (fromA == NULL) {perror("fopen(fromA, w) failed: "); return;}; if (fgets(str, BOUND, toA) == NULL) { perror("fgets(str, bound, toA) failed: "); return; }; printf("input = %s\n", str); l = strlen(str) - 1; i = 0; // convert the string to the lower case while (i < l) {str[i] = tolower(str[i]); i++;} printf("output = %s\n", str); fputs(str, fromA); fflush(fromA); printf("output to fromA done\n"); return; } - Comparison with C - C - If both programs are in C, then the whole loop of the string exchange (with fifo2.c rewritten into a loop) works as needed, both for the variants with fgets and with `read'. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Posting etiquette, was Re: Records in Haskell
On January 19, 2012 05:14:30 Malcolm Wallace wrote: > I find it completely unreasonable for a reply to a very long post to quote > the entire text, only to add a single line at the bottom (or worse, > embedded in the middle somewhere). +1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type operators in GHC
On Thu, Jan 19, 2012 at 07:11:19AM -0500, Matthew Farkas-Dyck wrote: > > Sometimes I thought to use "∀" to quantify over type variables, as > over term variables, at least as an option. Do you mean that in f :: (x, X, (+), (:+)) only x would be a type variable and X, (+), (:+) would be type constructors, but that in g :: forall y, Y, (*), (:*) . (x, X, (+), (:+), y, Y, (*), (:*)) y, Y, (*), (:*) would be type variables and x, X, (+), (:+) would be whatever is in scope (constructors, unless there is an enclosing forall that binds them)? Perhaps we should be heading towards a case-insensitive syntax for type names. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type operators in GHC
Hi, Am Donnerstag, den 19.01.2012, 07:11 -0500 schrieb Matthew Farkas-Dyck: > On 19/01/2012, Joachim Breitner wrote: > > (I have no good idea, but here is at least one: A dot '.' as the first > > character indicates a type variable; compared to a ':' this is a > > non-capitalized character). > > So that all symbols that start in dot are variables, and all others > are types/constructors? exactly, that would be an option to get the benefit of the proposal (nicer type constructor operator names) without giving up completely on type variable operators names. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type operators in GHC
On 19/01/2012, Joachim Breitner wrote: > (I have no good idea, but here is at least one: A dot '.' as the first > character indicates a type variable; compared to a ':' this is a > non-capitalized character). So that all symbols that start in dot are variables, and all others are types/constructors? > Also, is there maybe another way of distinguishing constructors and > variables, besides capitalization, that works equally well for operators > and non-operators? That could also help if a user would like to use > unicode characters in the name of a constructor that are letters but > don’t have a upper or titlecase variant. But then, this has probably > been given thought a long time ago, without a better solution than > capitalization resp. leading ':'. Sometimes I thought to use "∀" to quantify over type variables, as over term variables, at least as an option. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Posting etiquette, was Re: Records in Haskell
On 19/01/2012, Malcolm Wallace wrote: > I find it completely unreasonable for a reply to a very long post to quote > the entire text, only to add a single line at the bottom (or worse, embedded > in the middle somewhere). In this case, there are 7 pages of quotation > before your one-sentence contribution. (That is on my laptop. I dread to > think how many pages it represents on a smartphone screen...) Usually, if I > need to scroll even to the second page-worth of quotation and have still not > found any new text, I now just delete the post without reading it. > > Regards, > Malcolm > Sorry. The reason that I have done so is that my primary mail client (GMail web) automatically folds quoted text (marked by ">" at start of line). (I'm not sure whether my secondary client (mutt) can do so.) When I first saw this message, I thought I would be slammed for top-posts (I have been guilty a few times). Anyhow, I shall keep this in mind. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Posting etiquette, was Re: Records in Haskell
Hi, On 01/19/2012 10:22 AM, Jos Pedro Magalhes wrote: One could also argue that a good email client should automatically hide long quotes. In fact, I guess many people are not even aware of the problem because their client does this. But then what is the point of including the text in the first place if it is understood it is only there to be hidden? Besides, personally, I don't want my e-mail client to attempt (and, short of it truly having an understanding of what is being said, inevitably fail) to understand which parts of an e-mail are of interest to me and which parts are not. No, I agree completely with Malcolm: not taking the time to quote ONLY what is of relevance to provide the immediately relevant context for a point one wishes to make is a failure of communication and, indeed, an abuse of other's time. Thanks, Malcolm, well said! /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Posting etiquette, was Re: Records in Haskell
Hi, One could also argue that a good email client should automatically hide long quotes. In fact, I guess many people are not even aware of the problem because their client does this. Cheers, Pedro On Thu, Jan 19, 2012 at 11:14, Malcolm Wallace wrote: > Sorry to pick on your post in particular Matthew, but I have been seeing a > lot of this on the Haskell lists lately. > > I find it completely unreasonable for a reply to a very long post to quote > the entire text, only to add a single line at the bottom (or worse, > embedded in the middle somewhere). In this case, there are 7 pages of > quotation before your one-sentence contribution. (That is on my laptop. I > dread to think how many pages it represents on a smartphone screen...) > Usually, if I need to scroll even to the second page-worth of quotation > and have still not found any new text, I now just delete the post without > reading it. > > It is a failure to communicate well, on the part of the writer who values > their own time more highly than that of their intended readers. Even the > much-maligned top-posting style, as forced upon Outlook users (and as I am > doing right here), is preferable to the failure to trim, or to get to the > point quickly. My inbox has >1600 unread messages in it, and life is just > too short. So I offer this plea as a constructive social suggestion - if > you want your ideas to reach their intended audience, don't annoy them > before they have even seen what you want to say. > > Regards, >Malcolm > > > On 15 Jan 2012, at 20:33, Matthew Farkas-Dyck wrote: > > > On 13/01/2012, Simon Peyton-Jones wrote: > >> Thanks to Greg for leading the records debate. I apologise that I > >> don't have enough bandwidth to make more than an occasional > >> contribution. Greg's new wiki page, and the discussion so far has > >> clarified my thinking, and this message tries to express that new > >> clarity. I put a conclusion at the end. > >> > >> Simon > >> > >> Overview > >> > >> It has become clear that there are two elements to pretty much all the > >> proposals we have on the table. Suppose we have two types, 'S' and 'T', > >> both with a field 'f', and you want to select field 'f' from a record > 'r'. > >> Somehow you have to disambiguate which 'f' you mean. > >> > >> (Plan A) Disambiguate using qualified names. To select field f, say > >>(S.f r) or (T.f r) respectively. > >> > >> (Plan B) Disambiguate using types. This approach usually implies > >> dot-notation. > >> If (r::S), then (r.f) uses the 'f' from 'S', and similarly if > >> (r::T). > >> > >> Note that > >> > >> * The Frege-derived records proposal (FDR), uses both (A) and (B) > >> http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing > >> > >> * The Simple Overloaded Record Fields (SORF) proposal uses only (B) > >> > http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields > >> > >> * The Type Directed Name Resolution proposal (TDNR) uses only (B) > >> > >> > http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution > >> > >> I know of no proposal that advocates only (A). It seems that we are > agreed > >> that we must make use of types to disambigute common cases. > >> > >> Complexities of (Plan B) > >> > >> Proposal (Plan B) sounds innocent enough. But I promise you, it isn't. > >> There has ben some mention of the "left-to-right" bias of Frege type > >> inference engine; indeed the wohle explanation of which programs are > >> accepted and which are rejected, inherently involves an understanding > >> of the type inference algorithm. This is a Very Bad Thing when the > >> type inference algorithm gets complicated, and GHC's is certainly > >> complicated. > >> > >> Here's an example: > >> > >> type family F a b > >> data instance F Int [a] = Mk { f :: Int } > >> > >> g :: F Int b -> () > >> h :: F a [Bool] -> () > >> > >> k x = (g x, x.f, h x) > >> > >> Consider type inference on k. Initially we know nothing about the > >> type of x. > >> * From the application (g x) we learn that x's type has > >> shape (F Int ). > >> * From the application (h x) we learn that x's type has > >> shape (F [Bool]) > >> * Hence x's type must be (F Int [Bool]) > >> * And hence, using the data family we can see which field > >> f is intended. > >> > >> Notice that > >> a) Neither left to right nor right to left would suffice > >> b) There is significant interaction with type/data families > >>(and I can give you more examples with classes and GADTs) > >> c) In passing we note that it is totally unclear how (Plan A) > >>would deal with data families > >> > >> This looks like a swamp. In a simple Hindley-Milner typed language > >> you might get away with some informal heuristics, but Haskell is far > >> too complicated. > >> > >> Fortunately we know exactly what to do; it is described in some detail > >> in our paper "Modular type inference with local a
Posting etiquette, was Re: Records in Haskell
Sorry to pick on your post in particular Matthew, but I have been seeing a lot of this on the Haskell lists lately. I find it completely unreasonable for a reply to a very long post to quote the entire text, only to add a single line at the bottom (or worse, embedded in the middle somewhere). In this case, there are 7 pages of quotation before your one-sentence contribution. (That is on my laptop. I dread to think how many pages it represents on a smartphone screen...) Usually, if I need to scroll even to the second page-worth of quotation and have still not found any new text, I now just delete the post without reading it. It is a failure to communicate well, on the part of the writer who values their own time more highly than that of their intended readers. Even the much-maligned top-posting style, as forced upon Outlook users (and as I am doing right here), is preferable to the failure to trim, or to get to the point quickly. My inbox has >1600 unread messages in it, and life is just too short. So I offer this plea as a constructive social suggestion - if you want your ideas to reach their intended audience, don't annoy them before they have even seen what you want to say. Regards, Malcolm On 15 Jan 2012, at 20:33, Matthew Farkas-Dyck wrote: > On 13/01/2012, Simon Peyton-Jones wrote: >> Thanks to Greg for leading the records debate. I apologise that I >> don't have enough bandwidth to make more than an occasional >> contribution. Greg's new wiki page, and the discussion so far has >> clarified my thinking, and this message tries to express that new >> clarity. I put a conclusion at the end. >> >> Simon >> >> Overview >> >> It has become clear that there are two elements to pretty much all the >> proposals we have on the table. Suppose we have two types, 'S' and 'T', >> both with a field 'f', and you want to select field 'f' from a record 'r'. >> Somehow you have to disambiguate which 'f' you mean. >> >> (Plan A) Disambiguate using qualified names. To select field f, say >>(S.f r) or (T.f r) respectively. >> >> (Plan B) Disambiguate using types. This approach usually implies >> dot-notation. >> If (r::S), then (r.f) uses the 'f' from 'S', and similarly if >> (r::T). >> >> Note that >> >> * The Frege-derived records proposal (FDR), uses both (A) and (B) >> http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing >> >> * The Simple Overloaded Record Fields (SORF) proposal uses only (B) >> http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields >> >> * The Type Directed Name Resolution proposal (TDNR) uses only (B) >> >> http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution >> >> I know of no proposal that advocates only (A). It seems that we are agreed >> that we must make use of types to disambigute common cases. >> >> Complexities of (Plan B) >> >> Proposal (Plan B) sounds innocent enough. But I promise you, it isn't. >> There has ben some mention of the "left-to-right" bias of Frege type >> inference engine; indeed the wohle explanation of which programs are >> accepted and which are rejected, inherently involves an understanding >> of the type inference algorithm. This is a Very Bad Thing when the >> type inference algorithm gets complicated, and GHC's is certainly >> complicated. >> >> Here's an example: >> >> type family F a b >> data instance F Int [a] = Mk { f :: Int } >> >> g :: F Int b -> () >> h :: F a [Bool] -> () >> >> k x = (g x, x.f, h x) >> >> Consider type inference on k. Initially we know nothing about the >> type of x. >> * From the application (g x) we learn that x's type has >> shape (F Int ). >> * From the application (h x) we learn that x's type has >> shape (F [Bool]) >> * Hence x's type must be (F Int [Bool]) >> * And hence, using the data family we can see which field >> f is intended. >> >> Notice that >> a) Neither left to right nor right to left would suffice >> b) There is significant interaction with type/data families >>(and I can give you more examples with classes and GADTs) >> c) In passing we note that it is totally unclear how (Plan A) >>would deal with data families >> >> This looks like a swamp. In a simple Hindley-Milner typed language >> you might get away with some informal heuristics, but Haskell is far >> too complicated. >> >> Fortunately we know exactly what to do; it is described in some detail >> in our paper "Modular type inference with local assumptions" >> http://www.haskell.org/haskellwiki/Simonpj/Talk:OutsideIn >> >> The trick is to *defer* all these decisions by generating *type constraints* >> and solving them later. We express it like this: >> >> G, r:t1 |- r.f : t2, (Has t1 "f" t2) >> >> This says that if r is in scope with type t1, then (r.f) has type t2, >> plus the constraint (Has t1 "f" t2), which we read as saying >> >> Type t1 must have a field "f" of
Re: Type operators in GHC
Hello, while I agree that operators are usually more useful als type constructors than as type variables, I’m wondering if it is future-proof to completely get rid of a possibility for infix type variables. With the type class system getting stronger and stronger, would this not mean that there will be more and more use cases for infix type variables? Maybe the change should at keep a (small) window open. Maybe, similar to the current situation, a special character to indicate variables, not constructors? (I have no good idea, but here is at least one: A dot '.' as the first character indicates a type variable; compared to a ':' this is a non-capitalized character). Also, is there maybe another way of distinguishing constructors and variables, besides capitalization, that works equally well for operators and non-operators? That could also help if a user would like to use unicode characters in the name of a constructor that are letters but don’t have a upper or titlecase variant. But then, this has probably been given thought a long time ago, without a better solution than capitalization resp. leading ':'. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users