- Haskell-Cafe - Haskell.org

RE: Just for your fun and horror
by Manuel M. T. Chakravarty 20 Feb '01

20 Feb '01

Jon Cast <jcast(a)ou.edu> wrote, > Manuel M. T. Chakravarty writes: > > So, I guess, I have to extend my example to > > > > bar x = x + 42 > > > > I don't know if this counts, but gcc allows: > > int bar(int x)__attribute__(const) > { > return(x + 42); > } > > which is the exact C analogue of the Haskell syntax. Sorry, but I would say that it doesn't count as it is a compiler specific extension :-) Nevertheless, a good point. > The majority of `C > functions', I believe, (and especially in well-written code) are intended to > be true functions, not IO monads. They modify the state for > efficiency/ignorance reasons, not because of a conscious decision. Yes and no. I agree that they are often intended to be true functions. However, it is not only efficiency and ignorance which forces side effects on the C programmer. Restrictions of the language like the lack of call-by-reference arguments and (true) multi-valued returns force the use of pointers upon the programmer. Anyway, I don't want to do C bashing here - although, on this list, I might get away with it ;-) Cheers, Manuel

2 1

Re: Just for your fun and horror
by jhf＠lanl.gov 20 Feb '01

20 Feb '01

On 16-Feb-2001 Matthias Felleisen wrote: > > Because imperative languages have named one half of the denotation (the > value return) and not all of it for a long long long time. It's too late > for Haskell to change that. -- Matthias Well now, if I am to understand what a return statement in C does, I must realize not only that it may return a value to a calling routine, but also that it preserves the store. If it allowed the store to vanish, it wouldn't be very useful, would it? So I don't see how it's reasonable to assert that "return" means only one of these two things to a C programmer. Cheers, --Joe Joseph H. Fasel, Ph.D. email: jhf(a)lanl.gov Technology Modeling and Analysis phone: +1 505 667 7158 University of California fax: +1 505 667 2960 Los Alamos National Laboratory post: TSA-7 MS F609; Los Alamos, NM 87545

4 5

newbie: running a state transformer in context of a state reader
by Konst Sushenko 20 Feb '01

20 Feb '01

hello, i have a parser which is a state transformer monad, and i need to implement a lookahead function, which applies a given parser but does not change the parser state. so i wrote a function which reads the state, applies the parser and restores the state (the State monad is derived from the paper "Monadic parser combinators" by Hutton/Meijer): type Parser a = State String Maybe a lookahead :: Parser a -> Parser a lookahead p = do { s <- fetch ; x <- p ; set s ; return x } now i am curious if it is possible to run the given parser (state transformer) in a context of a state reader somehow, so as the state gets preserved automatically. something that would let me omit the calls to fetch and set methods. i would appreciate any advise thanks konst

2 1

RE: Typing units correctly
by Andrew Kennedy 19 Feb '01

19 Feb '01

First, I think there's been a misunderstanding. I was referring to the poster ("Christoph Grein") of http://www.adapower.com/lang/dimension.html when I said that "he doesn't know what he's talking about". I've not been following the haskell cafe thread very closely, but from what I've seen your (Dylan's) posts are well-informed. Sorry if there was any confusion. As you suspect, negative exponents are necessary. How else would you give a polymorphic type to \ x -> 1.0/x ? However, because of the equivalence on type schemes that's not just alpha-conversion, many types can be rewritten to avoid negative exponents, though I don't think that this is particularly desirable. For example the type of division can be written / :: Real (u.v) -> Real u -> Real v or / :: Real u -> Real v -> Real (u.v^-1) where u and v are "unit" variables. In fact, I have since solved the simplification problem mentioned in my ESOP paper, and it would assign the second of these two (equivalent) types, as it works from left to right in the type. I guess it does boil down to choosing a nice basis; more precisely it corresponds to the Hermite Normal Form from the theory of integer matrices (more generally: modules over commutative rings). For more detail see my thesis, available from http://research.microsoft.com/users/akenn/papers/index.html By the way, type system pathologists might be interested to know that the algorithm described in ESOP'94 doesn't actually work without an additional step in the rule for let (he says shamefacedly). Again all this is described in my thesis - but for a clearer explanation of this issue you might want to take a look at my technical report "Type Inference and Equational Theories". Which brings me to your last point: some more general system that subsumes the rather specific dimension/unit types system. There's been some nice work by Martin Sulzmann et al on constraint based systems which can express dimensions. See http://www.cs.mu.oz.au/~sulzmann/ for more details. To my taste, though, unless you want to express all sorts of other stuff in the type system, the equational-unification-based approach that I described in ESOP is simpler, even with the fix for let. I've been promising for years that I'd write up a journal-quality (and correct!) version of my ESOP paper including all the relevant material from my thesis. As I have now gone so far as to promise my boss that I'll do such a thing, perhaps it will happen :-) - Andrew. > -----Original Message----- > From: Dylan Thurston [mailto:dpt@math.harvard.edu] > Sent: Wednesday, February 14, 2001 7:15 PM > To: Andrew Kennedy; haskell-cafe(a)haskell.org > Subject: Re: Typing units correctly > > > On Wed, Feb 14, 2001 at 08:10:39AM -0800, Andrew Kennedy wrote: > > To be frank, the poster that you cite doesn't know what he's talking > > about. He makes two elementary mistakes: > > Quite right, I didn't know what I was talking about. I still don't. > But I do hope to learn. > > > (a) attempting to encode dimension/unit checking in an existing type > > system; > > We're probably thinking about different contexts, but please see the > attached file (below) for a partial solution. I used Hugs' dependent > types to get type inference. This makes me uneasy, because I know that > Hugs' instance checking is, in general, not decidable; I don't know if > the fragment I use is decidable. You can remove the dependent types, > but then you need to type all the results, etc., explicitly. This > version doesn't handle negative exponents; perhaps what you say here: > > > As others have pointed out, (a) doesn't work because the algebra of > > units of measure is not free - units form an Abelian group (if > > integer exponents are used) or a vector space over the rationals (if > > rational exponents are used) and so it's not possible to do > > unit-checking by equality-on-syntax or unit-inference by ordinary > > syntactic unification. ... > > is that I won't be able to do it? > > Note that I didn't write it out, but this version can accomodate > multiple units of measure. > > > (b) not appreciating the need for parametric polymorphism over > > dimensions/units. > > ... Furthermore, parametric polymorphism is > > essential for code reuse - one can't even write a generic squaring > > function (say) without it. > > I'm not sure what you're getting at here; I can easily write a > squaring function in the version I wrote. It uses ad-hoc polymorphism > rather than parametric polymorphism. It also gives much uglier > types; e.g., the example from your paper > f (x,y,z) = x*x + y*y*y + z*z*z*z*z > gets some horribly ugly context: > f :: (Additive a, Mul b c d, Mul c c e, Mul e c b, Mul d c a, > Mul f f a, Mul g h a, Mul h h g) => (f,h,c) -> a > > Not that I recommend this solution, mind you. I think language > support would be much better. But specific language support for units > rubs me the wrong way: I'd much rather see a general notion of types > with integer parameters, which you're allowed to add. This would be > useful in any number of places. Is this what you're suggesting below? > > > To turn to the original question, I did once give a moment's thought > > to the combination of type classes and types for units-of-measure. I > > don't think there's any particular problem: units (or dimensions) > > are a new "sort" or "kind", just as "row" is in various proposals > > for record polymorphism in Haskell. As long as this is tracked > > through the type system, everything should work out fine. Of course, > > I may have missed something, in which case I'd be very interested to > > know about it. > > Incidentally, I went and read your paper just now. Very interesting. > You mentioned one problem came up that sounds interesting: to give a > nice member of the equivalence class of the principal type. This > boils down to picking a nice basis for a free Abelian group with a few > distinguished elements. Has any progress been made on that? > > Best, > Dylan Thurston >

2 1

Re: framework for composing monads?
by Elke Kasimir 19 Feb '01

19 Feb '01

(Moving to haskell cafe...) On 18-Feb-2001 Manuel M. T. Chakravarty wrote: >> It is even acceptable for me to manage the state in C - >> independent of the API design - but then some time there >> will be the question: Why do I always say that that Haskell >> is the better programming language, when I'm >> really doing all the tricky stuff in C?... > > Sure - therefore, I proposed to use `IORef's rather than C > routines. Thanks for the hint! I took a look at them and now have some questions: a) It is clear that I need some C-link to access the cli/odbc lib. Up to now I planned to use Haskell Direct for this. Except of this, I want to stick to Haskell 98 and seek for maximal portability. Practically, this raises the question of wether nhc and hbc support hslibs or else I can provide a substitute for IORef's for these compilers. Can someone give me hint? b) What I finally need is "hidden state". My first attempt to get one using IORefs is: > import IOExts > > state :: IORef Int > state = unsafePerformIO $ newIORef 0 > > main = seq state $ do > writeIORef state 1 > currstate <- readIORef state > putStr (show currstate) Is this the right way? Cheers, Elke --- "If you have nothing to say, don't do it here..." Elke Kasimir Skalitzer Str. 79 10997 Berlin (Germany) fon: +49 (030) 612 852 16 mail: elke.kasimir(a)catmint.de> see: <http://www.catmint.de/elke> for pgp public key see: <http://www.catmint.de/elke/pgp_signature.html>

