- Haskell-Cafe - Haskell.org

All Segments Problem
by Saswat Anand 01 Mar '02

01 Mar '02

Hi All, This is not a haskell problem. I need some pointers which some of you might provide. In program calculation community, segement problems e.g. maximum sum problem have been studied extensively. The problems involve finding a segment of the list that maximizes some objective function and satisfies some predicate. But I am wondering if is there similar study on the family of problems where we need to find all the segments of a list that satisfy some predicate. I am interested in predicates involving forall and existential quantifiers. Thanks for any suggestion. Cheers, Saswat

1 0

Changing a light bulb.
by Shawn P. Garbett 01 Mar '02

01 Mar '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Now after my earlier soap box tirade I'm trying to put my code where my mouth is. >>blush<< It's harder than I thought. I've broken it down into a State Model of a light bulb. The goal, to find out just how much Haskell code does it take to change the state of a light bulb? Here's a very crippled version. Is there an easy way to introduce state without changing the type of main??? I've written a much more complex example, but I got into things like main :: STT(IO) using a monad transformer. So really, the big question is, must I use a monad transformer? - ------------------------------------------------------------------------------------------------ - -- State model of a light bulb import Monad import IO main :: IO () main = do hSetBuffering stdin NoBuffering process process :: IO () process = do i <- assign initialState putChar '\n' print(s) if (s /= Exit) then process else return () data State = Dark | Light initialState :: State initialState = Dark data Stimulus = On | Off | Exit deriving (Show, Eq, Enum) charToStimulus :: Char -> Stimulus charToStimulus '1' = On charToStimulus '0' = Off charToStimulus c = Exit getStimulus :: IO Stimulus getStimulus = liftM charToStimulus getChar - -- State transformer newtype St a = MkSt (State -> (a, State)) - -- State transformer applied to state apply :: St a -> State -> (a, State) apply (MkSt f) s = f s - -- State monad instance Monad St where return x = MkSt f where f s = (x,s) p >>= q = MkSt f where f s = apply (q x) s' where (x, s') = apply p s - -- Useful State operations fetch :: St State fetch = MkSt f where f s = (s,s) assign :: State -> St () assign s' = MkSt f where f s = ((),s') done :: St () done = return () - ----------------------------------------------------------------------------------------------------------------------- - -- You're in a maze of twisty little statements, all alike. Public Key available from http://www.garbett.org/public-key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8fqdpDtpPjAQxZ6ARAkCWAJ9pGcS/hQpoK12AdcEmt8Y/0rEv9ACfWGtO 1FL9VwopmgsAyUAv9RL++T8= =a9xu -----END PGP SIGNATURE-----

2 1

Re: Ground Up
by Rijk J. C. van Haaften 01 Mar '02

01 Mar '02

Jerry wrote >However, my problems are: >* I still don't understand most of the codes I found, like the various > haskell libraries Practice is the only answer to this problem, as Keith Wansbrough says. >* I still have no clue of most (ok, almost all) of what is being > discussed in this mailing list Though I am a CS student, being highly interested in Haskell and practising a lot, I didn't understand most of the discussions on this mailing list. I started understanding them only after I got involved in implementing a Haskell compiler. Therefore, don't worry about this point. A haskell-user doesn't need to know the details of the haskell compiler ins and outs. Rijk-Jan van Haaften

4 4

Re: Help
by Rijk J. C. van Haaften 01 Mar '02

01 Mar '02

You probably want to do something like this: main = do { contents <- input "twoboxes.dat" return (control (parser contents)) } At 11:53 25-02-02 -0300, Juan M. Duran wrote: >Hi, I'm writting a small parser in Haskell and, when it is all done, I get >the following problem: Type Binding. >The thing is, I have 3 main functions: >1) Read the file, its type is: [Char] ->IO [Char] (see InputOutput.hs) >2) Parse a string (using words and readDec), its type is: Integral a => >[Char] -> [a] (see Parse.hs) >3) Parse a list of integer, its type is: [Float] -> [[Float]] >(Functions.hs) > >Now the problem is that I cannot run the first function, then use its >results as an input of the second function and, finally, its results as >the input of the third function. > >How can I fix this without modifing all my functions because they, >independly, works fine. > >Juan

5 6

RE: Ground Up
by Konst Sushenko 01 Mar '02

01 Mar '02

