Re: learning to love laziness
hello, Richard Nathan Linger wrote: On Wed, 24 Sep 2003, Norman Ramsey wrote: Consider the following Haskell function: asPair x = (fst x, snd x) This function has type forall a b. (a, b) -> (a, b) and is almost equivalent to the identity function, except it can be used to make programs terminate that might otherwise fall into a black hole. What is an example program that asPair rescues from nontermination? 'undefined' is a program that does not terminate. 'asPair undefined' is a program that terminates immediately (with a pair containing two nonterminating components). unfortunatelu in haskell you can tell the difference between those two: test (x,y) = True test undefind = undefined test (asPair undefined) = True it may be nice to have tuples unlifted in haskell (and in general datatypes with a single constructor). this could be introduced in the language by either changing the semantics of 'data' (prolly not too nice) or by generalizing 'newtype' (and perhaps renaming it to 'record') to handle more than one type. the semantics of such thing could be just like now except that pattern matching on them is always lazy (i.e.patterns have an implicit ~). then one could not tell the difference between `undefined' and (undefined,undefined). well i guess unless one used seq, but seq is also not very nice. bye iavor -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: lexer puzzle
Marcin 'Qrczak' Kowalczyk wrote: A... should be split into "A.." and "." I found a compromise: let's make it a lexing error! :-) At least that agrees with what some Haskell compilers implement. No current Haskell compiler/interpreter agrees with what the report seems to say, that is that "A..." should be lexed as the two tokens "A.." and ".", and similarly, "A.where" should be lexed as "A.wher" followed by "e". It seems that the source of the problem is the use of the (nonstandard) difference operator r1 in the specification of the lexical syntax in the Haskell report [1]. It was presumably fairly innocent and easy to understand originally, but I guess that nobody understood its consequences when qualified names were introduced. Anyway, this should teach us not to use homemade pseudo formal notation when defining a new language, but to stick to well-established, well-understood, tool-supported formalisms... For the Programatica Haskell front-end, I have now switched to a regular expression compiler that has direct support for the difference operator, so hopefully, our implementation agrees with what the report specifies. (This is not necessarily a good thing, though, since it makes our front-end different from all other Haskell implementations :-) For what it is worth, I tested "A...", "A.where" and "A.--" in the main Haskell implementations and in the Programatica Haskell front-end. The input was two modules A and B: 1 module A where 2 3 wher = id 4 e = id 1 module B where 2 import A 3 4 x = (A.where) 5 y = x Here is the result: GHC: B.hs:4: parse error on input `where' HBC: "B.hs", line 4, Bad qualified name on input: Hugs: ERROR "B.hs":4 - Undefined qualified variable "A.where" NHC98: Identifier A.where used at 4:6 is not defined. PFE: ok If line 4 in module B is replaced with x = (A...): GHC: B.hs:4: Variable not in scope: `A...' HBC: "B.hs", line 4, Bad qualified name on input: Hugs: ERROR "B.hs":4 - Undefined qualified variable "A..." NHC98: Identifier A... used at 4:6 is not defined. PFE: B.hs:4,13, before ): syntax error (A.. is lexed as A.. .) If line 4 in module B is replaced with x = (A.--) GHC: B.hs:4: Variable not in scope: `A.--' HBC: "B.hs", line 5, syntax error on input:= (treats -- as the start of a comment) Hugs: ERROR "B.hs":4 - Undefined qualified variable "A.--" NHC98: Identifier A.-- used at 4:6 is not defined. PFE: B.hs:5,1, before : syntax error (A.-- is lexed as A.- -) I used the following versions GHC 6.0.1 HBC 0..5b Hugs 98 November 2002 NHC98 1.16 PFE 030912 -- Thomas H [1] http://www.haskell.org/onlinereport/syntax-iso.html ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: learning to love laziness
On Wed, 24 Sep 2003, Norman Ramsey wrote: > Consider the following Haskell function: > > > asPair x = (fst x, snd x) > > This function has type forall a b. (a, b) -> (a, b) > and is almost equivalent to the identity function, except it > can be used to make programs terminate that might otherwise fall > into a black hole. > What is an example program that asPair rescues from nontermination? Nathan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Library Infrastructure Proposal & Home Page
Followups to [EMAIL PROTECTED] please. Greetings, After many rounds of email and discussion, some wiki work, and discussion at the HIM, I've finally put together a proposal for the Library Infrastructure Project. I've inserted the introduction below. The draft proposal itself is available in a variety of formats. I've also started a web page for the project under the haskell.org site: http://www.haskell.org/libraryInfrastructure/ Please let me know if there's anything that needs to be added, if anything is confusing, etc. Comments and questions are welcome by email or on the [EMAIL PROTECTED] mailing list. peace, isaac ps. I expect to be moving a lot of stuff off of the wiki page since it is duplicated here. Library Infrastructure Project Proposal The Library Infrastructure Project is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. The Haskell Implementations[1] come included with a good set of standard libraries, but this set is constantly growing and is maintained centrally. This model does not scale up well, and as Haskell grows in acceptance, the quality and quantity of available libraries is becoming a major issue. There are a wide variety of Haskell Implementations (both compilers and interpreters), each of which target a variety of hardware architectures and operating systems. There are also a number of different groups and individuals providing libraries, and these libraries depend upon each other and they depend upon external systems such as Java or GTK. It can be very difficult for an end user to manage these dependencies and build all the necessary software at the correct version numbers on their platform: there is currently no generic build system to abstract away differences between Haskell Implementations and operating systems [2]. The Library Infrastructure Project seeks to provide some relief to this situation by building tools to assist developers, end users, and operating system distributers. This is a draft proposal. If you have comments, please email Isaac Jones. The latest version of this document should be available in a variety of formats from the Library Infrastructure Project home page. _ Table of Contents 1. High-Level Overview 2. Issues Facing Developers 2.1. Issues Facing Packagers 2.2. Why We Should Solve This 3. A Solution for Haskell in Haskell 3.1. The Module Design 3.2. But Why Should We Use Haskell? 3.3. Setup.lhs Command-Line Interface 3.4. An Example Setup.lhs Script 4. Distribution Module 4.1. Distribution.Build 4.2. Distribution.Install 4.3. Distribution.Package 4.3.1. PackageConfig Data Structure 4.4. haskell-config Command-line interface 4.5. haskell-pkg? 4.6. Distribution.Config 5. Use Cases 6. Means of Distribution and Layered Tools 7. Development Plan A. Related Systems A.1. Debian A.2. Python Distutils A.3. CPAN and Boost A.4. FreeBSD's Ports System A.5. The XEmacs Packaging System A.6. Make-Based Systems A.7. hmake 1. High-Level Overview On a high level, we say that we want the system to help the user to install packages (whether they be libraries or applications) and their dependencies. To accomplish this, we propose a system similar to Python's Distutils (Section A.2) where each Haskell tool is distributed with a script (Section 3.4) which has a standard command-line interface. This script will provide a familiar user interface (Section 3.3) for compiling, installing, and removing packages and their dependencies. For instance, to install the HUnit package, the user might download the source code from the web site, change into the HUnit directory, and type ./Setup.lhs install default, which would build and install the HUnit package for the default compiler. Similarly, he might type ./Setup.lhs install nhc to install the package for NHC. Other tasks might be necessary to make the package known to the system, such as registering it with the Haskell Implementation of interest (Section 4.3). Such tasks would also be performed by this Setup program. FULL TEXT AT: http://www.haskell.org/libraryInfrastructure/proposal/index.html ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
learning to love laziness
Consider the following Haskell function: > asPair x = (fst x, snd x) This function has type forall a b. (a, b) -> (a, b) and is almost equivalent to the identity function, except it can be used to make programs terminate that might otherwise fall into a black hole. My students are extremely mystified by such functions---and I can hardly blame them! Is there a good place to read about programming with lazy evaluation that will cover such functions and when to use them? Norman ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Beautifying Haskell programs (was: Re: pretty newby )
Am Mittwoch, 24. September 2003, 18:01 schrieb Keith Wansbrough: > [...] > And your other point, Luc, about generating type signatures automatically, > shows up something about your approach to debugging code. You should always > put the type signatures in as you go - preferably, before you write the > function! This is not just good design practice and good documentation, it > helps you debug the function. With type signatures, the compiler can see > what you intended to write, and verify that what you did write matches it. > Without type signatures, all it can see is that two things don't match - it > has no idea what you meant to type. Try it: try putting in type signatures, > and see how much better the compiler's error messages become. Let me add that there are situations where you don't want the most general type (which is yielded by type inference) as the type of a specific variable (which can be a function, of course). One reason might be that the most general type doesn't fit your idea about what the variable (function) shall describe. You could, for example, describe mappings from keys to values as lists of key value pairs. An empty mapping would be implemented as []. The type of this would be infered as [a] but what you want is [(a,b)]. Another reason for giving a type signature with a restricted type is that you want to enforce certain constraints by the type system. A good example is Peter Thiemanns handling of HTML documents in his WASH/CGI software. Note also that the asTypeOf function from the prelude is essentially the const function; the only difference is the type. It's the restricted type of asTypeOf that lets this function fulfill its purpose. > Hope this helps.. > > --KW 8-) Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Beautifying Haskell programs
hello, i also like pretty for simple pretty priniting tasks, but i think it is a bit low level. for example, the cominators could be parameterised by a monad, so that one can have different printing styles, and also deal nicely with precedences. one can build that functionality on top of the library pretty and this was done for the pretty printing component of the programatica project mentioned in one of the other posts. bye iavor Keith Wansbrough wrote: John Huges wrote: On Wed, 24 Sep 2003, Luc Taesch wrote: alos, Im surprised that this bland issue has not already been solved (PP lib paper looks dated 96). no offence intended, but aas im newbie, i [..] As the author of the 96 paper (wasn't it 95?), let me defend it a bit, or at least explain what it offers, and what it does not. I think the reason it "looks dated" is that it pretty much solved the problem it was addressing. For pretty-printing data structures, the solution given in that paper does a rather good job, is configurable in the ways you might want to configure it, and is fairly easy to use and understand. No one has needed to invent a new way of doing it since. Regarding beautifying Haskell programs: as John says, it's not straightforward. But I think the reason that there isn't such a thing is that most people don't need it. We mostly use editors that allow us to get the indentation right, automatically, as we type the source in, and we take care to preserve it as we edit, because it makes the code easier to understand. (note that there *are* tools for producing beautified documentation: Haddock lists exports, type definitions, type signatures, and argument and function documentation in HTML format, but it doesn't deal with actual code). And your other point, Luc, about generating type signatures automatically, shows up something about your approach to debugging code. You should always put the type signatures in as you go - preferably, before you write the function! This is not just good design practice and good documentation, it helps you debug the function. With type signatures, the compiler can see what you intended to write, and verify that what you did write matches it. Without type signatures, all it can see is that two things don't match - it has no idea what you meant to type. Try it: try putting in type signatures, and see how much better the compiler's error messages become. Hope this helps.. --KW 8-) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: pretty newby
John Hughes <[EMAIL PROTECTED]> writes: > The problem is that parsers in compilers don't keep track of comments. > Instead they discard them at the first opportunity (during lexing). > ... What's needed is a parser that can parse > comments, and tie them to the *right place* in the abstract syntax tree. Fortunately, there *is* one Haskell parser already which preserves comments in the source code and links them properly to the surrounding program structure, namely Haddock, the automatic-documentation generator. I expect Haddock would be a good place to start if one wanted to develop a program re-formatter. (Furthermore, if one were to add a type inference engine that could fill-in missing type signatures in a program, that would be highly useful for both Haddock and the hypothetical re-formatter.) Regards, Malcolm ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Beautifying Haskell programs (was: Re: pretty newby )
John Huges wrote: > On Wed, 24 Sep 2003, Luc Taesch wrote: > > > alos, Im surprised that this bland issue has not already been solved (PP > > lib paper looks dated 96). no offence intended, but aas im newbie, i [..] > > As the author of the 96 paper (wasn't it 95?), let me defend it a bit, or > at least explain what it offers, and what it does not. I think the reason it "looks dated" is that it pretty much solved the problem it was addressing. For pretty-printing data structures, the solution given in that paper does a rather good job, is configurable in the ways you might want to configure it, and is fairly easy to use and understand. No one has needed to invent a new way of doing it since. Regarding beautifying Haskell programs: as John says, it's not straightforward. But I think the reason that there isn't such a thing is that most people don't need it. We mostly use editors that allow us to get the indentation right, automatically, as we type the source in, and we take care to preserve it as we edit, because it makes the code easier to understand. (note that there *are* tools for producing beautified documentation: Haddock lists exports, type definitions, type signatures, and argument and function documentation in HTML format, but it doesn't deal with actual code). And your other point, Luc, about generating type signatures automatically, shows up something about your approach to debugging code. You should always put the type signatures in as you go - preferably, before you write the function! This is not just good design practice and good documentation, it helps you debug the function. With type signatures, the compiler can see what you intended to write, and verify that what you did write matches it. Without type signatures, all it can see is that two things don't match - it has no idea what you meant to type. Try it: try putting in type signatures, and see how much better the compiler's error messages become. Hope this helps.. --KW 8-) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: pretty newby
On woensdag, sep 24, 2003, at 17:46 Europe/Amsterdam, John Hughes wrote: What's needed is a parser that can parse comments, and tie them to the *right place* in the abstract syntax tree. Figuring out what a comment is really commenting is probably extremely hard... The commenting conventions of Haddock serve this purpose pretty well. And Haddock's parser must hold onto the comments to do its job. Maybe that's a good place to start on a Haskell pretty-printer. Regards, Frank ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: pretty newby
On Wed, 24 Sep 2003, Luc Taesch wrote: > alos, Im surprised that this bland issue has not already been solved (PP > lib paper looks dated 96). no offence intended, but aas im newbie, i > wonder what am i missing ? what is different in the process of creation > so that this need did not arised already? i should admint i'm puzzled, > given the facilities at hand... As the author of the 96 paper (wasn't it 95?), let me defend it a bit, or at least explain what it offers, and what it does not. The problem I was solving in that was paper was how to pretty-print *data-structures* from inside a program. That includes abstract syntax trees in compilers -- in fact, that's maybe the most important application. The library is used in GHC, for example, to pretty-print programs at various stages, after varying degrees of transformation. You the user can see what the compiler has produced after each phase, and you see it laid out in a readable format. Pretty-printing data-structures is quite different from pretty-printing *programs* -- we should have two different words for it, really! When you pretty-print a program, you just want to change the layout in an existing text, and comments etc. ought to be preserved and appear in sensible places afterwards. When we pretty-print programs, there is an input (the program as you wrote it) to take into account. When you pretty-print a data-structure, you're just trying to output something produced by a program... there is no "input" it was produced from which the pretty-printed output ought to resemble. So, if you want to see what GHC has produced after phase X, then the pretty-printing library is appropriate. Of course, if there were comments in the program you wrote, then you ought to realise the compiler discarded them early, and you should not expect them to appear in the result of various transformations/optimisations. But if you want to standardise the layout of a program you wrote, then this is no good. The pretty-printing library is not sufficient to do this by itself... it solves a different problem. It is possible to BUILD a program pretty-printer using the library (although this is not the only possible approach), but it requires combining the library with a parser which loses no information, in particular including comments at the appropriate places in abstract syntax trees, so that they are a part of the data structure being pretty-printed. The problem is that parsers in compilers don't keep track of comments... instead they discard them at the first opportunity (during lexing). Thus such a parser, combined with a pretty-printer, cannot solve the *program pretty-printing* problem. What's needed is a parser that can parse comments, and tie them to the *right place* in the abstract syntax tree. Figuring out what a comment is really commenting is probably extremely hard... But without an AST with attached comments in the right places, my pretty-printing library, and Simon PJ's extension, are useless. That said, maybe it is surprising that no good Haskell pretty-printer has appeared yet, especially given the importance of layout in the language. Why not write one? I dare say there would be many users, and no doubt you could publish a paper at the Haskell Workshop... John Hughes ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: From enumerators to cursors: turning the left fold inside out
Hi Oleg, Just thought I'd mention that this is, in fact, my preferred method of iterating over a file. It alleviates the pain associated with lazy file IO, and simultaneously provides a useful abstraction. I actually have 3*2 functions that I use which look like: > type Iteratee iter seed = seed -> iter -> Either seed seed > hFoldChars :: FilePath -> Iteratee Char seed -> seed -> IO seed > hFoldLines :: FilePath -> Iteratee String seed -> seed -> IO seed > hFoldWords :: FilePath -> Iteratee [String] seed -> seed -> IO seed > type IterateeM iter seed = seed -> iter -> IO (Either seed seed) > hFoldCharsM :: FilePath -> IterateeM Char seed -> seed -> IO seed > hFoldLinesM :: FilePath -> IterateeM String seed -> seed -> IO seed > hFoldWordsM :: FilePath -> IterateeM [String] seed -> seed -> IO seed Which perform as expected (hFoldWords(M) can be written in terms of hFoldLinesM, but I find I use it sufficiently frequently to warrent having it stand out). Also, of course, the only ones actually implemented are the (M) variants; the non-M variants just throw a return into the Iteratee. - Hal > > hfold_left:: FileName -> Title > > -> Iteratee seed > > -> seed -- the initial seed > > -> IO seed > > type FileName = String > > type Title = String -- just an identifying string for debug printing > > type Iteratee seed = seed -> Char -> Either seed seed -- Hal Daume III | [EMAIL PROTECTED] "Arrest this man, he talks in maths." | www.isi.edu/~hdaume ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Haskell front ends, was pretty newby
Hi all, I'm not sure I'll answer the question properly, but I think it raises an interesting issue, regarding the state of Haskell front ends. > What I had in mind what to pp my own programs, > to clean the source layout, rather. > so the two gain i was expecting were : > - cleaning the layout, after i removed all the debugging code > - generating the type > alos, Im surprised that this bland issue has not already been > solved (PP lib paper looks dated 96). no offence intended, but > aas im newbie, i wonder what am i missing ? what is different in > the process of creation so that this need did not arised already? > i should admint i'm puzzled, given the facilities at hand... Is this what you are after? A tool to read in Haskell source, and then print it out (to file or screen) in a pretty printed manner. It should retain comments from the source. And possibly add type annotations. Such a tool would be very nice indeed. Though I do not think such a thing exists at the moment. Why not? Good question. One thing that Haskell is really lacking (IMO) is a common front end. Something that can lex, parse, type check ... do all the things that a compiler or interpreter would do before it starts to generate code. Such a thing would be great for many people. It would help define the language. It would help implementors and researchers. It would probably even serve as a good source of example Haskell code for those looking to study the language. And, importantly, it would enable Haskell specific editors, refactorers, pretty printers and so on. Some work has been done towards this, including the hsparser library and supporting material that comes with GHC these days. I have been a very happy client of that parser for a long time now (sorry about the pun). At the recent Haskell workshop I saw a presentation about the nice tools that the Programatica group are working on. This seems to include most of the front end of a Haskell system. http://www.cse.ogi.edu/PacSoft/projects/programatica/ It appears that binary forms of their programs are available: http://www.cse.ogi.edu/~hallgren/Programatica/download/ Alas, I could not find a source distribution and I'm not sure if one exists. One problem I see is that it is hard to justify the large amount of work that is required to implement such a thing when it might not be regarded as research worthy. Though, in the long run I think the research community is being held back because we must continually re-implement the front end of Haskell, and often we only get part way through it before we run out of steam (see Hatchet for example, I'm a guilty party...). We owe it to ourselves to implement a front end. Though I fully appreciate the difficulty of the task, and I'm not putting my hand up to do it at the moment (grumble, thesis writing, grumble). Perhaps there are some keen Haskell hackers out there who are itching for a nice project? And by the way, I don't want to sound like I'm complaining too much, because, as I said, I've been using the hsparser and pretty printer extensively, and I failed to finish Hatchet. Cheers, Bernie. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: pretty newby
Thanks. i understand that a2ps is rather for printing. What I had in mind what to pp my own programs, to clean the source layout, rather. The process i used in other context is to hack , without really taking care of the layout ( say getting distracted by) , and once i got a resonalble level of stability, i cleaned the program, using a pp; ideally in haskell, this would add the typing for me, also. ( still havent made my religion if that's cool to have the typing on top of the definition, or not, but at least for doc generation purpose, that's good.) feedback on that ? so the two gain i was expecting were : - cleaning the layout, after i removed all the debugging code - generating the type but i understood from Per from that the parser would not take care of the comments. ( not take care, or remove , btw ?). alos, Im surprised that this bland issue has not already been solved (PP lib paper looks dated 96). no offence intended, but aas im newbie, i wonder what am i missing ? what is different in the process of creation so that this need did not arised already? i should admint i'm puzzled, given the facilities at hand... > Alle 16:05, martedì 23 settembre 2003, Luc Taesch ha scritto: > > are there any facility to pretty print an haskell program ? > > If what you need is an external program and not a library, have a look > at GNU a2ps. > > Vincenzo > > ___ > Haskell mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
