- Haskell-Cafe - Haskell.org

Re: infinite types
by blaat blaat 17 Jul '03

17 Jul '03

Uhm, of to my holliday in France. But, ah, oh, the joy of programming ;-). I thought I would humor this list by showing where the infinite types (is it?) discussion ended. I found it quite nice and the code is short so here goes ;-) To test: save the mail after the marker and run it in Hugs. There are some examples at the end of the file. ------- cut from here, save as "Reactive.hs" --------------------------------- -- A reactive system is modelled by the type -- -- R m = m -> (Nottaken | Taken (R m) [m]) -- -- It is _not_ a coalgebraic definition, it is _not_ an arrow, it is -- a recursive type in this case used to model asynchronous message -- passing systems. -- -- A system may be thought of as collection of (UML) -- transitions: s0 - event[guard]/action* -> s1 where states are -- hidden in the transitions, and a next-state is a transition, -- or something, I guess. Uhm, huh? ;-) -- -- Note that no explicit distinction between in- and output messages -- is made. This allows liberal, although slightly odd ;-), structural -- composition operators a la Broy, Bird-Meertens, Arrows, Fudgets, -- whatever. In a nutshell: stream processing functions. -- -- After reading the following oddball operators, you, uhm, might -- really want to define your own. Really ;-) -- -- This formalization has weak algebraic rules on the composition -- operators. -- -- Load this code in hugs and test the examples by typing ex0 to -- ex6. module Reactive where type R m = m -> Response m data Response m = Nottaken | Taken (R m) [m] ---------------------------------------------------------------------- -- -- onTaken: helper function onTaken::Response m -> (R m -> [m] -> a) -> a -> a onTaken Nottaken f g = g onTaken (Taken s oo) f g = f s oo ---------------------------------------------------------------------- -- -- The behavior of a system is, of course, a mapping from an input -- stream of messages to an output stream of messages. behavior::R m->[m]->[m] behavior s [] = [] behavior s (i:ii) = onTaken (s i) (\s0 oo-> oo ++ behavior s0 ii) (i:behavior s ii) ---------------------------------------------------------------------- -- Copy is a simple system which copies all input to its output. -- -- +++++ -- + + -- +++++ ---------------------------------------------------------------------- copy::R m copy m = Taken copy [m] ---------------------------------------------------------------------- -- Lift is a simple system which is the lifting of a function from -- messages to messages to a reactive system. -- -- +++++++++ -- + ^ + -- + f + -- + + -- +++++++++ ---------------------------------------------------------------------- lift::(m->m) -> R m lift f m = Taken (lift f) [f m] ---------------------------------------------------------------------- -- -- If we have a system on messages of type b, and translator functions -- between another type a, we can change the interface to a system -- on messages of type a. (This is a solution for not -- making an explicit distinction between input and output messages; -- now we can partition the messages of subsystems) -- -- +++++++++ -- + + -- + s:R a +:R b -- + + -- +++++++++ interface::(a->b)->(b->a)->R b->R a interface t f s i = onTaken (s (t i)) (\s1 oo->Taken (interface t f s1) (map f oo)) (Nottaken) ---------------------------------------------------------------------- -- -- The parallel composition of two systems s and r is the system which -- if s takes an input then makes s process it, otherwise if r takes an -- input then makes r process it, otherwise does not process it. -- -- Supposed to model the parallel composition of a collection of -- event handlers (like: sound subsystem, graphics subsystem, etc). -- -- +++++ -- + s + -- + + + -- + r + -- +++++ -- -- ( (a <+> b) <+> c = a <+> (b <+> c) ) parallel::R m->R m->R m parallel s0 s1 i = onTaken (s0 i) (\s2 oo->Taken (parallel s2 s1) oo) (onTaken (s1 i) (\s2 oo->Taken (parallel s0 s2) oo) (Nottaken)) infixr 5 <+> (<+>) = parallel ---------------------------------------------------------------------- -- -- The sequential composition of systems s and r takes an input if -- s accepts the input and then makes r process all output of s. -- All output by s which is not taken by r _passes through_ r. -- -- Supposed to model pipes (where exceptions or messages to the -- outside world leak through). -- -- -- +++++++ -- + s.r + -- +++++++ -- -- ( (a <.> b) <.> c = a <.> (b <.> c) ) -- sequential::R m->R m->R m sequential s0 s1 i = onTaken (s0 i) (\s2 oo-> onTaken (seqloop s1 oo) (\s3 oo1-> (Taken (sequential s2 s3) oo1)) (Nottaken)) (Nottaken) seqloop::R m->[m]->Response m seqloop s [] = Taken s [] seqloop s (i:ii) = onTaken (s i) (\s1 oo0-> onTaken (seqloop s1 ii) (\s2 oo1 -> Taken s2 (oo0++oo1)) (Nottaken)) (onTaken (seqloop s ii) (\s1 oo -> Taken s1 (i:oo)) (Nottaken)) infix 6 <.> (<.>) = sequential ---------------------------------------------------------------------- -- -- Feedback on a system s feeds _all_ output of s back to s. All -- output which is not accepted by s _passes through_ s (and the -- loop). -- -- Feedback folds all the transitions taken over fed back output -- into _one_ big transition... -- -- +++++ -- -+-++ s +-+-- -- | +++++ ^ -- +--------+ ---------------------------------------------------------------------- feedback::R m->R m feedback s i = onTaken (s i) (\s0 oo0-> onTaken (feedloop s0 oo0) (\s1 oo1-> Taken (feedback s1) (oo1)) (Nottaken)) (Nottaken) feedloop::R m->[m]->Response m feedloop s [] = Taken s [] feedloop s (i:ii) = onTaken (s i) (\s0 oo-> feedloop s0 (ii++oo)) (onTaken (feedloop s ii) (\s0 oo -> Taken s0 (i:oo)) (Nottaken)) feed = feedback ---------------------------------------------------------------------- -- small examples: ---------------------------------------------------------------------- test s = take 40 (behavior s (repeat 1)) ex0 = test copy ex1 = test (lift (*2) <.> lift ((-)1)) ex2 = test (lift (+1) <+> lift (*2)) ex3 = test (lift (+2) <+> copy <.> lift (+3)) ex4 = test (feed copy) -- infinite computation ex5 = test (interface (\i->'a') (\a->5) copy) ---------------------------------------------------------------------- -- bigger example: ---------------------------------------------------------------------- data Msg = Tick | Out Int | Add Int | AddResult Int | Write Int Int | Fetch Int | Read Int Int deriving (Show) add::Maybe Int -> R Msg add Nothing (Add j) = Taken (add (Just j)) [] add (Just i) (Add j) = Taken (add Nothing ) [AddResult (i+j)] add _ _ = Nottaken register::Int->Int->R Msg register i _ (Write j r) | i == j = Taken (register i r) [] register i r (Fetch j) | i == j = Taken (register i r) [Read i r] register _ _ _ = Nottaken controller::R Msg controller Tick = Taken controller [Fetch 0, Fetch 1] controller (Read i j) = Taken controller [Add j, Write (1-i) j] controller (AddResult i) = Taken controller [Out i, Write 1 i] controller _ = Nottaken ex6 = test (interface (\_->Tick) (\(Out i)-> i) (feed (register 0 0<+>register 1 1<+>add Nothing<+>controller))) ---------------------------------------------------------------------- -- This code is licensed under the Big-Kazooba-Ritual license: -- -- You may copy, modify or distribute this software provided that -- you first perform the ritual described in section a. -- -- If you ever meet one of the authors of this work you can be asked, -- and must comply, to perform the ritual as described in section a. -- -- You must add this license to any derivatives of this work. -- -- a. Lift your left leg, close your eyes and jump in the air. -- Now tap the point of your nose exactly two times with your -- right index finger. To complete: say the words -- "thank you Big Kazooba" -- -- You may open your eyes now. -- -- The disabled may opt not to perform this ritual but have a -- volunteer perform the ritual on their behalf. -- -- Anyone, of suited position, may opt to command any number of -- subordinates to perform the ritual instead. -- -- Thank you, -- l4t3r ---------------------------------------------------------------------- _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus

1 0

RE: Hugs Humor
by Simon Marlow 17 Jul '03

17 Jul '03

Jerzy Karczmarczuk writes: > I am abhorred by the fact that adding ... :: Rational > changes the lexical meaning of a literal. It doesn't. A literal with a decimal point always means (fromRational (X%Y)) for some appropriate X and Y. Adding a type signature changes the dynamic meaning of the literal, not the lexical meaning (something we're used to in Haskell, no?). Cheers, Simon

1 0

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 16 Jul '03

16 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 15 Jul '03

15 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