- Haskell-Cafe - Haskell.org

Re: Case expressions, matching, and "constants"
by Graham Klyne 17 Jul '03

17 Jul '03

At 12:03 17/07/03 +0100, Bayley, Alistair wrote: >This is what I've turned it into to get it to work. It seems a bit clumsy; >is there a better way to write this? > > > test n = > > case True of > > _ | n == one -> "one" > > | n == two -> "two" > > | otherwise -> "three" The 'case' is somewhat redundant. How about: > test n | n == one = "one" > | n == two = "two" > | otherwise = "three" #g ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

1 0

Worldwide Partners program
by The TechNews 17 Jul '03

17 Jul '03

The TechNews, July 2003 Production Mini-plants in mobile containers. Worldwide Partners program Science Network will supply to countries and developing regions the technology and necessary support for production in series of Mini-plants in mobile containers (40-foot). The Mini-plant system is designed in such a way that all the production machinery is fixed on the platform of the container, with all wiring, piping, and installation parts; that is, they are fully equipped... and the mini-plant is ready for production." More than 700 portable production systems: Bakeries, Water purification, Dehydrated food, Steel Nails, Fruit juice preparation, Tire Retreading, Reinforcement Bar Bending for Construction Framework, Sheeting for Roofing, Ceilings and Façades, Plated Drums, Aluminum Buckets, Injected Polypropylene Housewares, Pressed Melamine Items (Glasses, Cups, Plates, Mugs, etc.), Mufflers, Construction Electrically Welded Mesh, Plastic Bags and Packaging, Mobile units of medical assistance, Sanitary Material, Hypodermic Syringes, Hemostatic Clamps, etc. Science Network has started a Co-investment program for the installation of small Assembly plants to manufacture in series the Mini-plants of portable production on site, region or country where required. One of the most relevant features is the fact that these plants will be connected to the World Trade System (WTS) with access to more than 50 million raw materials, products and services and automatic transactions for world trade. Due to financial reasons, involving cost and social impact, the best solution is setting up assembly plants on the same countries and regions, using local resources (labor, some equipment, etc.) Science Network participates at 50% (fifty percent) for investment of each Assembly plant. If you are interested in being a Science Network partner in your country or region, you can send your CV to: Mini-plants <A HREF="mailto:letters@the-tech-news.com">Worldwide Partners program</A> By Robert B. Lethe, The TechNews, Editor ------------------------------------------------------------------------- If you received this in error or would like to be removed from our list, please return us indicating: remove or un-subscribe in subject field, Thanks. <A HREF="mailto:editor@the-tech-news.com"> Editor</A> © 2003 The TechNews. All rights reserved.

1 0

Old alternative syntax for list comprehensions?
by Peter Pudney 17 Jul '03

17 Jul '03

I recently wanted to generate an infinite list of pairs [(i,j) | i <- [1..], j <- [1..]] Of course, this list comprehension never gets around to generating pairs (2,_). The solution I was after is easily done: [(i,s-i) | s <- [2..], i <- [1..s-1]] But I have a vague recollection of an alternative syntax, something like [(i,j) \ i <- [..], j <- [1..]] that generated a list something like [(1,1),(1,2),(2,1),(1,3),(2,2),(3,1),...]. Did I dream this, or was it a feature of Miranda*, Gopher or Hugs many years ago? Peter

4 3

Re: infinite types
by blaat blaat 17 Jul '03

17 Jul '03

> > > type R m = m -> Maybe (R m, [m]) > > > > I don't think there's an extension of Haskell with regular type > > unification. It's certainly possible, but there's an equivalent in > > standard Haskell: > > > > newtype R m = MkR (m -> Maybe (R m, [m])) > >It will possibly be more convenient to break the cycle in another place, >where >we will wrap and pattern match anyway: > >type R m = m -> Response m >data Response m > | NotTaken > | Taken (R m) [m] Thanks everyone for responding so swiftly. The trick by Marcin really cleaned up my code, thanks! Cheers, l4t3r _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail

1 0

Haskell book recommendation?
by bjkwak 16 Jul '03

16 Jul '03

Hi! Searching for a new programming language for my work, I got interested in functional languages. After several weeks of googling and searching, I decided to learn Haskell. I have downloaded and read some tutorials from the Haskell home page, but most of them are incomplete and I decided to buy a book or two. I have found a list of books on Haskell in the Haskell home page, but I cannot decide from the information given in the page. Could any body give me some advice? I have some experience in C, but never programmed in functional language before. I have read about 1/4 of the book "ML for the working programmer" by L.C. Paulson. Thanks! Byung-Jae

3 4

re: infinite types
by blaat blaat 16 Jul '03

16 Jul '03

