- Haskell-Cafe - Haskell.org

ANNOUNCE: Haskell Refactorer (HaRe) version 0.7.0.0
by AlanKim Zimmerman 04 Sep '13

04 Sep '13

I am please to announce an alpha release of the Haskell Refactorer making use of the GHC API. It is a work in progress, but currently supports the following refactorings iftocase Convert an if expression to a case expression dupdef Duplicate a definition liftToTopLevel Lift a declaration to the top level liftOneLevel Lift a declaration one level demote Move a declaration down one level rename Rename an identifier It offers emacs integration only at this point, based on the Wrangler elisp. The underlying environment in terms of cabal file, sandbox, etc are managed by ghc-mod via the internals exposed in version 2.1.2 There are some known issues (and bound to be plenty of unknown ones too). The most damaging of these is that layout is not adjusted after renaming an identifier if the new name is a different length. This affects layout-sensitive code. Installation instructions can be found at https://github.com/alanz/HaRe/blob/master/README.markdown Regards Alan

1 0

Haskell / Functional Programmers Group in Madrid (Spain)?
by Alejandro Serrano Mena 04 Sep '13

04 Sep '13

Hi, Is there any Haskell or functional programmers user group in the region of Madrid? If not, I think it could be a great idea to get to know each other, and share experiences. Furthermore, we could try to organize some meetings with presentations, hackatons and so on (my personal ambition is to be able to organize another "ekmett Workshop" as the Japanese one - http://comonad.com/reader/2013/japanese-workshop-1/) I know there is some locations along Madrid dedicated to open source promotion, like http://madridonrails.com/, and which we could use for these meetings. I'm really looking forward to hearing from you! PS: Maybe a bare "Haskell" group is not big enough (at least according to Haskellers.com) but a "functional programmers" one may well be.

5 4

Fwd: Can I use String without "" in ghci?
by Rustom Mody 04 Sep '13

04 Sep '13

On Mon, Sep 2, 2013 at 10:43 AM, Richard A. O'Keefe <ok(a)cs.otago.ac.nz>wrote: > > On 2/09/2013, at 3:55 PM, Rustom Mody wrote: > > > On Mon, Sep 2, 2013 at 5:43 AM, Richard A. O'Keefe wrote: > > > > > A slogan I have programmed by since I first met C and recognised > > how vastly superior to PL/I it was for text manipulation _because_ > > it didn't have a proper string type is "Strings are Wrong!". > > > > C rode to fame on the back of Unix. And Unix's innovation – one of many – > is that at the OS level the string type was made common fare – a universal > type. So everything from file names to file contents to IPC is a string. > > The idea of file names being strings was no innovation. > Yes, in crippled monstrosities like TOPS-10 file names were > weird records -- I can still remember too much of the details -- > and every ruddy TOPS-10 program had to do its own file name > parsing and it seemed as if they all did it differently. But > the B6700 MCP interfaces treated file names as strings before > UNIX was dreamed of. > > File contents in UNIX are *not* strings and never have been -- > NUL termination is no part of files and binary files have been > commonplace since the beginning (an a.out file is not a string!). > They are *byte arrays*. > > As for IPC, since when have System V shared memory, semaphores, > or message queues had anything to do with strings? > (Hint: the 'name' of a System V shared memory segment is a > key_t, and that's an integral type, not a string. > Hint: the 'name' of a System V semaphore is also a key_t > integer, not a string. > Hint: the 'name' of a System V message queue is also a key_t > integer, not a string. > Hint: messages sent using msgsnd are not strings, they are > byte arrays with a separate count parameter. > ) > > Whoops! my bad -- I was *thinking* 'pipes' but ended up *writing* 'IPC' :-) So let me restate more explicitly what I intended -- pipes, FIFOs, sockets, etc. IOW read/write/send/recv calls and the mathematical model represented by the (non-firstclass) pair of C data structures in those functions: <buf, len> (or count). As an aside: modern usage types the buf as void * . The version 7 unix manuals on which I grew up (and first edition of K&R), there was no void; buf would be just 'char *buf; ' > Classic UNIX uses strings for file names, and really, that's it. > (The command line argv[] is not really an exception, because it > was used for file names as well as options, and in fact mixing > the two up caused endless problems.) > Everything else in V7, S3, or SysV was identified by a *number*. > Plan 9 has exit(string) but Unix has exit(byte). > > From the perspective of someone who used UNIX v6 in 1979, > *POSIX* IPC -- with its IPC objects *might* be in the file > system but then again might *not* be so their names are > sorta-kinda-like file names but not really) -- and /proc are > recent innovations. > > The idea that 'string' was even remotely like a "universal type" > in UNIX is bizarre. > > Heck, UNIX never even used 'string' for *lines* in text files! > > > Of course when instructing a beginning programmer your basic premise > 'Strings are Wrong!' is most likely right. > > No, I'm talking about experienced programmers writing high performance > programs. > > > However if programs are seen as entities interacting with an 'external' > world, the currency at the portals is invariably string. > > - The currency at the portals is *not* invariably string. > Learn PowerShell. > - "Text" is one thing and "string" is another. This was the > B6700 lesson (well, really the B5500 lesson): for many purposes > you want a text *stream* not a text *string* at the interface. > It's also the what-Smalltalk-got-right-and-Java-got-wrong > lesson: the right way to convert objects to text is via a > *stream* interface, not a *string* interface. > I realize this is a terminology issue: My usage of terminology like string/file are evidently more aligned to http://en.wikipedia.org/wiki/Vienna_Development_Method#Collections:_Sets.2C… file(chap 4): http://red.cs.nott.ac.uk/~rxq/files/SpecificationCaseStudies.pdf Contrariwise 'file' can mean http://en.wikipedia.org/wiki/Data_set_%28IBM_mainframe%29 So coming back from terminology to principles... > And more than just noob programmers have got this wrong – think of the > precious one-byte opcodes that Intel wastes on ascii and decimal arithmetic. > > Hang on, they are there in order to *support* the "numbers are text" model. > You can't have it both ways. > So let me restate (actually I didn't state it earlier!) my point in this example: When Intel introduced these instructions in 8008 (or whatever) decades ago, it seemed like a good idea to help programmers and reduce their burden by allowing them to do some minimal arithmetic on data without burdensome conversion-to-binary functions. 4 decades on and (Intel's very own Gordon) Moore's law ensuring our machines and networks some 7 orders of magnitude larger, the cost-equations look different. printf and scanf are a basic given in any C library so optimizing them out does not optimize anything. On the other hand having instructions --that too 1-byte instructions -- that are almost never used is terribly inefficient: - the extra transistors in the millions of CPUs that are never used - the instructions that are used become fatter. Multiply by the GBs per installation multipled by millions of installations. And so Intel made (makes) the same mistake that the typical programmer-noob makes, which you capture pithily in your 'Strings are wrong!' Put slightly more verbosely: Strings (or byte-arrays if you prefer) are invariably what come into and go out of your program. Keep them that way and you reduce your work in the immediate term but increase it in the long term since it is almost always a bad fit for both problem-domain and machine-model. Building appropriate models is the central business of programmers Brings me to the OPs question: I want to know if it is possible that I use strings without "". > > If I type > *Prelude>foo bar* > which actually I mean > *Prelude>foo "bar"* > However I don't want to type ""s. > > I have noticed if *bar* is predefined or it is a number, it can be used > as arguments. But can other strings be used this way? Like in bash, we can > use *ping 127.0.0.1* where *127.0.0.1* is an argument. > > If not, can *foo* be defined as a function so that it recognize arguments > like *bar* as *"bar"*? > Its not clear what your use-case is. 1. In the simplest and most common case, a few data declarations will give you what you want. eg if in place of bar you have (a few) colors like red, green etc you can do data Color = Red | Green... and your strings like "red" "green" will disappear and become Red Green etc IOW if your "bar" and like strings is a small enumerate-able set then make a corresponding enumerated type. Thereafter haskell will do the quoting for you. For the IP example you dont even need a data; just type type IP = (Int,Int,Int,Int) or if you prefer type IP = (Word8,Word8,Word8,Word8) and then the shell 127.0.0.1 would be the haskell (127,0,0,1) Sometimes though one may prefer to be a little pedantic and write newtype IP = IP (Word8,Word8,Word8,Word8) Note the exact fit of the Word8 to the IP spec. And the corresponding non-exact fit with the string form: What happens when you see the string, "500.1000.1.2" ? You need to decide... Beyond that, as others have shown you may want to consider building your own DSL perhaps using template haskell Beyond that... are you sure shell is not what you want? ie if you need full haskell power, and typical shell quoting behavior and you have thought through a design that is sound and consistent (note Albert's refs above to $ usage in shell) then I (and I guess many others here) will want to hear of it!! However for starters you probably dont want to go beyond just defining well-fitting datas and types and many of the ".." will vanish from your code Rusi -- http://www.the-magus.in http://blog.languager.org

2 1

Traversals of monomorphic containers (was: Re: mapM_ for bytestring)
by Nicolas Trangez 04 Sep '13

04 Sep '13

# Redirected to haskell-cafe On Sun, 2013-09-01 at 14:58 +0400, Artyom Kazak wrote: > Would this be an appropriate place to propose adding mapM_ (and then > possibly mapM) to bytestring library? > > Was it suggested before? If yes, why was it rejected? This got me wondering: there are several type-classes useful for polymorphic container types, e.g. Functor, Foldable & Traversable which all apply to some type of kind (* -> *). Are there related things for monomorphic containers, like ByteString, Text or some newtype'd Vector with fixed element type, e.g. class MFunctor f a where mfmap :: (a -> a) -> f -> f instance MFunctor ByteString Word8 where mfmap = ByteString.map or (maybe even better) class MFunctor f where type Elem mfmap :: (Elem -> Elem) -> f -> f instance MFunctor ByteString where type Elem = Word8 mfmap = ByteString.map and similar for other classes. Nicolas

3 2

Fwd: World's First Commercial Haskell IDE and Deployment Platform, FP Haskell Center Launches Today
by Natalia Muska 03 Sep '13

03 Sep '13

FP Complete Has Officially Launched the World's First Commercial Haskell IDE! http://www.i-newswire.com/fp-complete-launches-fp-haskell/237230 We greatly appreciate the support we've received from the Haskell community. Natalia Muska Marketing Manager FP Complete, Inc. Natalia(a)fpcomplete.com 865-506-6513 skype: natalia.s.muska -- Natalia Muska Marketing Manager FP Complete, Inc. Natalia(a)fpcomplete.com 865-506-6513 skype: natalia.s.muska

6 6

On Markdown in Haddock and why it's not going to happen
by Mateusz Kowalczyk 03 Sep '13

03 Sep '13

Greetings café, Perhaps some saddening news for Markdown fans out there. As you might remember, there was a fair amount of push for having Markdown as an alternate syntax for Haddock. Unfortunately, this is probably not going to happen for reasons listed on the post I just published at [1]. This thread is meant to be for discussion about the post as many people, myself included, felt that Markdown would be a nice thing to have. I feel like I covered the topic fairly well on the post but feel free to give suggestions or ask questions. I would also like to remind you that if there's something that you'd like to see in Haddock or something that you feel is broken, a good way express this is to make a ticket on the Haddock Trac[2]. I will close the relevant Markdown ticket on the Trac[3] in about 3 days, unless someone can come up with a reasonable solution that meets the initial intent of this part of the project: a widely known markup format that could be used as an alternate syntax for Haddock so that it's possible to write the documentation without learning the vanilla syntax itself. [1]: http://fuuzetsu.co.uk/blog/posts/2013-08-30-why-Markdown-in-Haddock-can't-happen.html [2]: http://trac.haskell.org/haddock [3]: http://trac.haskell.org/haddock/ticket/244 -- Mateusz K.

5 10

Fwd: MVar problem in acid-state?
by Corentin Dupont 03 Sep '13

03 Sep '13

Hi the list, I have compiled my application on my PC, it works fine, but when I copy it on my server (same architecture), I get: Nomyx: thread blocked indefinitely in an MVar operation I don't use MVars in my application, is it possible that it's coming from acid-state? Thanks, Corentin

2 2

Re: [Haskell-cafe] stream interface vs string interface: references
by oleg＠okmij.org 03 Sep '13

03 Sep '13

> For lazy I/O, using shows in Haskell is a good analogue of using > #printOn: in Smalltalk. The basic form is "include this as PART of > a stream", with "convert this to a whole string" as a derived form. > > What the equivalent of this would be for Iteratees I don't yet > understand. Why not to try simple generators first, which are simpler, truly. It seems generators reproduce the Smalltalk printing patterns pretty well -- even simpler since we don't have to specify any stream. The printing takes linear time in input size. The same `printing' generator can be used even if we don't actually want to see any output -- rather, we only want the statistics (e.g., number of characters printed, or number of lines, etc). Likewise, the same printing generator print_yield can be used if we are to encode the output somehow (e.g., compress it). The entire pipeline can run in constant space (if encoding is in constant space). Here is the code module PrintYield where -- http://okmij.org/ftp/continuations/PPYield/ import GenT import Data.Set as S import Data.Foldable import Control.Monad.State.Strict type Producer m e = GenT e m () class PrintYield a where print_yield :: Monad m => a -> Producer m String instance PrintYield Int where print_yield = yield . show instance (PrintYield a, PrintYield b) => PrintYield (Either a b) where print_yield (Left x) = yield "Left " >> print_yield x print_yield (Right x) = yield "Right " >> print_yield x instance (PrintYield a) => PrintYield (Set a) where print_yield x = do yield "{" let f True x = print_yield x >> return False f False x = yield ", " >> print_yield x >> return False foldlM f True x yield "}" instance PrintYield ISet where print_yield (ISet x) = print_yield x newtype ISet = ISet (Either Int (Set ISet)) deriving (Eq, Ord) set1 :: Set ISet set1 = Prelude.foldr (\e s -> S.fromList [ISet (Left e), ISet (Right s)]) S.empty [1..200000] -- Real printing print_set :: Set ISet -> IO () print_set s = print_yield s `runGenT` putStr t1 = print_set set1 -- Counting the number of characters -- Could use Writer but the Writer is too lazy, may leak memory count_printed :: Set ISet -> Integer count_printed s = (print_yield s `runGenT` counter) `execState` 0 where counter _ = get >>= put . succ_strict succ_strict x = x `seq` succ x -- According to GHCi statistics, counting is linear in time -- (space is harder to estimate: it is not clear what GHCi prints -- for memory statistics; we need max bytes allocated rather than -- total bytes allocated) t2 = count_printed set1 -- Doesn't do anything but ensures the set is constructed t3 :: IO () t3 = print_yield set1 `runGenT` (\x -> return ())

1 0

stream interface vs string interface: references
by damodar kulkarni 03 Sep '13

03 Sep '13

In a reply to the question on the thread titled "Can I use String without "" in ghci?", Richard A. O'Keefe has noted that, It's also the what-Smalltalk-got-right-and-Java-got-wrong lesson: the right > way to convert objects to text is via a *stream* interface, not a *string* > interface. > I didn't want to clutter that thread so I am asking a question here. Where do I find foundational and/or other good references on the topic of "stream interface vs string interface to convert objects to text"? I tried google but failed. I am looking for pointers that explain the rational behind the above claim made by O'Keefe. and what is the take of Haskell on this topic? Thanks and regards, -Damodar Kulkarni

2 2

Fw: Re: On Markdown in Haddock and why it's not going to happen
by John MacFarlane 02 Sep '13

02 Sep '13

+++ Mateusz Kowalczyk [Sep 02 13 21:34 ]: > On 02/09/13 19:43, John MacFarlane wrote: > > When the proposal was first being discussed, I suggested that instead of > > adding markdown support to haddock, one might enhance the existing > > haddock markup, making it more expressive, so that it could encode the same > > range of structural features as markdown. If I'm not mistaken, currently > > haddock doesn't allow list items with multiple paragraphs or other block > > elements, or nested lists, or images, or blockquotes. > Paragraph level elements are indeed not allowed in lists. The list > contents are currently (that is, on my working branch) allowed to be: > monospace (delimited by @), anchors, identifiers, module names, > pictures, URLs, bold, emphasis, HTML escape codes, regular strings. Note > that if a monospaced string is the only element of the list content, it > gets turned into a code block. > > I'm not sure what you mean by block elements. I mean things like paragraphs, blockquotes, code blocks, other lists. In markdown you can have a list item that contains these things: 1. This is my first list item. Second paragraph of first list item. Some code: foo = bar <$> baz <*> 2.0 2. This is my second list item. * Sublist item one * Sublist item two 3. This is my third list item. Someone said: > We want markdown support in haddock! In Haddock, last I looked, you couldn't do any of this... In your original message, you emphasized features of Haddock that don't exist in standard markdown and would require extensions (definition lists, automatic links to Haskell identifiers, etc.). But in many other ways, markdown is much more expressive than Haddock markup, as the example above illustrates. The changes that would be needed to Haddock to allow it to express what can be expressed in markdown are much bigger, I think, than the changes that would be needed to markdown to allow it to express what can be expressed in Haddock.

1 0