October 2004 - Haskell

Re: [Haskell] threading mutable state through callbacks
by MR K P SCHUPKE 14 Oct '04

14 Oct '04

>its almost commutative Does that have something to do with splitting the supply? >newIORef why not use 'newSTRef' and use the ST monad... Keean.

4 3

RE: [Haskell] is $ a no-op?
by Kevin Millikin 13 Oct '04

13 Oct '04

On Wednesday, October 13, 2004 11:25 AM, Jacques Carette [SMTP:carette@mcmaster.ca] wrote: > > > -- It's kind of like an converse map. > > > > I have attempted, unsuccessfully, to write flist above in a point-free > > manner. Is it possible? > > > Of course it is, but why? > > flist = flip (map . flip ($)) > > Some functions are simpler point-free, others are simpler with points. I > was curious about this one (I like the pointwise version better). > > Also, the statement "It's kind of like a converse map" becomes quite clear > from the point-free way to write it, while still not so obvious in the > pointwise version. I haven't proven it, but I think that this is the same function on lists: > flist = (. return) . ap -- Kevin

1 0

Re: [Haskell] threading mutable state through callbacks
by Wolfgang Thaller 13 Oct '04

13 Oct '04

Well, Wadler's Law of Language Design has been disproved. We seem to agree on the syntax, that is, global "foo <- bar" bindings, and we're actually discussing semantics. That's great! Just for the record, I want exactly what Adrian proposed. There seem to be two interesting points about the semantics: 1) To prevent unwanted typecasts, all toplevel "<-" bindings must be monomorphic. This restriction should be sufficient to keep everything perfectly safe (does anyone disagree?), except for... 2) Evaluation order. That's what everyone has been fighting about. So what are our options? a) unsafePerformIO - like. This has some potential for abuse, but it works. Lazy initialization is a good thing for large programs - and that includes side effects. People deliberately do that in OO programs - you'll find methods that look like getSomeMemberVar accessor methods, but the first time they're invoked, they'll actually initialize a part of the program. I'd actually like to abuse this feature that way. Anyway, the non-determinism this introduces is not nearly as bad as what you get from concurrency or even signal handlers... b) Some predetermined order, with semantics like mdo: John Meacham wrote: > The basic idea is that your entire program behaves as if in a giant > 'mdo' block, ordered in module dependency order. What is module dependency order? There's no such thing when there are circular dependencies, and when there aren't any, it might still depend on the order of import directives, which is probably not something I want program semantics to depend on. I feel that In a large program, you'll probably get more surprises from this. The good thing is that you can always use unsafeInterleaveIO to get the other semantics back, so we should probably investigate this further. Is there some option c) that I overlooked? Another question is, if the order is to follow program order, what do we still need main for? Ugh... Cheers, Wolfgang

4 3

[ANNOUNCE] Hacle
by Matthew Naylor 13 Oct '04

13 Oct '04

Dear Haskellers and Cleaners, You may be interested in the results of my final-year student project at the University of York. It involved the development of a translator from Haskell to Clean; an idea that probably won't be too unfamiliar to most of you. The project's homepage is: http://www.cs.york.ac.uk/~mfn/hacle/ I hope that you enjoy the read, and find the results of interest. Kind regards. -- Matthew

1 0

Re: [Haskell] threading mutable state through callbacks
by MR K P SCHUPKE 13 Oct '04

13 Oct '04

>All we really need is a 'unique value monad' to give us unique values This sounds a lot like Clean's unique-types? Keean.

2 1

lazy constructors
by Serge D. Mechveliani 13 Oct '04

13 Oct '04

Dear Haskellers, I try to organize a `lazy' output in my program, so that the data are accumulated, step by step in a pair (String, String) (a contrived simplified example). And the first component is a `story' to be printed out in a `lazy' manner, the first steps need to print without waiting for the whole data field to be ready. If the program returns String, then I can arrange this. But with (String, String), I do not know how to do. And in the real progam, it is a more complex labeled record, carried along through the program. Probably, the obstackle is in the very Haskell language. Consider a simple example: --------------------------------------------------------------- bottomStr :: String bottomStr = let xs = xs in xs bottomSPair :: (String, String) bottomSPair = let p = p in p bound = 10^8 :: Int -- some large number f1, f2, g1, g2 :: Char f1 = head ('a' : (if last [1 .. bound] > 0 then "b" else "c")) f2 = head ('a' : bottomStr) g1 = head $ fst $ addToSPair 'a' (if last [1 .. bound] > 0 then ("b", "") else ("c", "")) g2 = head $ fst $ addToSPair 'a' bottomSPair addToSPair :: Char -> (String, String) -> (String, String) addToSPair c (xs, ys ) = (c:xs, ys ) main = putStr [ f1, '\n' ] -- f2 -- g1, g2 --------------------------------------------------------------- g1 is similar to f1, g2 similar to f2. f1 and f2 are evaluated immediately to 'a'; g1 evaluates to 'a' after a long computation; g2 evaluates to Fail: <<loop>> As g2 is similar to f2, should it have a value 'a' ? In head $ fst $ addToSPair 'a' bottomSPair bottomSPair is of type (String, String). addToSPair is declared as returning (String, String). Hence, the complier knows ab initio that after addToSPair the result is of kind ('a': _, _) :: (String, String) Hence, applying further head $ fst yields 'a'. This is in the air of a `lazy' computation. In a more clear presentation, the computation should (?) be head $ fst $ addToSPair 'a' bottomSPair = head $ fst $ addToSPair 'a' (bottomStr, bottomStr) = head $ fst (`a':bottomStr, bottomStr) = head (`a':bottomStr) = 'a' So, similarly as head ('a' : bottomStr) = 'a', (1) it should be head $ fst $ addToSPair 'a' bottomSPair = 'a' (2) Probably, Haskell-98 does not put so. Right? Question 1 ---------- What may be the consequences for the language (let us call it HCLazy) if it treats the data constructors like in (2), like more `lazy' ones? For example, fst (bottom :: (a,b)) = (bottom :: a) Question 2 ---------- How to arrange the above `lazy' output? The whole result story is ready in several hours, or days, and each step should be displayed immediately as it is ready. So far, I see no other way as to compile the program together with the Trace library, inserting there the calls \ step ... -> trace (show step) $ ... (?) Thank you in advance for the explanations. Copy, please, the answer to mechvel(a)botik.ru ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