Sorry if this mail starts a new thread. I am not subscribed to haskell-cafe and am new to hotmail. Uhm, as far as the example goes. I was trying to define a small (shallow encoding of) a reactive systems language. Because I wanted to try something else than monads I defined the following recursive type for a reactive system. type R m = m -> Maybe (R m, [m]) Supposedly a reactive system is a system which may not take a message (the Maybe), or do take it and respond with an updated version of itself, and a sequence of outgoing messages. For example, a copying machine might be defined as: id:R m id m = Just (id, [m]) A version for a ?Meally? machine embedding (always take an incoming message, and respond with one outgoing message) could be written as type Meally i o = i -> (Meally i o, o) where id is defined as id::Meally a a id m = (id, m) I like the formalization because (a) it is concise, (b) structural composition operators can be defined trivially, (c) hides the state of a machine, (d) might possibly, in the long run, somewhere, even work out equally well as a monadic approach. Does it make sense? Are there any known references to this approach? Cheers, l4t3r PS: Actually, I just realized this might be the co-algebraic approach, so I guess I am asking for a haskell which allows co-algebraic types. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

3 2

infinite types
by blaat blaat 16 Jul '03

16 Jul '03

Hi al! In my holliday I like to hobby a bit with haskell. For a small formalization I wanted to try out a specification which uses infinite types. Does a (extended) haskel compiler exist which allows infinite types? Chees, l4t3r _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

RE: functional "updatable" graph
by Hal Daume 16 Jul '03

16 Jul '03

>> I think that the >> difficulties you are >> facing are from the fact that you are trying to >> express a purely >> functional "updatable" graph. > > Should I understand from this, that this is a > difficult problem and that there exist no easy way to > do this at the moment? Well, I think he was being a bit ironic. You can either have a functional graph or an updatable graph, but not both. It sounds like either would do and given that later in this message you discuss that you don't like imperativeness, then a functional graph (ala the Functional Graph Library -- FGL) would suit you perfectly. > About the graphs:Well, I never had graphs at school > yet(first year student)... Although it is somewhere in > my textbooks... They're very simple. You have a collection of nodes, N, and a collection of edges between elements of N. Nodes and edges can have labels. So for instance you could have Teachers and Classes as the nodes and the edges could be between the teacher and the class(es) which go together. > To solve my problem... I need an mutable array, but in > Haskell my program will then be unbelievable > imperative. No, you just need a graph :). > I have been following the discussion about the graph > and so, but the arrow classes and so on, are like > something too sophisticated for me at this moment I > think, although I have some idea of how they work, I > really don't know when to apply them. I just found > out, how Monads work, so... THe discussion about arrows is a complete divergence. You don't need anything about them. > But I certainly believe that my problem must be fixed > before it's easy to program in Haskell. Theorem: this problem is already fixed. Proof: it is easy to program in Haskell. QED. :) - Hal

2 1

Simple monads
by Mark Carroll 15 Jul '03

15 Jul '03

Not really seeing why Unique is in the IO monad, not deeply understanding the use of Haskell extensions in the State source, and wanting to try to learn a bit more about monads, I thought I'd try to write my own monad for the first time: something for producing a series of unique labels. This is how it turned out: ========================================================================== module Label (Label, Labeller, newLabel) where import Monad newtype Label = Label Int deriving (Eq, Ord) newtype Labeller a = Labeller (Int -> (Int, a)) instance Monad Labeller where return r = Labeller (\n -> (n, r)) (Labeller g) >>= y = let f m = let (r, n) = g m Labeller h = y n in h r in Labeller f newLabel :: Labeller Label newLabel = Labeller (\n -> (n + 1, Label n)) runLabeller :: Labeller a -> a runLabeller (Labeller l) = snd (l minBound) labelTest :: Labeller [Int] labelTest = do Label a <- newLabel Label b <- newLabel Label c <- newLabel Label d <- newLabel return [a,b,c,d] main = print (runLabeller labelTest) ========================================================================== I was thinking that maybe, (a) People could point out to me where I'm still confused, as revealed by my code. Is it needlessly complicated? (b) My code may be instructive to someone else. -- Mark

12 24

Handling large ini files.
by Thaddeus L. Olczyk 15 Jul '03

15 Jul '03

A while ago I looked at Haskell. I got stuck on a problem which basically caused me to stop using Haskell. Realising that I never asked anyone else how they would approach the deal, I decided to ask before I put the final chapter on Haskell. I have a program that requires a lot of customisation. As a result there is an initialization file with many entries ( typically 30-80 entries ). Some of these entries need to be accessed quite often, so that opening the file and reading in on demand is not really an option. So the basic question is how do I handle access to these parameters? PS: I've thought of Hugh's approach to global variables, but even with compound data structures it really isn't practical for such a large number. Not even when creating compound structures to hold the data. Worse you wind up with data structures which are not coherent having only the fact that each is a customisation in common. Thaddeus L. Olczyk ----------------------- Think twice, code once.

4 3