- Haskell-Cafe - Haskell.org

(no subject)
by Atenea Azcue 28 Mar '01

28 Mar '01

Hello My name is Atenea : I�m what to ask you who can I make a program in haskell like une program that say hello word --------------------------------- Do You Yahoo!? Yahoo! Mail Personal Address - Get email at your own domain with Yahoo! Mail.

2 1

Re: the constant functor
by Tom Pledger 27 Mar '01

27 Mar '01

Tobias Haeberlein writes: | | > What is wrong with: | > | > class Functor ConstInt where | > map f (Const n) = Const n | | Ups - absolutely nothing. | I actually tried it with | | data ConstInt a = Int This version doesn't refer to the type Int. Instead, it introduces a new nullary data constructor called Int, which you could use like this: instance Functor ConstInt where fmap f Int = Int ...but I don't think that's what you were after. If you use a type alias (type ConstInt a = Int) instead of declaring a data type, it will refer to the type Int. However, then you'd need to use ConstInt partially applied in the instance declaration, which Haskell doesn't allow. I think Gofer has a more liberal type system which does allow it. | and didnt manage to make this an instance of | class Functor. Sorry for giving the wrong | example.

1 0

Re: the constant functor
by Koen Claessen 27 Mar '01

27 Mar '01

(moved reply to haskell-cafe) Hi Tobias, | data ConstInt a = Const Int | | Any ideas how to make 'ConstInt' an instance of class | Functor? What is wrong with: class Functor ConstInt where map f (Const n) = Const n ? /Koen. -- Koen Claessen http://www.cs.chalmers.se/~koen phone:+46-31-772 5424 mailto:koen@cs.chalmers.se ----------------------------------------------------- Chalmers University of Technology, Gothenburg, Sweden

1 0

Re: Linearity Requirement for Patterns
by Michael Hanus 23 Mar '01

23 Mar '01

Fergus Henderson wrote: > My understanding, from talking with Michael Hanus a few years ago, is > that Curry is not referentially transparent, in the sense that you can't > replace equals with equals, because it permits nondeterministic functions. > In particular, `let x = f y in g x x' is not the same as `g (f y) (f y)' > in Curry. Of course, as you already mentioned, one has te be very precise when talking about referential transparency. In particular, one has to say what "equals" mean. Otherwise, one could also argue that Haskell is not referential transparent: if a Haskell program has a defining equation "f 1 = 1", the expressions "(f 1)" and "1" might not be identical (if there is another equation like "f x = 0" before). In Curry, each defining equation contributes to the semantics of a function independently of the other equations for the same function, and the overall goal is to compute all values of an expression (plus possible substitutions for free variables) which can be derived from this equational reading of all rules. In this sense, Curry is refentially transparent (although I have no formal definition of this notion but only soundness, completeness and optimality results). Your "counter example" comes from a misunderstanding of the "let" in Curry. Since the kernel language is based lazy evaluation w.r.t. a set of constructor-based rewrite rules, the "let" is considered as syntactic sugar for abbreviating some function argument. For instance, the meaning of the definition h = let x = f y in g x x is defined as an abbreviation for the rules h = aux (f y) aux x = g x x W.r.t. this semantics, there is no problem even with non-deterministic functions. If you have a precise definition of "referentially transparent" at hand so that you can make your statement more precise, I would be very interested to read it. As you have seen, the slogan "replacing equals by equals" is still to fuzzy since just looking for equality symbols in a language is not sufficient. Michael

4 3

Re: Linearity Requirement for Patterns
by Michael Hanus 22 Mar '01

22 Mar '01

Bjorn Lisper wrote: > >some function argument. For instance, the meaning of the definition > > > > h = let x = f y in g x x > > > >is defined as an abbreviation for the rules > > > > h = aux (f y) > > aux x = g x x > > > >W.r.t. this semantics, there is no problem even with non-deterministic > >functions. > > How does sharing work here? I assume the "let x = ..." is intended to mean > sharing of "...". Does the same hold for function calls in Curry, so > "aux x = g x x" implies sharing of x when evaluating g? In that case I Yes. Since Curry is based on a lazy and (for a particular subclass, namely inductively sequential rules) also optimal evaluation strategy, sharing of function arguments is required and essential. > suspect you might have problems if, for instance, you inline aux naively > into g (f y) (f y) and f is nondeterministic. (Inlining should typically > work for a referentially transparent language.) The problem can be fixed > though: if you have this sharing, then "aux x = g x x" is really shorthand > for "aux x = let y = x in g y y". If this definition is inlined and the let > is kept (to preserve the sharing), then the transformation should work even > if f is nondeterministic. In the presence of nondeterministic functions (i.e., nonconfluent rules), one has several options for the semantics. For parameter passing, one can use either the call-time choice or run-time choice semantics. Curry is based on the former since there is a well-defined semantical framework for this in the presence of non-strict functions (Gonzalez-Moreno et al., Journal of Logic Programming, Vol. 40, 1999). Semantically, the call-time choice means that rewrite rules can only be applied if the arguments are constructor terms, i.e., totally evaluated. This does not necessarily imply a strict semantics since it can be implemented by lazy reduction provided that function arguments are shared. Thus, this sharing must be somehow represented in an intermediate language for executing the programs and on this level inlining is preserved, as you have remarked. Naive inlining (i.e., without lets but possibly duplicating function calls) does only work for deterministic functions (which is no restriction from a Haskell point of view since Haskell allows only deterministic functions). > I don't know how much of this applies directly to Curry, since the above is > for pure term rewriting and I suspect Curry has unification in its > evaluation mechanism (right?) which then makes the evaluation more > complex. But maybe the above can provide some ideas how to formally define > referential transparency for Curry? The paper mentioned above defines a proof calculus, model theory and operational semantics for this language where the denotation of functions distinguish between deterministic and non-deterministic functions which seems to be conform to your remarks. Although it does not explicitly define referential transparancy, it shows the equivalence of all three notions which I think is enough for reasoning about Curry programs. Nevertheless, many thanks for your hints. Michael

1 0

Re: Linearity Requirement for Patterns
by Michael Hanus 22 Mar '01

22 Mar '01

Lennart Augustsson wrote: > Yes, your definition of non-linear patterns would give you extra > power. It would also destroy the nice semantics of Haskell! > By using this facility you can now observe intensional properties > of the term, and the clean denotational semantics crumbles. > > E.g., in Haskell you can always replace equals by equals without > changing the meaning of a program. In your example `g 0' is equal > to bottom so it should be possible to replace it by any other bottom > without any change in meaning. But if I define > h x = h x > and evaluate `f (g 0) (h 0)' I will no longer get 0. > > So this definitions of non-linear patterns is not an option for a > language that claims to be "referentially transparent" (whatever that means :). I agree and the question is about "whatever that means"... Term rewriting systems (TRS) are based on replacing equals by equals and that could be also considered as "referentially transparent". Nevertheless, TRSs usually allow non-linear left-hand sides (but often come with other restrictions like termination). BTW, (g 0) and (h 0) are not considered as equal since there are no rules/equations to transform one into the other. However, I agree that there are good reasons (mainly, operational simplicity) to allow only linear patterns and constructor-based rules in a real programming language, since non-linear patterns or non-constructor-based rules require other and more advanced operational principles. I only wanted to remark that there is no simple way to translate non-linear pattterns into linear patterns in the general case. Michael