a word from a beginner (with a CS background): Alternatively, just do not use compiler specific features in your programs and this will make your programs work with different compilers. I went away from Lisp because there are no types. someone said once that Lisp is a sort of intermediate language that many people happen to like to program in. an assembly language of sorts. I went away from ML because once I got a taste of laziness, having my parameters evaluated before my function is called started to upset me ;-), and also I do not like that I have to use tuples in ML's datatypes. At least I did not find a way to not use them... But then of course one starts seeing all these problems with expressions taking too much heap space when writing programs of considerable size... But then using a purely functional language will teach you to forget trying to change a tuple or anything else in place (although I saw libraries in GHC that can change arrays, etc, in-place but I never used them), which is helpful I believe because it gives a different perspective on writing code. konst > -----Original Message----- > From: Max Kirillov [mailto:max630@mail.ru] > Sent: Thursday, February 28, 2002 1:10 PM > To: haskell-cafe(a)haskell.org > Subject: Re: Ground Up > > > Hi! > > I'm far not an expert in Haskell, but I'll venture to say > "I'm in". I'm not an CS student and I have never been (I > learned Solid State Physics). I became there in about 6 > months without paying a cent. Well, I paid for dialup. I > also spent a lot of time. My wife should hate Haskell. > > I would recommend you not to be confined by Haskell. Take a > look at Lisp, ML. First, it helps to get into concepts > rather than into details of syntax parsing of high-order > polymorphism. I began learning FP with Erlang, and I think > it helped me. > > Further, Haskell, though _very_ nice, is probably not "the > best choice" for a "pragmatic programming". It is too alive. > Different compilers are not 100% compatible each to other, > and even different versions of the same compilers may be > incompatible. You should be ready either to stick yourself > and your co-wokers to a certain version of the compiler or > to spend some significal time to keep you programs working > with any compiler. > > Maybe you will find that it's better to use Ocaml or > Scheme. Thay have own neats, and seem to be more stable. > > Max. > > On Thu, Feb 28, 2002 at 09:41:10PM +0800, Jerry, JiJie wrote: > > Good day everyone, I'm a haskell newbie trying to seeking advice to > > advance myself. > > > > My backgrounds are: > > * As a non-CS student, I have absolutely no knowledge of > lambda calculus > > * And unfortunately I have to make painful decision on spending $30 > > on a book or three days' meal > > > > While my goals are: > > * Become a pragmatic haskell programmer in the shortest time > > * At the minimal expense > > > > What I have done for the past few weeks were: > > * I read almost all the free educational sources at > www.haskell.org, > > * Subscribed to this mailing list and try > to digest every mail > > * Read most of the "The Haskell School of Expression" (by Paul > > Hudak) and the non-theoretical chapters of the "An Introduction To > > Functional Programming Systems Using Haskell" (by AJT > Davie), which > > are the only two introductory level haskell related books in our > > library > > > > However, my problems are: > > * I still don't understand most of the codes I found, like > the various > > haskell libraries > > * I still have no clue of most (ok, almost all) of what is being > > discussed in this mailing list > > > > So I'm eager to know if there are cost-effective ways to achieve my > > goals or at least leverage myself from the beginner's level. > > > > Your advice would be greatly appreciated! > > > > Regards, > > Jerry > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Lazy Parsing
by Brandon Michael Moore 28 Feb '02

28 Feb '02

I'm wondering if there are any libraries out there for creating parsers that lazily build up their result. I know I could thread the remaining input through a parser by hand, but it seems like someone should have already done it. I'd like to be able to turn a stream of XML into a lazy tree of tags (probably Maybe tags, or Either errors tags), but I don't think HaXml and the like do that sort of thing. Branodn Moore

3 2

Re: Ground Up
by Ketil Z Malde 28 Feb '02

28 Feb '02

"Jerry, JiJie" <jerry(a)gime.com> writes: > While my goals are: > * Become a pragmatic haskell programmer in the shortest time > * At the minimal expense How far have you come? Are you comfortable with recursion? With the type system? IO? Monads in general? > * I still have no clue of most (ok, almost all) of what is being > discussed in this mailing list Me neither; don't let that worry you. I'd advise you to ignore threads about difficult issues -- a lot of stuff discussed here is rare borderline cases that are mostly of interest to implementors, and not you and me. :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 1

Haskell in Space
by Christoph Lueth 28 Feb '02

28 Feb '02

Dear Haskell people, as the last exercise of a second-year undergraduate Haskell course I had the students write an asteroids-type game (older readers may remember this arcade classic from the last century) using the Hugs Graphics Library. I put some solutions up on a wee web-page, because I thought it might amuse some of you who teach or learn Haskell, and because frankly one of the students' solutions simply deserved some wider attention: http://www.informatik.uni-bremen.de/~cxl/haskell-in-space Enjoy, --Christoph.

2 1

Re: Lazy Parsing
by John Hughes 28 Feb '02

28 Feb '02

There's a combinator which Phil Wadler called "guarantee" which makes a parser lazy -- guarantee p succeeds at once, with a result which will be produced, when demanded, by p. Many parsing libraries include it under one name or another... John

1 0

Re: higher-kind deriving ... or not
by C T McBride 27 Feb '02

27 Feb '02

Hi On Thu, 28 Feb 2002, Tom Pledger wrote: > C T McBride writes: > | > data Fix f = Fix (f (Fix f)) > | > | There's no equivalent first-order definition. This is where > | higher-kind parameters actually buy us extra stuff, and it's also the > | point at which the first-order constraint for show becomes hopeless. > > Did you see the technique Mark Tullsen posted last year, for making > instances in the presence of a fixpoint? I've found it useful. > > http://haskell.cs.yale.edu/pipermail/haskell/2001-May/003942.html Thanks for the pointer. Yes, that looks like a kind of hard-coding of the lifting to higher kinds that I'm after. If I understand things correctly, it would seem that for every type class C t, indexed by types, one can manufacture the constructor class FC f which asserts that f preserves C-ness. For each C-method m :: blah[t] one gives the FC method fm :: C t => blah[f t] One can lift further, by defining classes for constructors with higher-kind parameters which take FC-ness (or whatever) to C-ness. Requiring FC f (a first-order constraint on a higher-kind thing) is a plausible fake of requiring (forall a. C a => C (f a)) (a higher-order constraint on types). If I read correctly, automating this construction, effectively yielding computation of classes from kinds, is part of Simon PJ and Ralf Hinze's `Deriving Type Classes' proposal. The functionality is clearly desirable. It does, however, come at the cost of introducing a third and still separate programming language as a component of Haskell---the language of programming over kinds. It's no good asking when this will stop, because it doesn't. It is worth asking when the different layers of this hierarchy will acquire a greater uniformity. Cheers Conor

1 0