Re: [Haskell] lazy constructors
by MR K P SCHUPKE 13 Oct '04

13 Oct '04

You can only return a list of pair's lazily, not a pair of lists. If the two strings are independant, then generate each in a separate function, and pair off the results lazily. Keean.

1 0

Re: [Haskell] threading mutable state through callbacks
by Udo Stenzel 13 Oct '04

13 Oct '04

Wolfgang Thaller <wolfgang.thaller(a)gmx.net> schrieb am 13.10.04 04:36:43: > 2) Evaluation order. > > That's what everyone has been fighting about. > > So what are our options? > > a) unsafePerformIO - like. > b) Some predetermined order, with semantics like mdo: c) same as b) plus unsafeInterleaveIO In fact, I think a specified order for side-effecting initialisation is a good thing. Initialisation should happen in order of declaration and in order of module dependecies. An initialisation that is to be performed lazily is simply wrapped in unsafeInterleaveIO. Anything wrong with that aproach? Regards, Udo. ________________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

1 0

Building from source
by Christian Maeder 12 Oct '04

12 Oct '04

Hi, after checking out fptools from cvs. The simple sequence $ autoreconf $ ./configure $ make failed in the directory hood, because the target boot is unknown there. Could/Should this be fixed? I know how to use mk/build.mk and the ProjectsToBuild variable. I don't need hood, but make still should not fail (after ./configure). Cheers Christian make[1]: Leaving directory `/home/maeder/haskell/linux/fptools-build/hdirect' make[1]: Entering directory `/home/maeder/haskell/linux/fptools-build/hood' make[1]: *** Keine Regel, um »boot« zu erstellen. Schluss. make[1]: Leaving directory `/home/maeder/haskell/linux/fptools-build/hood' make: *** [build] Fehler 1

2 1

[Job] NLP Developer
by Jochen L. Leidner 12 Oct '04

12 Oct '04

[Dear HASKELL subscribers, Apologies for the job posting, but according to the responses to my previous enquiry it does seem to be okay for most of your to receive Haskell-related job ads to this group. Regards, Jochen Leidner] =========================================================================== Natural Language Processing Developer Linguit GmbH --------------------------------------------------------------------------- This position is available in Edinburgh, UK, from 1 January, 2005. We are looking for a skilled developer to join our friendly R&D team to develop our existing question answering technology, which is used in our Nuggets mobile search engine <http://www.mynuggets.net/>. Requirements: ------------- - BSc/MSc/Diploma in Computer Science or Computational Linguistics - At least 2 years of full-time commercial development experience in C/C++/Java/C# - Proven track record in Natural Language Processing (NLP) - Significant practical development and self-management experience in Haskell under a UNIX(R) environment - Python/Perl/sh considered a plus - Prior exposure to software build process (make/ant, CVS/Subversion/ Perforce etc.) - The ability to work independently in a team and good communication skills Salary to be negotiated based on experience. Linguit GmbH is a German-based, privately held, limited liability company that aims to provide cutting edge consulting, services, and products in language and speech technology. Linguit has broad expertise in all major areas of NLP, but focuses especially on Information Extraction and Question Answering. To apply, send your cover letter and curriculum vitae/resume in plain text, PDF, HTML or SPDL to <info(a)linguit.com> (please include the string 'Job: NLP Developer' in your subject line). Deadline for submission is 1 December, 2004. Thank you for your interest. =========================================================================== Try Nuggets, the mobile search engine! <http://www.myNuggets.net/> =========================================================================== -- Jochen L Leidner PhD student University of Edinburgh <http://www.iccs.inf.ed.ac.uk/~s0239229/>

1 0