From nicolas.frisby at gmail.com Fri Jan 2 13:10:05 2009 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Fri Jan 2 13:01:51 2009 Subject: Suggestion: Syntactic sugar for Maps! In-Reply-To: <200812220228.43930.g9ks157k@acme.softbase.org> References: <2629c41e0812131549mcac143cj6cf86129e16ffa1c@mail.gmail.com> <404396ef0812140635t1f2e8e4es3231b2185f56c65@mail.gmail.com> <200812220228.43930.g9ks157k@acme.softbase.org> Message-ID: <5ce89fb50901021010m28c8a91ah792b6996440e59a8@mail.gmail.com> FWIW, state monad works fine. And I imagine the QuasiQuote extension could get get rid of the double quotes on strings (and recover the use of the colon?). module Sugar ((~>), build, Builder) where import Data.Map (Map); import qualified Data.Map as Map import Control.Monad.State (~>) :: Ord k => k -> a -> Builder k a k ~> a = do m <- get let m' = Map.insert k a m put m' return m' type Builder k a = State (Map k a) (Map k a) build :: Builder k a -> Map k a build x = evalState x Map.empty m = build $ "zero" ~> 0 >> "one" ~> 1 >> "two" ~> 2 n = build $ do "zero" ~> 0 "one" ~> 1 "two" ~> 2 o = build $ do { "zero" ~> 0; "one" ~> 1; "two" ~> 2 } On Sun, Dec 21, 2008 at 7:28 PM, Wolfgang Jeltsch wrote: > Am Sonntag, 14. Dezember 2008 15:35 schrieb Neil Mitchell: >> I am fairly certain someone could write the necessary magic so: >> >> do {'a' ~> 1; 'b' ~> 2} >> >> becomes a map without any changes to the language at all. It seems >> like throwing syntax at a problem should be a last resort. I often do: >> >> let (*) = (,) in ['a' * 1, 'b' * 2] >> >> I find that quite elegant as an associative list, which you can then >> convert to a map, a hash table, use as an associative list etc. >> >> I also think that those who are looking for Haskell will have their >> mind so blown by lazy evaluation that keeping their maps similar isn't >> so necessary :-) >> >> Thanks >> >> Neil > > +1 > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From redbeard0531 at gmail.com Wed Jan 7 04:39:14 2009 From: redbeard0531 at gmail.com (Mathias Stearn) Date: Wed Jan 7 04:30:48 2009 Subject: Suggestion: Improved handling of overlapping imports Message-ID: <3d03c0530901070139udff8cd0o60391529675ad5c2@mail.gmail.com> I've noticed an annoying (anti)pattern when using modules that collide with other modules (esp with the prelude). I find this is most common with modules conflicting with Data.List or System.IO. I'm fairly new to Haskell (did a little last January with XMonad and Just now getting back into it) so maybe there is a better way to handle this. Example: import Data.Foldable (minimum, minimumBy, maximum, maximumBy) import Data.List hiding (minimum, minimumBy, maximum, maximumBy) import Prelude hiding (minimum, maximum) import System.IO.UTF8 (putStrLn, hPutStrLn) import System.IO hiding (putStrLn, hPutStrLn) import Prelude hiding (putStrLn) As you can see this can be quite annoying and is a disincentive to use improved or more general tools. Especially worrisome is that it is not obvious what you must hide from the Prelude. If you try to hide hPutStrLn or minimumBy you get an error. I found this led to a lot of trial and error (read: guess and check). I have a few ideas on how to solve this.The first two are using current syntax and simply doing what the programmer really meant. The third one is adding new syntax to allow a programmer to specify what they mean. All three should be able to work either together or separately. 1) Transitive Hiding If you hide something when importing a module it automatically hides identical imports. I cant think of a situation where this isn't what the user would want. This also seems easy to implement because the compiler already must know which functions are identical when checking for ambiguities. 2) Explicit Import Lists Take Precedence Any ambiguity should be resolved in favor of the module that has the name explicitly in its import list. An additional advantage here is that it offers some protection against a program breaking if a function is added to a module. This can be considered an extension of the current ImportShadowing (http://hackage.haskell.org/trac/haskell-prime/wiki/ImportShadowing) proposal if the current module is thought of as imported with everything explicit. 3) Import A Shadowing B This actually adds a new import style which I think is the best solution: import System.IO.UTF8 shadowing System.IO import Data.Foldable shadowing Data.List In each case all functions in A would shadow any function in B. I think this should behave like Transitive Hide where the identical Prelude functions would also be shadowed. A major advantage here is that it allows drop-in replacements for the standard libs to be easily used. A few things I could go either way on with this: 3.1) if minimum was explicitly imported from Data.List do we use it, Foldable.minimum, or do we error out? 3.2) if a module reexports Data.Foldable should it also reexport the shadowing? I could see this being useful on a big project where you import a module that reexports several modules shadowing the Prelude to create a specialized standard lib. 3.3) should there be a shadowing all? I may take a peek at GHC this weekend to see how easy it would be to add any of these as optional extensions. ~Mathias Stearn From simonpj at microsoft.com Wed Jan 7 12:51:53 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Jan 7 12:43:27 2009 Subject: Suggestion: Improved handling of overlapping imports In-Reply-To: <3d03c0530901070139udff8cd0o60391529675ad5c2@mail.gmail.com> References: <3d03c0530901070139udff8cd0o60391529675ad5c2@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33287047158@EA-EXMSG-C334.europe.corp.microsoft.com> Mathias | I've noticed an annoying (anti)pattern when using modules that collide | with other modules (esp with the prelude). I find this is most common | with modules conflicting with Data.List or System.IO. I'm fairly new | to Haskell (did a little last January with XMonad and Just now getting | back into it) so maybe there is a better way to handle this. | | Example: | import Data.Foldable (minimum, minimumBy, maximum, maximumBy) | import Data.List hiding (minimum, minimumBy, maximum, maximumBy) | import Prelude hiding (minimum, maximum) | | import System.IO.UTF8 (putStrLn, hPutStrLn) | import System.IO hiding (putStrLn, hPutStrLn) | import Prelude hiding (putStrLn) Yes, I've seen this too. | 1) Transitive Hiding | If you hide something when importing a module it automatically hides | identical imports. I don't like this because a 'hiding' clause on one import affects other imports. Yuk. | 2) Explicit Import Lists Take Precedence | Any ambiguity should be resolved in favor of the module that has the | name explicitly in its import list. ...This can be considered an extension of | the current ImportShadowing | (http://hackage.haskell.org/trac/haskell-prime/wiki/ImportShadowing) | proposal if the current module is thought of as imported with | everything explicit. I like this. It's in the same spirit as the ImportShadowing proposal, so if that proposal is accepted, then this one makes sense too. (If not, then think again.) Why don't you modify the ticket to add your proposal to it. | 3) Import A Shadowing B | This actually adds a new import style which I think is the best solution: | | import System.IO.UTF8 shadowing System.IO | import Data.Foldable shadowing Data.List I'm not keen on this. Not only is it new syntax, but it leads to the same repeats as you objected to earlier: import System.IO.UTF8 shadowing Prelude import System.IO shadowing Prelude import Prelude So for me (2) is a clear winner. Simon From redbeard0531 at gmail.com Fri Jan 9 12:17:46 2009 From: redbeard0531 at gmail.com (Mathias Stearn) Date: Fri Jan 9 12:09:11 2009 Subject: Suggestion: Improved handling of overlapping imports In-Reply-To: <3d03c0530901081425k1518aa7ek13e3b57381d5ba75@mail.gmail.com> References: <3d03c0530901070139udff8cd0o60391529675ad5c2@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33287047158@EA-EXMSG-C334.europe.corp.microsoft.com> <3d03c0530901081425k1518aa7ek13e3b57381d5ba75@mail.gmail.com> Message-ID: <3d03c0530901090917o71c953d4la10af64cc5e8ace1@mail.gmail.com> > | 1) Transitive Hiding > | If you hide something when importing a module it automatically hides > | identical imports. > > I don't like this because a 'hiding' clause on one import affects other imports. Yuk. Perhaps limit it to hiding implicit Prelude re-exports then. In each of those examples the Prelude is only listed to hide things. If the only import is: import System.IO hiding (putStrLn, hPutStrLn) There is no indication that System.IO.putStrLn is still in scope. Also the following three examples are valid haskell98 but are likely a programmer accident: import System.IO hiding (print, putStrLn) import Prelude hiding (putStrLn) import System.IO hiding (print) --assume no import Prelude line import System.IO hiding (print) import Prelude (print) None of these trigger a warning from GHC 6.8.3 with -Wall even though they will not do what the programmer likely intended. Note that the second will implicitly become the the third (if print is the only thing used from Prelude), and that the third has no reasonable meaning. (I think. Does it?) > | 2) Explicit Import Lists Take Precedence > | Any ambiguity should be resolved in favor of the module that has the > | name explicitly in its import list. ...This can be considered an extension of > | the current ImportShadowing > | (http://hackage.haskell.org/trac/haskell-prime/wiki/ImportShadowing) > | proposal if the current module is thought of as imported with > | everything explicit. > > I like this. It's in the same spirit as the ImportShadowing proposal, so if that proposal is accepted, then this one makes sense too. (If not, then think again.) Why don't you modify the ticket to add your proposal to it. I'll do that later today. I thought the ticket system was abandoned though? > | 3) Import A Shadowing B > | This actually adds a new import style which I think is the best solution: > | > | import System.IO.UTF8 shadowing System.IO > | import Data.Foldable shadowing Data.List > > I'm not keen on this. Not only is it new syntax, but it leads to the same repeats as you objected to earlier: Do you object to the idea in general or just this specific syntax? > import System.IO.UTF8 shadowing Prelude > import System.IO shadowing Prelude > import Prelude Well System.IO wouldn't have to shadow Prelude because their name collisions are re-exports and therefore, not ambiguous. Only if shadowing wasn't transitive would need to do something like: import System.IO.UTF8 shadowing (Prelude, System.IO) I was trying to come up with a better way to use a module designed to "overlay" on top others. This was the best syntax I could think of that makes overlay modules easy to use. At first I was considering a priority system where you could list the order to search for names, but shadowing seemed easier. The two common uses for these modules that I've seen are improvement and generalization. I see both as important in allowing the language to flexibly update. Consider something like the following to try a updated partial Prelude which still uses the old Prelude for things that haven't changed: import NewPrelude shadowing Prelude Is there a way to do this without introducing a new syntax (other than explicitly listing every name or importing Prelude qualified, neither of which are practical when testing an overlay module)? >| Mathias > Simon Mathias PS- I couldn't find a (non-strawman) proposal on the wiki about improving Unicode IO in Haskell'. Has that been discussed to death on the mailing list or should I start a new thread for it? From barsoap at web.de Fri Jan 23 18:35:26 2009 From: barsoap at web.de (Achim Schneider) Date: Fri Jan 23 18:26:18 2009 Subject: Outlaw tabs Message-ID: <20090124003526.0b8814cf@solaris> I guess everyone knows why. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From dons at galois.com Fri Jan 23 19:17:13 2009 From: dons at galois.com (Don Stewart) Date: Fri Jan 23 19:07:55 2009 Subject: Outlaw tabs In-Reply-To: <20090124003526.0b8814cf@solaris> References: <20090124003526.0b8814cf@solaris> Message-ID: <20090124001713.GI26651@scytale.galois.com> barsoap: > I guess everyone knows why. Use -Wwarn-tabs From bayer at cpw.math.columbia.edu Fri Jan 23 19:25:59 2009 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Fri Jan 23 19:16:43 2009 Subject: Outlaw tabs In-Reply-To: <20090124001713.GI26651@scytale.galois.com> References: <20090124003526.0b8814cf@solaris> <20090124001713.GI26651@scytale.galois.com> Message-ID: On Jan 23, 2009, at 7:17 PM, Don Stewart wrote: > barsoap: >> I guess everyone knows why. > > Use -Wwarn-tabs It's -fwarn-tabs From barsoap at web.de Sat Jan 24 01:25:42 2009 From: barsoap at web.de (Achim Schneider) Date: Sat Jan 24 01:16:32 2009 Subject: Outlaw tabs References: <20090124003526.0b8814cf@solaris> <20090124001713.GI26651@scytale.galois.com> Message-ID: <20090124072542.27c8e42d@solaris> Dave Bayer wrote: > > On Jan 23, 2009, at 7:17 PM, Don Stewart wrote: > > > barsoap: > >> I guess everyone knows why. > > > > Use -Wwarn-tabs > > It's -fwarn-tabs > I use :set et, always and ever, I don't need to. Think of all those newbies being stuck with strange type errors... Doesn't anyone think of the newbies? ;) -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From jon.fairbairn at cl.cam.ac.uk Sat Jan 24 05:50:57 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Sat Jan 24 05:41:46 2009 Subject: Outlaw tabs References: <20090124003526.0b8814cf@solaris> <20090124001713.GI26651@scytale.galois.com> Message-ID: Don Stewart writes: > barsoap: >> I guess everyone knows why. > > Use -Wwarn-tabs Warnings are the wrong answer to this problem. In fact, they're rarely the right answer to any problem. Tabs in sourcecode can have bad effects, and Haskell is a language that attempts to reject bad effects as far as possible. Nor can I see any argument in favour of allowing tabs (if HT is allowed, why not VT?). -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From duncan.coutts at worc.ox.ac.uk Sat Jan 24 08:51:14 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Jan 24 08:41:45 2009 Subject: Outlaw tabs In-Reply-To: <20090124003526.0b8814cf@solaris> References: <20090124003526.0b8814cf@solaris> Message-ID: <1232805074.8432.391.camel@localhost> On Sat, 2009-01-24 at 00:35 +0100, Achim Schneider wrote: > I guess everyone knows why. Can I recommend Ian's Good Haskell Style http://urchin.earth.li/~ian/style/haskell.html We should have it linked/published more widely. The Vim mode that it links to is also excellent. We should try and get it ported to the Haskell emacs mode. As others have also pointed out adding ghc-options: -fwarn-tabs to a project .cabal file is a good way to stop them creeping back in. A lot of projects use -Wall. If there is consensus on the tabs issue then we could ask for -fwarn-tabs to be included in -Wall. That should be a good first step. If we cannot achieve consensus within the community for having -Wall include -fwarn-tabs then we have no hope of banning them in the language definition. So lets first test test the waters on that proposal. Duncan From cgibbard at gmail.com Sat Jan 24 18:38:27 2009 From: cgibbard at gmail.com (Cale Gibbard) Date: Sat Jan 24 18:29:05 2009 Subject: Outlaw tabs In-Reply-To: <1232805074.8432.391.camel@localhost> References: <20090124003526.0b8814cf@solaris> <1232805074.8432.391.camel@localhost> Message-ID: <89ca3d1f0901241538y5080708cq72fdda6201994598@mail.gmail.com> 2009/1/24 Duncan Coutts : > A lot of projects use -Wall. If there is consensus on the tabs issue > then we could ask for -fwarn-tabs to be included in -Wall. That should > be a good first step. If we cannot achieve consensus within the > community for having -Wall include -fwarn-tabs then we have no hope of > banning them in the language definition. > > So lets first test test the waters on that proposal. > > Duncan +1 for treating tab characters outside comments as a lexical error, and of course if you'd like to add -fwarn-tabs to -Wall first that would be fine with me. - Cale From lennart at augustsson.net Sat Jan 24 19:00:49 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Sat Jan 24 18:51:27 2009 Subject: Outlaw tabs In-Reply-To: References: <20090124003526.0b8814cf@solaris> <20090124001713.GI26651@scytale.galois.com> Message-ID: But VT is allowed in Haskell. On Sat, Jan 24, 2009 at 10:50 AM, Jon Fairbairn wrote: > Don Stewart writes: > >> barsoap: >>> I guess everyone knows why. >> >> Use -Wwarn-tabs > > Warnings are the wrong answer to this problem. In fact, > they're rarely the right answer to any problem. Tabs in > sourcecode can have bad effects, and Haskell is a language > that attempts to reject bad effects as far as possible. Nor > can I see any argument in favour of allowing tabs (if HT is > allowed, why not VT?). > > -- > J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From jon.fairbairn at cl.cam.ac.uk Sun Jan 25 06:07:35 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Sun Jan 25 05:58:32 2009 Subject: Outlaw tabs References: <20090124003526.0b8814cf@solaris> <20090124001713.GI26651@scytale.galois.com> Message-ID: Lennart Augustsson writes: > But VT is allowed in Haskell. Gosh, so it is. It's been a while since I looked, and I've no recollection of the discussion that made it part of whitechar. But does it mean what I want it to mean? Does anyone actually use it? Are there any occurrences of it in Haskell programmes that aren't mistakes? -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2008-04-26) From lennart at augustsson.net Sun Jan 25 06:18:01 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun Jan 25 06:08:38 2009 Subject: Outlaw tabs In-Reply-To: References: <20090124003526.0b8814cf@solaris> <20090124001713.GI26651@scytale.galois.com> Message-ID: I don't know what you want it to mean, so I can't answer that. :) I doubt anyone has ever used a VT on purpose. I know I haven't. I regard it as a lexical quirk. -- Lennart On Sun, Jan 25, 2009 at 11:07 AM, Jon Fairbairn wrote: > Lennart Augustsson writes: > >> But VT is allowed in Haskell. > > Gosh, so it is. It's been a while since I looked, and I've > no recollection of the discussion that made it part of > whitechar. But does it mean what I want it to mean? Does > anyone actually use it? Are there any occurrences of it in > Haskell programmes that aren't mistakes? > > -- > J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk > http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2008-04-26) > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From jon.fairbairn at cl.cam.ac.uk Sun Jan 25 11:50:33 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Sun Jan 25 11:41:17 2009 Subject: Outlaw tabs References: <20090124003526.0b8814cf@solaris> <20090124001713.GI26651@scytale.galois.com> Message-ID: Lennart Augustsson writes: > I don't know what you want it to mean, so I can't answer that. :) I'm not saying, either ;-P > I doubt anyone has ever used a VT on purpose. I know I > haven't. I regard it as a lexical quirk. Say no to quirks. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From twanvl at gmail.com Sun Jan 25 21:22:58 2009 From: twanvl at gmail.com (Twan van Laarhoven) Date: Sun Jan 25 21:13:35 2009 Subject: Outlaw tabs In-Reply-To: References: <20090124003526.0b8814cf@solaris> <20090124001713.GI26651@scytale.galois.com> Message-ID: <497D1E82.5050504@gmail.com> Jon Fairbairn wrote: > Warnings are the wrong answer to this problem. In fact, > they're rarely the right answer to any problem. Tabs in > sourcecode can have bad effects, and Haskell is a language > that attempts to reject bad effects as far as possible. Nor > can I see any argument in favour of allowing tabs (if HT is > allowed, why not VT?). Tabs can be convenient for quick scripts and things like that, where you wouldn't use -Wall. And while I keep hearing about the problems with tabs, I have never encountered any with Haskell code. There are other things that are currently warnings that come up much more often and usually have much more severe consequences, such as name shadowing. Twan From barsoap at web.de Sun Jan 25 23:15:38 2009 From: barsoap at web.de (Achim Schneider) Date: Sun Jan 25 23:06:24 2009 Subject: Outlaw tabs References: <20090124003526.0b8814cf@solaris> <20090124001713.GI26651@scytale.galois.com> <497D1E82.5050504@gmail.com> Message-ID: <20090126051538.0885fd2b@solaris> Twan van Laarhoven wrote: > Jon Fairbairn wrote: > > Warnings are the wrong answer to this problem. In fact, > > they're rarely the right answer to any problem. Tabs in > > sourcecode can have bad effects, and Haskell is a language > > that attempts to reject bad effects as far as possible. Nor > > can I see any argument in favour of allowing tabs (if HT is > > allowed, why not VT?). > > Tabs can be convenient for quick scripts and things like that, where > you wouldn't use -Wall. And while I keep hearing about the problems > with tabs, I have never encountered any with Haskell code. > I don't understand how tabs in your code can be convenient for quick scripts, considering that you'd have to switch your editor from sane behaviour, that is expanding them to a number of spaces suitable to your taste, to zomg-I-have-to-waste-space-on-8-space-tabs to prevent any problems with Haskell code. But that's all beside the point. Tabs are a reminiscence of early typewriters used to layout tables that made their way onto early text terminals and onto modern PC's. I don't really understand why, as they have been and always will be obsolete and problematic on everything but a mechanical typewriter. It's not just Haskell code, or generally layout-rule syntax, but any syntax: Did you ever have a look at a mixed tab/space-indent C file with another tab width setting than the original author? Sure, {}'s will help you along, but not before your eyes exploded. If you want a table, use latex or a spreadsheet: Don't use a typewriter. If you want to indent your code, use spaces so everyone sees the same code and does not have to stick indents to tab stops. If you want a key to quickly indent your code, use that funky key with those two arrows, but don't let it produce a tab character while you're editing text. Preferably, let it analyse the syntax of the previous line and automagically Indent By The Right Amount. Finally, for great profit, remove \t out of your ASCII table. There would be less wars. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From phercek at gmail.com Mon Jan 26 03:57:17 2009 From: phercek at gmail.com (Peter Hercek) Date: Mon Jan 26 03:50:37 2009 Subject: Outlaw tabs In-Reply-To: <20090124003526.0b8814cf@solaris> References: <20090124003526.0b8814cf@solaris> Message-ID: Looks like some people still like tabs. I personally do not mind them in my source code if the leading isSpace characters on lines are everywhere of the same kind in one source file. If all indentations would be done only with tabs then one can easily change the indent size for whole file. If monitor is big enough a bigger indent size is nicer (easier to see what is indented together). If monitor is smaller then smaller indent size is better (lines will not wrap so early). If somebody uses proportional fonts then he would like to have tabs available since there would be too much spaces to achieve any reasonable indenting. I can imagine writing in a proportional font myself since I'm indenting only the starts of lines and I'm not indenting anything after the first non-isSpace character. Any indenting after the first non-isSpace character is a pain since it makes small localized changes to look like big changes in diffs and vcs systems and it requires an effort to maintain it. That said, I use non-proportional font and ban tabs in text editor, simply because editor setups for banning tabs are readily available. But I would probably use only tabs (but probably not proportional font) if such editor setups would be ready. The difference is not enough for me to configure editor myself either way. What I want to say is that tabs are not bad, mixing tabs and spaces is bad. And this mixing should be banned if you care about this at all when -fwarn-tabs is available. I would not mind banning tabs as an acceptable solution too. Heh, too much keystrokes for the smallest problem of Haskell' :) Peter. Achim Schneider wrote: > I guess everyone knows why From johan.tibell at gmail.com Mon Jan 26 05:11:38 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon Jan 26 05:02:12 2009 Subject: Outlaw tabs In-Reply-To: References: <20090124003526.0b8814cf@solaris> Message-ID: <90889fe70901260211t5af3de30x5c1476313478acbe@mail.gmail.com> On Mon, Jan 26, 2009 at 9:57 AM, Peter Hercek wrote: > I personally do not mind them in my source code if the leading isSpace > characters on lines are everywhere of the same kind in one source file. If > all indentations would be done only with tabs then one can easily change the > indent size for whole file. If monitor is big enough a bigger indent size is > nicer (easier to see what is indented together). If monitor is smaller then > smaller indent size is better (lines will not wrap so early). I do for the following reason: If you use only tabs for leading whitespace you loose the ability to align things. Here's and example using a list (view using a fixed width font): lst = [1, 2, 3 4, 5, 6] This definition uses alignment to align the first element on the first line with the first element of the second line. You can't do this kind of alignment using tabs. Cheers, Johan From jon.fairbairn at cl.cam.ac.uk Mon Jan 26 05:58:13 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Mon Jan 26 05:48:58 2009 Subject: Outlaw tabs References: <20090124003526.0b8814cf@solaris> <20090124001713.GI26651@scytale.galois.com> <497D1E82.5050504@gmail.com> <20090126051538.0885fd2b@solaris> Message-ID: Achim Schneider writes: > Twan van Laarhoven > wrote: >> Tabs can be convenient for quick scripts and things like that, where >> you wouldn't use -Wall. And while I keep hearing about the problems >> with tabs, I have never encountered any with Haskell code. >> > If you want a key to quickly indent your code, use that funky key with > those two arrows, but don't let it produce a tab character while you're > editing text. Preferably, let it analyse the syntax of the previous line > and automagically Indent By The Right Amount. Exactly. There's no reason that convenience of input should be part of the language syntax. It's a job for another component. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From phercek at gmail.com Mon Jan 26 09:49:02 2009 From: phercek at gmail.com (Peter Hercek) Date: Mon Jan 26 09:41:04 2009 Subject: Outlaw tabs In-Reply-To: <90889fe70901260211t5af3de30x5c1476313478acbe@mail.gmail.com> References: <20090124003526.0b8814cf@solaris> <90889fe70901260211t5af3de30x5c1476313478acbe@mail.gmail.com> Message-ID: Johan Tibell wrote: > I do for the following reason: If you use only tabs for leading > whitespace you loose the ability to align things. Here's and example > using a list (view using a fixed width font): > > lst = [1, 2, 3 > 4, 5, 6] > > This definition uses alignment to align the first element on the first > line with the first element of the second line. You can't do this kind > of alignment using tabs. Yes, most people use that style or its variations (e.g. when multiple assignments have the equal sign aligned somewhere in the middle of a line or comments are aligned at the end, etc). I do not because when I rename lst to myLst then I need to modify two lines (the second one to fix the alignment). Also I do not like that the change looks bigger in a text diff. I prefer: lst = [1, 2, 3 4, 5, 6] -- fixed indent by two spaces regardless of previous lines Or, if I really care about alignment at such a low level (which I almost never do): lst = [1 ,2 ,3 -- fixed indent by two spaces ,4 ,5 ,6] -- fixed indent by two spaces For your style spaces are the only way to go, what I'm perfectly fine with. Actually whatever way this is resolved, I do not care. Just wanted to point out that there is a use for tabs at the line start ... now thinking it might have been an error :-) Peter. From tom.davie at gmail.com Fri Jan 30 11:03:29 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Fri Jan 30 10:53:51 2009 Subject: [Proposal] Move most of Control.Monad to Control.Applicative Message-ID: <07248FD7-D6FD-4BD1-8C7D-9C30E326585D@gmail.com> Hi, Most of Control.Monad doesn't actually rely on Monads, but instead Applicatives. Data.Traversable fixes this in a lot of cases, but it would be nice to have the 'standard' functions as general as possible. My quick reading of Control.Monad says these at least should fall victim to demotion to applicatives: mapA :: (Applicative f) => (a -> f b) -> [a] -> f [b] mapA_ :: (Applicative f) => (a -> f b) -> [a] -> f () sequence :: (Applicative f) => [f a] -> f [a] sequence_ :: (Applicative f) => [f a] -> f () filterA :: (Applicative f) => (a -> f Bool) -> [a] -> f [a] mapAndUnzipA :: (Applicative f) => (a -> f (b,c)) -> [a] -> f ([b], [c]) zipWithA :: (Applicative f) => (a -> b -> f c) -> [a] -> [b] -> f [c] zipWithA_ :: (Applicative f) => (a -> b -> f c) -> [a] -> [b] -> f () replicateA :: (Applicative f) => Int -> f a -> f [a] replicateA_ :: (Applicative f) => Int -> f a -> f () when :: (Applicative f) => Bool -> f () -> f () unless :: (Applicative f) => Bool -> f () -> f () I may have missed some. Bob