- Haskell-Cafe - Haskell.org

constructors in O'Haskell
by Peter Padawitz 11 Jul '03

11 Jul '03

How may I hide constructors in O'Haskell 'cause export lists don't work in this language? Peter

1 0

Monad constructors
by Peter Padawitz 11 Jul '03

11 Jul '03

Why must every Monad instance be a datatype or newtype, even if there will be just a single constructor? Peter

1 0

Re: Representing cyclic data structures efficiently in Haskell
by C.Reinke 08 Jul '03

08 Jul '03

> What is the best way to represent cyclic data structures in Haskell? There used to be some work on direct cyclic representations at UCL: Dynamic Cyclic Data Structures in Lazy Functional Languages Chris Clack, Stuart Clayman, David Parrott Department of Computer Science, University College London, October 1995 The link to the project, from http://www.cs.ucl.ac.uk/staff/C.Clack/research/report94.html is broken, but the paper seems to be online at http://www.cs.ucl.ac.uk/teaching/3C11/graph.ps If you want to go for this direct cyclic representation, the interplay with lazy memo functions is also interesting: J. Hughes, Lazy memo-functions, Functional Programming Languages and Computer Architecture, J-P. Jouannaud ed., Springer Verlag, LNCS 201, 129-146, 1985. (lazy memo-functions remember previous input-output pairs based only on pointer-info, which is sufficient to write functions over cyclic structures that, instead of infinitely unrolling the cycles, produce cyclic results) (not online?-( Claus

1 0

I NEED YOUR HELP
by johnmboma＠sify.com 08 Jul '03

08 Jul '03

Dear Sir, I need your help,I am John Mboma the son of a Late minister during the reign of mobutu seseko, I came to know you in the course of my search for a reliable and God fearing partner and I decide to contact you because I believe you are a reputable person and I felt you can help us over this confidential matter. I count on your intergrity and honesty to be able to handle this business. My father was a minister in Democratic Republic of Congo during the reign of Late President Mobutu. Our father was killed during the rebel attack and our house was burnt. We manage to escape to South Africa with my mother and two of my sisters where we are now taking refuge.Before the death of my father he deposited US$30.5 MILLION, with a security company in Europe.The money is kept in a trunk boxes and was registered as precious substance. Thus there is nobody that knows that it is money that is in the box. All the document with which the money was deposited is with us. I am looking for somebody to that is capable and willing to travel to Europe Country to receive the two trunk boxes of money on behalf of my family from the security company. We need a trust worthy and experience person that will help us to invest this money in your country and take us as one family and will also buy a house for us over there where we can live safely. We are expecting to hear from you.Please contact me on this Email Address: john.mboma1(a)caramail.com Thanks for your anticipated cooperation.please include your telephone number and fax number in your reply Best Regards, JOHN MBOMA

1 0

Representing cyclic data structures efficiently in Haskell
by Sarah Thompson 08 Jul '03

08 Jul '03

