- Haskell-Cafe - Haskell.org

RE: Ground Up
by Simon Peyton-Jones 04 Mar '02

04 Mar '02

| 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. It's true that GHC and Hugs and nhc don't accept exactly the same language but a) Haskell 98 is a very stable language that all three accept, and are committed to continuing to do so. b) If you stick to one compiler of the three, you can be pretty sure that programs that used to work will continue to work. (GHC, for example, always has a "stable branch", currently 5.02.2, that we maintain in parallel with introducing new features and bugs into the head. Bleeding-edge folk can and do compile the head from source, but you don't have to do that!) It's true that we occasionally make incompatible changes, but not often. | Maybe you will find that it's better to use Ocaml or | Scheme. Thay have own neats, and seem to be more stable. c) I have a very high opinion of Caml and Scheme, and their impls, but I think you are being a bit unfair on Haskell here. Caml has only one impl, and Scheme has many incompatible variants (eg PLT Scheme), so in practice you have to stick to one impl unless you use a the R3RS subset. I don't think any of them are more stable than any particular one of the Haskell impls. Simon

3 2

Ground Up
by Jerry, JiJie 01 Mar '02

01 Mar '02

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

4 3

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

01 Mar '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I finally got a clue. I got the Haskell program working. Now to build upon it. Jay's comment really made the IO monad concept sink in for me. Also reading through Manuael M T Chakravarty's Boolean editor was mind expanding as well. My biggest question is how to simplify, make more efficient, make more lazy what I have here. There's so much more to do now..... - -- State model of a light bulb with IO import Monad import IO main :: IO () main = do -- Turn off buffering so response is immediate hSetBuffering stdin NoBuffering hSetBuffering stdout NoBuffering -- Process from the intialState process initialState return () - -- A generic state-machine processor process :: State -> IO () process st = do -- retrieve current stimulus s <- getStimulus putChar '\n' -- compute new state and response (r, st') <- do { return (s st) } -- do the specified response r -- if the state is lambda then exit if( st' /= Lambda) then process st' else return () - -- Now define state for our humble lightbulb - -- State definition data State = Dark | Light | Lambda deriving (Show, Eq, Enum) - -- The inital state initialState :: State initialState = Dark - -- Response definitions type Response = IO () activate :: Response activate = putStr "Haskell said, let there be light.\n" deactivate :: Response deactivate = putStr "And darkness was upon the void.\n" - -- Here is the state transforms (i.e. stimuli) type Stimulus = State -> (Response, State) on :: Stimulus on Dark = (activate, Light) on Light = (return (), Light) off :: Stimulus off Dark = (return (), Dark) off Light = (deactivate, Dark) exit :: Stimulus exit x = (return (), Lambda) - -- Create a stimulus source from stdin charToStimulus :: Char -> Stimulus charToStimulus '1' = on charToStimulus '0' = off charToStimulus c = exit getStimulus :: IO Stimulus getStimulus = liftM charToStimulus getChar Shawn - -- 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 iD8DBQE8f8hxDtpPjAQxZ6ARAtWFAJ9fQ7rURyKebnSlBvrEklBSqnnb1QCdHHtM I4nSaTg0Sl2vIz+Yx1Z7ab8= =FKTr -----END PGP SIGNATURE-----

1 0

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

RE: higher-kind deriving ... or not
by Simon Peyton-Jones 27 Feb '02

27 Feb '02

| > data Wonky f | > = Wonky | > | Manky (f (Wonky f)) | > deriving Show | | The trouble is that when I ask either hugs -98 or ghci | -fglasgow-exts to | | show (Wonky :: Wonky Copy) | | the poor compiler's brain explodes. I fixed this a few weeks ago. GHC (5.03) now says: Foo.hs:3: No instance for `Show (f (Wonky f))' When deriving the `Show' instance for type `Wonky' | I tried to guess the type of the show instance derived for | Wonky. Being a naive sort of chap, I thought it might be | | show :: (forall a. Show a => Show (f a)) => Wonky f -> String Not naive. That's exactly the right type. See Section 7 of "Derivable type classes". http://research.microsoft.com/~simonpj/Papers/derive.htm Havn't implemented this, yet, alas. | It's clear that with typing problems, inference becomes | unsustainable pretty soon after you leave the safe harbours | of the Hindley-Milner system. However, lots of lovely | programs have more interesting types: it would be very | frustrating if Haskell forbade these programs just because | their types were not inferrable---not least since, for these | jobs, we usually do think of the type first and the code | afterwards. Sensibly, Haskell allows us to write these types | down, so the machine's task is merely checking. This hybrid | approach preserves type inference for `old' code, whilst | promoting more adventurous programming by allowing us to say | what we mean when the machine is too dim to guess. I agree wholeheartedly with this; it's exactly the approach I'm trying to take with GHC. One obvious extension is to let the user specify the context for a derived instance decl, but still let the compiler generate the code. Havn't done this either! Simon

1 0

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

27 Feb '02

Hi I'm rather fond of fixpoint constructions like this one: > newtype Copy a = Copy a deriving Show > data Wonky f > = Wonky > | Manky (f (Wonky f)) > deriving Show (Clearly this is an ill-motivated example, but the real example which caused this problem is available on request...) The trouble is that when I ask either hugs -98 or ghci -fglasgow-exts to show (Wonky :: Wonky Copy) the poor compiler's brain explodes. I take it this is a known problem with instance inference, deriving, etc. Of course, it's easy to write my own show for Wonky Copy, but that's a tad annoying. I tried to guess the type of the show instance derived for Wonky. Being a naive sort of chap, I thought it might be show :: (forall a. Show a => Show (f a)) => Wonky f -> String but that's a syntax error. A little more tinkering, and it looks like it might be show :: Show (f (Wonky f)) => Wonky f -> String Is this really the type of show? If so, no wonder there's a problem. I don't want to start an argument about how to solve this problem. I do want to suggest that, for the time being, it would be better to reject `deriving Show' for type constructors like Wonky (ie those with higher-kind parameters) than to generate instances which break the compiler. Or am I just being a spoilsport? Conor

3 4

java program
by Stewart Litt 27 Feb '02

27 Feb '02

dear sir/madam iam contacting you regarding a java problem which i have come across. My teacher at manchester met has set a problem for us to solve but thinking his teaching is excellent and everyone understands him wen no one does I would appreciate you helping me in this problem as it would save us from embarrassment. THE PROBLEM: Consider a simplified plan of the liverpool bus system. The system consists of a network of bus stops(at most 20) and bus lines (at most 5). Each bus stop has a unique name and each busline has a unique number. Each bus stop is connected to other bus stops by at most 3 different bus lines. Each of these bus lines connects a bus stop to exactly one other bus stop and for each bus stop and each connecting bus line it is known how many minutes the bus needs to get to the next bus stop. The objectives are to design and implement in java: 1. A representation of the bus system using suitable data structures. 2. A mechanism to go from one bus stop to a conected bus stop via a particular bus line. 3. A mechanism for searching for a connection between two given bus stops. A command line text based interface should be provided that will allow the user to issue a series of the following five commands: start: Allows to enter the current bus stop by name and resets the total journey time to zero. list: The system will show the total journey time so far, and all information on the current bus stop, that is, its name and the numbers of all outgoing bus lines. go: The system asks for the number of a busline. If the number is that of an outgoing busline, then the system finds out the busstop connected to the current bus stop and makes it the new current bus stop. If the number is not that of an outgoing bus line, then the system will indicate this by a message , but make no other changes. search: The system asks for the name of a bus stop. The system will then indicate whether there is a way to get to this bus stop from the current bus stop, but makes no other changes. exit: Stops and exits the system. Description of the liverpool bus stop below. THE LIVERPOOL BUS SYSTEM Bus Stop Outgoing bus line Connected bus stop Time in mins Bootle strand 22 South road 11 Pier head 10 Shiel road 14 22 Bootle strand 7 79 Edge hill 11 Edge hill 79 Picton clock 10 Green lane 10 Page moss 13 22 Bootle strand 18 Page moss 10 Prescot 8 Picton clock 79 Netherly 21 Shiel road 10 Green lane 5 South road 22 Green lane 9 _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

1 0

a more practical version of getLine???
by Rich 26 Feb '02

26 Feb '02

Hi, I'm writing a program for my final project at uni and I've come across the following annoying bug in my program. Basically, I have an interactive text prompt and I wish to be able to write commands into the prompt. I am currently using the function 'getLine', which as it's name suggests reads a line of text from the prompt. Unfortunately, when the delete key is used while writing to the prompt, the output differs (so typing "loaf" then 'delete' and then "d" does not seem to produce the same output as typing "load"). Also, the left and right arrow keys don't work, as they do in any normal text prompt. Any suggestins as to an alternative method to read the input??? (I'm by no means a Haskell expert btw, so I may have to be spoon fed!) thanks for your help, Rich.

3 2

Help
by Juan M. Duran 25 Feb '02

25 Feb '02

Hi, I need to parse a string to a list of integer, like this: "12 32\n15...." to [12,32,15...] f :: String -> [Int] What I´ve found is the function "words" which does words :: String -> [String] it is in the Prelude.hs then if I have something like "12 32\n15..." with words I get ["12","32","15"...] which is cool but not exactly what I need. Would you help me? Thanks J. ------------------------------------ Porque la única lucha que se pierde, es la que se abandona, ¡Ni un paso atrás!

2 2

RE: Monadic Call/CC?
by Simon Marlow 25 Feb '02

25 Feb '02

> At 2002-02-23 07:55, Marcin 'Qrczak' Kowalczyk wrote: > > >It's in GHC in module MonadCont, together with a monad transformer > >providing continuations and some instances. > > Could this sort of thing _please_ be added to > <http://www.haskell.org/ghc/docs/latest/set/book-hslibs.html> > or somewhere? Is this documented somewhere? My apologies for the lack of documentation for some of these libraries, and the generally poor state of the doumentation for hslibs. Some of the libraries come from external sources, and in some cases the authors didn't provide documentation, or provided it in a form that we couldn't use directly. For the next release of GHC, I'm hoping we can do a much better job, though not just by writing more documentation but by generating more of it automatically from the source code. That's the plan; we don't have anything concrete yet. Cheers, Simon

1 0

Re: Graphs
by David Feuer 25 Feb '02

25 Feb '02

I seem to remember an article about functional graph algorithms using extra-lazy arrays. Anyone know if these arrays have appeared in any mainstream implementation? David Feuer

2 1

RE: Survival of generic-classes in ghc
by Simon Peyton-Jones 25 Feb '02

25 Feb '02

| > Another possiblity would be to make the ConCls class look like this | > class ConCls c where | > name :: String | > arity :: Int | > ...etc... | > | > Now we'd have to give an explicit type argument at the call site: | > | > show {| Constr c t |} (Con x) = (name {| c |}) ++ show x | > | > I quite like the thought of being able to supply explicit type | > arguments.... but I don't konw how to speak about the order of type | > parameters. What order does map takes its two type parameters in? | | Sorry, this seems like a non-sequitur to me? | | 'map' has type '(a->b) -> [a] -> [b]'; supplying explicit | type parameters would mean giving values to 'a' and 'b'. If | I wanted to propose notation for this, I would suggest, e.g., | (map :: (String -> Int) -> [String] -> [Int]) length | ["Hello", "World"] | | 'name' (above) has type 'String'; the '{| c |}' is not | providing a type parameter in the same sense. Yes it is. 'name' would have type forall c. ConCls c => String It requires a type argument, just like map. Simon

1 0

RE: Survival of generic-classes in ghc
by Simon Peyton-Jones 25 Feb '02

25 Feb '02

| I'm disturbed by the idea of adding explicit type application | and the like to Haskell. Haskell language extensions are | rapidly becoming a riotous array of confusing syntax and | twisty semantic corners. From an experimenter's standpoint, | this isn't so bad. However, many of these extensions are | incredibly useful, and there's a lot of code relying upon | them. This creates pressure (from both users and | implementors) to immortalize the existing, grubby | implementations. The result? An incomprehensible, byzantine language. Yes, that's a danger. My own hope is that the practial experience of using and programming with these various features will lead us slowly to a realisation of some underlying unifying approaches or principles. That is what the rest of you message is reaching for -- which is great. But it easier to identify the problem than to come up with a satisfactory solution, and I for one do not have one. But I think it would be great to find one. Simon

1 0

RE: Survival of generic-classes in ghc
by Simon Peyton-Jones 25 Feb '02

25 Feb '02

| As long as we're reifying everything in sight, why not | simplify the design problem and reify the constructor dictionaries? Because the generic function may be building the contructor not taking it apart. (Think of a generic read function). So there is no reified constructor to deconstruct. This is discussed in the generic classes paper. It has to be done by recursion over the type. It's emphatically not just an efficiency issue. Simon

1 0

(no subject)
by Tom Bevan 25 Feb '02

25 Feb '02

Hi, I've come across this sort of data constructor below many times but I'm not really sure how to use it. Can someone please point me to the right section in the documentation? In particular, I want to know how to create a calendar time and how to access the fields . Tom data CalendarTime = CalendarTime { ctYear :: Int, ctMonth :: Month, ctDay, ctHour, ctMin, ctSec :: Int, ctPicosec :: Integer, ctWDay :: Day, ctYDay :: Int, ctTZName :: String, ctTZ :: Int, ctIsDST :: Bool } deriving (Eq, Ord, Read, Show)

2 1

Re: (no subject)
by Ashley Yakeley 25 Feb '02

25 Feb '02

At 2002-02-24 22:46, Tom Bevan wrote: >I've come across this sort of data constructor below many times but I'm >not really sure how to use it. Can someone please point me to the right >section in the documentation? http://haskell.org/onlinereport/decls.html#sect4.2.1 "Labelled Fields" >In particular, I want to know how to create a calendar time and how to >access the fields . > >Tom > >data CalendarTime = CalendarTime { > ctYear :: Int, > ctMonth :: Month, > ctDay, ctHour, ctMin, ctSec :: Int, > ctPicosec :: Integer, > ctWDay :: Day, > ctYDay :: Int, > ctTZName :: String, > ctTZ :: Int, > ctIsDST :: Bool > } deriving (Eq, Ord, Read, Show) Basically it's equivalent to this: data CalendarTime = CalendarTime Int Month Int Int Int Int Integer Day Int String Int Bool deriving (Eq, Ord, Read, Show); ctYear (CalendarTime x _ _ _ _ _ _ _ _ _ _ _) = x; ctMonth (CalendarTime _ x _ _ _ _ _ _ _ _ _ _) = x; ctDay (CalendarTime _ _ x _ _ _ _ _ _ _ _ _) = x; etc. ...but you can also use the labelled fields to construct: CalendarTime { ctYear = 2002, ctMonth = 2, ... } -- Ashley Yakeley, Seattle WA

1 0

Magnets supplier located.
by LEWIS＠haskell.org 25 Feb '02

25 Feb '02

1 0

if -> is a type constructor
by Cagdas Ozgenc 24 Feb '02

24 Feb '02

Greetings folks. If (->) is a type constructor, what does its definition look like, what data constructors does it have? How does it differ from other type constructors, or maybe it doesn't? Could someone give an explanation... Thanks for taking time.

2 1

Re: Graphs
by Jan-Willem Maessen 23 Feb '02

23 Feb '02

David Feuer <dfeuer(a)cs.brown.edu> writes: > I seem to remember an article about functional graph algorithms using > extra-lazy arrays. Anyone know if these arrays have appeared in any > mainstream implementation? I assume you're referring to this paper by Thomas Johnsson: @Article{lazyArray, author = {Johnsson, Thomas}, title = {Efficient Graph Algorithms Using Lazy Monolithic Arrays}, journal = JFP, year = 1998, volume = 8, number = 4, pages = {323--333}, month = {July} } He uses similar techniques to do whole-program flow analysis of Haskell programs, a clever bit of coding described in the following paper: @inproceedings{grinHeap, AUTHOR = "Johnsson, Thomas", TITLE = "Analysing Heap Contents in a Graph Reduction Intermediate Language.", booktitle = Proc # "Glasgow Functional Programming Workshop", address = "Ullapool 1990", MONTH = "August", YEAR = 1991 } The LazyArray library is part of the standard hbc distribution. The Eager Haskell compiler depends on it (you can get very nice static hash tables this way, among other things). As a result, I've done a port of the library to GHC (and, I think, hugs). I should note that most of the hints required to pull off the implementation were found in the "State in Haskell" paper by Simon PJ and John Launchbury. The library is available (along with a few other useful snippets, like universal splittable supplies) here: http://www.csg.lcs.mit.edu/~earwig/haskell-lib/ -Jan-Willem Maessen

2 1

Re: Monadic Call/CC?
by Ashley Yakeley 23 Feb '02

23 Feb '02

At 2002-02-23 07:55, Marcin 'Qrczak' Kowalczyk wrote: >It's in GHC in module MonadCont, together with a monad transformer >providing continuations and some instances. Could this sort of thing _please_ be added to <http://www.haskell.org/ghc/docs/latest/set/book-hslibs.html> or somewhere? Is this documented somewhere? -- Ashley Yakeley, Seattle WA

1 0

Re: Monadic Call/CC?
by Marcin 'Qrczak' Kowalczyk 23 Feb '02

23 Feb '02

Thu, 21 Feb 2002 19:36:13 -0800, Ashley Yakeley <ashley(a)semantic.org> pisze: > data ContMonad p a = MkContMonad ((a -> p) -> p); [...] It's in GHC in module MonadCont, together with a monad transformer providing continuations and some instances. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK

1 0

Re: Monadic Call/CC?
by Ashley Yakeley 23 Feb '02

23 Feb '02

At 2002-02-22 01:36, Richard Uhtenwoldt wrote: >So, congratulations, you've written call/cc in Haskell. I think. Yes. test2 :: CPS (IO ()) (); test2 = do { liftM (putStr "aa\n"); ref <- liftM (newIORef Nothing); liftM (putStr "bb\n"); flag <- peirceM (\c -> do { liftM (putStr "cc\n"); liftM (writeIORef ref (Just c)); liftM (putStr "dd\n"); c True; liftM (putStr "ee\n"); return False; }); liftM (putStr "ff\n"); if (flag) then do { liftM (putStr "gg\n"); Just c' <- liftM (readIORef ref); liftM (putStr "hh\n"); c' False; liftM (putStr "ii\n"); } else do { liftM (putStr "jj\n"); } }; ContMonad> doMonadCPS test2 aa bb cc dd ff gg hh ff jj ...which shows that the continuation passed in by peirceM works both inside and outside the call. Changing "c' False" to "c' True" gave this endless iteration: ContMonad> doMonadCPS test2 aa bb cc dd ff gg hh ff gg hh ff gg hh ... I assume by the magic of Haskell's tail recursion, this won't eat up space. -- Ashley Yakeley, Seattle WA

1 0

Haskell problem
by Mark Wotton 22 Feb '02

22 Feb '02

Hi, I'm trying out some combinatorial parsers, and I ran into a slightly inelegant construction. To parse a sequence of things, we have a function like pThen3 :: (a->b->c->d) -> Parser a -> Parser b -> Parser c -> Parser d pThen3 combine p1 p2 p3 toks = [(combine v1 v2 v3, toks3) | (v1, toks1) <- p1 toks, (v2, toks2) <- p2 toks1, (v3, toks3) <- p3 toks2] The problem with this is that this structure has to be duplicated for pThen2, pThen4, and so on. These other forms are very similar to pThen3, but there seems to be no way to capture this in Haskell's type system, as the combine function has a different signature for each pThenX. (This is actually the first time the Haskell type system has got in my way rather than helping.) Is there a way around this problem? mrak

5 5

Graphs
by Wojciech Fraczak 22 Feb '02

22 Feb '02

Hi everybody, I would like to ask you, if you do not know any graph library for haskell. I would like to use haskell for prototyping some of algorithms on graphs and finite state automata/transducers. In fact what I'm looking for is a good (efficient and easy readable) data type definition for labeled graphs. Thanks, Wojtek

3 2

Re: Monadic Call/CC?
by Ashley Yakeley 22 Feb '02

22 Feb '02

At 2002-02-22 01:36, Richard Uhtenwoldt wrote: >Yeah, it's called continuation-passing style (CPS). Good. I have a small collection of wheels I've reinvented in my ignorance. >So, congratulations, you've written call/cc in Haskell. I think. >So, what I said this afternoon, namely, that call/cc is >"not something an implementation is likely >to be able to support unintentionally", I now have to retract. >I think. Well, I have to create my own monad and do call/cc in that. Doing call/cc in IO is another matter entirely. >I guess the call/cc you wrote last night in terms of catch and a ref >didn't work too well; huh? I havent't tested it. But I agree that it certainly won't allow continuations to survive after peirceM has returned, so can't be considered proper call/cc. -- Ashley Yakeley, Seattle WA

1 0

Re: Monadic Call/CC?
by Ashley Yakeley 22 Feb '02

22 Feb '02

>Given this: > > class (Monad m) => PeirceMonad m where > { > peirceM :: ((a -> m b) -> m a) -> m a; > }; > >...which Monads can be made PeirceMonads? Here's one: data ContMonad p a = MkContMonad ((a -> p) -> p); unContMonad (MkContMonad app) = app; instance Monad (ContMonad p) where { return a = MkContMonad (\cont -> cont a); (MkContMonad ma) >>= bf = MkContMonad (\cont -> ma (\a -> unContMonad (bf a) cont)); }; instance PeirceMonad m where { peirceM foo = MkContMonad (\cont -> unContMonad (foo (\a -> MkContMonad (\_ -> (cont a)))) cont); }; doContMonad :: ContMonad p p -> p; doContMonad cm = unContMonad cm id; test1 = doContMonad (peirceM (\continuation -> do { continuation 1; continuation 2; continuation 3; })); -- returns 1 Now here's the interesting thing. The usual way to represent "real-world" functions (i.e. with side-effects, or changing the world) from a to b is to define a special _type constructor_, 'IO', and define the function as 'a -> IO b'. But an alternative, would have been to define a special _type_, Action, and define the function as 'a -> (b -> Action) -> Action'. And then your 'main' function has type 'Action'. Nor do we have to declare special >>= and return functions as we do for IO. Here's how it's equivalent: type Action = IO (); type ActionMonad = ContMonad Action; doActionMonad :: ActionMonad () -> Action; doActionMonad cm = unContMonad cm return; liftIO :: IO a -> ActionMonad a; liftIO ioa = MkContMonad (\cont -> ioa >>= cont); ...and note that we get Peirce continuations for free: peirce foo cont = foo (\a _ -> (cont a)) cont; -- constructors removed -- Ashley Yakeley, Seattle WA

2 1

Re: Monadic Call/CC?
by Ashley Yakeley 22 Feb '02

22 Feb '02

At 2002-02-21 19:36, I wrote: > And then your 'main' function has type 'Action'. Sorry, And then your 'main' function has type 'Action -> Action'. -- Ashley Yakeley, Seattle WA

1 0

Re: Monadic Call/CC?
by Ashley Yakeley 21 Feb '02

21 Feb '02

At 2002-02-20 22:15, I wrote (on the Haskell list): >Haskell? Given this: > > class (Monad m) => PeirceMonad m where > { > peirceM :: ((a -> m b) -> m a) -> m a; > }; > >...which Monads can be made PeirceMonads? This is untested, but... instance PeirceMonad IO where { peirceM foo = do { ref <- newIORef Nothing; catch (foo (\a -> do { writeIORef ref (Just a); ioError (userError "break"); })) (\ex -> do { ma <- readIORef ref; case ma of { Just a -> return a; _ -> ioError ex; }; }) } }; So you can do it if you have refs and throw/catch for your monad. I think. -- Ashley Yakeley, Seattle WA

2 1

RE: Survival of generic-classes in ghc
by Jan-Willem Maessen 21 Feb '02

21 Feb '02

* Language philosophers who are skimming this discussion will want to take a look at #### below. Simon PJ writes: > One thing that is slowing me down is a design uncertainty: how to > deal cleanly with constructors. To write read, show, etc, one needs > access to the constructor name, fixity etc. We dance around that a > little in the paper. I'm thinking of this design: ... > -- Con is part of the Generics library, like 1, :*:, :+: > newtype Con c a = Con a > > class ConCls c where > name :: c -> String > arity :: c -> Arity > ..etc.. > > data NilT -- Phantom types > data ConsT -- one per constructor > > instance ConCls NilT where > name _ = "Nil" > ...etc... > > instance ConCls ConsT wher > name _ = "Cons" > ...etc... But you're going to have to keep those ConCls dictionaries somewhere, which means either: 1) The type Con should existentially quantify over c: < data Con a = forall c. (ConCls c) => Con a [I haven't checked that this is even legal anywhere, but you get the idea] 2) Any function which needs the type "c" must carry around a dictionary for *each* constructor in the type. I'm not quite sure how to work the typing of the code generic functions in this regime, though I'm sure it could somehow be managed. As long as we're reifying everything in sight, why not simplify the design problem and reify the constructor dictionaries? >From my own strawman experiments (this is old code): > data Constructor t = Constructor CI !t > > data CI = CI Bool String Int [String] [Bool] deriving (Eq) > -- Op-ness, constructor, fixity, field names, strictnesses of fields We could do something similar for fields, of course. There need only be one copy of this info for each data constructor (and field); it's easy for the compiler to share these. The type CI is effectively a representation of the dictionary for ConCls. The "Constructor" type the works just like the existentially quantified example (1). The drawback? We need to store the constructor info CI in every reified constructor. My suspicion is this will not matter much in practice. Compiling generics should be done with one of two sets of assumptions: * Generics are a mechanism of convenience. If you want your code to go fast, you should write the code longhand (possibly using an overlapping instance for an otherwise generic function/class). In this case, the extra overhead of the constructor info is likely to be a drop in the bucket. * Generics should be specialized at the types at which they are used. This might be accomplished by careful inlining of reification functions into the bodies of generic methods (or vice versa). In this case "Constructor" should vanish. ####################### On a broader philosophical note: I'm disturbed by the idea of adding explicit type application and the like to Haskell. Haskell language extensions are rapidly becoming a riotous array of confusing syntax and twisty semantic corners. From an experimenter's standpoint, this isn't so bad. However, many of these extensions are incredibly useful, and there's a lot of code relying upon them. This creates pressure (from both users and implementors) to immortalize the existing, grubby implementations. The result? An incomprehensible, byzantine language. For example, we now have multiparameter type classes (useful) with functional dependencies (addressing a vital problem with multiparameter constraint solving). Now Simon is wants explicit type application, kind annotations, and the like. There are some things Haskell does very well---algebraic types and pattern matching are cleaner and more pleasant to use then in ML, and the class system has proven to be Haskell's most brilliant distinguishing feature. I'd like to see solutions to some of the current problems that build on these strengths. I'm not sure if it's possible to get a type language based on functions and pattern matching in the face of type inference. Cayenne makes it clear that one can write type-level code very naturally when the type language and the value language work the same way. Similarly, I observe that: * Views = coercion methods + implicitly-inserted coercions + deforestation * Generics = reification methods + functions become methods + implicitly-inserted reification + deforestation The two lists are pretty similar, and it might be worth trying to unify the efforts in some fashion---possibly by breaking down the functionality into simple pieces. Here are some possibilities: * Come up with a coherent story on implicitly-inserted coercions. Ideally fromInteger and fromRational would just be specific cases of this coherent story. (The current story is nice and coherent: if it's a numeric constant, there's a coercion, otherwise there isn't.) * Allow patterns to match at multiple types, if those types match particular constraints (such as coercability). These two together might well be enough to give you views. * Give the deriving mechanism a language-level reading. Allow "deriving"-like clauses outside the context of type declarations. * Give some way to declare "closure" of a class. This should be done with an eye on abstraction barriers. Perhaps "closed" classes may still be derived (by newtypes, or using the mechanism for generics). * Make generic functions look like closed classes; possibly this means allowing the programmer to write instances as part of the class declaration. * Perhaps Haskell needs a universal class. This class would provide the reification methods for all [boxed?] data types, and might be a place for the implementation to hide (e.g.) type-based GC methods or specialized versions of seq. I'm hoping something along these lines is enough for single-parameter generics at least. Much of this work already exists in fragmentary form. However, in many cases it's part of attempts at larger mechanisms. For example, "views" proposals have suggested using distinguished "view types", and adding coercions when patterns mention the constructor of a view type. "Closed" classes were mentioned in the paper on instance resolution at PoPL last month. And of course there's lots of good work on generics, the big problem being that the efforts have become scattershot and still doesn't seem to fit the rest of the language nicely. It's time to reduce the useful mechanisms to their essentials. -Jan-Willem Maessen Eager Haskell project

1 0

RE: Survival of generic-classes in ghc
by Simon Peyton-Jones 21 Feb '02

21 Feb '02

| and I know from testing earlier versions that the | generic-classes support was pretty buggy. Is there any hope | of a revival? Does it already work in CVS? I suspect it will | rot away if nobody works on it. | | Any comments from the implementors - does the idea "fit well" | with ghc? Is it a lot of work to make it more stable? No, it should not be a lot of work to revive, and I will do it. Keep bugging me until I do. One thing that is slowing me down is a design uncertainty: how to deal cleanly with constructors. To write read, show, etc, one needs access to the constructor name, fixity etc. We dance around that a little in the paper. I'm thinking of this design: -- An example data type data List a = Nil | Cons a (List a) -- The "ring" type derived from it -- Note the Con wrapped around the constructors data ListO a = Con NilT 1 :+: Con ConsT (a :*: List a) -- Con is part of the Generics library, like 1, :*:, :+: newtype Con c a = Con a class ConCls c where name :: c -> String arity :: c -> Arity ..etc.. data NilT -- Phantom types data ConsT -- one per constructor instance ConCls NilT where name _ = "Nil" ...etc... instance ConCls ConsT wher name _ = "Cons" ...etc... Now you can write class Show a where show :: a -> String show {| Con c t |} (Con x) = (name (undefined::c)) ++ show x ...etc.. Note the "undefined::c"; it is really just a type argument to "name", so that we get the string for the right constructor. It's a bit clunky, though. Another possiblity would be to make the ConCls class look like this class ConCls c where name :: String arity :: Int ...etc... Now we'd have to give an explicit type argument at the call site: show {| Constr c t |} (Con x) = (name {| c |}) ++ show x I quite like the thought of being able to supply explicit type arguments.... but I don't konw how to speak about the order of type parameters. What order does map takes its two type parameters in? Another question is whether we need an indication that we have reached a field of the constructor. Should we have: data ListO a = Con NilT (Field 1) :+: Con ConsT (Field a :*: (Field List a)) newtype Field a = Field a Without this, it's hard to write a generic function to count the number of fields of the data type. But in general, one might want to know when making the transition from "this" type to the argument types of the constructors. I think that the main reason I'm not making much progress is that I don't know what design choices to make. I'd be glad to discuss it with interested parties. Simon

2 1

Re: a universal printer for Haskell?
by Bernard James POPE 20 Feb '02

20 Feb '02

Hi all, This thread started with the consideration of a means (hack?) to implement a generic printer in Haskell. It has moved to the bigger issue of Meta programming, in particular reflection. I think this is a topic worthy of consideration, and something we don't seem to talk much about in these groups. > Ashley Yakeley writes: > What I would hate to see is widespread use of reflection in general > programs. It rather seems to miss the point of Haskell's type system. I think the point of Haskell's type system varies depending on who you ask. The rules may be fixed to a certain degree in Haskell 98, but future versions of the language are free to change them. Meta programming is made more difficult when you have a strong static type system, no doubt. But is that a problem of meta programming or of the type system? This is a matter of opinion. Systems such as Meta ML [1], show that the two can be made compatible. I must admit that I haven't used Meta ML, so I'm not in a position to evaluate it, although it does make for some interesting research. My point is that there are some things that can't easily be expressed in current Haskell (like generic printing) that are useful and might be aided by meta-programming technology. The interesting question is can it be done in a way that preserves whatever we want from the type system: safety, security, efficiency, error detection ... > And I don't want other people peeking inside my types at run-time. There are numerous ways to provide security for your data types. You can specifically request that they not be made visible to the meta facility, or you can use a module system to grant access to the implementation of data only in certain modules. It does not have to be program wide. The scheme I suggested for generic printing was not as safe as you might like, but it was intended to be simple and easy to implement, and there is some merit in that I think. Cheers, Bernie.

3 2

Re: a universal printer for Haskell?
by C.Reinke 20 Feb '02

20 Feb '02

> You don't need meta-programming technology (reflection) to do things like > generic prinitng. A generic programming extension of Haskell (like > Generic Haskell, or derivable classes) can do the job for you. Isn't generic programming usually based on a kind of compile-time reflection (if the argument is of this type, do this, else..)? And don't you write generic functions with the intention that the implementation will figure out the approriate type-specific variants, i.e., you write your code at a level of abstraction that is not easily reached with the standard language tools -- a meta level, where functions at different types are the first-class objects of discourse? I find it helpful to think of generic programming support as one way of integrating well-behaved subsets of reflection and other meta-programming techniques into Haskell. It is partly a trade-off: you get some of the features and avoid some of the problems of a fully reflective architecture. It is also a specialisation: by avoiding the full generality, the specific subset of features can be designed in a structured fashion, with the application domain in mind, making them easier to use for that domain. Claus (another fan of reflection and meta-programming, who would like to get their advantages without their disadvantages -- the latter are more clearly visible in a pure functional language than in Lisp)

2 1

Re: a universal printer for Haskell?
by Ashley Yakeley 20 Feb '02

20 Feb '02

At 2002-02-19 22:46, Bernard James POPE wrote: >The scheme I suggested for generic printing >was not as safe as you might like, but it was intended to be simple >and easy to implement, and there is some merit in that I think. I strongly recommend you check out generic classes: <http://www.haskell.org/ghc/docs/latest/set/generic-classes.html> I suspect you can use them to do what you want... -- Ashley Yakeley, Seattle WA

2 1

Re: syntax...(strings/interpolation/here docs)
by C.Reinke 20 Feb '02

20 Feb '02

{- > Unlike my rough proposal, one should aim for a combination of > (mostly) in-Haskell implementation and (some) pre-processing. As > Thomas Nordin has pointed out to me in private email, Hugs (Dec > 2001) already supports this (module lib/hugs/Quote.hs and flag +H). > > The real trick is to have the same support in all implementations.. -} module HereDocuments where {- :set +H -} import Quote text = `` When I mentioned pre-processing, I didn't mean doing something to generate a Haskell program, I meant simple language extension (as in: syntactic sugar). It is nice that the Hugs variant of here documents is easily implemented with pre-processing, but that should be done behind the scenes. Usually, I wouldn't make such a fuss, but here documents are really not some new and experimental feature. They're an old hat, and a very useful hat. The only question is how to integrate them into the rest of Haskell. The Lewis/Nordin suggestion implemented in Hugs looks like a good compromise, but it won't do harm to bind the sugar to an option/flag for a test period. In the end, a stable form of here documents should be part of the language (not part of what you can do to it with whatever tools in whatever contexts), directly supported by all implementations. '' main = putStrLn $ trim text -- Claus

5 4

Re: a universal printer for Haskell?
by Ashley Yakeley 20 Feb '02

20 Feb '02

At 2002-02-19 20:50, Eray Ozkural wrote: >> It's ugly, and isn't part of the spirit of the language. > >The above statement cannot be a basis for any argument against Bernard's >proposal. It's an aesthetic argument that hopes for an aesthetic consensus among Haskell users (which may or may not exist). ... >Since you are defining the spirit of the language, Oh no, spirit cannot be defined, only suggested. ... >A general concept such as reflection cannot be deemed as worthless in >itself. It might reasonably be considered inappropriate to Haskell. Reflection may be useful for debugging, so I would not call it worthless. I consider reflection such as Generics to be in more or less the same aesthetic category as unsafe IO functions -- something to be generally avoided but perhaps useful in certain limited contexts such as debugging. I don't use Generics or unsafe-anything in my Haskell software. I _do_ occasionally use the 'deriving' construct, which is strictly speaking reflection though I think a relatively harmless form. What I would hate to see is widespread use of reflection in general programs. It rather seems to miss the point of Haskell's type system. >Any system that has a tiny bit of introspective powers can be said to be >reflective to some extent, for instance a Haskell interpreter. That's fine, but I don't include a Haskell interpreter in my compiled Haskell programs. And I don't want other people peeking inside my types at run-time. -- Ashley Yakeley, Seattle WA

1 0

Re: a universal printer for Haskell?
by Ashley Yakeley 20 Feb '02

20 Feb '02

At 2002-02-19 09:56, Richard Uhtenwoldt wrote: >>This is reflection! I'd rather not have Haskell contaminated with such >>things; > >Can you say a little more about why you think reflection is bad? >Does it make the language implementation run slower? It's ugly, and isn't part of the spirit of the language. You shouldn't be able to peer into types that way. If you decide to change the private structure of your types, you shouldn't have to worry about what effects it will have on the rest of the program. Consider: module A (Thing()) where { data Thing = MkThing Char; } module B where { import A; peek :: Thing -> Char; peek thing = (\(MApp _ (MChar c)) -> c) (reify thing); } B can look inside a private structure of A. The problem is not the Reify class, but the compiler's autogeneration of instances. >(I'd ask via private email, but when I emailed you in the past >I didn't get a reply.) That sounds like me... -- Ashley Yakeley, Seattle WA

2 1

Re: a universal printer for Haskell?
by Richard Uhtenwoldt 19 Feb '02

19 Feb '02

Ashley Yakeley writes: >This is reflection! I'd rather not have Haskell contaminated with such >things; Can you say a little more about why you think reflection is bad? Does it make the language implementation run slower? (I'd ask via private email, but when I emailed you in the past I didn't get a reply.)

1 0

performance of monads
by Eric Allen Wohlstadter 19 Feb '02

19 Feb '02

I see a lot of literature that says that monads "simulate" the effects of imperative programming concepts. It seems to me that the relative performance of monadic implementations must be equivalant to imperative ones to provide a strong case for functional programming. For example, in the Exception handling monad it seems that the "bind" function must be called continously to pass the Error value back to an error handling function. However, in imperative languages we can make an immediate non-local transfer of control. Similiar is the way State is handled. Do compilers for haskell do any sort of optimization on these monadic operations or is it all as ineffecient as it looks. Eric Wohlstadter UCDavis Software Tools Lab

12 11

Re: a universal printer for Haskell?
by Ch. A. Herrmann 19 Feb '02

19 Feb '02

Hi Haskellers, >>>>> "Bernard" == Bernard James POPE <bjpop(a)cs.mu.OZ.AU> writes: Bernard> Handling functions is always going to be hard. Actually, a Bernard> related issue in Haskell is what do you do with partially Bernard> evaluated structures? Certainly in some circumstances you Bernard> don't want to force the value just so that you can write it Bernard> out. sorry if I wasn't precise enough. I don't want to force ANY evaluation on the value to be marshalled; in some cases the computation may even not terminate! Instead, the string is an encoding of the smallest part of the heap that is necessary to restore the information. My aim is to save a state which contains unevaluated closures to disk and resume the computation at a later time or to send a state to a remote location. The nice property of a functional language, in contrast to imperative languages, is that you can make a snapshot of your computation without any support by the runtime environment if, of course, those (un)marshalling functions are available. Bernard> If you compiled to byte code, life would be a lot Bernard> easier, however everything will get a lot messier if you Bernard> want to mix machine code and byte code. urgh... The problem is to encode program functions, not just functions that arise during the computation. Compiling to byte code is a different issue. Bernard> It would be nice if you could write out some data to file from Bernard> GHC and then read it in using NHC :) That'll be very complicated and require a deep discussion about an interface language. Bernard> I think Clean has a prototype persistence mechanism, I saw Bernard> a short demo late last year. I'm not sure how they Bernard> represent functional values. I think you can only read the Bernard> data from within the same program that wrote the data. That would be OK for me. It would even be OK if it is the same binary, i.e., not to be used in heterogeneous networks. Anyway, I don't like to change my favourite programming language unless it's better than Haskell and that'll be very likely Haskell-II :-) Cheers -- Christoph

1 0

laziness again...
by ketil＠ii.uib.no 19 Feb '02

19 Feb '02

Hi, I'm a bit puzzled by this observatio that I made. I have a function that, pseudocoded, lookes somewhat like f i as bs cs = ins i (f (i+1) as) ++ ins i (f (i+1) bs) ++ ins i (f (i+1) cs) where ins i = manipulates the first element of the list Now, without the ins'es, the function appears to be lazy, i.e I can "take" a part of it without evalutating the rest. With the ins'es, the whole thing seems to be calculated as soon as I touch it. Is this obvious? Or is my observation wrong? -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 3

Trouble with DtdToHaskell
by Shawn P. Garbett 18 Feb '02

18 Feb '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've got a debian install (2.2.18kernel, 2.95.4 gnu c compiler) with ghc installed using hmake. I also found DtdToHaskell was installed on my computer. I run it on any Dtd and get the following: spg@Further:~/clean$ DtdToHaskell clean.dtd module DTD_clean where import Xml2Haskell {-Type decls-} {-Instance decls-} {-Done-} This also happens if I compile DtdToHaskell myself from the source. Any ideas what's misconfigured? - -- 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 iD8DBQE8cQ/ZDtpPjAQxZ6ARAopFAJ4pePWkXo3TCtadkBR67zHHWoGPRwCfT8qL 86iZ8hdUPZHhbSA3DUVhB84= =k7Ax -----END PGP SIGNATURE-----

1 0