3 2

Re: Just for your fun and horror
by Jerzy Karczmarczuk 19 Feb '01

19 Feb '01

Dear all, at haskell-café & plt-scheme. 1. THANK YOU VERY MUCH for enlightening comments about the terminology, student psychology, etc. I will get back to it in a second, for the moment I ask you very politely: survey the adressee list if you "reply-all". For people subscribing both Haskell and Scheme forums means 4 copies of your message, if you send the messages simultaneously to the private address of the previous author...!. I thought that a cross posting might have some merits, and I see now the nuisance. My deep apologies. 2. People suggest that the word return has been badly chosen. I have no strong opinion, I begin to agree... we had unit, result, people propose liftM, compute, deliver, etc. I wonder why return stuck? Just because it exists elsewhere? I believe not, it has some appeal, as Joe Fasel acknowledges. C. Reinke writes: > One way to look at the problem is that some of your students have > concrete experience with `return' in different contexts, and that > Haskell tries to make different things look similar here. You say > "we worked with monads for several weeks" but, you being yourself, > this was probably at a fairly abstract and general level, right? No, not exactly. Being myself, just the opposite. There is *NO* more abstraction in my course than in Wadler's "Essence...". * I begin with a silly functional evaluator of a tree representing an arithmetic expression. * We recognize together with the students that a program may fail, and we introduce Maybe. They see thus a simple monadic generali- sation and the first non-trivial instance of return. We try to implement (in a sketchy way) a tracing generalisation as well. * They have parallelly a course of Prolog, so we play con mucho gusto with a few "non-deterministic" algorithms, such as standard combinatoric exercices : the generation of permutations, of the powerset, etc. On average the students seem to understand the idea and the implementation, and *mind you*: while writing their exercises <<a vista>> they duly corrected themselves when they were tempted to write "z" instead of "return z". ([] =-> [[]]). * We worked for a reasonable period with monadic parsers. The comment above is valid. Semantically they accepted the difference between "z" and "return z". I couldn't foresee any surprises. * They had to write a serious program in Haskell, so I gave them an introduction to Haskell I/O. They couldn't escape from *practical* Monads (although some of my students "perverted" [with my approval] the idea of writing a *syntactic* converter to Scheme, realizing it not in Haskell but in Scheme...) I spoke of course about types, but not simultaneously. We took advantage of the type inference, and the *type* of return has not been discussed explicitly sufficiently early. This is - I believe - my main, fundamental pedagogical fault! Yes Joe, I think this has been my own <<pons asinorum>>. If my compilation course survives all this affair (not obvious) I will try to remember Jón Fairbarn's suggestion (repeated by Manuel Chakravarty), and to discuss thoroughly the status of "C" imperative concepts, in order to prevent misunderstandings. C. Reinke again: > Unless you're one of Asimov's technicians of eternity, it is a bit > difficult to change the history of programming languages, and assuming > that the students pay for the opportunity to learn, you can't really > fire them either.. Hm. We are all Technicians able to change the past, but since we do not live outside the System, we do it usually in the Orwellian way: we change the INTERPRETATION of the past. Things which were good (structural top-down programming) become bad (inadapted to object approach). Strong typing? A straitjacket for some, a salvation for the other. Scheme'ists add OO layers in order to facilitate the code reusing, and this smuggles in some typing. Dynamic typing in static languages became a folkloric, never-ending issue... The history of languages is full of "second thoughts". Who will first write a paper with a Wadlerian style [[but taken from earlier literature]] title: "Monads considered harmful" "Return should NOT return its argument" etc.? And in France students don't pay for the opportunity to learn. Regards. Jerzy Karczmarczuk Caen, France

1 0

FW: Announcing haskelldoc
by Simon Peyton-Jones 19 Feb '01

19 Feb '01

> In the Haskell community is there a generally accepted best way to > approach Literate Programming? The language has support for literate > comments, but it seems that many common LP tools don't respect it. I don't know whether you'd regard this as literate programming, but there's a move afoot to get a widely used Haskell documentation tool (enclosed). Simon -----Original Message----- From: Henrik Nilsson [mailto:nilsson@cs.yale.edu] Sent: 05 February 2001 22:14 To: haskell(a)haskell.org Subject: Announcing haskelldoc Dear Haskellers, At the recent Haskell Implementors' meeting in Cambridge, UK, it was decided that it would be useful to have a standard for embedded Haskell documentation. Such standards, and associated tools for extracting and formating the documentation in various ways, exists for other languages like Java and Eiffel and have proven to be very useful. Some such tools also exist (and are being actively developed) for Haskell, but there is as yet no generally agreed upon standard for the format of the embedded documentation as such. To address this, a mailing list has been started with the aim of defining a standard for embedded Haskell documentation, and possibly also related standards which would facilitate the development of various tools making use of such documentation (formatters, source code browsers, search tools, etc.). We feel that it is important to involve all who might be interested in this work at an early stage, so that as many aspects as possible can be taken into consideration, and so that the proposal for a standard which hopefully will emerge has a reasonable chance of gaining widespread support. Thus, You are hereby cordially invited to join haskelldoc(a)haskell.org. To join, just goto http://www.haskell.org/mailman/listinfo/haskelldoc. Best regards, Armin Groesslinger <groessli(a)fmi.uni-passau.de> Simon Marlow <simonmar(a)microsoft.com> Henrik Nilsson <nilsson(a)cs.yale.edu> Jan Skibinski <jans(a)numeric-quest.com> Malcolm Wallace <malcolm(a)abbess.demon.co.uk> _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

1 0

Re: [newbie] Lazy >>= ?!
by Scott Turner 18 Feb '01

18 Feb '01

Andrew Cooke wrote: >1. After digesting what you wrote I managed to make a lazy list of IO >monads containing random numbers, but couldn't make an IO monad that >contained a lazy list of random numbers. Is this intentional, me >being stupid, or just chance? I had wondered what kind of thing you were doing with the IO monad. Random numbers are an odd fit. Pseudorandom numbers can be generated in a lazy list easily; you don't need a connection with the IO monad to do it. Using the Random module of the Hugs distribution, it's for example randoms (mkStdGen 1) :: [Int] The IO monad can be brought into this picture easily. return (randoms (mkStdGen 1)) :: IO [Int] But it sounds as if you're looking for something more sophisticated. You want to use randomIO perhaps because it better matches your notion of how random numbers should be generated. Using randomIO places more restrictions on how you operate, because it forces the random numbers to be created in a particular sequence, in relation to any other IO which the program performs. Every random number that is ever accessed must be produced at a particular point in the sequence. An unbounded list of such numbers cannot be returned! That is, you are looking for randomsIO :: IO [a] which yields a lazy list, by means of repeated calls to randomIO. All such calls would have to occur _before_ randomsIO returns, and before _any_ use of the random numbers could be made. The program hangs in the process of making an infinite number of calls to randomIO. But, you may say, those infinite effects are invisible unless part of the list is referenced later in the program, so a truly lazy implementation should be able to skip past that stuff in no time. Well, that's conceivable, but (1) that's making some assumptions about the implemetation of randomIO, and (2) lazy things with no side effects can and should be handled outside of the IO monad. >Also, should I be worried about having more than one IO monad - it >seems odd encapsulating the "outside world" more than once. No. Consider the expression sequence_ [print "1", print "two", print "III"] Try executing it from the Hugs command line, and figure out the type of the list. An expression in the IO monad, such as 'print 1' makes contact with the "outside world" when it executes, but does not take over the entire outside world, even for the period of time that it's active. I moved this to haskell-cafe mailing list, because it's getting a little extended. -- Scott Turner p.turner(a)computer.org http://www.billygoat.org/pkturner

2 1

Re: Just for your fun and horror
by Ashley Yakeley 18 Feb '01

18 Feb '01

At 2001-02-17 19:50, Manuel M. T. Chakravarty wrote: >It is > > bar = 42 > >for which C has no corresponding phrase. Hmm... #define bar 42 ...although I would always do const int bar = 42 -- Ashley Yakeley, Seattle WA

2 1

Re: Just for your fun and horror
by Scott Turner 18 Feb '01

18 Feb '01

Matthias Felleisen wrote: >When a C programmer thinks about the >'return' type of a C function, he thinks about the value-return half >of a return statement's denotation. The other half, the modified store, >remains entirely implicit as far as types are concerned. Just because the type system of C keeps store implicit, it doesn't change the match between the meaning of 'return' in the two languages. The IO monad provides a refined way of typing imperative-style functions, including return statements. If you want to use a return statement in Haskell, you can, and it's called 'return'. (A reasonable alternative would be for 'return' to have second class status, as syntactic sugar for 'unit', analgous to otherwise=True). -- Scott Turner p.turner(a)computer.org http://www.billygoat.org/pkturner

4 3