What is the best way to represent cyclic data structures in Haskell? Lists are trivial. Trees are trivial. But what if the thing you're trying to represent is shaped like an electronic circuit, with a (possibly large) number of nodes connected by multiple arrows to other nodes? In an imperative language like C++, I'd probably just model the circuit directly, with objects representing nodes and pointers representing links between nodes. A good way to model this in Haskell is less obvious, however. A simplistic approach would be to represent such a structure as a list of nodes, where each node contained a list of other connected nodes. Containing the actual nodes within the sub-lists probably isn't feasible -- some kind of reference would be necessary in order to get around chicken-and-egg problems with instantiating the data structure. But, in this case, it's not so easy to see how one could 'walk' the structure efficiently, because moving from node to node would involve quite horrible (possibly slow) lookups. In C++, I'd simply follow a pointer, which would be an extremely fast operation. I would also need to implement efficient indexes into the data structure -- flat searching will be too slow for non-trivial amounts of data. In C++, I'd implement one or more external (probably STL-based) indexes that point into the main data structure. How do people typically solve this problem at the moment? I know a few people out there have written hardware compilers in Haskell and similar languages, so there should be some experience of this in the community. I can probably work something out soon enough, but reinventing the wheel is never a great idea. Thank you in advance, -- ---------------------------------------------- / __ + / Sarah Thompson **** / / (_ _ _ _ |_ / * / / __)(_|| (_|| ) / sarah(a)telergy.com * / / + / http://findatlantis.com/ / ----------------------------------------------

6 6

RE: Representing cyclic data structures efficiently in Haskell
by Hal Daume 07 Jul '03

07 Jul '03

>From reading your message, it seems you want a graph library of sorts. I've used FGL extensively and found it to be very nice. It even provides both a purely functional interface as well as an imperative-esque interface. It also comes with a bunch of standard algorithms built in, though I don't know enough about circuitry stuff to know whether those would be useful or not. If FGL seems like overkill to you, I have my own little mini graph library which basically looks like: - An ADT, Node: newtype Node = Node Int deriving ... - The 'Graph n e' data structure, containing: - a FiniteMap from n -> Node - an (growable?) array of type IOArray (Node,Node) e the array represents the edges in the top half (i do some index fiddling to get this efficient) and the finitemap represents the node labellings. It's a pretty stupid interface and works a lot better when the graphs are fixed size (that way you don't need to grow the array). But it works. -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > -----Original Message----- > From: haskell-cafe-admin(a)haskell.org > [mailto:haskell-cafe-admin@haskell.org] On Behalf Of Sarah Thompson > Sent: Monday, July 07, 2003 8:04 AM > To: haskell-cafe(a)haskell.org > Subject: Representing cyclic data structures efficiently in Haskell > > > What is the best way to represent cyclic data structures in Haskell? > > Lists are trivial. Trees are trivial. But what if the thing you're > trying to represent is shaped like an electronic circuit, with a > (possibly large) number of nodes connected by multiple arrows > to other > nodes? In an imperative language like C++, I'd probably just > model the > circuit directly, with objects representing nodes and pointers > representing links between nodes. A good way to model this in > Haskell is > less obvious, however. > > A simplistic approach would be to represent such a structure > as a list > of nodes, where each node contained a list of other connected nodes. > Containing the actual nodes within the sub-lists probably > isn't feasible > -- some kind of reference would be necessary in order to get around > chicken-and-egg problems with instantiating the data > structure. But, in > this case, it's not so easy to see how one could 'walk' the structure > efficiently, because moving from node to node would involve quite > horrible (possibly slow) lookups. In C++, I'd simply follow a > pointer, > which would be an extremely fast operation. > > I would also need to implement efficient indexes into the > data structure > -- flat searching will be too slow for non-trivial amounts of > data. In > C++, I'd implement one or more external (probably STL-based) indexes > that point into the main data structure. > > How do people typically solve this problem at the moment? I > know a few > people out there have written hardware compilers in Haskell > and similar > languages, so there should be some experience of this in the > community. > I can probably work something out soon enough, but > reinventing the wheel > is never a great idea. > > Thank you in advance, > > -- > ---------------------------------------------- > / __ + / Sarah Thompson **** / > / (_ _ _ _ |_ / * / > / __)(_|| (_|| ) / sarah(a)telergy.com * / > / + / http://findatlantis.com/ / > ---------------------------------------------- > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Mailing Lists - Fax Directory - Company Databases
by Peter Cororan 06 Jul '03

06 Jul '03

We can supply you with UK mailing lists, Fax Directories and Company Databases, in any format that you specify. If you would like FREE sample data, please go to our web site www.ukdata.ndirect.co.uk Thank you Peter Cororan cororan(a)ndirect.co.uk

1 0

ucuz arama
by NETTEALO 06 Jul '03

06 Jul '03

1 0

Worldwide Partners program
by The TechNews 05 Jul '03

05 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

FFI Ptr question
by paul＠theV.net 03 Jul '03

03 Jul '03

If a C function returns a (void*), let's say: data MyObj = MyObj foreign import ccall "static myobj_ffi.h new_obj" newMyObject :: IO (Ptr MyObj) ptr <- newMyObject should I free the ptr afterwards or not? If I have another imported C function: foreign import ccall "static myobj_ffi.h print_obj" printMyObject :: Ptr MyObj -> IO () Can I safely assume the C function print_obj(void *) always get the same pointer even if I call (printMyObject ptr) multiple times? Any hints is greatly appreciated! Regards, .paul.

4 7