4 3

Re: Linearity Requirement for Patterns
by Michael Hanus 22 Mar '01

22 Mar '01

Jerzy Karczmarczuk wrote: > Logic languages which allow for nonlinear patterns use unification, > which is usually much more costly than simple pattern compiling. > Now, I wonder whether in FP where there is no place for "logical > variable" concept one needs or doesn't need the classical unification, > with all the substitutions of variables. > "Read-only" patterns are manipulated more efficiently, but in presence > of laziness, of ~patterns etc., I feel - for the moment - rather > lost. > > What is the status of the referential transparency of Prolog or > Mercury? Prolog isn't referential transparent due to predefined predicates with side effects. However, logic programming ("pure Prolog") is referentially transparent if one considers a "non-deterministic" semantics where an expression is reduced to a disjunction of expressions (Prolog systems explore this disjunction in a left-to-right manner by backtracking). Actually, one can extend Haskell by "logical variables" in a conservative manner. This is the idea of the functional logic language Curry (http://www.informatik.uni-kiel.de/~curry/) where the pattern matching process is slightly extended so that the operational behavior is identical to Haskell (i.e., not more costly) for programs without occurrences of logical variables and, if a logical variable occurs during pattern matching, it is (non-deterministically) bound to some pattern. However, in order to support infinite data structures and laziness, linear patterns are also required. Non-linear patterns must be transformed into linear patterns by introducing a unification constraint in the condition part, i.e., all non-linearities must be made explicit in the program (so that pattern matching can be efficiently performed). Thus, I think that linearity is a natural requirement even for logic languages that support laziness. Michael

3 2

Re: ANNOUNCE: HasChorus - some modules for Haskore
by Robert Jeschofnik 21 Mar '01

21 Mar '01

On 20-Mar-2001, Martin Schwenke <martin(a)meltin.net> wrote: > HasChorus: > > A set of Haskell (http://haskell.org/) modules written on top of > Haskore (http://haskell.org/haskore/) to make it easier to sequence > simple, repetitive music. Even without having had a look at the code yet, I am led to wonder... > BubbleSort.lhs: An implementation of bubble sort. > Used by HasGroove.lhs. (I reformatted the quote so it wouldn't wrap over 80 chars) -Why- bubblesort? Rob

2 1

RE: Coroutines
by Simon Peyton-Jones 20 Mar '01

20 Mar '01

Lazy evaluation *is* coroutines, in a way. Or you may be interested in Concurrent Haskell See section 4 of "Tackling the awkward squad" http://research.microsoft.com/~simonpj/papers/marktoberdorf.htm Simon | -----Original Message----- | From: Andreas Gruenbacher [mailto:gruenbacher@geoinfo.tuwien.ac.at] | Sent: 19 March 2001 17:00 | To: haskell-cafe(a)haskell.org | Subject: Coroutines | | | Hello, | | has anybody thought about how to implement Simula style coroutines in | Haskell? What I have in mind is several "procedures" that | communicate via | message passing in a co-operative way. That would give clear | and intuitive | code for things like simulations... | | Thanks, | Andreas. | | -------------------------------------------------------------- | ---------- | Andreas Gruenbacher gruenbacher(a)geoinfo.tuwien.ac.at | Research Assistant Phone +43(1)58801-12723 | Institute for Geoinformation Fax +43(1)58801-12799 | Technical University of Vienna Cell phone +43(664)4064789 | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe |

6 6

RE: Coroutines
by Simon Peyton-Jones 20 Mar '01

20 Mar '01

| I see your point, and I must admit that this approach has its | charm. It's | not what I had in mind, though. Simon's MVars (in the Awkward Squad) | come pretty close, but they're still not the sort of (cooperative) | multitasking that I'm thinking of. I'm not looking for a | process or thread | model of concurrency. That's too expensive for simulations due to the | frequency of task switches. Could you try it and see? GHC's threads are implemented in GHC's runtime system; thread switching is much much much cheaper than switching between OS threads. It's designed to support thousands or hundreds of thousands of threads. Give it a whirl! Simon

1 0

RE: Coroutines
by Simon Peyton-Jones 19 Mar '01

19 Mar '01

1 0

Coroutines
by Andreas Gruenbacher 19 Mar '01

19 Mar '01

Hello, has anybody thought about how to implement Simula style coroutines in Haskell? What I have in mind is several "procedures" that communicate via message passing in a co-operative way. That would give clear and intuitive code for things like simulations... Thanks, Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher gruenbacher(a)geoinfo.tuwien.ac.at Research Assistant Phone +43(1)58801-12723 Institute for Geoinformation Fax +43(1)58801-12799 Technical University of Vienna Cell phone +43(664)4064789

1 0

Re: Linearity Requirement for Patterns
by Michael Hanus 19 Mar '01

19 Mar '01

Brian Boutel wrote: > In any case, the same effect can be obtained using guards, where the > extra power of expression syntax solves the problem. Instead of > f x x = e1 > f (illegal pattern) = e2 > ... > > you can write the single equation > > f x y | x == y = e1 > | x /= y = e2 It depends on the meaning of pattern matching wrt. non-linear patterns. The standard notion (e.g., term rewriting) matches a pattern by finding a substitution for the pattern variables so that the instantiated pattern is identical to the function call. In this case, it can also match partially defined functions in contrast to your transformation. For instance, consider the definitions g z = 1 + g z f x x = 0 Then a call like (f (g 0) (g 0)) is reducible to 0 (wrt. standard notion of pattern matching using the instantiation {x |-> (g 0)}) whereas it is undefined if we transform this definition to f x y | x==y = 0 (which requires the evaluation of both arguments). Thus, I would say that non-linear patterns gives you extra power. Michael

3 2

(no subject)
by mc991008 18 Mar '01

18 Mar '01

hello, i'm a student of computer science in a known university of pakistan. in this semester i'm doing a course on "programming methodology". in this course i had given a project on learning haskell, a functional language and to give a comparison on haskell with prolog. if u plz kindly guide me and help me out, i'll be very thankful to u. looking forward soon from u bye amara hussain mc991008(a)pgc.edu

2 1

FREE Biotech Stock Info! 298
by biotechstox13＠excite.com 18 Mar '01

18 Mar '01

1 0

Linearity Requirement for Patterns
by Samuel E. Moelius III 17 Mar '01

17 Mar '01

What is the reasoning for the requirement that patterns be linear? Am I correct to say that if non-linear patterns were allowed, it would require equality to be defined for all data types? Is this the reason, or are there others? Sam Moelius

4 4

GHC HQ are looking for a Linux-IA64 box
by Julian Seward (Intl Vendor) 12 Mar '01

12 Mar '01

[Apologies if you get multiple copies of this msg.] Folks, Following a recent discussion about future development directions for GHC, it seems one thing we want to start thinking about is support for the IA64 architecture. Does any kind person have an IA64 box, running Linux, on which we could have an account? The extent of the work would be to make GHC's runtime-support system work again on a 64-bit platform (it used to), and possibly to build an IA64 native code generator. This work would be spread across a couple of months, I imagine. Basic requirements are: * IA64 Linux box, with development tools (gcc, perl, autoconf, gdb, etc -- all the usual Linux/Unix stuff). * As many spare processor cycles as possible. GHC building/debugging tends to CPU intensive. Also, probably at least 256MB of memory would be necessary to keep us out of trouble. * At a bare minimum, 300 MB of free disk space; 1 GB would be preferable, since it would allow more thorough testing of the system. * Decent, permanent, reliable internet connection from so that we can work remotely (obviously) and so that we can talk to our CVS server. I'd say at a bare minimum a 128 kb/sec connection. Preferably as few as possible network hops from Cambridge, UK. This work is likely to be on-and-off (not all the time) over a couple of months, I'd guess. We probably won't be ready to start on it for at least a month, so some time around the start of May would be when we'd really want to start moving on this. Availability of such a machine would be a useful contribution to the GHC development effort, so we'd be grateful if any of you could point us in the right direction. J (speaking for the GHC crew as a whole)

2 1

zips and maps
by Eric Allen Wohlstadter 09 Mar '01

09 Mar '01

I find myself very often needing to use this function and was wondering if there was already a way to do this using zip,maps, and folds. zipMap::[a->b]->[a]->[b] zipMap [] _ = [] zipMap _ [] = [] zipMap (f:fs) (x:xs) = (f x):(zipMap fs xs) Alternatively I can get the same affect like this: fstOnSnd::(a->b,a)->b fstOnSnd (f,x) = f x zipMap::[a->b]->[a]->[b] zipMap fs xs = map fstOnSnd (zip fs xs) Both require me to invent some new function (or use a lambda) which I am trying to avoid. If it is unavoidable then can someone think of a better name then zipMap? Eric Wohlstadter UCDavis Software Engineering

4 3

RE: zips and maps
by Conal Elliott 09 Mar '01

09 Mar '01

Note also that zipMap is the classic S combinatory if you think of lists as functions over the natural numbers, so there's something especially compelling about it. Similarly, repeat is K. From zipMap & repeat, you can easily define map, zip, zipWith, zipWith3, etc. s = zipWith ($) k = repeat mapT f xs = s (k f) xs zipWithT f as bs = s (mapT f as) bs zipT = zipWithT (,) zipWith3T f as bs cs = s (zipWithT f as bs) cs - Conal -----Original Message----- From: Mieszko Lis [mailto:elf@sandburst.com] Sent: Thursday, March 08, 2001 6:30 PM To: Eric Allen Wohlstadter Cc: haskell-cafe(a)haskell.org Subject: Re: zips and maps Eric Allen Wohlstadter wrote: > > I find myself very often needing to use this function and was wondering if > there was already a way to do this using zip,maps, and folds. Do you mind using zipWith? How about zipMap = zipWith ($) ..? -- Mieszko _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: zips and maps
by Conal Elliott 09 Mar '01

09 Mar '01

How about zipMap = zipWith ($) - Conal -----Original Message----- From: Eric Allen Wohlstadter [mailto:wohlstad@cs.ucdavis.edu] Sent: Thursday, March 08, 2001 6:19 PM To: haskell-cafe(a)haskell.org Subject: zips and maps I find myself very often needing to use this function and was wondering if there was already a way to do this using zip,maps, and folds. zipMap::[a->b]->[a]->[b] zipMap [] _ = [] zipMap _ [] = [] zipMap (f:fs) (x:xs) = (f x):(zipMap fs xs) Alternatively I can get the same affect like this: fstOnSnd::(a->b,a)->b fstOnSnd (f,x) = f x zipMap::[a->b]->[a]->[b] zipMap fs xs = map fstOnSnd (zip fs xs) Both require me to invent some new function (or use a lambda) which I am trying to avoid. If it is unavoidable then can someone think of a better name then zipMap? Eric Wohlstadter UCDavis Software Engineering _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Re: Summer School on Functional Programming?
by Johan Jeuring 08 Mar '01

08 Mar '01

>I was wondering if anyone knew if there was going to be a summer school on >functional programming this year. Also, where would I find information >about it? Thanks. I don't think a summer school on advanced functional programming will be organised this year. Maybe next year, but as far as I know nothing has been decided yet. I will try to start up something (which doesn't mean I will organise it!) soon. -- Johan Jeuring

1 0

Summer School on Functional Programming?
by Eric Allen Wohlstadter 08 Mar '01

08 Mar '01

I was wondering if anyone knew if there was going to be a summer school on functional programming this year. Also, where would I find information about it? Thanks. Eric Wohlstadter UCDavis Software Engineering

1 0

Literate Programming in Haskell?
by Tom Moertel 02 Mar '01

02 Mar '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. For example, in order to convert some .lhs code into LaTeX via the noweb LP tools, I had to write a preprocessor to convert the ">" code blocks into something that noweb would respect. (The preprocessor actually does a bit more and, in conjunection with noweb, gives pretty good results for little effort. For an example, see: http://www.ellium.com/~thor/hangman/cheating-hangman.lhs http://www.ellium.com/~thor/hangman/cheating-hangman.pdf ) Yet somehow, I don't think that my homebrew approach is optimal. Can anybody recommend a particularly elegant LP setup for Haskell programming? Or if you have an approach that works well for you, would you mind sharing it? Cheers, Tom

7 6

RE: Literate Programming in Haskell?
by Conal Elliott 02 Mar '01

02 Mar '01

Has anyone gotten Ralf's lhs2tex to work under Windows? I compiled it up with GHC 4.08.1 and then GHC 4.08.2, on Windows 2k pro, and it appears to fail in all of its file reads. Haven't yet isolated a small bug example to report. - Conal -----Original Message----- From: Ralf Hinze [mailto:ralf@cs.uu.nl] Sent: Thursday, March 01, 2001 5:40 AM To: Patrik Jansson Cc: haskell-cafe(a)haskell.org Subject: Re: Literate Programming in Haskell? Patrik Jansson wrote: > A tool I am using is Ralf Hinze's > > http://www.informatik.uni-bonn.de/~ralf/Literate.tar.gz > > http://www.informatik.uni-bonn.de/~ralf/Guide.ps.gz > > It transforms .lhs files (with some formatting commands in LaTeX-style > comments) to LaTeX. Development based on this idea is something I would be > willing to participate in as I already have a fair amount of Haskell > code/articles (read: my PhD thesis;-) in this format. > > Maybe Ralf can say something about his views on further development of > lhs2tex (copyright etc.) by other people (us?). [Sorry for the delay.] In principle, everyone can use and/or modify the program to adjust it to her needs. However, since I use lhs2text almost daily, I am willing to maintain the program. So if you have suggestions, proposals etc please let me know. Cheers, Ralf _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

FW: Pattern guards vs. case (was, unfortunately :Re: interesting example of laziness/ghc optimisation)
by Simon Peyton-Jones 01 Mar '01

01 Mar '01

1 0

RE: Primitive types and Prelude shenanigans
by Simon Peyton-Jones 28 Feb '01

28 Feb '01

| Why not just let | | if x then y else z | | be syntactic sugar for | | Prelude.ifThenElse x y z The burden of my original message was that a) this is reasonable, but b) it would have to become the *defined behaviour* As you say, the "defined behaviour" would have to cover guards as well, and I'm not absolutely certain what else. The way GHC is set up now, it's relatively easy to make such changes (this wasn't true before). But it takes some design work. If someone cares enough to do the design work, and actively wants the result, I'll see how hard it is to implement. Simon

3 2

examples using built-in state monad
by Konst Sushenko 28 Feb '01

28 Feb '01

hello, in my program i used my own parameterised state transformer monad, which is well described in literature: newtype State s m a = ST (s -> m (a,s)) ghc and hugs contain built in implementation of state monad ST. is it the same thing? the documentation is not clear on that. if it is the same, is it faster? also, could someone please recommend any samples that use the built in ST monad? thanks konst

2 1

Re: Literate Programming in Haskell?
by Bill Halchin 28 Feb '01

28 Feb '01

Hello Haskell Community, Probably somebody else has already brought this issue up already. Why can't we have some kind of integrated literate programming model where I can I can have hyperlinks in comments to documents represented in XML?? In other words, a kind of seamless literate progarmming environment in Haskell with XML, i.e. Haskell and XML are seamless?? E.g. here is a step in the right direction by writing in Literate Haskell in HTML!: http://www.numeric-quest.com/haskell/ The stuff at this URL is pretty cool, i.e. "Haskell" scripts written in HTML. I want to also see hyperlinks to XML docs in Literate Haskell comments or maybe even to Haskell code! Regards, Bill Halchin >From: "Erik Meijer" <erik(a)meijcrosoft.com> >To: "Patrik Jansson" <patrikj(a)cs.chalmers.se>, <haskell-cafe(a)haskell.org> >CC: <ralf(a)cs.uu.nl> >Subject: Re: Literate Programming in Haskell? >Date: Mon, 19 Feb 2001 22:00:47 -0800 > >You also might take a look at Maarten Fokkinga's mira.sty >http://www.cse.ogi.edu/~mbs/src/textools/ and Mark Shileds' abbrev.sty >which >was derived from that http://www.cse.ogi.edu/~mbs/src/textools/. > >Erik >----- Original Message ----- >From: "Patrik Jansson" <patrikj(a)cs.chalmers.se> >To: <haskell-cafe(a)haskell.org> >Cc: <ralf(a)cs.uu.nl> >Sent: Monday, February 19, 2001 6:07 AM >Subject: Re: Literate Programming in Haskell? > > > > On Mon, 19 Feb 2001, Bostjan Slivnik wrote: > > > > > > > I'm also very interested in this, but ideally I would want the >output >to > > > > be in some proportional font, with symbols like =>, ->, <- replaced >with > > > > arrows, etc. Also, it would be very nice to have the code >automatically > > > > column aligned (using heuristics). > > > > > > So am I. Is anybody willing to cooperate on the desing of such tool? > > > > A tool I am using is Ralf Hinze's lhs2tex > > > > http://www.informatik.uni-bonn.de/~ralf/Literate.tar.gz > > > > http://www.informatik.uni-bonn.de/~ralf/Guide.ps.gz > > > > It transforms .lhs files (with some formatting commands in LaTeX-style > > comments) to LaTeX. Development based on this idea is something I would >be > > willing to participate in as I already have a fair amount of Haskell > > code/articles (read: my PhD thesis;-) in this format. > > > > Maybe Ralf can say something about his views on further development of > > lhs2tex (copyright etc.) by other people (us?). > > > > /Patrik Jansson > > > > PS. I have made some small improvements to lhs2tex locally and I seem to > > remember that one or two of those were actually needed to get it to > > run with my ghc version. > > > > > > _______________________________________________ > > 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 _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

RE: Primitive types and Prelude shenanigans
by Simon Peyton-Jones 27 Feb '01

27 Feb '01

| | Some while ago I modified GHC to have an extra runtime | | flag to let you change this behaviour. The effect was | | that 3 turns into simply (fromInt 3), and the | | "fromInt" means "whatever fromInt is in scope". | | Hmmm... so how about: | | foo fromInt = 3 | | Would this translate to: | | foo f = f 3 This exactly what will happen. But you are right to say that it is perhaps not what you want. Another alternative would be: "3" turns into "Prelude.fromInt 3", where "Prelude.fromInt" means "whatever Prelude.fromInt is in scope". So then you'd have to say import Prelude () import MyPrelude as Prelude (as Malcolm and Marcin suggested). Maybe that's a good plan; it's a little more heavyweight. [Incidentally, if this is nhc's behaviour, it's not H98. The Report (tries to) stress that you get the "fromInt from the actual standard Prelude" regardless of what is in scope. That's why I'm not going to make it the default behaviour.] Yet another possibility would to be say you get "the unqualified fromInt that's in scope at top level". But that seems worse. Re Bools, Koen and Marcin write (respectively) | | [...] guarantee that (if otherwise e1 e2) = e1. | | I do not understand this. "otherwise" is simply a function | name, that can be used, redefined or hidden, by anyone. It | is not used in any desugaring. Why change that behaviour? | > So much for numerics. It's much less obvious what to do | about booleans. | | IMHO a natural generalization (not necessarily useful) is to follow | the definition of the 'if' syntactic sugar literally. 'if' expands | to the appropriate 'case'. So Prelude.True and Prelude.False must be | defined, and they must have the same type (otherwise we get a type | error each time we use 'if'). This would allow even | data FancyBool a = True | False | DontKnow a The point is that there must be a *defined* desugaring. The desugaring in the report defines the behaviour, but the compiler is free to do differently. If one is to be free to rebind types, the desugaring must be fully defined. Marcin suggests that 'if' is just syntactic sugar. But that would be a disaster if the new Bool type didn't have constructors True and False. For example, maybe Bool becomes a function: type Bool = forall b. b -> b -> b No constructor 'True'! Here I think the right thing is to say that desugaring for boolean constructs uses a function 'if' assumed to have type if :: forall b. Bool -> b -> b -> b Now the programmer can define both Bool and if, and the compiler will be happy. My point is this: there is some *design* to do here. It's not obvious what the design should be. But if anyone feels inclined to do the design (in consultation with the community of course) then I'd be inclined to implement it in GHC. (Though I'm not writing a blank cheque!) Decoupling the prelude is a desirable goal. Simon

3 2

Re: Tree handling
by Lars Lundgren 26 Feb '01

26 Feb '01

On Mon, 26 Feb 2001, Martin Gustafsson wrote: > Hello > > I'm a haskell newbie that tries to create a tree with arbitary numbers of childs. > I create the data structure but i can't do anything on it can someone please help > me with a small function that sums the values of the leafs, so i don´t loose my hair > so fast. > > The datastructure looks like this and a binary tree built with it would look like this: > > > data GeneralTree = Nil | Node (Integer,[GeneralTree]) > As you said you were a newbie I will ask a few questions about your datastructure. Do you know that there is no need to tuple the elements in the Node if you do not want to. You can write: data GeneralTree = Nil | Node Integer [GeneralTree] What is the intended difference between (Node 5 []) and (Node 5 [Nil]) ? > > tree = > (20, > [ > (-20,[(30,[Nil]),(20,[Nil])]), > (40,[(65,[Nil]),(-40,[Nil])]) > ] > ) This is not of type GeneralTree! (And its layout is messed up) Hint: write the type of every expression you write, and debugging will be much easier. tree :: GeneralTree ERROR tree.hs:8 - Type error in explicitly typed binding *** Term : tree *** Type : (a,[(b,[(c,[GeneralTree])])]) *** Does not match : GeneralTree This is an expression with type GeneralTree: tree :: GeneralTree tree = Node 20 [Node (-20) [Node 30 [Nil], Node 20 [Nil]], Node 40 [Node 65 [Nil], Node (-40) [Nil]]] Now it should be very easy to write a function to sum the nodes in a tree sumTree :: GeneralTree -> Integer sumTree Nil = 0 sumTree (Node n ts) = ... write this yourself hint - sum and map are very useful functions (defined in the prelude) as are recursion. Good luck! /Lars L

1 0

RE: stack overflow
by Scott Turner 26 Feb '01

26 Feb '01

At 01:26 2001-02-26 -0800, Simon Peyton-Jones wrote: >And so on. So we build up a giant chain of thunks. >Finally we evaluate the giant chain, and that builds up >a giant stack. > ... >If GHC were to inline foldl more vigorously, this would [not] happen. I'd hate to have my programs rely on implementation-dependent optimizations. BTW, I've wondered why the Prelude provides foldl, which commonly leads to this trap, and does not provide the strict variant foldl', which is useful enough that it's defined internal to the Hugs prelude. Simple prejudice against strictness? -- Scott Turner p.turner(a)computer.org http://www.billygoat.org/pkturner

1 0

Lo mejor de Internet aqu�
by promocionesdosmiluno＠yahoo.es 25 Feb '01

25 Feb '01

Visita esta web http://MundoEspanya.redireccion.com

1 0

Re: unliftM
by Lars Lundgren 23 Feb '01

23 Feb '01

On 23 Feb 2001, Julian Assange wrote: > > Is there a standard construct for something of this ilk: > > unliftM :: Monad m a -> a > I do not know if it is a standard, but every monad usually has a "runMonad" function. For ST you have runST, for IO you have unsafePerformIO and for your own monad you need to define it. Note, that if you use unsafePerformIO you, the action must not have (important) sideeffects. The burden of proof is upon YOU. /Lars L

1 0

Re: Inferring from context declarations
by D. Tweed 22 Feb '01

22 Feb '01

George Russell wrote: > > (3) Simon Peyton Jones' comments about dictionary passing are a red herring, > since they assume a particular form of compiler. Various (MLj, MLton) > ML compilers already inline out all polymorphism. Some C++ compilers/linkers > do it in a rather crude way as well, for templates. If you can do it, > you can forget about dictionary passing. [Standard disclaimer: I write prototype code that's never `finished' to ever-changing specs in a university environment; other people probably view things differently.] I'm not sure I'd agree about this. Note that there's two levels, inlining polymorphic functions at the call site and `instantiating polymorphic functions at each usage type' without doing the inlining. C++ compilers have to at least do the second because of the prevailing philosophy of what templates are (i.e., that they're safer function-macros). Some of the time this is what's wanted, but sometimes it imposes annoying compilation issues (the source code of the polymorphic function has to be available everytime you want to use the function on a new class, even if its not time critical, which isn't the case for Haskell). I also often write/generate very large polymorphic functions that in an ideal world (where compilers are can do _serious, serious_ magic) I'd prefer to work using something similar to a dictionary passing implementation. I'd argue that keeping flexibility about polymorphic function implementation (which assumes some default but can be overridden by the programmer) in Haskell compilers is a Good Thing. Given that, unless computing hardware really revolutionises, the `speed/memory' profile of todays desktop PC is going to recurr in wearable computers/PDAs/etc I believe that in 20 years time we'll still be figuring out the same trade-offs, and so need to keep flexibility. ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers email: tweed(a)cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.

2 2

Re: Primitive types and Prelude shenanigans
by Ketil Malde 22 Feb '01

22 Feb '01

qrczak(a)knm.org.pl (Marcin 'Qrczak' Kowalczyk) writes: > 'negate' defined, as it's obviously meaningless for them. We can put > 'fromInteger' in some class and 'negate' in its subclass, and make > only the former instance for natural numbers. Nitpick: not necessarily its subclass, either. We can probably imagine types where negate makes sense, but fromInteger does not, as well as vice versa. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

making a Set
by Tom Pledger 21 Feb '01

21 Feb '01

(moved to haskell-cafe) G Murali writes: | hi there, | | I'm tryng to get my concepts right here.. can you please help in | defining a funtion like | | makeSet :: (a->Bool)->Set a | | I understand that we need a new type Set like | data Set a = Set (a->Bool) what puzzles me is how to apply the funtion | to all elements belonging to type a. What other operations do you need to implement for "Set a"? Is there anything that can't be expressed in terms of those set membership functions you already have?

1 0

RE: Primitive types and Prelude shenanigans
by Simon Peyton-Jones 21 Feb '01

21 Feb '01

I don't mind doing this, but can someone first give a brief justification about why it's a good idea, independent of the discussion that has taken place on this list? I'd like to add such an explanation to the code. Simon | -----Original Message----- | From: qrczak(a)knm.org.pl [mailto:qrczak@knm.org.pl] | Sent: 16 February 2001 17:42 | To: haskell-cafe(a)haskell.org | Subject: Re: Primitive types and Prelude shenanigans | | | Thu, 15 Feb 2001 20:56:20 -0800, William Lee Irwin III | <wli(a)holomorphy.com> pisze: | | > literal "5" gets mapped to (fromPositiveInteger 5) | > literal "-9" gets mapped to (fromNonZeroInteger -9) | | Note that when a discussed generic Prelude replacement | framework is done, and ghc's rules are changed to expand -9 to | negate (fromInteger 9) instead of fromInteger (-9), then you don't | need uglification of the fromInteger function to be able to define | types with only nonnegative numeric values. Just define your negate | in an appropriate class, different from the fromInteger's class. | | -- | __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ | \__/ | ^^ SYGNATURA ZASTEPCZA | QRCZAK | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe |

3 4

RE: newbie: running a state transformer in context of a state rea der
by Konst Sushenko 21 Feb '01

21 Feb '01

Marcin, thanks for your help. to implement the lift functionality i added these well known definitions: class (Monad m, Monad (t m)) => TransMonad t m where lift :: m a -> t m a instance (Monad m, Monad (State s m)) => TransMonad (State s) m where lift m = ST (\s -> m >>= (\a -> return (a,s))) but my lookahead function lookahead p = do { s <- fetch ; lift (evalState p s) } is typed as lookahead :: State MyState Maybe a -> State MyState Maybe (a,MyState) but i need lookahead :: State MyState Maybe a -> State MyState Maybe a apparently, the (>>=) and return used in the definition of lift above are for the monad (State s m), and not monad m... everything works if i do not use the TransMonad class, but define lift manually as: lift :: Parser a -> Parser a lift m = ST (\s -> unST m s >>= (\(a,_) -> return (a,s))) but this looks like a special case of the lift above, except the right hand side of 'bind' is executed in the right context. i am still missing something konst -----Original Message----- From: Marcin 'Qrczak' Kowalczyk [mailto:qrczak@knm.org.pl] Sent: Tuesday, February 20, 2001 10:17 AM To: haskell-cafe(a)haskell.org Subject: Re: newbie: running a state transformer in context of a state reader Mon, 19 Feb 2001 18:07:17 -0800, Konst Sushenko <konsu(a)microsoft.com> pisze: > 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. It should be possible to do something like this: lookahead:: Parser a -> Parser a lookahead p = do { s <- fetch ; lift (evalState p s) } where evalState :: Monad m => State s m a -> s -> m a lift :: Monad m => m a -> State s m a are functions which should be available or implementable in a monad transformer framework. I don't have the Hutton/Meijer's paper at hand so I don't know if they provided them and under which names. Such functions are provided e.g. in the framework provided with ghc (by Andy Gill, inspired by Mark P Jones' paper "Functional Programming with Overloading and Higher-Order Polymorphism"). This definition of lookahead uses a separate state transformer thread instead of making changes in place and undoing them later. I don't think that it could make sense to convert a state transformer to a state reader by replacing its internals, because p does want to transform the state locally; a value of type Parser a represents a state transformation. The changes must be isolated from the main parser, but they must happen in some context. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTEPCZA QRCZAK _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

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

Scalable and Continuous
by Ashley Yakeley 18 Feb '01

18 Feb '01

A brief idea: something like... -- class (Additive a) => Scalable a scale :: Real -> a -> a -- equivalent to * (not sure of name for Real type) class (Scalable b) => Continuous a b | a -> b add :: b -> a -> a difference :: a -> a -> b -- Vectors, for instance, are Scalable. You can multiply them by any real number to get another vector. Num would also be Scalable. An example of Continuous would be time, e.g. "Continuous Time Interval". There's no zero time, although there is a zero interval. Space too: "Continuous Position Displacement", since there's no "zero position". -- Ashley Yakeley, Seattle WA

5 6

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

17 Feb '01

Andrew Cooke wrote: >2. Why does the following break finite lists? Wouldn't they just >become lazy lists that evaluate to finite lists once map or length or >whatever is applied? > >> Now, if this were changed to >> ~(x:xs) >>= f = f x ++ (xs >>= f) >> (a lazy pattern match) then your listList2 would work, but finite >> lists would stop working. They wouldn't just become lazy lists. A "lazy" pattern match isn't about removing unnecessary strictness. It removes strictness that's necessary for the program to function normally. A normal pattern match involves selecting among various patterns to find the one which matches; so it evaluates the expression far enough to match patterns. In the case of (x:xs) it must evaluate the list sufficiently to know that it is not an empty list. A lazy pattern match gives up the ability to select which pattern matches. For the sake of less evaluation, it opens up the possibility of a runtime error, when a reference to a named variable won't have anything to bind to. The list monad is most often used with complete finite lists, not just their initial portions. The lazy pattern match shown above breaks this because as it operates on the list, it assumes that the list is non-empty, which is not the case when the end of the list is reached. A runtime error is inevitable. -- Scott Turner p.turner(a)computer.org http://www.billygoat.org/pkturner

1 0